bug-gettext
[Top][All Lists]
Advanced

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

Re: [bug-gettext] Further about --kde mode for xgettext


From: Chusslove Illich
Subject: Re: [bug-gettext] Further about --kde mode for xgettext
Date: Tue, 17 Feb 2015 11:41:26 +0100
User-agent: KMail/1.13.7 (Linux/3.0.13-0.27-default; KDE/4.10.3; x86_64; ; )

> [: Daiki Ueno :]
> Sorry for late response.

No, thank you for investing brainwidth on this :)

> Sorry, I'm not talking about the difference of [--qt, --boost, --kde]
> formats, but about the option semantics. If I understand correctly (from
> the xgettext code), they are supposed to work as: "mark any string with X-
> format which can be interpreted as a valid X-format string". In that
> sense, it's not surprising to me that all normal strings are marked as
> kde-format when --kde is specified.
>
> But I could be wrong; neither the documentation nor the help text
> explicitly state that.

(I suppose you meant "...all normal strings are *not* marked as kde-format
when --kde is specified." As that is the current behavior.)

For the design intent behind these options, I am mainly relying on this
passage from the manual:

> [: Gettext manual, sec. 4.6 :]
>
> If in the same line as or the immediately preceding line to the gettext
> keyword the xgettext program finds a comment containing the words
> xgettext:c-format, it will mark the string in any case with the c-format
> flag. This kind of comment should be used when xgettext does not recognize
> the string as a format string but it really is one and it should be
> tested. [...]
>
> This situation happens quite often. The printf function is often called
> with strings which do not contain a format specifier. Of course one would
> normally use fputs but it does happen. In this case xgettext does not
> recognize this as a format string but what happens if the translation
> introduces a valid format specifier? The printf function will try to
> access one of the parameters but none exists because the original code
> does not pass any parameters.

In typical Qt program, if in the original string there is no format
specifier but translation introduces one, nothing will try to access a non-
existing parameter. So such original strings do not need qt-format flag, and
xgettext --qt does now exactly what it should.

A KDE program is more like the printf example above, except that it is
*guaranteed* that a parameter will be accessed for every format specifier
(there is no equivalent of fputs). So, following this discussion from the
manual, the xgettext:kde-format comment should be added to each and every
original string without format specifier. Since that is the case, I thought,
xgettext --kde should do it itself, no recognition heuristics needed.

But, if xgettext --kde were to do this, then it would also have to know the
default keywords, to make a distinction when to put kde-format and when
kde-xml-format. So, as I said, if this all together feels like too much
change, I'm not opposed to relying on --flag options.

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

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

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