Re: yesno module and i18n

[Eric Blake]

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

According to Bruno Haible on 8/19/2007 4:30 AM:
> 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.

YESEXPR and NOEXPR are the only two locale entities that belong directly
to LC_MESSAGES; although you are correct that since they are regular
expressions, their interpretation can _also_ be impacted by LC_COLLATE and
LC_CTYPE.  I agree with Paul - a POSIX conforming mv uses only yesexpr to
decide on affirmative responses.

> 
> 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?

Here, I agree with Bruno - Cygwin's nl_langinfo is broken (it does not
allow overriding the C locale, regardless of the setting of LC_MESSAGES or
LC_ALL, because cygwin does not yet support message catalogs); using
gettext as a fallback sounds reasonable.  In other words, gettext is more
likely to be right than nl_langinfo on non-POSIX conforming hosts, such as
cygwin.

One more point - the specification for nl_langinfo declares that it will
always return a valid string (if it returns NULL, the platform is broken),
and that if the locale matching LC_MESSAGES does not define yesexpr, then
nl_langinfo should return the C locale version instead.  The result of
nl_langinfo is the empty string only when the locale specifies a yesexpr,
but the specification is not a valid regex.  Here, it would be nicer to
use gettext than the empty string (the empty string is a valid regex, but
it matches all input, so the user can't say no).

I still wonder whether that means we should try nl_langinfo first, but if
strcmp("^[yY]", nl_langinfo(YESEXPR)) is 0, fall back to gettext (rather
than the current patch proposal of gettext first, and nl_langinfo second
if there was no gettext translation).

- --
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

iD8DBQFGyFBl84KuGfSFAYARApRPAJ904N6rxlTpBaIgsdvJhB6zA8Gh5wCg2GWY
//BvGbf0XC4EywFiVFoNFVM=
=CX7T
-----END PGP SIGNATURE-----