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

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

Re: [Translation-i18n] Handling qt-format in gettext tools (was: Updatin


From: Chusslove Illich
Subject: Re: [Translation-i18n] Handling qt-format in gettext tools (was: Updating qt-format handling?)
Date: Tue, 9 Oct 2007 14:19:42 +0200
User-agent: KMail/1.9.5

> [: Bruno Haible :]
> It is safer to put "xgettext: no-c-format" on a case-by-case basis,
> because a single missed instance of c-format, combined with an
> inappropriate translation, can crash the entire program.

Although there really are no real c-format strings as of yet, when I factor
out all the kind-of-c-format (i.e. where the translator shouldn't really
change %x), and all legacy usages of %n in plural messages (a bug for KDE4),
there indeed remains but a handful of messages really needing explicit
no-c-format. So probably not worth the possible danger of a c-format string
actually appearing, or an extra option in xgettext for that matter...

> xgettext does not add c-format by itself when the string is already marked
> as kde-format. But this here ["%1% finished."] is not a kde-format. What
> is it then?

This was just a (bad) example of the top of my head, a realistic message
would be "No 100% suggestions were found.", or "%1m %2s" (short for minutes,
seconds). But as I said these are few.

However I'm slightly alarmed by the bit that "%1% finished." is not kde-
format :) I don't see why it shouldn't be (xgettext also extraxts it as
such). Or I misunderstood what you wrote?

-- 
Chusslove Illich (Часлав Илић)

Attachment: pgplRRGoAdFcf.pgp
Description: PGP signature


reply via email to

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