The i18n guide doesn't explain what to do in this situation:

    g_print (_("Execution ended after %" G_GUINT64_FORMAT " iterations
(sum %"
            G_GUINT64_FORMAT " ns, average %" G_GUINT64_FORMAT " ns,
min %"
            G_GUINT64_FORMAT " ns, max %" G_GUINT64_FORMAT " ns).\n"),
        iterations, sum, sum / iterations, min, max);

The strings in gst/gst.c are fixed.

Danilo?

The splitup problem also applies to:

#: gst/parse/grammar.y:741
#, c-format
msgid "no element to link URI \"%s\" to"


I guess "to" should be followed by something here, perhaps another
argument. Since some languages need to reorder the arguments here it's
crucial that both arguments are inside the same message.

D'oh, ignore my last comment. I obviously cannot read plain English.

are there any strings left to which this still applies ? If not we can close
this bug.

(note that there is not really a general solution for this problem)

Yes, there are lots of strings to fix still.  Keep this open until someone does
an audit.

Christian,

can you explain how, given code like this:

    g_print (_("Execution ended after %" G_GUINT64_FORMAT " iterations (sum %"
            G_GUINT64_FORMAT " ns, average %" G_GUINT64_FORMAT " ns, min %"
            G_GUINT64_FORMAT " ns, max %" G_GUINT64_FORMAT " ns).\n"),
        iterations, sum, sum / iterations, min, max);


this situation can be fixed ? I am at loss to figure out what we are supposed to
do here to help translators.  A simple patch for this issue will help me fix others.

Thomas: Gettext simply can't handle that. What's wrong with simply using %u?

regs,
 Chris

As cneumair already pointed out, you need to use a printf-style approach to
solve this. Gettext simply cannot handle preprocessor constants directly
inserted into strings.

There is no printf-style approach.  The problem is that the format string must
be different on various architectures.

Christian(s). %u is not portable for 64 bit values.

ping, still waiting for ideas for a possible solution

The only possible and remotely clean solution that I see for making this
translatable is with a printf-style approach.

If this currently isn't possible with printf or g_printf for 64-bit values, then
there is no such solution at the moment, I'm afraid.

there's no solution at the moment.

I resolved some of these in gst-launch by printing the numbers to strings, and
then printing the string.  It's clumsy, but commented.  I'd prefer to kinder to
the translators than to people reading the code.

Hopefully there won't be too many of these cases.

This bug is waiting for someone (either a developer or a translator) to go
through the message list and propose fixes.

Matthias, I remember you saying something about that glib guarantees that the
printf code for 64-bit integers always being lli and llu. Is that so?

Here is the ChangeLog entry I was referring to:

2004-05-14  Tor Lillqvist  <tml@iki.fi>

	* glib/gnulib/vasnprintf.c (vasnprintf): Handle empty digit string
	for precision correctly. (#142400)

	For backward compatibility with the Trio implementation, make "ll"
	format modifer work on Win32, too. Change into "I64" before
	passing to the system printf. (#142433)

GCC gives a warning if you use %lld and the argument is 'long'.  IIRC, gint64 is
'long' and not 'long long' on 64-bit architectures, even though they're
equivalent.  It's a bug, but I'll let someone else throw the mud to see where it
sticks.

Indeed, I just verified this on alpha.

Another approach to this problem, is if G_GUINT64_FORMAT takes a fixed, known
set of values. According to configure.in I have in my checkout of glib, it can
be one of 8 values currently:
  guint64_format='"u"'
  guint64_format='"lu"'
  3 x  guint64_format='"'$glib_cv_long_long_format'u"'
  3 x  guint64_format='"'$glib_cv_long_long_format'u"'

glib_cv_long_long_format is one of "ll", "q", "I64" (checked in configure.in).

Equipped with this data, you can also use N_() to mark such eight messages for
translators, eg.
/* This is just for xgettext to catch all possible (known?) variants of the
message for translators */
/* */
N_("Execution ended after %u iterations (sum %u ns, average %u ns, min %u ns,
max %u ns).\n");
N_("Execution ended after %lu iterations (sum %lu ns, average %lu ns, min %lu
ns, max %lu ns).\n");
N_("Execution ended after %qu iterations (sum %qu ns, average %qu ns, min %qu
ns, max %qu ns).\n");
....
    g_print (gettext("Execution ended after %" G_GUINT64_FORMAT " iterations (sum %"
            G_GUINT64_FORMAT " ns, average %" G_GUINT64_FORMAT " ns, min %"
            G_GUINT64_FORMAT " ns, max %" G_GUINT64_FORMAT " ns).\n"),
        iterations, sum, sum / iterations, min, max);


Here, translators will get all messages in their entirety, so they won't have
problems translating them (and they're all alike, so gettext-fuzzy matching
would help them do that). Note that I replaced _() call with gettext(), so
xgettext wouldn't catch that message.

The drawback of this is, as everybody probably sees, that number of different
specifiers for G_GUINT64_FORMAT can change, and you'd have to follow glib
changes in that (hard-coding is bad, I agree).  But, the advantage here is that
you keep the code relatively sane, yet help translators translate it efficiently
on most common architectures (all that glib currently supports).  Of course, the 

Note that David's approach of first doing something like:
  char *n_iterations = g_strdup_printf("%" G_GUINT_FORMAT, iterations);
and using "%s" instead in the message (now we get single message to translate),
is nice to translators as well (even better, because translators get one message
to translate).

(sorry for not responding earlier, my gstreamer bugzilla maildir was hidden from
Gnus, and only now I noticed that)

Should this bug be reopened or marked as closed?

No replies so marking closed.

I noticed there was a new pot file (0.8.7pre2) in the Translation Project that
had this problem fixed. Many thanks to all of you who fixed this!