[Bug 553162] Re: Set $LANGUAGE if the user picks a different locale in gdm, so that language-selector and gdm stop disagreeing

[Gunnar Hjalmarsson]

@ David
Thanks for your praising comment.

It seems to me that you, and possibly also Martin, assume that $LANG
ought to correspond to the first language in the $LANGUAGE list. That, I
believe, is a misconception, at least from a language-selector
perspective, and I fear that we have talked at cross-purposes so far.

In an attempt to help changing that, I wrote a wiki-page:
https://wiki.ubuntu.com/GdmLanguageSelectorDissonance

It summarizes my view on where we stand, where we want to go ("Desired
behavior"), and my proposed solution in English. It would be great if
you, Martin and anybody else with an interest in this issue could study
the page and add your possible objections and comments.

Basically, what I hope to convince you about is that since it's only language that the users can set from GDM, and not any other locale aspects, GDM should not do anything with the $LANG variable. Not at any point. Never.
Instead GDM should update $LANGUAGE and set $LC_MESSAGES. That appears to be sufficient to reliably control which language is used in menus and messages. $LANG is used for the non-translation locale aspects, and its value shall not be used as a fall back by programs that don't understand $LANGUAGE.

As regards apps that don't understand $LANGUAGE:
> Rather than using a workaround, would it not be better to fix the
> bug in the affected applications? I see you've followed up on
> Firefox already. 

If I have understood it correctly, $LANGUAGE is a gettext specific
variable, and certain applications' inability to understand that
variable is not a bug per se. Consequently I think that Ubuntu in any
case shall provide the preferred translation language also via the
$LC_MESSAGES variable, and I don't think that's a workaround. Rather
should the Firefox fix I provide at bug 550222 be considered a
workaround IMO.

I noted that you don't consider this issue a matter for the translation
community. But it's a borderline case, isn't it? ;-)

-- 
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
Sponsors Team, which is a direct subscriber.

Status in Ubuntu Translations: Triaged
Status in “gdm” package in Ubuntu: In Progress
Status in “language-selector” package in Ubuntu: In Progress

Bug description:
Binary package hint: gdm

This is a follow-up to bug 407300, which has been fixed but a separate issue remains. I'm opening a separate task for language-selector, as it refers to the interaction between it and gdm.

The problem is basically that GDM seems to always override the LANG values set by language selector, and quite easily one can get to a situation where LANGUAGE and LANG differ and the desktop is a mixture of two languages.

Steps to reproduce (a):

 * New install, choosing Catalan in the installer
 * I log in without doing any changes to the language in GDM
 * I start System > Administration > Language support
 * I choose English there
 * I log out
 * I log back in without doing any changes in the GDM language chooser
 * My session is half English and half Catalan due to LANGUAGE=en and LANG=ca_ES.utf8 (Firefox in Catalan, gnome-panel in English, gnome-menus in Catalan).

Steps to reproduce (b):

 * Perform a full installation in English, as per http://testcases.qa.ubuntu.com/Install/NonEnglishLanguage#Installation%20Full%20Network%20Support
 * Go to System > Administration > Language Support
 * Install the Traditional Chinese language
 * Bring Traditional Chinese to the top of the list to become the main desktop language
 * Press the "Apply System-wide..." button
 * Reboot
 * When entering the session, you'll notice the desktop half translated in English, half in Chinese. The most noticeable parts shown in English are all the menus and Firefox. These applications seem to ignore the LANGUAGE variable
 * Running 'locale' on the terminal shows that LANG=en_US.UTF-8 and LANGUAGE=zh_K:en_US:en

I understand that this might be a problem in each application, as they should give LANGUAGE preference. Rather than filing a bug in each app right now, would it not make more sense to ensure that at least the first locale in LANGUAGE, the one in LANG and LC_MESSAGES are the same? (assuming it is possible to do such a thing, of course).

Also see the related bug 552664