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?
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 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.
I agree. Language-selector has code to generate the LANGUAGE variable language- selector/ data/languageli st to find fallbacks for
out of any given LANG locale code. It uses the file
/usr/share/
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 debian- installer to
library, so that it can be used by gdm and ubiquity/
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?