> [: 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 (Часлав Илић)
signature.asc
Description: This is a digitally signed message part.
