Re: [gentoo-dev] [RFC] How to deal with LINGUAS mess?

[Mart Raudsepp]

Ühel kenal päeval, L, 21.05.2016 kell 11:19, kirjutas
waltdnes@××××××××.org:
> On Sat, May 21, 2016 at 09:41:28AM +0200, Micha?? Górny wrote
> > 3. We remove LINGUAS from USE_EXPAND and stop using it. If ebuilds
> > have
> > a good reason to use flags for localization, we introduce a new,
> > non-colliding USE_EXPAND for that. We also ask users to replace
> > LINGUAS
> > with the new flag in their make.conf files. LINGUAS gets the
> > original
> > upstream behavior back, and we eventually discourage it in favor of
> > new
> > INSTALL_MASK features (WiP) [2].

Short of making an exception to LINGUAS in the USE_EXPAND rules, I
think this is the only way.

> 5. An reversed variant of INSTALL_MASK in make.conf, e.g.
> LOCALE_ALLOW="foo bar fubar"
> 
> 6. Integrate localepurge into Portage, and run it post install
>
>   There are some lazy programmers out there who *DO NOT* respect the
> LINGUAS setting, and splatter files throughout /usr/share/locale/*
> and
> /usr/share/man/* regardless.  That's the reason "localepurge" was
> written in the first place.  Any proposed solution should take that
> problem into consideration, and handle it too.

For both of these cases, I have to point out that e.g
LINGUAS="en et pl"
does not mean "keep only /usr/share/locale/{en,et,pl}/*", it means have
support for only these languages. This means for example that *.desktop
files will have translations in them only for those language. Same for
dconf schema files. Same for many other things. MO Translation files
and manuals aren't the only thing here, especially with intltool (and
many of these intltool features are now part of gettext proper).
In short, LINGUAS affects the content of files too, not only the
existence of files. See any file in /usr/share/applications/ for
example.
I always put "en" as my first in LINGUAS, due to historical abuse of
the first value there, I think e.g mplayer or vlc used to do this.
LINGUAS is an unordered list, but some packages used to took the first
value as meaning the default and switch the UI to that by default,
instead of honoring LC_* variables. Another reason I put "en" there, is
because of IUSE_EXPAND and packages that might not be natively english,
but do have english translations (I think I've seen some french ones
like that :D)


And no, localepurge is not capable of stripping these translations out
of existing files. To my knowledge at least. Though it could be
improved to do so in some cases.


Mart