Re: FW by firstname.lastname@example.org : Bug#467249: man-db: over sensitive on the spell of locale
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=zh_CN.utf8 LC_ALL=zh_CN.utf8 locale
(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
> 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.
Colin Watson [email@example.com]