bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: address@hidden: Re: [PATCH] I18n flag for msgfmt]


From: Paul Eggert
Subject: Re: address@hidden: Re: [PATCH] I18n flag for msgfmt]
Date: 06 Jan 2004 11:33:46 -0800
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3

Behdad Esfahbod <address@hidden> writes:

> So the decision better be left to each translation team, instead of
> the (usually) western developer which all this "I" thing is a
> non-issue for him.

As a (western) developer I tend to agree.  It would be a difficult and
painstaking job to put ifdefs around all printf formats for numbers.
Most developers won't bother.  I'm not saying your proposed solution
is the right one -- Bruno is a far better judge than I of that -- but
I do think the ifdef solution won't fly.


> Note: As a consequence, software developers should call gettext
> on all of their singleton "%d" format strings too.

That goes a bit too far, as "%d" is sometimes correct regardless of
locale.  For example, POSIX requires that plain "diff" must use %d for
line numbers, regardless of locale.  This makes it easier for a user
in one locale to send a patch to a user in another locale.


> The question is where should we start the fix?  Bottom-up, adding
> support in glibc first, or no way, we should go the hard way, add it
> in POSIX first, glic later?

I'd say glibc first.  %I isn't in POSIX yet, is it?  At any rate the
POSIX folks prefer to have implementations first.

On a related issue, many applications do not use %d to print numbers,
so %Id won't suffice for them.  For example, there's no portable way
to print off_t values using printf (until we can assume C99
everywhere), so many applications use their own code that divide by 10
and print the off_t values directly.  If gettext were to support the
C99 printf formats (even on non-C99 hosts), that would address much of
this problem, but it raises other problems and I worry that we may be
trying to fold too much functionality into gettext.




reply via email to

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