Re: Bug#250488: LANGUAGE should be allowed to work even under C locale (fwd)

[Santiago Vila]

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.