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
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 ca_ES@valencia: ca_ES:ca: en_GB:en "de_DE. utf8" "de_DE. utf8" "de_DE. utf8" "de_DE. utf8" "de_DE. utf8" "de_DE. utf8" "de_DE. utf8" "de_DE. utf8" "de_DE. utf8" "de_DE. utf8" "de_DE. utf8" ON="de_ DE.utf8"
LANG=de_DE.utf8
LANGUAGE=
LC_CTYPE=
LC_NUMERIC=
LC_TIME=
LC_COLLATE=
LC_MONETARY=
LC_MESSAGES=
LC_PAPER=
LC_NAME=
LC_ADDRESS=
LC_TELEPHONE=
LC_MEASUREMENT=
LC_IDENTIFICATI
LC_ALL=
This can be potentially very confusing to users switching locales.
Arne, could you comment on this? Should we open a separate bug?