[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: Gecko/20070728 Thunderbird/ Mnenhy/

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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]