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

[Behdad Esfahbod]

On Mon, 5 Jan 2004, Bruno Haible wrote:

> > glibc 2.2 adds i18n flag to printf formats, which msgfmt doesn't support
> > it. Attached is a small patch for format-c.c which adds it.
>
> Hi,
>
> Given that this 'I' flag is not portable (it is not even documented in
> the glibc manual!), any program using it would need a variant of the format
> string without this 'I' flag:

Hi Bruno,

Thanks for replying.  Unfortunately the problem is not so easy to
solve.  Details follows.  Also, we would send patches for glibc
manual soon.  Ulrich recently added support for %If after a patch
from Hamed too.

>   #ifdef __GLIBC__
>     printf (_("%Id inhabitants"), n);
>   #else
>     printf (_("%d inhabitants"), n);
>   #endif
>
> Which makes extra work for the translators. Therefore I suggest that you
> use the technique described in the gettext manual, section "Preparing
> Translatable Strings", leading to

Well, this "I" thing is something that should be used in message
translations, not original messages themselves, for a few
reasons:

1.  There are currently tens of thousands of message strings out
there that use "%d" or "%f" that with any solution in source code
they should all change.  And you can observe yourself that
requiring people to put an #ifdef block everytime writing a
number out is not an option.

2.  If applications use "%Id" in source, then when I for example
run them with my default LANG=fa_IR, but I don't have Persian
translations for this specific application, I don't like to get
Persian numerals, but original English ones.  So "%Id" should not
be used in source code, but in Persian translations.

3.  The border between which numbers should be written with local
digits, which with latin digits, is not quite clear.  For example
in Persian we write every number with Persian digits, but I can
see how we may write a price with US dollar currency sign with
Latin digits.  Or Arab people may have their own desires about
which numbers they would like to see in their local digits, which
not.  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.

>   char buf1[100];
>   #ifdef __GLIBC__
>     sprintf(buf1, "%Id", n);
>   #else
>     sprintf(buf1, "%d", n);
>   #endif
>   printf (_("%s inhabitants"), buf1);
>
> And once you do this, msgfmt doesn't need to know any more about the 'I'
> modifier.

I assume my reasons above have shown that the problem cannot be
solved this way.  So my solution:

1. msgfmt does not err about "I" flag, as it's a valid (and
should be encouraged) usage.

2. gettext library, silently remove the "I" flag if the
underlying libc does not support that.  It may not be the best
idea in the world, but having gettext already handling things
like "<PRId64>", I find it the suitable place to handle the "I"
flag, which is both necessary and sufficient for solving local
digits in software translation.

Note: As a consequence, software developers should call gettext
on all of their singleton "%d" format strings too.  Perhaps, with
some context, to let the translators decide on if it needs the
"I" flag or not.  With the infrastructor in place, these problems
would be solved later on a one-by-one basis.

> Bruno

Sincerely,
Behdad

PS.  Got a question now:  The current locale model is missing a
few features that we need in Persian locale.  One I can recall is
decimal separator (and thousands separator?) for local digits is
different from ones for Latin digits.  In the current model,
there is one and only one decimal separator per locale, so we
have set it to the Arabic Decimal Separator charactor, but it
means that we get Latin digits with Arabic decimal separator
which is not the way people write Latin float numbers in Iran.
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?