[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug#250488: LANGUAGE should be allowed to work even under C locale (
Re: Bug#250488: LANGUAGE should be allowed to work even under C locale (fwd)
Fri, 16 Jul 2004 18:10:18 +0200 (CEST)
On Fri, 16 Jul 2004, Bruno Haible wrote:
> Bill Allombert wrote:
> > gettext/intl/dcigettext.c:1219 include the following comment:
> > /* Ignore LANGUAGE if the locale is set to "C" because
> > 1. "C" locale usually uses the ASCII encoding, and most international
> > messages use non-ASCII characters. These characters get displayed
> > as question marks (if using glibc's iconv()) or as invalid 8-bit
> > characters (because other iconv()s refuse to convert most non-ASCII
> > characters to ASCII). In any case, the output is ugly.
> > 2. The precise output of some programs in the "C" locale is specified
> > by POSIX and should not depend on environment variables like
> > "LANGUAGE". We allow such programs to use gettext(). */
> > gettext should provide a way to use LANGUAGE even if locale is set to "C"
> The comment you cite explain why the "C" locale shall not do localization.
> If you want an English locale that supports the LANGUAGE variable, use
> en_US or en_US.UTF-8. This locale exists on most systems.
Indeed. I see a lot of en_* locales when I do "dpkg-reconfigure locales"
on a Debian system.
> > For that purpose I use the following snippet from
> > info gettext "Being a `gettext' grok":
> > /* Change language. */
> > setenv ("LANGUAGE", lang, 1);
> > It works quite well unless the locale is set to C ...
> Then I'd suggest that you set the locale to en_US.UTF-8 (and install
> that locale, of course).
Thanks a lot, I'm closing this bug, then.