GNOME Bugzilla – Bug 517670
missing language error
Last modified: 2008-03-07 19:49:30 UTC
The bug has been opened on https://bugs.launchpad.net/bugs/178402 "after updating to hardy alpha 3 from gutsy, every time ubuntu boots there is this error : Language en_US does not exist, Using system default" Christian Kellner did some work on the issue and commented, " 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. ;-)" The LANGUAGE variable is a list of countries and not locales so it looks like gdm is trying to use it wrongly there
This happens when upgrading to GDM 2.21; updating version.
So this is my fault. See bug 485852 comment 6 The problem is that some of the values returned in g_get_language_names() will lack a codeset. While valid locales, they aren't utf8 locales and so probably aren't ever what we want. Furthermore, some distributions strip those non-utf8 locales out entirely. It's wrong to interpret the return value of g_get_language_names() as a list of available locales. That was a misunderstanding on my part. We should probably change the code to be like it was originally in bug 485852 with the exception of checking LC_MESSAGES instead of LC_CTYPE. the latter is bogus, since we're changing the greeter locale to update the messages on the screen. Also, setting LANG=setlocale (LC_MESSAGES, NULL) is probably okay if we're just showing the greeter with that LANG. But we definitely don't want to do something like that generally, and it would be cleaner overall to just pass LANG/LC_* through verbatim to the greeter (and only changing LANG if changing things up)
Independent of the above. I think that it is wrong that LANGUAGE is getting set to a list of locales that don't exist on the system. I don't know if that's an Ubuntu bug or a misconfiguration. I believe that the locales can be *more* specific than what's available, but not less.
Thanks. I'm happy to update the code if someone wants to propose a patch.
Ray, could you provide a patch to fix things as you describe in comment #2? I'd like to do a GDM 2.20 release soon, and it would be nice to fix this bug.
Created attachment 106803 [details] [review] get default locale from LC_MESSAGES instead of g_get_language_names()
Thanks, Ray, this is now fixed in the 2.20 branch.