How does it break the build, in particular? The use of localized digits
unconditionally like this is likely a portability problem to windows at
runtime, but I would think it would build OK.

It was no windows build - on windows I dont care for po at all.
It breaks from /usr/bin/gmsgfmt -c -o $file fa.po

fa.po:92: 'msgstr' ist not a valid C format string ...

Just in case you want even more information ;)

hb@hb-athlon glib $ /usr/bin/msgfmt --version
msgfmt (GNU gettext-tools) 0.12.1
Copyright (C) 1995-1998, 2000-2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Ulrich Drepper.


file=./`echo fa | sed 's,.*/,,'`.gmo \
  && rm -f $file && /usr/bin/gmsgfmt -c -o $file fa.po
fa.po:92: 'msgstr' is not a valid C format string, unlike 'msgid'. Reason: In
the directive number 1, the character 'I' is not a valid conversion specifier.
fa.po:231: 'msgstr' is not a valid C format string, unlike 'msgid'. Reason: In
the directive number 1, the character 'I' is not a valid conversion specifier.
fa.po:236: 'msgstr' is not a valid C format string, unlike 'msgid'. Reason: In
the directive number 1, the character 'I' is not a valid conversion specifier.
/usr/bin/gmsgfmt: found 3 fatal errors
make[2]: *** [fa.gmo] Error 1
make[2]: Leaving directory `/mnt/Home/from-cvs/glib/po'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/mnt/Home/from-cvs/glib'
make: *** [all] Error 2

The same issue exists for gtk+ from cvs. Is the patch from above 
the right fix - or do I need to update some tool?

Another workaround is:

export LINGUAS="de es ja"

(obviously every language except 'fa' would be possible)

You would need to update your version of gettext. Version 0.14.1 doesn't emit
any errors.

Closing the bug. Please reopen if the problem persisted after the update.

Yeah.  For more information, we worked with Bruno Haible and added the
functionality to gettext such that the 'I' (i18n) flag is ignored if the runtime
does not support the flag (ie. is not glibc).  This went in gettext-0.14.  So,
it's not unconditionally really.   Maybe we should depend on a later version of
gettext though.

It definitely needs to be explicitely required by configure if we are
going to depend on fairly recent gettext. (I'm also thinking that this
isn't going to work with native gettext on Solaris.)

Hmm, gettext 0.13.1 (which I still use on Win32) doesn't complain about the 'I'
flag, even though the runtime definitely does not support it. (Actually, if I
understand the runtime sources include with the Windows Platform SDK correctly,
it has another meaning for the 'I' flag: It can be followed by "32" or "64" to
indicate the bit size of the integer. Just an 'I' indicates 64-bit integer on
Win64.) So maybe just requiring 0.13.1 would be enough?

This only breaks make check now, since I recently added -c to the msgfmt calls
in order to catch things like %.*s -> %s which really break things at runtime.

I think we could

a) live with the fact that make check may fail with gettext < 0.14

b) try to come up with a patch which adds -c to the msgfmt calls only if gettext
   is new enough

I will check the GNU gettext sources to see what the exact conditions are, then:

  - We should check for the gettext version in configure.
  - If a recent-enough gettext found, leave it all to gettext.
  - Otherwise, use a shell script to drop the unsupported flags ('I' currently)
before generating .mo files.


If I'm not confusing anything, these all can be done in intltool.  So the bug
can be moved to intltool if everybody agrees on the above scheme.

Behdad wrote:
> Otherwise, use a shell script to drop the unsupported flags ('I' currently)
> before generating .mo files.

One may as well drop the languages which use that flag in their PO files and not
build '.mo' files for them at all. Replacing localized digits with European
digits may not even result in the same rendering: sometimes even the bidi is
different, other things may also happen.

Roozbeh, I totally disagree.  First, most of Win32 builds do not use GNU
gettext.  Next, that way you don't leave any way to use these languages on
legacy systems, that I can see as a reason for many teams not using the i18n
flag (Arabeyes comes to my mind).  And third, since the bidi catogeries for the
problematic characters (dash and solidus mainly) has been changed recently,
there would be implementations of both old and new types around for the coming
five years, at least.  So any translation depending on one behavior or the other
is broken anyway.  And no, there shouldn't be any assumption that localized
digits are available and the translations should work correctly either way.  A
user may redefine the fa_IR locale for her preference and cut out the outdigit
section.

One more reason: Having gettext >= 0.13.1 doesn't guarantee localized digits
anyway.  It all depends on the libc.  So if fa_IR translations without localized
digits are wrong, then they are wrong even with a recent gettext on a non-GNU
system.

Created attachment 52468 [details] [review]
a patch to handle glib build breaks with old gnu gettext.

Attached is a patch to fix the problem of Persian translations on systems with
old gnu gettext as Roozbeh had suggested. Please review.

I don't think that removing the fa translations is the right fix. We should just
remove -c from the msgfmt call.

We can as well remove -c, and it would fix the build break problem, but it will
raise another problem:
If we run a Persian session on a system with old gnu gettext, the 'I' flag won't
get resolved and would cause runtime errors.

Farzaneh,

Like Matthias already said, and I said before in comments 13 and 14, we don't
think this is the right approach.  I've sketched the solution in comment 11.  It
involves a bit of sed work though.

The bug is not blocking anything really, again, as Matthias said, we can live
with the fact that make check fails with gettext < 0.13.1 for now.  If you want
to give the right way a try, patches are welcome.

Changing component to intltool, the problem is by no means limited to glib, and
by no means should be solved in glib.

Behdad, your opinion is different from Matthias's: he believes that the "-c"
flag should be removed, you believe that a shell/sed script should be written to
filter the translation. So your way is not necessarily the right way, until
someone confirms your view. Changing the component back to glib for the same reason.
I believe Farzaneh's patch is a good temporary fix, until your sed script appears.

Matthias, what do you think? Considering what Farzaneh said in comment 17, do
you think we should remove the Persian translation or the "-c" flag?

I think having distcheck not work with old gettext is fine until a proper fix
appears. Nobody but the person doing the release is required to use distcheck.

There is a portability problem only to platforms with glibc-2.1.x or older. 
But these are more than 5 years old. 
 
There is no portability problem to Woe32: libintl removes the 'I' on platforms 
that don't support it. But it assumes you are using libintl >= 0.14.1. 
 
Ad #8: The fake-GNU gettext() functions on Solaris are at the level of GNU 
gettext in 2000; they don't support this %I handling. The normal gettext.m4 of 
GNU gettext makes sure that Solaris libc gettext() doesn't get used accidentally. 
(But if GNOME uses a different .m4 file, that's GNOME's problem.) 
 
Ad #9: gettext 0.13.1 is not enough. 
 
Ad #10, #16: Adding "msgfmt -c" to "make check" was a good idea; otherwise 
badly translated format strings can crash the applications at runtime. Not 
only for Farsi, but for all languages. I wouldn't loosen this checking. 
 
I would suggest to just require gettext 0.14.1 or newer, both for the build 
and at runtime. 
 
Ad #15: You can simplify that patch by just looking at the output of 
msgfmt --version. >= 0.14.1. 
 

Roozbeh:

> So your way is not necessarily the right way, until
> someone confirms your view.

My way is /a/ right way, until somone claims otherwise.  Bugzilla is not a "I
agree" forum.  I asked in comment 11 whether everybody agrees with moving it to
intltool, and nobody disagreed.

On the other hand, your suggestion is not a right way, as I've already explained
above and later in this note.

> Changing the component back to glib for the same reason.

The problem is available in gtk+ too, and will show up in any other package that
does msgfmt -c and has i18n flag in any translation.  What is that small-fix in
glib exactly?

> I believe Farzaneh's patch is a good temporary fix,
> until your sed script appears.

We are not looking for a temporary fix.  As far as your approach is concerned,
according to Matthias's comments, the bug can be closed as WONTFIX.  I don't
mind doing that and opening another bug for actually fixing it in a right way.  

And I disagree with removing -c, because the error message is showing a possible
problem, that is, Persian translations will crash the application at runtime if
libc doesn't support i18n flag.  Removing -c is like hiding the bug under the
carpet.  I prefer current false positives, to false negatives that your approach
brings.

I see two resolutions:

  1) let it be as it is, or require gettext 0.14.1 in any package that has
translations using i18n flag. (headaches to come in the future one package at a
time)

  2) instruct intltool to magically handle it all.  What it would do is: if
(!(gettext >= 0.14.1 || glibc >= 2.2)) use sed to drop i18n flag.  Have to
decide about cross-compiling though.


Somebody please confirm what should be done, as per Roozbeh's request.

I'll pick 1) here, and close this bug. I'll add a note to the release notes stating that make check will fail with gettext < 0.14.1.