Ühel kenal päeval, L, 21.05.2016 kell 11:19, kirjutas waltd...@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