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

[Allen Winter]

On Thursday 22 March 2012 6:25:36 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.)
> 
Do you mean all of KDE SC 5 (eventually)?  or just frameworks?

Personally, I have put a lot of time and effort into adding KUIT into my projects
over the years and think it is a great help, even if just for the developers to understand
how the strings are being used. 

True, the semantic tags are harder to use and understand for me in the more complex cases.
Sometimes I'm afraid to touch since I'm not sure the implictions of my change.

I'm really surprised at this proposal. 
I'm not getting what's broken nor what's causing problems.