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

[Chusslove Illich]

> [: Oswald Buddenhagen :]
> i would find this number way more helpful if it gave the percentage of
> strings with markup only amongst strings which have placeholders, as that
> is by far the most interesting target group.

I recognize that simply taking into account all messages is somewhat
lacking, but it is also not that obvious one should rather look at messages
with placeholders. Here is the comparision between the two:

                       total    KUIT-tagged     ratio
  all messages        202995           1144     0.56%
  placeholder only     15771            557     3.53%

While ratio is much higher on placeholders, half of all used tags are not in
messages with placeholders.

Maybe the best reference of what should be considered "thorough use" would
be to look at one application that uses it thoroughly. I've seen at least
KAlarm to be such, and for it the statistics are:

                       total    KUIT-tagged     ratio
  all messages          1037            153    14.75%
  placeholder only       125            100    80.00%

_From this it would appear that in all KDE current use of KUIT is 3.8% (0.56/
14.75) of thorough use over all messages, and 4.4% (3.53/80.00) over
placeholder only. Which, being roughly equal, indicates that simply taking
all messages is representative enough... But the "thorough use" sample here
is small, granted.

> i wouldn't set the hopes too high. while the system is certainly well
> thought out, it isn't such a spectacular improvement (as far as the
> average dev is concerned) that you'd have much of a chance to stand
> against the momentum of the solutions the various communities have.

That's exactly what it seems to me too. So, that small hope is simply this:
make a standalone library available, buildable with different "backends"
(QtCore/QtScript, GLib/SpiderMonkey...), several language/framework
bindings, and see what happens. But I don't say I'll do it, still pondering
between opposed ends of "lot of work" and "low probability of acceptance".
(It also needs some support from Gettext, and in this respect it is
troublesome that Gettext maintainer remained silent on the proposal.)

> it's way more likely that you gain traction when you optimize for minimal
> migration pain in a community which is actually in search of a solution.
> the next qt contributor summit is in only two months.

Well... speaking of relative improvement, doing something outside of PO/
Gettext base would be to me a regression that dwarfs any improvement I
wanted to have :)

-- 
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/20120324/f593aa72/attachment.sig>