> [: David Jarvie :] > The original intention of enabling consistent formatting of displayed text > via semantic tags seems a very desirable one. Removing the tags seems to > imply that KDE would abandon the aim of presenting a consistent interface > for such items. If an inconsistent interface is generally considered > acceptable, then I can live with it.
Based on the (lack of) usage so far, I would say that inconsistent UI text markup is considered acceptable. Or at least too small an issue to be worth bothering with. It occured to me that I could examine usage-over-time statistics, since KDE 4.0. Here is the percentage of strings in core (SC) modules containing KUIT markup, in 6-month steps: 2008-01-01 0.28% 2008-06-01 0.32% 2009-01-01 0.36% 2009-06-01 0.41% 2010-01-01 0.42% 2010-06-01 0.41% 2011-01-01 0.49% 2011-06-01 0.49% 2012-01-01 0.60% While there is some rise in usage, I would consider a 0.32% rise in 4 years to support the "tolerable inconsistency" conclusion above. > Removing the functional effects which context markers have, including > the /format modifiers, might have a significant effect if this makes > everything plain text rather than rich text, so at first sight I'm not too > keen on this idea. When KUIT tags are removed on conversion target formats would be heeded, since they are statically resolvable. So one would end up with some strings converting to plain text, and other Qt rich text. In other words, it would become as if these visual formats were used carefully and consistently from the start. > [...] if we really want to try to make these interface elements > consistent, we shouldn't drop the existing scheme without first > considering what might replace it. Even if majority of programmers would rather not bother, I agree that it would be nice to provide for those who would. So, actually, I have considered a lot what the replacement might be, one which would avoid technical issues I observed so far, and provide extra flexibility that I've seen to be needed. I wrote it up in a proposal for Gettext itself, but there was little enthusiasm. The proposal is here: http://nedohodnik.net/gettextbis/. Chapter 4 and section 5.1 deal with markup, and it is easy to extrapolate back to KDE i18n (revert to %1, %2... placeholders, and consider ggettext() = ki18n() and igettext() = i18n()). However, I don't propose implementing this now, for two reasons. First is that it would be some work in absence of significant number of interested people (which, admittedly, usually does not stop me...), and the second is that I have a small hope that in the future we could actually push the full system as proposed :) -- Chusslove Illich (Часлав Илић)
signature.asc
Description: This is a digitally signed message part.