I'd honestly as a minor issue like ot know why we called it linguas in the first place. Linguas itself is latin/romance based in name, so gentoo at least has been showing a bit of a bias.
Personally I think its a bad name on neutrality grounds alone. I think though I should also point out...don't we already have existing ebuilds that expose LINGUAS options in their USE flags? On Wed, Jun 1, 2016 at 7:17 AM, Michał Górny <mgo...@gentoo.org> wrote: > Dnia 1 czerwca 2016 16:03:40 CEST, Mart Raudsepp <l...@gentoo.org> > napisał(a): > >Ühel kenal päeval, K, 01.06.2016 kell 15:19, kirjutas Michał Górny: > >> As for LINGUAS, it should be left as a toy for advanced users and not > >> presented as a recommended solution. > > > >There is nothing advanced in it for the user, only the mess we have > >created with package manager behaviour and mis-use of it (the order > >matters case; which I believe is long eradicated). > >We are a source based distribution, and gettext/intltool upstream > >LINGUAS behaviour is perfect advantage for our main use case of > >customizing ones own system and almost always building things from > >source, only using binary packages before an upgrade as a backup, if at > >all. > >So it's natural to use the way that really build only the support you > >want. This is what LINGUAS gives you, when the PM doesn't happen to > >munge it. > > > >Hiding this away under some toy for advanced users is not in our spirit > >of Gentoo, as far as I would judge. > > You forget the important point that it's done silently and implicitly, > with no clear way of knowing which localizations were actually discarded > afterwards. > > And the fact that currently LINGUAS affects both packages listing the > flags and not doing so is causing even more confusion. > > > > >But this is a matter of documentation at this point, in principle I > >agree that SRC_URI extra downloads should be under a different naming. > > > >INSTALL_MASK groups for locales is what I would consider a convenience > >for binary package builders in a wide environment where language choice > >to the end user preferably gets filtered on deployment in a site- or > >machine-specific manner. Or a toy for advanced binary distribution > >creators, if you will. A way for binary packages to provide almost as > >good support for LINGUAS as source packages (but not quite). > >That said, supporting our binary package ecosystem is very important, > >and I applaud these efforts. The proposed INSTALL_MASK improvements are > >very useful for many other cases as well. For source-based users as > >well (openrc init scripts, systemd unit files, gtk-doc documentation, > >etc) > > > >Either way, the masterplan works out, I just don't think we need to > >wait for INSTALL_MASK groups here in any way. The reminder is a matter > >of documentation, a matter of perspective. > >This l10n.eclass PLOCALES nonsense needs to go ASAP. > > > > > >Mart > > > -- > Best regards, > Michał Górny (by phone) > >
