Re: yesno module and i18n

[Bruno Haible]

Paul Eggert wrote:
> (if I'm understanding things correctly)
> POSIX says that mv's behavior here depends on nl_langinfo's result and
> nothing else.

That's not my understanding. http://www.opengroup.org/susv3/utilities/mv.html
says that
  - The processing of user responses uses the LC_MESSAGES locale category.
  - If nl_langinfo(YESEXPR) is used, it uses the LC_COLLATE and LC_CTYPE
    locale categories.

> > +   /* First, look in the gnulib message catalog.  */
> > +   const char *translated_pattern = _(english_pattern);
> > +   if (translated_pattern == english_pattern)
> > +     {
> > +       /* The gnulib message catalog provides no translation.
> > +    Try the system's message catalog.  */
> > +       translated_pattern = nl_langinfo (nl_index);
> > +       if (translated_pattern == NULL || translated_pattern[0] == '\0')
> > +   /* Broken system.  */
> > +   translated_pattern = english_pattern;
> 
> The overall idea seems sound, but shouldn't the code simply use the
> nl_langinfo result, if nl_langinfo exists and returns a nonempty
> string?

On most systems, nl_langinfo provides worse localization that a gnulib
messages catalog. The notable exception are glibc systems, with its support
of dozens of locales - but on glibc systems, the gnulib replacement for
rpmatch() is not used anyway. IMO, proper localized behaviour here is
more important than consistency with badly localized system primitives.

For example, on Cygwin, nl_langinfo(YESEXPR) will always return a result
for English. If you test nl_langinfo(YESEXPR) before _("^[yY]"), how do
test whether it's properly localized or not?

Bruno