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 (Часлав Илић)
signature.asc
Description: This is a digitally signed message part.