Hi all, a few comments for clarification:
On 11/30/2010 08:12 PM, Gunnar Hjalmarsson wrote: > Hmm.. If I recall it correctly, we agreed a few weeks ago to > conceptually convert GDM's locale selector to a pure language picker, in > order to make it play well with the language tab in language-selector. > It should be noted that language-selector's language tab is not designed > to set LC_MESSAGES, but to build LANGUAGE lists. The language tab > menu includes both ll_CC combinations and pure ll options, and that's > the kind of values that has been passed to the dmrc Language field (and > with that $GDM_LANG) in all the variants I have uploaded the past few > weeks. Even if a .utf8 extension is appended, no testing of whether the > resulting string represents a valid locale is done, AFAIK. > > To get a string that equals the name of a valid locale, and hence can be > assigned LC_MESSAGES, language-selector uses similar code with locale -a > etc. as you have noted in the language_update() function. Typically an > ll_CC combination plus .utf8 makes up the name of a valid locale, while > you need to have the program pick an arbitrary country code in the case > of a pure ll option. > > The dmrc Language field and GDM_LANG serve the purposes of > * determining the pre-selected option in GDM's language picker, and > * holding the new value if another language is picked from the greeter. > > For the above reasons, LC_MESSAGES should not be assigned the GDM_LANG > value just like that. > > So, why doesn't language-selector pass the same string to dmrc as it > does to LC_MESSAGES? My reason for not wanting to do it that way is that > it would result in incorrect pre-selected options in GDM's language > picker. For instance, if you would drag "Deutch" to the top of the menu > in language-selector's language tab, you would see "German (Austria)" as > the pre-selected option at next login. Certainly not a disastrous bug, > but significant enough IMO to not introduce intentionally. > > In other words, I suggest that we start using dmrc's Language field and > $GDM_LANG in a way that differs from the original intention, but only > for Ubuntu users with language-selector. As you pointed out above, we > would make GDM behave differently when the new language-selector version > is installed compared to when it's not, and that ought to take care of > the risks for backwards compatibility issues as well as issues with > other dms. The code in language-selector is a bit hackish and unprofessional, since Iʼm not an experience programmer or python coder and this whole thing more or less got dumped on me and I was under pressure to deliver features in time for the Ubuntu release. :( The reason *why* I implemented this feature was, because of the inability of Gnome to let the user choose a different locale setting from his desktop language. Something, that KDE for example has had for a long time already. Now for the locale handling code in language-selector: There are currently no checks done if a generated locale code is "valid" according to /usr/share/i18n/SUPPORTED. Instead, the code just appends ".utf8" to any existing ll_CC combination on the system, just because it works. For example, according to /usr/share/i18n/SUPPORTED, "en_IN" is listed there and therefor "valid", while an explicit "en_IN.utf8" is not. However, since some applications are "buggy" in that they "require" the encoding to be specified in the locale code, and appending ".utf8" by default "just works", I figured itʼs probably safe to omit this check. Well, Colin Watson recently pointed out to me in another bug report, that those buggy applications should get fixed instead and l-s should actually do the check and that there should be exiting functions in the locale handling libraries which do this check already. Regarding the language list for the LANGUAGE variable: Traditionally, localized software relied on the locale code to specify which language the software should use to interact with the user. Translations for languages which had some variations according to the county code therefor were duplicated (e.g. de_DE, de_CH and de_AT were largely the same, except for the small amount of different strings). The ability to "fall back" to a different language when translations are not present for the first one, and the ability to define this fall back list (the LANGUAGE variable), is an extension to gettext. Non-gettext applications, like cross platform applications (e.g. Mozilla, OpenOffice.org), donʼt have this functionality and therefor still rely on LANG or LC_MESSAGES to be set correctly. This gettext extension triggered a change in how gettext using applications got translated: in order to minimize the skew between language variations, translators decided to use a single language code as the default language and only put the diffs into country specific locales (e.g. use "de" as default, and the diffs go into "de_CH" and "de_AT" respectively). Launchpad also emphasizes on this, so translators donʼt see "de_DE" anymore, but only "de". However, not all applications use this scheme, some still ship their translations as "de_DE" instead of "de". Therefor it is certainly possible for a user to select just "de" in his LANGUAGE variable, but the effect would be, that he wonʼt see those translations, which only come as "de_DE". So, using "de" as the first language code in the LANGUAGE variable is indeed not desired, "de" should only be used as a fall back to a country specific "de_*" language codes. This check has not been implemented yet in language-selector, since I didn't have the time and knowledge how to do this in time for the Lucid release. It was planned for Maverick, but got bumped off the schedule again, since Canonical decided to not employ me any longer. Since then I need to earn my food by other means and don't have time for Ubuntu anymore. >>> I'd like to raise a couple of Kubuntu related questions. >> >> I'm afraid I don't know anything about the KDE bits; it's worth >> speaking to the kubuntu-dev folks about it. However, I think as a >> first step we should make these changes to /etc/gdm/Xsession first and >> see how it goes out in the field. Then we can see how to apply these >> to kdm and whether there's something to factor out. WDYT? > > I brought it up now since Kubuntu is also using language-selector, and > there is a separate Kubuntu binary. KDE has it's own means to handle the desktop language separate from the system locale, and therefor the QT version on language-selector does not include this functionality. The QT version of l-s is embedded in the regular KDE language handling interface, so duplicating this functionality would be counter-productive. The functionality in l-s was implemented to mimic the behavior for KDE for gnome. However, KDE uses a slightly different approach, AFAIK. IIRC, instead of manipulating the LANG, LANGUAGE and LC_ environment variables directly, KDE creates a layer in between the system variables and the applications where the language settings are handled and stored in the KDE registry. But I may be wrong about this. Thanks for taking over the language-selector development, btw. ;) Cheers Arne -- Arne Götje (高盛華) <a...@linux.org.tw> PGP/GnuPG key: 1024D/685D1E8C Fingerprint: 2056 F6B7 DEA8 B478 311F 1C34 6E9F D06E 685D 1E8C Key available at wwwkeys.pgp.net. Encrypted e-mail preferred. -- Set $LANGUAGE if the user picks a different locale in gdm, so that language-selector and gdm stop disagreeing https://bugs.launchpad.net/bugs/553162 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
