What happens to translations when upstream is brought in

Danilo Šegan danilo at canonical.com
Tue Aug 22 13:29:58 BST 2006

Hi Krzysztof,

On August 17th, Krzysztof Lichota wrote:

> No, you are missing the point. Ubuntu translators team has no connection
> to KDE translation team. The person approving members of translation
> team does not have to even use KDE, not to mention to know style guide
> of KDE team. And there is no way to limit which translation can be done
> by whom, so person who is great translator of, lets say, XFCE tools
> might go and screw up KDE translation by using wrong vocabulary,
> incorrect plural forms, etc.

As with any team, many things are up-to internal team organization.  I
know Serbian KDE translation team has at least two commiters, just
like Serbian Gnome and Serbian Fedora teams.

Obviously, the way teams are organized NOW in Rosetta is wrong, since
many more people have such commit rights.  But it doesn't mean Rosetta
is entirely to blame.  The blame is on Rosetta for not communicating
well on how one should organize a team.  The blame is on Rosetta for
not allowing "associate" members without "commit" privileges.

But the blame is not on Rosetta for other team administrators allowing
anyone to commit translations.  And if you have tried, you would have
probably found out that Rosetta Administrators care a lot about
upstream, and that you would have probably be granted administration
privileges for your language team only if you applied.  But just like
with KDE, if there is more than one trustworthy person, it's assumed
that they coordinate between themselves.

> The rule "everyone can translate anything" is wrong.

And that's not true of Rosetta either.  The problem is with teams.  I
run into exact same problems with Serbian team (even if I am upstream
Gnome translation coordinator, my membership has even expired in
ubuntu-l10n-sr) with many different people (I've never heard of
before) allowed to translate.

The solution is simple: remove them from Serbian team.  Anyone who
gets into a team must be aware of responsibilities, and needs to watch
out not to step on anyone's toes.

So, true statement for Rosetta is: "everyone can *suggest* a translation
for anything".

> Inside KDE translation team not everyone has right to commit
> translations to repository, exactly because not everyone is trusted to
> create correct (and good) translation. Control is necessary to provide
> quality.

Exactly, and that's how one should organize teams in Rosetta as well.
Others are able to provide suggestions *only*, so they *can't*
overwrite translations.

Rosetta *can* help here with another level of team membership, which
will basically simply list "associate members" without any rights
(this would be just for display purposes, so team administrators don't
add anybody and everybody to a team, thus giving them commit rights).

If you notice, this is only about *display* and *recognition* (i.e. no
functionality would change compared to these members not being part of
a team), which means that Rosetta is already fully usable even in
those scenarios, even if it's far from perfect.

So, the suggestion for Ubuntu l10n team administrators is:

 - keep only a couple of people in the team
 - those people would be assigned specific sub-parts/products, just
   like it's usually done in other projects (eg. in Gnome, I have a
   single translator for Evolution, another for Gimp, one allowed to
   do updates/fixes in all modules...), so you might have single KDE
   committer, single Gnome comitter, single XFCE...
 - it's up to them not to mess with else's work: that's common with
   other translation projects as well, if you've got more than one
   committer (eg. if I touched Evo translation, I would expect Evo
   maintainer to get upset about it, even if system [CVS] allows me to)

There will soon also be Ubuntu l10n coordinator who will help with
misuses and such (eg. if XFCE translator decides to mess up KDE
translation, he'll be able to remove him from the team).

> I am getting tired of repeating the same arguments over and over.
> Please read
> http://wiki.kde.org/tiki-index.php?page=KDERosettaCollaboration, it has
> been provided exactly for the purpose of explaining our arguments. It
> also has proposal of solutions.

I've seen this earlier (forwarded to me by Caslav Ilic, one of KDE
i18n hackers and Serbian translator), and we had a short discussion on
this topic. We feel that most of these are misunderstandings due to
bad communication, and we'll be working on fixing that!  Others are
real issues, and we'll be working on fixing those as well.

We will probably post an explanation of all the stuff there one of
these days.

As I said, I am also a translator and I am intimately familiar with
problems of translation and team organization.  And I'll be sure to
help make Rosetta better for everybody, including upstream.

We'll also be working on improving workflow and adding more
fine-grained privileges to Rosetta.


More information about the rosetta-users mailing list