Translation in Qt5

[Oswald Buddenhagen]

On Tue, Jul 05, 2011 at 11:04:41AM +0200, Chusslove Illich wrote:
> [: Oswald Buddenhagen :]
> > - 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...
> 
> >> On that it depends whether those who complained would want to compensate.
> >
> > 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.
> 
that's not entirely fair or even accurate.
for one, i was talking about duplicated messages which positively do
*not* need disambiguation (otherwise the argument would be bogus in the
first place).
second, it isn't too surprising that many people didn't think about
alternatives, given that the automatic contexts are there, even if they
do a rather poor job at disambiguating in a semantically meaningful way.

> 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.
>
that won't fly.
the current library's qt integration both improves its usefulness and
makes its implementation much more lightweight.

> In fact, the hardest thing about that library is designing how it
> should interface and behave.
> 
yes, exactly.
this is a typical case for shared specification, not shared code.

> > - 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,
> 
i mean duplication within the qt ecosystem. it would be a somewhat poor
outcome for kde's qt-addon-ification effort if it doesn't manage to
upstream something as core as i18n.

> > - it fragments the qt ecosystem regarding translations. the
> > communities translating qt and addons would have to deal with two
> > systems.
> 
> Not entirely. [...] 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.
> 
that's only half the problem. one also needs to contribute translations
to qt upstream, and within the legal framework of the qt contribution
model, there is no way around the translators dealing with whatever
system qt chooses to use.

fwiw, there have been thoughts of detaching the "qt translation project"
from the qt contribution model. not sure about the licensing model;
whether lgpl-only would be acceptable.

> > - 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.
>
ok, let's amend that. it deprives (apps & libs using only) qt essentials
from being being really well translatable.
the dualism you are suggesting makes no sense even for qtcore itself -
it has both high-quality community translations and crappy commercial
translations out of need for nokia devices. consequently we need a
system which serves both target groups, without noteworthy compromises
on either side.

> It is better than anything other than raw Gettext/PO. When TS->PO->TS
> roundabout is present, they become equivalent[1].
> 
> [1] Just please add per-file plural formulas. They can be optional,
> with fallback to hardcoded default if missing.
> 
i already did that. in fact, (i think) i fixed all problems you pointed
out in your last review round.
and just for fun, the PO->TS->PO roundtrip should be lossless as well.
in theory, you can directly open PO files in linguist (in practice, it
often does not work due to TS having no representation for PO's #~|).

the one thing that is not compatible are the plurals. during the TS->PO
coversion, i simply duplicate msgid into msgid_plural (i wonder whether
an empty string would work instead?). on the way back, i drop identical
plural sources, while differing ones are stored in an extension field
(which is displayed by linguist, but is otherwise meaningless to the
system). on top of that, the plural formulas are inherently incompatible
(linguist adds and preserves gettext ones, but cannot use them in any
meaningful way).
so while using PO is feasible for transporting qt translations, it isn't
really native and thus would be a suboptimal choice for a default format
given the current state of affairs. it's all about determining
priorities and making choices now.