[Top][All Lists]
[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 (Часлав Илић)
pgplRRGoAdFcf.pgp
Description: PGP signature