> That's not true. ".utf8" is the canonical name now, and .UTF-8 is an > alias. > >> This LANG/LANGUAGE settings behavior brakes some i18n codepages related >> applications (such as xarchiver, file-roller with archiver that has >> "codepage handling"). > > These would be bugs in those applications then, not gdm.
We have a similar problem at Opera with Ubuntu users, they are filing reports with us that their locale doesn't work if they use gdm. All these applications - including Opera - call standard X11 functions to set X's locale (see XSupportsLocale(3)). The problem is that some locales in the *.utf8 form are not supported by X11 as distributed with Ubuntu, but their *.UTF-8 counterparts are. An example of this would be bg_BG.utf8, which is one of the locales that gdm will set. This can be fixed in two ways: gdm should use *.UTF-8 instead (as kdm does on Kubuntu), or X11 should be fixed to support the various *.utf8 locales that are missing (this can be done by adding the locale to X11's locale.alias file). I don't have an exhaustive list of locales that don't work - I only know about bg_BG.utf8 and ru_UA.utf8 from bug reports by our users - but in the specific case of bg_BG.utf8 it's worth noting that that entry is in fact present in locale.alias on Ubuntu, but misspelled as be_BG.utf8. There is no entry for ru_UA.utf8. -- Unset $LANGUAGES if the user picks a different locale in gdm, so that language-selector and gdm stop disagreeing https://bugs.launchpad.net/bugs/553162 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
