Translation in Qt5

[Chusslove Illich]

>> [: Chusslove Illich :]
>> [...] "they" weren't seriously thinking about disambiguation at all.
>
> [: Oswald Buddenhagen :]
> that's not entirely fair or even accurate.

Granted that I am assuming too much (maybe you're dealing with a vigilant
bunch), but in most scenarios I'd expect to be right. I would expect that
you'd get the same complaint for repeated instances such as:

  msgctxt "@title:window"
  msgid "Add New Profile"
  msgstr ""

  msgctxt "@action:button"
  msgid "Add New Profile"
  msgstr ""

I can give you some numbers on current trunk/l10n-kde4/ POs:

  === Statistics by words ===                                                                                                                         
  Total: 917230
  Total with contexts: 149926 (16.3%)
  Total with context markers: 56172 (6.1%)
  Total with context other than context marker: 108852 (11.9%)
  Total would-be unique without context at all: 816322 (+12.4% growth)
  Total would-be unique without context marker: 832550 (+10.2% growth)

This means that total word count is 12.4% larger due to contexts. Only a
smaller part of this increase belongs to technically necessary contexts
(when two same English strings need different translations); I would have to
sift and compare through all languages to give a number on this as well, but
a generous estimate from my daily experience is not more than one third
(4%). This means that a commercial entity's translation costs would be 8%
higher due to contexts, which professional CAT tools may even ignore. How do
you think they'd feel about it?

At any rate, we both agree manual @-context markers should be documented as
an optional convention, and there are no technical issues with them. Then
who uses them, uses them. So this element is satisfactorily closed.

>> [: Chusslove Illich :]
>> 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.
>
> [: Oswald Buddenhagen :]
> that won't fly. the current library's qt integration both improves its
> usefulness and makes its implementation much more lightweight.
> [...]
> this is a typical case for shared specification, not shared code.

What current library's Qt integration, that wouldn't be present in the
standalone library? How would the implementation be less lightweight?

I agree that few will want to pull in QtCore and QtScript just to be able to
use this library. I agree that having well-defined specification would be
nice, so that someone may implement the same thing on top of whatever. But
if one uses Qt anyway, I don't see an issue with adding this standalone
library too. Except for not wanting to depend on anything but Qt. But then I
don't really care for the walled-garden environments that much to compromise
with the hard requirements.

>> [: Chusslove Illich :]
>> [...] 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.
>
> [: Oswald Buddenhagen :]
> 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.

I can't see how this relates to the technicalities of the workflow.

> [: Oswald Buddenhagen :]
> 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.
> [...]
> 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.

You have to keep in mind that differences between those two target groups
are substantial. Compared to this, programmers have much more similar tools
and workflows (ok, I've read about super-expensive-yet-horrible VCS's and
the rest), graphic artists likewise, etc. Then, translators of KDE apps are
also frequently doing stuff out of KDE (or out of "the Qt ecosystem"), and
out there it is only Gettext/PO (native or not[1]). In my opinion, this
warrants the duality.

Where I stand, there can be no compromise on: PO (including xgettext/msgfmt
support, while msgmerge is implicit by PO) and scripting possibility.
Ditching PO would be enormous loss for almost no gain; ditching scripting
would be highly inconvenient loss for almost no gain. Whether upholding this
leads to full duality, format duality, tool duality, deprecation... I'm fine
with it.

[1] Openoffice? Translated over PO (Libreoffice is drafting a switch to
native). Mozilla? Over PO (web pages too). Anyone's documention? PO.

By the way, Mozilla people are developing an entirely new file format and
runtime engine (don't know about workflow). It includes a sort of what I'd
call "declarative scripting" (not a full scripting language). My guess is,
if it goes through, it'll still be translated mostly over PO :)
https://wiki.mozilla.org/L20n

> 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).

I don't see a need for empty string, would be just confusing. I don't
understand exactly what you do on the way back or where the problem is. Is
it actually related to...

> on top of that, the plural formulas are inherently incompatible (linguist
> adds and preserves gettext ones, but cannot use them in any meaningful
> way).

...this? Why can't it use them? A converter or native parser, why not?

-- 
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/20110707/92d93fba/attachment.sig>