[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 16:00:49 +0200
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.
> 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).
- Re: Bug#250488: LANGUAGE should be allowed to work even under C locale (fwd),
Bruno Haible <=