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

Wed Dec 1 21:39:29 GMT 2010

For the record, below please find Martin Pitts comments on a superseded
(and deleted) merge proposal, followed by my reply.

--------------------------------
Martin Pitt wrote on 2010-11-24:
--------------------------------
Hello Gunnar,

many thanks for working on this! Some comments:

- in the beginning of writeUserLanguageSetting() you moved the first
line of code above the function's docstring, please revert.

- Thanks for moving the _update_gdm_dmrc() from the "system.." to the
"user.." configuration writing, nice catch.

- the stuff that data/gdm-lang-unset.sh and data/language-environment.sh
are doing, can we please intregrate this into language-selector itself
instead of inflicting it on every login? I don't think we need to try
too hard to fix the variables on upgrades. There's too much that can go
wrong, and it'll lead to unintended changes for some people. I think we
should update the system and ~/.dmrc and ~/.profile variables in
language-selector only, when you run it and change your configuration.

Thank you!

-----------------------------------------
Gunnar Hjalmarsson replied on 2010-11-24:
-----------------------------------------
I moved the first line of code because there are now two docstrings in writeUserLanguageSetting(), explaining one section each, and the conffiles variable is used in both sections. Do you still want me to revert?

Actually, _update_gdm_dmrc() was moved from writeUserLangSetting().
Diffs may play a trick on you sometimes. :)

data/gdm-lang-unset.sh makes it possible to by-pass the LANG="$GDM_LANG"
line in Xsession, and as far as I can tell, it has to be done at each
login in order to keep LANG separated from the translation language.

I understand that you are anxious to avoid that expensive code is run
unnecessarily at login, and I share that view. I think that my first
Xsession suggestion(s) included such unnecessary code, and that was
stupid. However, in data/language-environment.sh there is the
language_update() function which holds the possibly expensive stuff, and
that function is only called if the user changes the language from the
greeter; otherwise only the variable checks at the bottom are done. In
other words I would say that my suggestion does not include any
expensive code that would be run at each login.

For the case the user does change the language from the greeter, OTOH, I
can't see how we could avoid doing something at login. Setting LANGUAGE
and LC_MESSAGES to new values is reasonably necessary. Then why do I
suggest that ~/.profile is updated as well? Right now I come to think of
two reasons:

1. Efficiency. If ~/.profile was not updated, ~/.dmrc would not
correspond with ~/.profile, and if the user does not go to "Language
Support" and redo the language switch (and why would s/he find such a
measure to make sense?), it would mean that data/language-environment.sh
would need to set LANGUAGE and LC_MESSAGES at each login. In other
words, in the long run it's more efficient to have data/language-
environment.sh update ~/.profile as well.

2. Avoid confusion. A user, who checks the contents of ~/.profile, would
find that the LANGUAGE and LC_MESSAGES lines would not correspond with
the LANGUAGE and LC_MESSAGES environment variables.

The only thing I suggest with a bearing on upgrades is the stuff in the
debian/language-selector.postinst file which sets LC_MESSAGES out from
LANGUAGE. While I believe that the result of it would be that for some
users Ubuntu would start doing The Right Thing instantly after upgrade
(or rather after next login after the upgrade...), I can't really see
which unintended changes you have in mind. But if your concerns in this
respect remain, the file can be dropped without any consequences for the
rest of the suggestions. Let me know.

** Patch added: "gdm_lp553162.debdiff"
   https://bugs.launchpad.net/ubuntu/+source/language-selector/+bug/553162/+attachment/1752037/+files/gdm_lp553162.debdiff

-- 
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 GDM: The Gnome Display Manager: New
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