On Fri, 27 May 2016 10:17:20 +0300
Mart Raudsepp <leio@gentoo.org> wrote:

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

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/>