/etc/gdm/Xsession breaks LANGUAGE

[Johan Kiviniemi]

Binary package hint: gdm

/etc/gdm/Xsession contains:

  if [ -n "$LANGUAGE" ]; then
    if [ "$LANGUAGE" != "$LANG" ]; then
      LANGUAGE="$LANG"
    fi

LANGUAGE is not only an extension of LC_MESSAGES (not LANG), it doesn’t even have the same syntax as LANG.

My locale settings (whom /etc/gdm/Xsession breaks):

LANG=fi_FI.UTF-8
LC_MESSAGES=en_US.UTF-8
LC_NUMERIC=en_US.UTF-8
LANGUAGE=en_US:en

I.e. “use fi for stuff like month names, paper size and units, but en for the UI strings and decimal numbers”.

ProblemType: Bug
Architecture: i386
Date: Fri Jul 31 13:20:09 2009
DistroRelease: Ubuntu 9.10
NonfreeKernelModules: wl
Package: gdm 2.27.4-0ubuntu6
ProcVersionSignature: Ubuntu 2.6.31-4.23-generic-pae
SourcePackage: gdm
Uname: Linux 2.6.31-4-generic-pae i686

[Sebastien Bacher (seb128)]

I'm not sure to understand the logic behind this code, the upstream change seems to be due to https://bugzilla.gnome.org/show_bug.cgi?id=89970, not sure if LANGUAGE should be unset or forced to some value, if the value is not set by gdm the session might be using a different language than the one selected on the login screen

[Arne Goetje (arnegoetje)]

This bug breaks the new language-selector functionality, as gdm always overrides the user's language settings.

Expected behaviour:
 * scan ~/.profile for 'export LANG=' and 'export LANGUAGE=' entries and parse those.
 * LANG is the good old locale, e.g. "en_US.UTF-8"
 * LANGUAGE is a string of languages, e.g. "de_DE:de:en_GB:en". Parse the first item from that list and set the language combobox to that language.
 * if present, use LANG and LANGUAGE from ~/.profile for the session
 * fall back to system settings (LANG and LANGUAGE in /etc/default/locale and /etc/environment), if LANG and LANGUAGE are not present
 * if only LANG is present, but no LANGUAGE, generate one artificially for the session: en_US.UTF-8 -> en_US:en

[Martin Pitt (pitti)]

This seems way too complicated and error prone. How about

 * if $GDM_LANG == $LANG, don't touch anything
 * if $GDM_LANG != $LANG, unset $LANGUAGE

?

This should maintain the default case where you don't change your language in gdm, and if you do, it cleanly overwrites the system settings.

[Launchpad Janitor (janitor)]

This bug was fixed in the package gdm - 2.29.6-0ubuntu5

---------------
gdm (2.29.6-0ubuntu5) lucid; urgency=low

  * Add 18_locale_env_vars.patch: gdm does not have a facility to specify a
    list of languages for $LANGUAGE, so do not break $LANGUAGE by forcing it
    to $LANG (they have a completely different syntax, and different
    meanings). Also, if the system sets $LC_ALL (which distros should never
    ever do), we should not clobber this. $LINGUAS is not a runtime
    environment variable for locales, so just drop this. (LP: #407300)
 -- Martin Pitt <email address hidden> Thu, 04 Mar 2010 12:55:59 +0100

[David Planella (dpm)]

While the patch fixes the issue where Xsession was writing a LANGUAGE variable with incorrect syntax, now we've got a situation where:

• GDM can only write LANG (and the LC_xx categories)
• language-selector can write LANGUAGE
• That effectively means that the language one selects in GDM is useless, since LANGUAGE has precedence
• In some applications LANG (or LC_xxx) is used, though.

As a test, in my Catalan session I logged out, chose German as the language in GDM, logged back in and noticed:

• Most applications are in Catalan
• The calendar is half Catalan, half German
• Firefox is in German

$ locale
LANG=de_DE.utf8
LANGUAGE=ca_ES@valencia:ca_ES:ca:en_GB:en
LC_CTYPE="de_DE.utf8"
LC_NUMERIC="de_DE.utf8"
LC_TIME="de_DE.utf8"
LC_COLLATE="de_DE.utf8"
LC_MONETARY="de_DE.utf8"
LC_MESSAGES="de_DE.utf8"
LC_PAPER="de_DE.utf8"
LC_NAME="de_DE.utf8"
LC_ADDRESS="de_DE.utf8"
LC_TELEPHONE="de_DE.utf8"
LC_MEASUREMENT="de_DE.utf8"
LC_IDENTIFICATION="de_DE.utf8"
LC_ALL=

This can be potentially very confusing to users switching locales.

Arne, could you comment on this? Should we open a separate bug?

[Arne Goetje (arnegoetje)]

David Planella wrote:
> While the patch fixes the issue where Xsession was writing a LANGUAGE
> variable with incorrect syntax, now we've got a situation where:
>
> • GDM can only write LANG (and the LC_xx categories)
> • language-selector can write LANGUAGE
> • That effectively means that the language one selects in GDM is useless, since LANGUAGE has precedence
> • In some applications LANG (or LC_xxx) is used, though.
>
> As a test, in my Catalan session I logged out, chose German as the
> language in GDM, logged back in and noticed:
>
> • Most applications are in Catalan
> • The calendar is half Catalan, half German
  -> bug in the calendar code
> • Firefox is in German
  -> bug in firefox

> $ locale
> LANG=de_DE.utf8
> LANGUAGE=ca_ES@valencia:ca_ES:ca:en_GB:en
> LC_CTYPE="de_DE.utf8"
> LC_NUMERIC="de_DE.utf8"
> LC_TIME="de_DE.utf8"
> LC_COLLATE="de_DE.utf8"
> LC_MONETARY="de_DE.utf8"
> LC_MESSAGES="de_DE.utf8"
> LC_PAPER="de_DE.utf8"
> LC_NAME="de_DE.utf8"
> LC_ADDRESS="de_DE.utf8"
> LC_TELEPHONE="de_DE.utf8"
> LC_MEASUREMENT="de_DE.utf8"
> LC_IDENTIFICATION="de_DE.utf8"
> LC_ALL=
>
> This can be potentially very confusing to users switching locales.

I agree. Language-selector has code to generate the LANGUAGE variable
out of any given LANG locale code. It uses the file
/usr/share/language-selector/data/languagelist to find fallbacks for
LANGUAGE and if the specific locale is not mentioned there, just strips
the encoding and country code from the LANG value.

I think this code and the fallback list should be placed into a separate
library, so that it can be used by gdm and ubiquity/debian-installer to
set the LANGUAGE variable correctly.

I can split out the code from language-selector and create a
command-line interface to query the mapping. If you guys agree with
that, can we get this done until beta2?

[Martin Pitt (pitti)]

David Planella [2010-03-20 19:32 -0000]:
> • GDM can only write LANG (and the LC_xx categories)

Indeed, gdm does not currently have a concept of a "language list",
just a locale picker.

> • language-selector can write LANGUAGE

(but also LANG)

> • That effectively means that the language one selects in GDM is useless, since LANGUAGE has precedence

It's only useless if you fine-tuned your $LANG/$LANGUAGE in the
language-selector. It does work fine if you didn't (and most people
won't, I figure).

So, I agree it's confusing, but I don't see how to easily rectify it.
The best that comes to my mind is to disable the locale picker for
users which have a $LANGUAGE set?

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

[David Planella (dpm)]

El Mo 22 de 03 de 2010 a les 07:52 +0000, en/na Martin Pitt va escriure:
> David Planella [2010-03-20 19:32 -0000]:
> > • GDM can only write LANG (and the LC_xx categories)
>
> Indeed, gdm does not currently have a concept of a "language list",
> just a locale picker.
>
> > • language-selector can write LANGUAGE
>
> (but also LANG)

But it seems that it either doesn't do it or GDM overwrites it. Arne
explained me last week that there is a problem with GDM restoring
the .dmrc file from /var/cache/gdm/$USER/dmrc, which might be related.

>
> > • That effectively means that the language one selects in GDM is
> useless, since LANGUAGE has precedence
>
> It's only useless if you fine-tuned your $LANG/$LANGUAGE in the
> language-selector. It does work fine if you didn't (and most people
> won't, I figure).
>

It's not just about fine tuning. Simply selecting a language in language
selector will lead you to this situation. I've tried this:

      * 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). 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)

> So, I agree it's confusing, but I don't see how to easily rectify it.
> The best that comes to my mind is to disable the locale picker for
> users which have a $LANGUAGE set?
>

If that would also stop GDM from setting LANG, it might be an option.
I'm not sure if all cases can be covered, but I think an aim could be
that GDM and language-selector have got some minimal sane interaction at
least, since right now they work totally independently of each other.

Arne, you proposed something else already, but I cannot assess how much
work it is involved or whether this is doable/worth doing until beta2.

If not, do you think there is anything else we could do to make GDM play
a bit nicer with language-selector?

[Martin Pitt (pitti)]

Arne Goetje [2010-03-21 8:20 -0000]:
> I think this code and the fallback list should be placed into a separate
> library, so that it can be used by gdm and ubiquity/debian-installer to
> set the LANGUAGE variable correctly.

I don't think we'll have time to add this to gdm anytime soon, though.
We still have tons of other and more pressing bugs to fix in gdm in
particular, and the desktop in general.

> I can split out the code from language-selector and create a
> command-line interface to query the mapping. If you guys agree with
> that, can we get this done until beta2?

Is that file hard to parse? It might be easier and more efficient to
parse the file directly than to call an external program and parse
its output?

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

[David Planella (dpm)]

As the original problem reported in the bug has been fixed, I've filed bug 553162 to track the other issue.

[Mohamed Amine Ilidrissi (ilidrissi.amine)]

Since this is fixed, I'll mark the ubuntu-translations task as Fix Released.

[hardik (hardik-soni)]

see https://bugs.launchpad.net/ubuntu/+source/unity/+bug/820333

[Rolf Leggewie (r0lf)]

karmic has seen the end of its life and is no longer receiving any updates. Marking the karmic task for this ticket as "Won't Fix".