On Fri, Feb 29, 2008 at 08:52:12AM +0100, Petter Reinholdtsen wrote: > [Michelle Konzack] > > It seems there is a common problem while setting up the correct UNICODE > > locale in systems. As the posster in the attached message has written, > > he has setup his locale to "zh_CN.utf8" which is wrong, but as he has > > written too, the output of "locale -a" show it. > > 'locale -a' do not show that the locale is working, it just show what > is set in the environment.
locale will indicate whether a locale is working by means of the messages it prints on standard error if it isn't: $ LANG=zz_ZZ.utf8 LC_ALL=zz_ZZ.utf8 locale locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory LANG=zz_ZZ.utf8 [...] $ LANG=zh_CN.utf8 LC_ALL=zh_CN.utf8 locale LANG=zh_CN.utf8 [...] (The same goes for 'locale -a', which in fact does not show what is set in the environment at all, but does what it is documented to do: "Write names of available locales.") > Use 'locale charmap' to check that the locale is working and that the > correct character set is selected. If it return 'ANSI_X3.4-1968' > (which is ASCII), the locale isn't working (unless it is a locale that > uses ASCII, not very likely). If it show 'UTF-8', the locale settings > are working. $ LANG=zh_CN.utf8 locale charmap UTF-8 > In the case you describe, I believe the only fix is to get the user to > stop using an invalid and non-existing locale, It is neither an invalid nor a non-existing locale. It is not in the form documented in /usr/share/i18n/SUPPORTED, but it is in the canonical form into which glibc normalises it internally. See the _nl_normalize_codeset function in glibc/intl/l10nflist.c. > and instead use the correct locale string, which I would suspect is > 'zh_CN.UTF-8'. The only workaround to this would be to rewrite glibc > and locales, and it does not seem useful to me. This is not a glibc bug. This is not a locales bug. This is a man-db bug. I am both the Debian maintainer and the upstream maintainer and I have accepted the bug (see the bug log). I wish people would stop trying to argue that it isn't a bug or that it is a bug somewhere else. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]