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