Hello, My KDE knowledge is quite limited, so please forgive me for any pointless comment. I'm looking at the source and tests from:
$ git clone git://anongit.kde.org/ki18n Is this the right place to start with? Chusslove Illich <[email protected]> writes: > The --kde option makes xgettext recognize KDE 4 format strings, and add > kde-format flag to them. For example: > > #, kde-format > msgid "File %1 not found." > > There is one issue with this alone, and one new speciality in KF5 (KDE > Frameworks 5, informally "KDE 5"). > > The issue is that in KDE 4 format placeholder substitution is performed on > every string. String such as this should also get the flag: > > #, kde-format > msgid "File not found." > > because if the translation were to contain %1 (e.g. left in as unfuzzing > error), the runtime would try to replace it with an argument. So, to be > technically correct, xgettext with --kde should not try to test strings for > KDE 4 format, but blindly add kde-format to all of them. I wonder if this is really useful. If a placeholder were removed from the string, wouldn't the argument also be omitted from the i18n(...) call and cause unwanted output e.g. "File (null) not found."? > A new specialty in KF5 is that there is another set of translation calls > which is guaranteed to contain well-formed XML strings. The plain-text calls > are named i18n* and the XML ones are named xi18n*, so it is possible to > discern between them at extraction time. It would thus be a pity if all XML > strings also simply get kde-format tag, as that would prevent any XML > validation of translation. Instead it would be good if they get another > flag, e.g. kde-xml-format. Then msgfmt with -c could verify also the well- > formedness of such strings, but even until/if that is implemented, other > tools could use it for validation (e.g. a PO editor). I remember there were related discussions before, talking about a more generic xml-format tag. I agree that it would be a useful feature, though the msgfmt -c implementation wouldn't be straightforward; maybe one would need to consider encodings, entity references, etc. > Taking these two things together, we could do by having only kde-xml-format > flag added in a lightweight manner, e.g. without matching by xgettext and > with msgfmt verification same as for kde-format. The rest could be achieved > by applying multiple --flag options to xgettext. Would this be acceptable? That would make sense, if the current kde-format is useless and kde-xml-format is really specific to KDE. > However, since the --kde option anyway exists, and since KDE translation > call set is fixed and used as-is (no arbitrary short forms through #define > directives), it seems to me it would be nicer and non-problematic if all of > the above is automatically applied by xgettext. That is, that the user does > not have to specify many -k and --flag options just to support all the > default calls (32 in total, as [k][x]i18n[d][c][p], the ones with *x* being > XML). Of course, -k would continue to have its normal function (cancel > defaults, add more calls). Would this be acceptable? Couldn't those options be added to the KDE's CMake rules? That would allow users to tweak options when a new keyword is added to KDE. Regards, -- Daiki Ueno
