© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
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-
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:/
>> I guess for the actual implementation in l-s and gdm we don't need
>> to parse /usr/share/
>> 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/
>>>
>>> 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/
/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:/