[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)
Sat, 17 Jul 2004 17:41:25 +0200
On Fri, Jul 16, 2004 at 04:00:49PM +0200, 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.
It would be nice to be able to get around such limitation short of
recompiling gettext, by using a specific function call, for example.
> > 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).
There is no warranty any locale is compiled and I cannot change that
Imagine a large red swirl here.