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

[David Jarvie]

On Thu, March 22, 2012 10:25 am, Chusslove Illich wrote:
> 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.)

I understand from your email that you are only proposing to remove KUIT
semantic tags, not KUIT context markers. Can you confirm this?

-- 
David Jarvie.
KDE developer.
KAlarm author - http://www.astrojar.org.uk/kalarm