Thanks Martin and Arne for your valuable feedback! I agree that also /usr/share/locale should be taken into consideration, so I modified the l-s branch accordingly and wrote a new Perl script (lang-list2.pl). There is also GDM, and since I don't know C, I'm not able to make the equivalent changes to the C code - somebody else needs to do that, unless it can't wait till release 13.10 or something... To me it looks like it's gui/simple-greeter/gdm-languages.c that needs to be patched. One possibility, that would minimize the necessary changes to existing GDM files, is that I write a script, that takes a list of available locales as arguments and outputs the desired list of language options. Martin, I guess it's up to you. Even if Perl isn't an option, e.g. due to efficiency concerns, maybe a shell script? A few comments on your comments: On 2011-01-06 17:32, Arne Goetje wrote: > On 01/06/2011 07:55 PM, Martin Pitt wrote: >> > > What about /usr/share/locale/ ? That's at least where universe > software puts its translations. And there you may even find de_DE and > en_US folders... Therefor always put ll_CC codes first in the > LANGUAGE variable string, followed by the country-less fallback, i.e. > de_DE:de ! Is the country-less fallback in LANGUAGE really necessary? My tests indicate that gettext automatically goes to 'll' if it doesn't find a translation in 'll_CC'. Do you know of a reproducable use case that shows something else? (It should be noted that it doesn't work the other way around; see bug 700213.) This is what happens in the code I'm proposing: * If there are only translations under 'll' for a language, the list of language options only includes 'll'. Personally I find it neater to not unnecessarily include country specific items. * If there are translations under 'll_CC' for a language, the list of language options does not include 'll' (with the exception of 'en'). This is because of the gettext bug I mentioned. > There is code for this in l-s. I have seen makeEnvString() in LocaleInfo.py, which is used to generate a LANGUAGE list in the special case when l-s doesn't find a stored LANGUAGE value. For the above reason I do at least not find it motivated to extend the use of that function. Please feel free to prove me wrong. ;-) >>> * As regards languages with more than one translation: When the >>> country is not specified, does it matter which of the locales >>> that is assigned to the LC_MESSAGES environment variable? >> >> No, it doesn't for messages. It is relevant for $LANG and other >> LC_* categories, of course. Actually, in the l-s branch I still propose that we introduce the possibility to pick the main or origin country; at first hand because it feels better and may prevent user bewilderment, but also because it would have prevented this special case surprise: https://lists.ubuntu.com/archives/ubuntu-desktop/2010-December/002722.html >> I guess for the actual implementation in l-s and gdm we don't need >> to parse /usr/share/xml/iso-codes/, as these already have the >> translated names of the locales? Right, I was just playing around with the first test script; had no intension to propose that we upload that reinvented wheel. On 2011-01-07 12:03, Martin Pitt wrote: > Arne Goetje [2011-01-07 2:03 -0000]: >> On 01/07/2011 12:51 AM, Martin Pitt wrote: >>> Arne Goetje [2011-01-06 16:32 -0000]: >>>> What about /usr/share/locale/ ? >>> >>> Good point, thanks, I missed that. I think we should offer >>> >>> - all languages/locales from /usr/share/langpack-locale/ >>> >>> plus >>> >>> - the intersection of /usr/share/locale/ and `locale -a` >>> >>> Gunnar, how does that sound to you? That way we would add these items to the lists of language options, despite the fact that no corresponding locales are available: - en@boldquot - en@quot - en@shaw - en_US@piglatin So far I have assumed that that is not what you intended, so the latest Perl script generates the union of /usr/share/langpack-locale and /usr/share/locale as a first step, and then it determines the list of language options as the intersection of the just mentioned union and 'locale -a'. >> Just keep in mind that each time a universe package gets installed >> or removed, the list of available languages may change then. > > Right, that's the downside with this approach. It should only affect > some corner cases, as it'd be very unusual to not have any country > specific translations in the entirety of main, but one in a universe > package? Unusual or not, an example of it occurs on my box. I installed the CD burner GnomeBaker a couple of months ago, and it brought translations to 'de_DE', 'de_AT' and 'de_CH'. Hence the latest Perl script outputs those three German options instead of just 'de'. OTOH, is it really a downside? If I had been an Austrian, I might well have preferred Austrian German when available. I for one do not share the view expressed at https://blueprints.launchpad.net/language-selector/+spec/language-loader