[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: yesno module and i18n
From: |
Eric Blake |
Subject: |
Re: yesno module and i18n |
Date: |
Sun, 19 Aug 2007 08:15:01 -0600 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.666 |
-----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-----
Re: yesno module consumes too much input, Jim Meyering, 2007/08/17
Re: yesno module consumes too much input, Paul Eggert, 2007/08/17
- Re: yesno module consumes too much input, Jim Meyering, 2007/08/17
- Re: yesno module consumes too much input, Eric Blake-1, 2007/08/17
- Re: yesno module consumes too much input, Paul Eggert, 2007/08/17
- Re: yesno module consumes too much input, Eric Blake, 2007/08/18
- Re: yesno module consumes too much input, Bruno Haible, 2007/08/18
- Re: yesno module consumes too much input, Eric Blake, 2007/08/18
- Re: yesno module consumes too much input, James Youngman, 2007/08/18