Re: yesno module and i18n

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Bruno Haible on 8/18/2007 9:42 AM:
> Eric Blake wrote:
>> The yesno module also has a potential POSIX-compliance problem
>> on all platforms.  Inside rpmatch, the code uses _("^[yY]") to
>> get the locale-specific regex to use as the yesexpr.  However,
>> this is not necessarily the same as using nl_langinfo(YESEXPR).
> 
> Why is this a POSIX compliance problem? POSIX does not specify the yesno()
> function nor the rpmatch() function.

But POSIX _does_ specify that mv shall use YESEXPR as the regular
expression for determining affirmative responses, and since mv uses yesno
(and thus rpmatch) to implement this requirement, we might as well make
use of nl_langinfo which is provided for this purpose, when it is available.

> Remember that we support many platforms which have deficient locale support.
> For example, what is nl_langinfo(YESEXPR) in a German or French locale on
> Cygwin? Just the same string as in English. That's why we put "^[yY]" into
> gnulib's message catalog.
> 
> But I have no problem with using nl_langinfo(YESEXPR) when it has a locale
> dependent information and gnulib's message catalog doesn't.

Sounds okay to me.

> 
>> If nothing else, we should add a TRANSLATOR comment before
>> both regex strings in rpmatch.c, to make it obvious that these strings
>> should be consistent with the locale's choice of yesexpr and noexpr,
>> rather than the usual use of _() to designate translated output.
> 
> Consistency is not a must, in my opinion. But a translator comment cannot
> hurt. How about this patch? OK to commit?

Once you fix the following problem:

> 
> 
> 2007-08-18  Bruno Haible  <address@hidden>
> 
>       * lib/rpmatch.c: Include langinfo.h.
>       (N_): New macro.
>       (localized_pattern): New function/macro.
>       (rpmatch): Use it. Add translator comments.
>       * m4/rpmatch.m4 (gl_PREREQ_RPMATCH): Test for nl_langinfo and YESEXPR.
>       Suggested by Eric Blake.
...
> 
> + 
> + # if HAVE_LANGINFO_YESEXPR
> + static const char *
> + localized_pattern (const char *english_pattern, nl_item nl_index)
> + {
> +   /* 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);

Not reliable.  nl_langinfo is entitled to use static storage that can be
overwritten by later calls to nl_langinfo or by subsequent changes to the
locale.  You will need to do something like strdup to avoid problems with
nl_langinfo's storage; then properly clean up to avoid memory leaks.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGxxc984KuGfSFAYARAsiCAKCBKrT8CSNWZtqFxFRhy1VJh0BziwCgniRM
PnFXozfstVwFL7Fj71YWNlA=
=a2yv
-----END PGP SIGNATURE-----