Ühel kenal päeval, T, 07.06.2016 kell 20:28, kirjutas Michał Górny: > > So here's how I would word it. I think if we combine a few different > texts, we may end up with something good ;-). > > --- > The LINGUAS USE flag group has been renamed to L10N, in order to > avoid > a conceptual clash between the Gentoo use of the name, and a standard > environment variable used by multiple gettext-based packages.
Where "multiple" is pretty much the whole tree of autoconf based packages (and probably cmake too?). Pretty much anything that has a translation :) > Therefore, > from now on filtering localizations is supported on three independent > levels: L10N, LINGUAS and INSTALL_MASK. > > The L10N flags affect built and installed localizations of the > packages > listing those flags explicitly. They are fully controlled by > the package manager, and their values are defined globally. They do > not > affect the packages not listing them explicitly. > > The LINGUAS variable is now verbosely passed through to the build > system. If we have a transition phase for the USE_EXPAND, where we'll have both for a while, then this is not strictly true immediately. It also means we can't roll out your portage changes to stop the special casing before we are finished with the transition and LINGUAS is removed from the USE_EXPAND set. > It controls the localizations built and installed by packages > that use it, and that do not override it using L10N flags. Packages should not be exporting some LINGUAS values based on L10N USE_EXPAND anyways in my opinion; I'd make such approach a QA violation maybe even, though we have some odd cases in a very limited set of packages, iirc. > Note that > due to the design, the localization stripping is done implicitly > and the package manager can not determine which localizations were > actually provided. > Additionally, the INSTALL_MASK improvements available in Portage > 2.3.0 > make it possible to filter localizations at package merge stage. In > this > case, the filtering is done on installed directories transparently, > and the build process and binary packages are not affected. So I take it that these install_mask groups are in for upcoming 2.3.0. Before that, you can still do it though, just need to list paths manually yourself. Info on what groups are pre-shipped or whatnot would have to be on the wiki page then, I suppose. > If you were using LINGUAS before, you most likely want to replace it > with L10N. If you need to strip localizations more (e.g. for embedded > systems), you may also want to set LINGUAS and/or INSTALL_MASK. > However, if you intend to provide or use binary package, you will > most I don't like this shunning of LINGUAS feature and shunning to some sort of embedded systems use case still. Most of us build systems used by only ourselves, I believe, and there is nothing wrong in getting a gettext feature applied for free, which reduces translation lines in .desktop, .schema and other files, and reduces the runtime mmap caches of those with it for free. It being clear in the appropriate place that this is a build time thing and whatnot is of course quite fine. If we go with BCP47, then users will want to revise their values based on the available options in the new l10n.desc I suppose. > likely want to leave L10N and LINGUAS unset in order to build most > portable binary packages, and use INSTALL_MASK to transparently strip > installed localizations on the hosts using them. L10N unset would mean no language packs at all, unless we have a wide default set in base profile. So unless we set a default set of all of them in profile, this would mean opposite behavior for L10N and LINGUAS when unset. > For more information, please see: > https://wiki.gentoo.org/wiki/Localization/Guide > --- > > Of course, we'd need to update the guide to explain all three layers > in detail. This was just my random set of thoughts, so Ulrich knows them while writing a new version of the news item tomorrow ;) Mart
