Rosetta and Upstream

Aron Xu happyaron.xu at
Mon Nov 9 17:36:24 GMT 2009

Thus, I feel kind of difficult to cooperate with upstream even though
I have upstream commit right. Please don't consider me as part of
upstream in my following messages because I will take mostly the
opinions from downstream now, :)

For quality, translations directly on LP for KDE applications are
still far behind upstream due to some reasons that related to former
lacking coordination on Ubuntu Simplified Chinese Translators, and it
is changing rapidly at present. But this commit is really kind of
puzzling because I have reviewed that file with caution before commit
to repository. That long diff produced by this commit is showing its
uselessness, I think and I have read the diff line-by-line just like
what the commit message documented. Mostly this commit changed a style
of translation, which style I guess is more suitable for the
reviewer's taste. I don't believe a file can contain such a large
quantity of mistakes after my review, or many users may have already
complained about translations I've worked on, :)

Taking this opportunity, I would like to talk about something I got
when working on translations downstream as well as upstream.

Firstly, it is a hard job when communicating each other. There ARE
people upstream don't like Launchpad unreasonable, maybe there was
some bad impression that LP had ever given them. Also people familiar
with LP like to take it's advantages such as convenience, and perhaps
don't like to go upstream very much.

Secondly, Kubuntu users and contributors are evidently far less than
Ubuntu, at least I can confirm this in the Greater China user circles.
Yesterday somebody was talking with me about there are more
"well-known" translators working for GNOME as well as Ubuntu than that
on KDE and Kubuntu.

Thirdly, the release time of KDE and Kubuntu is something not good for
communication and cooperation. The integration of GNOME upstream and
Ubuntu downstream in zh_CN is getting very well and most of best
translators on Ubuntu are sent upstream. But for KDE, it is really
difficult even when I want to write a plan for those who on downstream
team want to work for upstream, so they just do it on LP, leave it
there. And upstream don't like to accept the translations due to maybe
some issues, either.

Forthly, zh_CN KDE upstream is lacking hands but I still haven't get a
very proper way to provide such assistance from Ubuntu Simplified
Chinese Translators that can make both sides happy. I can commit the
reviewed messages to KDE svn directly but this will sure make some
people unhappy both sides like this time.

Things might look to be ridiculous to have such a conflict (this
commit, I mean) taking place, because Lie_Ex is the person who take
the most maintainace work on KDE upstream currently, but the fact is
some other people may don't like LP and take a special care on what
was originated from LP, and such situation may caused by a natural
reaction that LP had given them a bad impression before as I've

It could be something unsuitable for upstream leaving such comment on
downstream contributions since we are working on providing a better
result for users and a better free software community. We need more
and more communication and find out a way to cooperate then make it a
better eco-system. The way will differ from Ubuntu/Gnome, because we
have quite different situations.

I believe such conflicts between upstream and downstream are not the
only example. So I suggest that before our making any plan on Project
TimeLord (or just the translation part), let's take a more
comprehensive discussion on the current state of various languages'
Ubuntu Translators team when they working with their respective
upstream teams, and further more, what is the better way to work with
upstream, how to set up a healthy eco-system. This may lead our work
to a more reasonable and effective one.

As for Project Timelord, changes on translations cannot drop the
translation teams and users away then just write out a plan. We need
to know what our translators and users are thinking and doing but not
only some of developers and upstream voices. We are facing our users
and co-working with our teams, not only developers can tell the whole
things and we need to hear more from others. Contributors and users
are our work's key and need most care, I suppose.

Comments welcomed, :)

PS: I am CCing this mail to kde-china at, hopefully can make
someone interested join our discussion.

Best regards,
Aron Xu

2009/11/9 David Planella <david.planella at>:
> Hi all,
> El ds 07 de 11 de 2009 a les 12:32 +0100, en/na Harald Sitter va
> escriure:
>> What zh_cn upstream thinks of upstreamed rosetta translations:
> [...]
>> For reference:
>> I suppose you all know by now how that makes me feel :(
> Let's put this into context, after a chat with Aron Xu, who works on
> coordinating the Ubuntu Simplified Chinese team (and has also got commit
> rights on KDE upstream).
> The Ubuntu Simplified Chinese translations team noticed that the Amarok
> translation was not complete upstream and that no one was working on it,
> so they took the translation from Launchpad, reviewed it and sent it
> upstream.
> The translation apparently did not meet the KDE upstream standards,
> which is fair enough. In my opinion though, it would have been much
> constructive to teach the translators what was wrong or not matching
> their guidelines or glossary of terms rather than writing a commit
> message which in my oppinion sounds unfair to the work of those
> translators doing both the translation and upstreaming.
> From my point of view, the Simplified Chinese Ubuntu translators did the
> right thing. If there were something to improve, I could only think of
> more communication.
> Regards,
> David.
> P.S. In case they want to add any comments, I'm CC'ing Aron and Lie_Ex,
> who have been leading an effort to improve the quality of K/Ubuntu
> Simplified Chinese and in my opinion are doing an awesome job at it.
> --
> David Planella
> Ubuntu Translations Coordinator
> david(dot)planella(at)ubuntu(dot)com

More information about the kubuntu-devel mailing list