[Qt-l10n] [Development] Using Transifex for handling Qt localization?

[mvillarino]

2012/5/18, Oswald Buddenhagen <oswald.buddenhagen at nokia.com>:
> On Wed, May 16, 2012 at 03:55:41PM -0700, ext Quim Gil wrote:
>> - How valuable is to have an efficient tool for handling translations
>> between teams - as opposed to whatever process we have now? Are we happy
>> with the current system? Do we believe we would improve significantly
>> with a tool like Transifex?
> not being a translator myself (except to help out with strings i have
> some relation to as the developer), i cannot really assess the added
> value. i can imagine it would be significant - qt linguist just ain't
> that great, and our review infrastructure completely sucks for
> translations.
> i cc'd the qt-l10n list to move the discussion over to a relevant place.

Ok, my 0,02 eur: I'm proud to say my experience with Qt tranlation is
like a pain in the part of the body you would prefer the most not to
suffer a pain, and that is neither because ot the file format you
deliver your data to the translation service providers, nor because of
lupdate nor Qt linguist (=the cat tool), but because of the versioning
control system: git. I understand it is great for source code, but it
is soooo easy to shoot your own leg that it discourages some people (I
mean me).

In fact, in my  oppinion Qt linguist is a nice translation tool that
only lacks of support for translation memory exchange format and
termbase format.

If you plan to use a tool like transifex, or broadly speaking to
outsource the management of localization through some kind of web
interface: go on, as far as you let your translators forget about vcs,
and you keep a contact person.

>> As far as Reviewing is concerned, there is this feature in Transifex
>> itself. Each string can be reviewed from a privileged translator. Each
>> team can have any number of reviewers.
>>
> you still need to get this sorted with nokia legal, but it sounds like
> the tools to make a point are there.
>
> but irrespective of that, i think it would indeed make sense to make the
> translations lgpl-only (or use a CC license, as that's more appropriate,
> at least in theory) - there doesn't seem to be much of a business case
> for making them "proprietarily utilizable" (though we'd need some hard
> data from digia on that matter). it would also enable us to use a lot of
> qt translations from the kde community.

Sure. Have you calculated how many of your translators are also kde translators?

> one thing to consider is that some translators may not particularly like
> the idea of using a proprietary web app for their work, so gerrit would
> still need to be the authoritative repository with "normal" submissions
> enabled. i think that's doable.

Best regards,
Marcelino Villarino