Bug#345639: nl_langinfo(YESEXPR) ignores LANGUAGE, no apparent workaround
On Mon, Feb 13, 2006 at 12:33:38AM -0600, Peter Samuelson wrote:
>
> [Denis Barbier]
> > On Sun, Feb 12, 2006 at 06:27:35PM +0100, Claudio Nieder wrote:
> > > Otherwise, if for libc supported language xx_YY no message catalog
> > > is supplied, the user would receive the prompt in untranslated
> > > english (y/N), but expected to type either ä or è because thats
> > > what nl_langinfo expects for language xx_YY.
> >
> > You are also right, but for this exact reason, y/n answers are also
> > taken into account when they are unambiguous. For instance in
> > German, you can type y or j for yes, and n for no.
>
> This doesn't fix it. Consider a user who speaks Italian natively but
> also speaks French. She sets LANGUAGE=it_IT:it:fr and LANG=it_IT@euro.
> I hope we can agree that this is a sensible thing to do.
It is.
> Now she runs an app which is translated into French, but not into
> Italian. It prompts her in French:
>
> Faire ces changes? [o/N]
>
> and it calls nl_langinfo(YESEXPR) to parse the response. This yields
> "^[sSyY]" since it doesn't know anything about LANGUAGE or what message
> catalogs are available. (NOEXPR is not a problem, since all three
> languages use "n".)
Right.
> The only solution to this dilemma, at present, is to tell users *not*
> to put multiple languages in their LANGUAGE variable. But as far as I
> can tell, that is the *only* point to the LANGUAGE variable in the
> first place!
>
> Which leaves us with the recommendation *not* to use LANGUAGE *at all*.
> Would you agree?
Certainly not. The recommendation is to learn how to use LANGUAGE
and to be aware of its few caveats, users can then decide to set it
or not.
Denis
Reply to: