After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 625083 - Gettext can't parse GLib's printf format constants
Gettext can't parse GLib's printf format constants
Status: RESOLVED FIXED
Product: evolution-data-server
Classification: Platform
Component: general
unspecified
Other All
: Normal minor
: ---
Assigned To: Evolution Shell Maintainers Team
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2010-07-23 05:01 UTC by Tao Wang
Modified: 2010-07-28 19:36 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Tao Wang 2010-07-23 05:01:25 UTC 
Hi,

During my translation, I found the following string:

#: ../camel/providers/local/camel-mbox-summary.c:524
#, fuzzy
#| msgid "Fatal mail parser error near position %ld in folder %s"
msgid "Fatal mail parser error near position %"
msgstr ""


Why there is only "%" in the string? It might be a typo bug.
Comment 1 Matthew Barnes 2010-07-23 10:07:07 UTC 
We're using a printf format constant for 64-bit integers.  The code is:

  ·_("Fatal mail parser error near position %" G_GINT64_FORMAT " in folder %s")

I guess you'll need to file this bug against intltool?

https://bugs.launchpad.net/intltool
Comment 2 Tao Wang 2010-07-23 12:23:59 UTC 
I reported at intltool: https://bugs.launchpad.net/intltool/+bug/609124
Comment 3 Tao Wang 2010-07-27 20:51:49 UTC 
First, intltool said it's not the bug of intltool, because, intltool call gettext for string extraction, so I reported it to gettext, http://savannah.gnu.org/bugs/?30536

Then, gettext said it's not a bug of 'gettext', http://savannah.gnu.org/bugs/?30536#comment1

So, I'm back here.

Could you check it and solve it? Thanks.
Comment 4 Matthew Barnes 2010-07-27 22:15:09 UTC 
Okay, so basically the answer is we have to do backflips to get their tools to work right.  That's about what I expected.

I was especially amused at the suggestion to use a C99 macro which has portability issues in place of a macro whose sole purpose is to avoid those portability issues.