Re: FW by lidaobing@gmail.com : Bug#467249: man-db: over sensitive on the spell of locale

[Colin Watson <cjwatson@debian.org>]

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                                       [cjwatson@debian.org]