Language en_US does not exist; using System default

Bug #185947 reported by Omid Mottaghi on 2008-01-25
This bug report is a duplicate of:  Bug #178402: [hardy] missing language error. Edit Remove
Affects Status Importance Assigned to Milestone
gdm (Ubuntu)
Ubuntu Desktop Bugs

Bug Description

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_DESCRIPTION="Ubuntu hardy (development branch)"

Christian Kellner (gicmo) wrote :

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

Christian Kellner (gicmo) wrote :

Changing Package

am_public (am-public) wrote :

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

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

Marc D. (marc.d) wrote :

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

DISTRIB_DESCRIPTION="Ubuntu hardy (development branch)"

$ dpkg -l language-selector
| 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) wrote :

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:


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.

Changed in language-selector:
status: New → Confirmed
Christian Kellner (gicmo) wrote :

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) wrote :

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) wrote :

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

Changed in gdm:
assignee: nobody → desktop-bugs
importance: Undecided → Medium
status: Confirmed → Triaged
Christian Kellner (gicmo) wrote :

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) wrote :

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) wrote :

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.

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) wrote :

Can confirm this bug on current Hardy.

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

$ locale -a

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





# fixing bugs...

chastell (chastell) wrote :

As noted in my comment to #178402, you need to change /etc/default/locale:

KrazyPenguin (krazypenguin) wrote :

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) wrote :

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


To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers