RFC: i18n: drop KUIT tags in KDE Frameworks 5.0?

[Chusslove Illich]

>> [: Thomas Zander :]
>> But can we be certain enough of succeeding now where we clearly failed
>> before that this is actually worth stopping the innovations that
>> Chusslove is working on?

> [: Albert Astals Cid :]
> I did not understand that it was stopping any innovation, Chusslove can
> you clarify if you want to remove them for the sake of simpler code (which
> I don't say it's unimportant) or because they create problems with other
> features you are developing?

It's not stopping any innovation as such, since I just want to drop it and
add nothing new. But the system cannot remain as it is, because of too many
quirks. To remain, it would have to be fixed, and to be made optional. Both
these aspects are problematic.

"Fixed" would make it require more discipline. For example, one could no
longer do:

  QString problem = i18n("Blah blah <emphasis>foom</emphasis>.");
  ...
  QString report = i18n("Blah blah: <note>%1</blah>", problem);

because substitution would cause autoescaping of any target format tags
(e.g. if <emphasis> was turned into <i>), and show them verbatim. Instead,
one would have to do:

  KLocalizedString problem = ki18n("Blah blah <emphasis>foom</emphasis>.");
  ...
  QString report = i18n("Blah blah: <note>%1</blah>", problem);

as only KLocalizedString as argument would not be autoescaped (it would be
enforced to be valid wrt. markup).

"Optional" would cause uncertainty. One could not count on KUIT being
available in a particular section of code, but would have to check 1) which
catalog are messages looked up in 2) does that catalog have KUIT enabled
(optionality would be by-catalog). That someone in doubt does not have to be
a human, but also source code/translation validation tool.

These two implications, combined with low usage as it is, makes me conclude
it is not worth investing the work in fixing the system. Higher discipline
and more uncertainty would mean even less people would use it than they do
now.

(The stakes are somewhat different for the more radically new system that I
describe in that proposal for extending Gettext. The higher discipline
requirement would remain, but is (supposed to be) offset by the fact that
you could use the exact same i18n in any programming language and toolkit,
providing availability of bindings, and use arbitrary target visual formats
transparently for translators; i.e. translators would no longer see the
underlying programming framework. The uncertainty aspect would be mostly
removed, because new option to xgettext would be used on extraction, and all
messages in PO file would get appropriate *-format flag, whether they have
any placeholder or not.)

-- 
Chusslove Illich (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120324/74e6b2c7/attachment.sig>