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

[Chusslove Illich]

> [: 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 (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120323/e8757774/attachment.sig>