Comment 9 for bug 185947

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