Bug 477032 – RFE: LINGUAS fallbacks

• Product: Gentoo Hosted Projects
• Status: RESOLVED OBSOLETE

[Description kavol 2013-07-16 09:40:15 UTC]

I've set LINGUAS="cs"
Recently, I wanted to install vym, and I have noticed that it does not install Czech locales despite these are available.
The problem is that vym expects "cs_CZ" so it does not match just simple "cs". But there is no other "cs_something", no point in insisting that "cs_CZ" is something else than "cs".

This can be worked around by simply adding "cs_CZ" into LINGUAS, but to me it seems less than optimal. I'd prefer some AI here which could decide that if I have specified some generic language code that I want the specific language that falls into this category installed.

Czech is not a good example, let's try with German, as per http://wiki.gentoo.org/wiki/Localization#USE_flag

There is:
de - German locale
de_DE - German locale for Germany
de_FR - German locale for France

1) Let's say that I want "de_DE" so I put it into LINGUAS.
As long as the ebuild provides "de_DE", everything is fine.
But what if it provides just "de"? - I'd like to see AI that sees no de_DE is available, but as "de_DE" belongs under more generic "de" category, let's use "de".
If the ebuild procides "de_FR", don't install it, as I've specified "de_DE" strictly, not the generic "de" (see the next bullet).

2) Let's say that I want any German locale. So I put "de" into LINGUAS.
As long as the ebuild provides "de", everything is fine.
But what if it provides just "de_DE"? - I'd like to see AI that knows "de_DE" is one of "de" variants, so it installs it. The same for "de_FR".
And if the ebuild has both de_DE and de_FR, let's either install both or the default (which would have to be specified somewhere, like de_DE is preferred, en_US is preffered, and so on).

3) Let's say that I prefer "de_DE" but I can read also other "de_X" variants, so I put "de" and "de_DE" into LINGUAS. The AI looks for exact "de_DE" match. If found, let's install the exact match. If not found. let's fall back to the generic "de" group and behave just like in 2), install the next available "de_X" variant from the "de" group.

Reproducible: Always

[Comment 1 kavol 2013-07-16 09:41:41 UTC]

"If the ebuild procides" => "If the ebuild includes" ... interesting typo :-)

[Comment 2 Jeroen Roovers (RETIRED) 2013-07-16 13:03:39 UTC]

One fundamental problem is that there are too many different build systems. I happen to maintain various packages which require different solutions.

Yet besides the source packages' build systems, there are several ways to implement LINGUAS support in ebuilds:

1) The dynamic approach is to use eutils.eclass' strip-linguas function (or some other function specific to the source package) to find supported locales during src_prepare(), so that you do not need to add a static list of supported locales to IUSE. This helps maintainers greatly because now they do not need to check every new source package for changed locale support (additions, removals, renamings), but one detrimental side effect is that this stops us from exposing the supported locales to the emerge user (LINGUAS=...).

2) The static approach means that the package maintainer checks what locales are supported and lists them in IUSE, which makes LINGUAS a static list that /can/ be exposed to the emerge user, so that the emerge user knows beforehand what locales he can expect the package to support and can make configuration changes before emerging it.[1]

It isn't obvious which of these approaches to locale support in ebuilds is better, and obviously we cannot expect every upstream to deploy one generic approach to listing and storing locale files in their releases. So we can't do this at the ebuild level.

Best-matching of preferred linguas should thus be executed by the package manager. The LINGUAS variable simply holds a bunch of USE flags, and adding wildcards to USE variables is likely going to be more trouble than it's worth, so now the package manager will need to do a LINGUAS calculation (LINGUAS becoming an extra special case of a USE_EXPAND variable).

Package managers would end up needing to expand LINGUAS="de*" or indeed take LINGUAS="de" to actually mean "de_*".



[1] In some packages I implement a function that die()s when the locales in the sources do not match the locales listed in LINGUAS. This approach has its own problems.
[2] http://www.gentoo.org/proj/en/qa/pms.xml

[Comment 3 Ulrich Müller 2018-08-08 14:36:27 UTC]

LINGUAS is just a normal variable nowadays and no longer USE-expanded. Closing.