[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. 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".) 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? Peter
Attachment:
signature.asc
Description: Digital signature