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

[Chusslove Illich]

Starting with KDE 4.0, i18n() functions act as XML processors under the
hood, expecting the strings to be well-formed XML and resolving some tags
(KUIT tags) to a target format (HTML or pure text). These KUIT tags include
<filename>, <para>, <emphasis>, etc.

I would like to drop this support in KDE Frameworks 5.0. There would be a
fully automatic conversion script for sources to resolve KUIT tags in
existing i18n() calls into appropriate target formats. The reasoning is as
follows.

Firstly, in the past 4 years, KUIT tags didn't get to be used very much.
Only 0.56% of all messages (1144 out of 200,000) contain any. Only 5 out of
24 KUIT tags were used more than 100 times (<filename> being the most used
with 333 appearances). This means that both original strategic goals were
not accomplished: text elements still have different formatting across most
of KDE applications (such as whether filenames are singly or doubly quoted,
bold, etc.), and translators still have little additional semantic
indication of what text placeholders are substituted with.

Secondly, XML processing in strings was made somewhat lax, as a compromise
between ease of use, mixing with existing markup (Qt rich text), and not
changing programming habits. Most conspicuously, string arguments
substituted for placeholders are not automatically escaped, e.g. < into <,
which causes silent non-well formedness behind the scene. In the other
direction, people also complained about < inexpectedly becoming <, etc.
(i.e. the programmer didn't know about the XML nature of i18n() and doesn't
want this at all).

Based on these two observations, I myself would drop KUIT and that's it. But
there are a few heavy users, and I'd like to know if they would "strongly
object" to this. Among them: KAlarm, Partition Manager, DrKonqi, libkcdraw...

One automatic question could be: can we have KUIT as option, default off? In
KDE 4 this was not even technically possible, due to one ugly design problem
of i18n(), but I plan to deal with this problem in KDE 5; so it should be
technically possible. But, given the usage statistics above, I'm not sure if
it makes sense spending time on this. (There would also have to be some
redesign, making everything stricter, e.g. automatic escaping on
substitution and no mixing with Qt rich text. This means that current KUIT
users who would like to continue to use it, would have to do some manual
checking and modification in existing code.)

-- 
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/20120322/decce7e4/attachment.sig>