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

[Daiki Ueno]

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 <address@hidden> 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