Translation in Qt5

[Chusslove Illich]

> [: Oswald Buddenhagen :]
> because "everyone" is complaining about the extra contexts, including our
> qml team. so there will be change. the question is what is necessary to
> compensate it (@tags) and what we can usefully piggy-back on it as we
> change anyway.

I would be interested at what the concrete complaints were. On that it
depends whether those who complained would want to compensate. If they
would, then @-markers do not automatically mean they would also want
semantic markup. And if there is no markup, then @-markers are indeed pure
convention, adding them equals adding one section to documentation.

> you are missing the point here. there won't be a "kde app" distinction any
> more, not at the level where i18n starts to play a role (which is qtcore).
> kde libs continuing to have a separate i18n system will immediately cut
> half of their value as qt addons.

I do not understand this. The way I see it, there will not be KDE app
distinction only because there will not be KDE libs any more. You build an
app or a library, and make use of pieces of Qt, pieces of KDE framework, and
of whatever else you think is nice and can afford to depend on. If you can
depend on N pieces of KDE framework, but N+1 to include KDE translation
system is too much, that's fine by me.

I could even conjecture an advantage in having two separate translation
systems (as opposed to merely disadvantages in designing and maintaining a
single frankestein mix).

I try to at least cursory follow what happens in professional translation
world. A profesional translation sevices shop, and even freelance
professional translators, basically stick to their CAT (computer-aided
translation) tool of choice. These tools have piles and piles of features,
and are the only technical environment there is for them. The format of the
files to be translated is irrelevant, it must only be supported by the CAT
tool. There is no concept of merging translation files; each new version of
project files are translated anew, by relying on the TM (translation memory)
of the CAT tool. TM's are a tresure on their own, kept as a confidential
data, even traded for money.

On the average, the amount of translations a professional translator outputs
in say a month is huge, possibly order of magnitude greater than that of an
average hobby/volunteer translator. The professional translator has little
incentive (to be fair, not the slightest) to expend considerable effort on
the far end of the diminishing returns curve, where stuff such as
translation scripting lies. Even something rather trivial such as plural
support, in all the years Linguist is the only other system that introduced
it (and that fairly late compared to PO).

This means there is a considerable rift between the needs and practices of
professional and hobby/volunteer translators, much wider then between e.g.
programmers. It therefore makes sense to optimize translation systems for
the two groups.

In that sense, I would start to gear Linguist system towards the
professional bunch. This would both ease maintenance and bring selling
advantage. You could immediatelly drop Linguist the editor, since
professionals will just hate it compared to their CAT tool of choice. You
can drop most bells and whistles from the Linguist the format, since to the
professionals they are just superfluous gimmicks. You should instead talk to
CAT vendors (e.g. Lionbridge (Trados), Wordfast) to add native Linguist
format support to their tools. This is the place where an XML format is
world ahead of PO: it would be much easier to negotiate/implement support
for yet another XML format in an established CAT tool. 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.

The other system would be targeted to software developers who would rely on
hobby/volunteer/community translations. Due to Gettext's de-facto dominance
and overall superiorty over anything else, this system must be Gettext based
in both the format and process tooling (what it does not have to do is use
gettext() from glibc). It would carry over all the advanced features of the
current KDE system, and possibly some more, since this group of translators
can afford and is willing to use them.

-- 
Chusslove Illich (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110705/c31de6e1/attachment.sig>