On Fri, 27 May 2016 10:17:20 +0300 Mart Raudsepp <[email protected]> wrote:
> Ühel kenal päeval, L, 21.05.2016 kell 11:19, kirjutas > [email protected]: > > 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. Just to be clear, I don't think we care that much about filtering those. I can understand people not wanting to install a dozen translation files because of their potential size, especially when filesystem can't handle small files efficiently. But stripping extra descriptions from .desktop files doesn't seem like a major use case. > 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. That's yet another reason not to extend the abuse of LINGUAS. I don't really see adding another rule to PMS that attempts to enforce this. > 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. Well, this is certainly something that can be done. -- Best regards, Michał Górny <http://dev.gentoo.org/~mgorny/>
pgph65TNXGmGn.pgp
Description: OpenPGP digital signature
