What happens to translations when upstream is brought in

Krzysztof Lichota krzysiek at lichota.net
Fri Aug 18 08:45:25 BST 2006

Og Maciel napisał(a):
> All,
> Good and interesting remarks from both angles have been exposed, but
> the one thing I would like to see (and I'm sure everyone as well) is a
> combined solution to the issue.  It is MHO that any team,
> Gnome/KDE/you-name-it, would be at an advantage point if they were to
> take advantage of what Rosetta can offer now and all the potential it
> has for the future.  Let me explain this a bit more...
> Right now, and I ask for forgiveness if I miss anything OR provide
> incomplete information from this point onward, there is a pretty steep
> learning curve for new collaborators to join any of the major
> localization teams out there.  The reason I say this is due to the
> number of steps and applications required to perform translations the
> way most teams are set up.  You have to learn about PO files, how to
> handle them, how the file headers should be treated, how something
> should be marked as fuzzy, maybe even create a diff (maybe?), etc...

Nope. I agree that there is a steep learning curve. But it is not a
structure of .po file or creating diffs - there are good tools for that
(for example KBabel). All translator has to do is to fetch the file from
WWW page, open it with KBabel and translate it by writing translation in
one box while original is in another box. Then send it in e-mail to
The learning part is getting vocabulary, style, knowing correct "quirks"
in translation (plural forms, desktop entries, comments), getting
experience in translation. None of these issues can be solved by
providing just WWW interface (like Rosetta).
What we get with Rosetta: lack of control over commiting process, no
reviewing, lack of version control, etc.

> I think that Rosetta has bridged the enrmous gap that existed between
> the open source communities (localizartion teams in especific) and the
> general community of users.  This means that even if someone doesn't
> take the time to read any docuemntation put out there by the
> individual teams (Rosetta) and jumps right in, all they are really
> doing is sending more suggestions... There is no major learning curve
> involved, and though you will get some screwy suggestions, you cannot
> deny the overall positive effect that it has not only for the team
> members, who now have more data to sample and maybe come up with the
> best translations (based on their set of quality standards), but also
> for the overall community who can now relate to the whole open source
> experience!

I agree providing _suggestions_ about correct translation might be
valuable, if they are mailed to proper upstream translation team.
But I don't want our translations to be _overridden_ by some random WWW
translator (even if he is a part of Ubuntu translators team).

> So I propose a new direction for this thread.  Instead of trying to
> dig out more issues and problems with the current situation, how about
> we set out to come up with a set of ways we could make it work for
> everyone?
> Ideas?

OK, let's get constructive.
I think what could be done is to make Rosetta only a tool for providing
suggestions to upstream teams. I.e. suggestions made in Rosetta are sent
periodically to upstream team in some kind of diff (to not conflict with
upstream work). It must be easy to review such changes and apply or
reject them. There also must be a way to know the person who provided
this suggestion, to be able to discard all changes from the person if
he/she starts flooding with wrong translations.

	Krzysztof Lichota (Polish KDE translation coordinator)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/ubuntu-translators/attachments/20060818/02647a74/attachment.pgp 

More information about the ubuntu-translators mailing list