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

[Chusslove Illich]

>> [: Chusslove Illich :]
>> Any decision about this?
>
> [: Daiki Ueno :]
> I haven't decided anything about it yet.

I don't want to press you, just to make sure that all the information you
need is provided.

> Are you fine with xml-format which only checks XML well-formedness?

I think it is fine and very useful for XML formats in general.

But in the context of this thread, do you have in mind that instead of
kde-xml-format, such messages get kde-format and xml-format flags together?
This would not be good.

One reason is trivial, as I mentioned earlier, because literal ampersand is
used as accelerator marker. In kde-xml-format using & is required only
if it would start a valid entity reference which is not wanted. E.g.
"Ask &for confirmation" is valid kde-xml-format. So standard XML well-
formedness check cannot be applied. (This is an ugly hack in the format, I
agree, but it was one of those unfortunate historical coincidences where
every other solution would have been worse.)

The other reason is more principal. Having both foo-format and xml-format
flags would semantically indicate that the message is orthogonaly both
foo-format and xml-format. On the other hand, foo-xml-format would indicate
tighter integration. For example, with Ki18n this alone:

  QString path("foo/bar/baz.txt");
  QString msg = kxi18n("No such file 
<filename>%1</filename>").subs(path).toString();

would set msg to value "No such file 'foo/bar/baz.txt'" on POSIX, and
"No such file 'foo\bar\baz.txt'" on Windows. And if the line ends instead
with ...toString(Kuit::RichText), msg will get the value
"No such file <tt>foo/bar/baz.txt</tt>".

>> [...] But, relying solely on --flag options to set formats, we would get
>> into strange situation that --kde option serves no purpose any more.
>
> Yes, but I'm not too sure that reusing the existing --kde option is a good
> idea. The option is designed to be similar to --qt and --boost, and if we
> changed the meaning, it would become inconsistent and backward
> incompatible (even though it is currently not in use).

For the meaning, in fact, this is how the option should have functioned from
the start (also my bad for not realizing that when it was being introduced).
The technical difference to --qt and --boost is that with those formats the
argument substitution does not happen if the original string has no
placeholders, and there is no integral markup processing.

About compatibility, it would change the output template, but only for the
better. A maintainer doesn't have to touch anything after switching to new
xgettext, simply the extracted template will become better. So to me, having
every message flagged is a fix, and supporting more keywords by default is a
new feature. Am I missing a case where this behavior change could introduce
unwanted results?

> So, I'd rather add a new option if the shorthand form is really desired,
> and that's my question. Isn't it feasible to maintain the custom --flag
> list within the KDE's build infrastructure? Then users don't need to wait
> for a new release of gettext being deployed when a new keyword is added to
> ki18n.

The keyword set is stable, since it is designed and not accumulated with
time. It was expanded exactly twice in the past 12 years, once in 2006 (for
KDE 4) and once in 2013 (for KF 5).

Technically I'm ok with --flag list too. It is no problem to do this on the
side of the infrastructure. And to put the complete xgettext options block
into the Ki18n manual, for those not using the infrastructure.

But I think that in this case the --kde option should be made explicitly
deprecated.

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

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