Language en_US does not exist; using System default

[Omid Mottaghi]

After upgrading from Gutsy to Hardy, after login to Gnome, I see a box with an OK button with this message "Language en_US does not exist; using System default". It comes in each login.

After pressing OK, Gnome comes normally.

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=8.04
DISTRIB_CODENAME=hardy
DISTRIB_DESCRIPTION="Ubuntu hardy (development branch)"

[Christian Kellner (gicmo)]

Same thing here, after using the language selector. So I *guess* its a language selector bug.

[Christian Kellner (gicmo)]

Changing Package

[am_public (am-public)]

same problem with new install of hardy alpha3, with it_IT language. The message is correctly translated to italian.

[Jakob Breivik Grimstveit (jakobbg)]

Confirm same experience here. Hardy, 2.6.24-5-generic. Occurs both for Xfce4 and Gnome, btw.

[Marc D. (marc.d)]

Same here. Running gnome-language-selector does not reveal any missing stuff. (hardy alpha 3, fresh install)
Default language here is en_US.

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=8.04
DISTRIB_CODENAME=hardy
DISTRIB_DESCRIPTION="Ubuntu hardy (development branch)"

$ dpkg -l language-selector
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-f/Unpacked/Failed-cfg/Half-inst/t-aWait/T-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++-==============-==============-============================================
ii language-selec 0.2.10 Language selector for ubuntu linux

[Chris Jones (cmsj)]

I see the same thing with en_GB. I note that setting the language from gdm adds en_GB.UTF-8 to my .dmrc, which stops the complaining.
This is presumably therefore something from previous installs that is setting the language without the encoding, which the login session then complains about.
FWIW, I see this in /etc/environment:

LANGUAGE="en_GB:en"

So it's either this or something similar that needs to be handled on upgrade. I'm pretty sure it's not a language-selector bug though, so I'm going to move this to gdm.

[Christian Kellner (gicmo)]

Quick status report, after some more investigations: So the error clearly comes from gdm. It is in daemon/slave.c line 3708:
--- snip ---
 if G_UNLIKELY ( ! ve_string_empty (language) &&
   ! ve_locale_exists (language)) {
  char *msg = g_strdup_printf (_("Language %s does not exist; using %s"),
          language, _("System default"));
  gdm_errorgui_error_box (d, GTK_MESSAGE_ERROR, msg);
  language = NULL;
  g_free (msg);
 }
--- snap ---
So gdm clearly things that the language set in language is not a valid locale. It checks it with ve_locale_exists () by doing a setlocale (LC_MESSAGES, locale) call.
Setting LANGUAGE to en_US.UTF-8 totally fixes the issue. So either my initial guess was right and the language selector should set the LANGUAGE var to en_US.UTF-8 and not en_US:en or gdm is to blame for not stripping the variable as it should or wrongly checking with the setlocale () call.

Anybody has some clues about the legal values of LANGUAGE?

I will investigate some more where the language variable is set from.

[Christian Kellner (gicmo)]

So, after making sure that the setlocale () call behaves identically on gutsy and hardy I moved on and downgraded to the gdm version of gutsy (updates). Which is 2.20.1 and the problem disappeared. So this is totally caused by a change in gdm (2.20.1 -> 2.20.3). Looking at the diff didnt reveal anything too obvious. I will have a closer look. Any gdm people around?

[Christian Kellner (gicmo)]

So after some more investigation I *think* I nailed it down to that change:

--- snip ---
@@ -1585,9 +1585,7 @@ main (int argc, char *argv[])
- if (setlocale (LC_CTYPE, NULL) != NULL) {
- gdm_system_locale = g_strdup (setlocale (LC_CTYPE, NULL));
- }
+ gdm_system_locale = g_strdup (g_get_language_names()[0]);
--- snap ---
gdm would use that variable later in slave.c:
--- snip ---
   if ((gdm_system_locale != NULL) && (!has_language)) {
    lang = gdm_system_locale;
   } else {
    lang = language;
   }
--- snap ---
And from the docs of g_get_language_names():

"Computes a list of applicable locale names, which can be used to e.g. construct locale-dependent filenames or search paths. The returned list is sorted from most desirable to least desirable and always contains the default locale "C".

For example, if LANGUAGE=de:en_US, then the returned list is "de", "en_US", "en", "C".
"

So in the opposite of calling setlocale () and saving the result which would either be NULL or a valid locale string (valid, as in you can pass it again to setlocale without getting an error), g_get_language_names() can, and will if LANGUAGE is set in that way, also return "en_US". I made a little test program that showed that setlocale () will return NULL on here for anything other then "en_US.UTF-8" (i.e. en_US or en_US:en).

Since g_get_language_names() will return en_US (and not en_US.UTF-8) and since that is non-NULL (thus ve_string_empty (language) == FALSE) and ve_locale_exists () will return FALSE, hence the error dialog. Also setting LANGUAGE to en_US.UTF-8 fixes the issue since then g_get_language_names() will not return en_US but en_US.UTF-8.

So, the original question remains valid: Is en_US:en for LANGUAGE correct, then gdm needs to change its logic (again) or if it is not we need to set LANGUAGE correctly to en_US.UTF-8.

I am not a locale expert so I leave that as an exercise to the reader. ;-)

[Christian Kellner (gicmo)]

After reading the docs of g_get_language_names() again where it states that list is "sorted from most desirable to least desirable". If the docs dont lie and the logic of g_get_language_names() is not wrong then I think its *not* gdm to blame here but the really the language selector since its setting the LANGUAGE env variable to a value that is not valid on the system. A call to locale -a shows no "en_US" but only "en_US.UTF-8", and therefore a call to setlocale () with the value of "en_US" will return NULL. If I am not entirely mistaken the gdm change only showed the bug.

[zenith (lasse-bigum)]

I am experiencing this problem as well, has this issue been reported upstream, provided that Christian Kellner has diagnosed the problem correctly? I'm assuming the Language Selector is a gnome specific thing? Or have Ubuntu done something with it?

[Markus (doits)]

i hope there'll be a fix around soon, because i'm using a german keyboard.

when the error is displayed the keyboard changes to english layout even in preferences / keyboard is written "german". i have to add "german" again and remove the first "german" to make my keyboard layout german again. on every logon... that sucks.

[Andrew Conkling (andrewski)]

On Feb 6, 2008 4:44 PM, Markus Doits <email address hidden> wrote:

> when the error is displayed the keyboard changes to english layout even
> in preferences / keyboard is written "german". i have to add "german"
> again and remove the first "german" to make my keyboard layout german
> again. on every logon... that sucks.

Actually, I think that sounds like bug #187969.

[sibidiba (sibidiba)]

Can confirm this bug on current Hardy.

Although the workaround of changing the environment file doesn't work!

$ locale -a
C
de_AT.utf8
de_BE.utf8
de_CH.utf8
de_DE.utf8
de_LU.utf8
en_AU.utf8
en_BW.utf8
en_CA.utf8
en_DK.utf8
en_GB.utf8
en_HK.utf8
en_IE.utf8
en_IN
en_NZ.utf8
en_PH.utf8
en_SG.utf8
en_US.utf8
en_ZA.utf8
en_ZW.utf8
hu_HU.utf8
POSIX

I tried utf8, UTF-8 and "" as a suffix for LANG, LANGUAGE and NLS_LANG with en_US, but the error dialog appeared.

$ cat /etc/environment
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games"
LANGUAGE="en_US.utf8"
LANG="en_US.utf8"

NLS_LANG="en_US.utf8"

LC_CTYPE="hu_HU.utf8"
LC_COLLATE="hu_HU.utf8"
LC_TIME="hu_HU.utf8"
LC_NUMERIC="hu_HU.utf8"
LC_MONETARY="hu_HU.utf8"
LC_MESSAGES="en_US.utf8"
LC_PAPER="hu_HU.utf8"
LC_NAME="hu_HU.utf8"
LC_ADDRESS="hu_HU.utf8"
LC_TELEPHONE="hu_HU.utf8"
LC_MEASUREMENT="hu_HU.utf8"
LC_IDENTIFICATION="hu_HU.utf8"

TZ='Europe/Budapest'

EDITOR=vim

# fixing bugs...
#DISPLAY=:0
#G_BROKEN_FILENAMES=1
LIBXCB_ALLOW_SLOPPY_LOCK=1
INTEL_BATCH="1"

[chastell (chastell)]

As noted in my comment to #178402, you need to change /etc/default/locale: https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/178402/comments/28

[KrazyPenguin (krazypenguin)]

I'm experincing the same bug " en_US does not exist; using system default".

I never upgraded from Gutsy, but did a fresh Alpha4 install, and I am not sure
what caused this bug.

I'm trying the workaround.

[KrazyPenguin (krazypenguin)]

Update:
Changing /etc/default/locale as mentioned above works so it looks like this:

LANG="en_US.UTF-8"
LANGUAGE="en_US.UTF-8"