Translation in Qt5

[Chusslove Illich]

>>> [: Oswald Buddenhagen :]
>>> because "everyone" is complaining about the extra contexts, including
>>> our qml team.
>>
>> [: Chusslove Illich :]
>> I would be interested at what the concrete complaints were.
>
> [: Oswald Buddenhagen :]
> - class names are not meaningful in qml
>
> additionally, from the lupdate pov, the parsing of class names (and
> namespaces) is unreliable in the face of #ifdefs and other preprocessor
> magic.

These are rock-solid reasons, and the ones I would have been against such an
automatic approach in the first place. Contexts should be manual.

Automatic should be extracted comments (that's PO terminology, #. comments).
Since they are comments, all sorts of parsing unreliability is totally fine,
so long as the overal effect is clearly benefitial.

> - the class names cause many messages to be duplicated

This is exactly the reason I was afraid someone had put out :) It basically
reveals that "they" care zero about context. It shows you...

>> [: Chusslove Illich :]
>> On that it depends whether those who complained would want to compensate.
>
> [: Oswald Buddenhagen :]
> sure they do - even if they don't know yet. the contexts were trying to
> automate disambiguation.[...]

...that "they" weren't seriously thinking about disambiguation at all.

> in fact, nobody asked for semantic markup. so i asked you why you added
> it, and what changed since.

As expected. I'll get to that one in an another reply.

> - it's yet another library. who wants to link kdecore (or maybe ki18n if
> we went for such absurdly fine granularity) for "just" translations,
> especially given that they are usually an afterthought?

I really would like it to be a library on its own, precisely so that I could
use it and recommend it out of KDE (as in KDE project/community) and Qt
apps. In fact, the hardest thing about that library is designing how it
should interface and behave. Implementation is much easier, assuming all
pieces listed in footnote 3 in my previous message are available. I would be
more than happy if someone were to port it to, say, Glib and whatever. I am
primarily a translator, and therefore I want as wide adoption of the
advanced concepts that KDE currently offers, rather than stop at "our
framework offers the best i18n".

> - the ongoing basic feature duplication puts kde into a bad light

There is already Linguist and raw Gettext. That already makes for
duplication, unless Qt switches to raw Gettext, or Qt and Gettext meet half-
way (absurd). KDE i18n library would be, as it is, a layer atop Gettext, so
it does not add to duplication as such (runtime MO parsing would be
duplicated, but that's internal and trivial).

> - it fragments the qt ecosystem regarding translations. the communities
> translating qt and addons would have to deal with two systems.

Not entirely. Though I shudder from Scripty, I will personally go in and
hack it to do the TS->PO->TS roundabout, so that KDE (as in KDE Translation
Project) translators do not feel Linguist workflow. There would only be lack
of advanced features (scripting, etc.) but that is no news, since we already
translate pure text, documentation, and hopefully other custom formats in
the future (all over PO of course).

> - it deprives qt essentials themselves and addons & apps which want to
> depend only on the essentials from having a reasonable translation system.

Linguist is a *reasonable* translation system. It is better than anything
other than raw Gettext/PO. When TS->PO->TS roundabout is present, they
become equivalent[1]. KDE i18n atop Gettext is *martial arts* of translation
(but such that willing translators can steadily improve with it, rather than
being thrown into the breach at first encounter).

[1] Just please add per-file plural formulas. They can be optional, with
fallback to hardcoded default if missing.

>> [: Chusslove Illich :]
>> Then you can market Qt translation system as seamlessly fitting with the
>> translation industry practices, reducing costs of translation services --
>> I think this is by far the most important "feature" you can have.
>
> [: Oswald Buddenhagen :]
> "optimize for crap". no way. if somebody cares, he can make *that* an
> addon.

I bet even money you would say this out loud :) From the rational business
point of view, I hold by my advice and estimate. It's also not mere crap,
both approaches are Pareto-optimal (efficiency vs. quality). But I totally
understand your sentiment, I can't stand it either.

-- 
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/20110705/a40a70b7/attachment.sig>