Project Timelord -- Initial consideration
David Planella
david.planella at ubuntu.com
Wed Nov 4 13:58:55 GMT 2009
Hi all,
First of all, let me start with a word of thanks to all of you who've
participated in some way or another in translations on this cycle, be it
translators, developers, documenters, advocates or any other
contributors. You've done a truly rocking job, and I believe I can say
without a doubt that this release has been the best in translations so
far, with Kubuntu featuring the most visible results.
It's been my first complete cycle as UTC. I've learned a lot, and I'm
very proud of what we've achieved together. I probably can't make an
exhaustive list of what we've done, but here are some of the items we've
delivered:
* The UTC team at full swing. The team [1] has been building up,
learning, defining processes and at the same time doing awesome
work in administering and coordinating translations globally.
* The ubuntu-translations project. Born from an initiative
discussed at UDS, this project in Launchpad [2] has been
initially used as a central place to track and fix translation
issues. We've seen more translation bugs reported, triaged and
fixed than ever.
* Communication. More transparent processes, documentation and
regular communication and focus through meetings.
* UDS. We've seen a lot of good discussions on UDS, and this time
we're going to have even more content.
* Governance, best practices. Started an effort to define policies
and best practices in Ubuntu translations, with the intention of
achieving translations with the best quality around.
* Jams. Translation Jams are from now on a regular feature of the
Ubuntu Global Jam.
* Translation Days. We've kicked off the Kubuntu Translation Days,
to give some love to the distro's translations.
For me, this is just the beginning. We've started with a great
foundation to build upon, and make Kubuntu and Ubuntu the distros with
best translations around.
I've read the Project Timelord's goals with interest, and I'm glad to
see that translations are a major focus. With all said, what strikes me
is that there has been no communication with the translations teams
before drafting such a proposal. Although developers do have a great
deal of interaction with Rosetta, it is ultimately a tool for
translators, and I consider it very important that they have their say
on this as well. On that question, I greatly appreciate the "The
ultimate decision will be left to the translation community" point in
the Solution section of the document.
At the risk of being repetitive, I'll mention again that I'm very proud
on the path we've started for communication between the several actors
involved (Kubuntu developers, Translations Community, Launchpad
Translations developers, Ubuntu developers), which I think is key in
solving a great deal of the issues.
We've got quite a lot of communication channels available (translations
meetings, UDS, ubuntu-translators and ubuntu-translations-coordinators
ML, #ubuntu-translators, #launchpad, #launchpad-dev) and I would like to
see all of us involved in translations to more actively use those which
normally fall outside of our day-to-day communities.
I'd also like to comment on some particular points of the proposal:
"most of the bugs where Launchpad Translations breaks upstream
translations have been fixed; as far as we know."
There are a lot of translation bugs, which are not exclusive to
Launchpad Translations. Since KDE switched to using the standard gettext
we've had less and less problems, and I believe this cycle has been
particularly good in terms of not having big infrastructural bugs. There
are many other types of bugs affecting Kubuntu translations: packaging,
translations themselves and yes, sometimes there are also mistakes in
upstream translations [3]. I agree with Riddell that QA is a point which
still needs much improvement, but what have been the particular issues
in this release which have made you want to stop using Launchpad for
translations?
"the current levels of Kubuntu developer and translator resources are
insufficient to reap the intended benefits of the system, much less fix
what goes wrong. Kubuntu modifications to applications do not get
translated in most of our supported languages due to a virtually
nonexistent Kubuntu translation team. This lack of resources also leaves
us unable to perform quality assurance on any languages other than the
one or two major languages translations-minded Kubuntu developers can
keep an eye on"
This is true, but it is also getting traction. I've had several
questions from different Ubuntu translation teams to promote and better
document the Kubuntu translation process, because they'd like to
translate Kubuntu. It is difficult sometimes for the UTC team as well,
because it is an involved process, but we've already started a
documentation effort [4], to be further expanded (help appreciated)
which should help on that aspect.
"A great part of the reason we do not have Kubuntu translators is that
in the past translations have been abysmal, depsite the hard work of the
Kubuntu translators. We lost entire languages-worth due to this. The
other part of the reason is the Launchpad Translations interface
itself."
I totally agree on that. And improving that is I believe what we are
working towards.
"Through chats with KDE translators on the KDE translators mailing list
and elsewhere, we have found that the use of Rosetta is a major
dealbreaker for getting them to help with our translations. One thing is
clear; to get a translations community we must make it as convenient as
possible for existing translators to contribute, and currently
translators have expressed their disinterest in the Launchpad
Translations interface."
Some of the concerns related to the particular point of using Launchpad
for translation I've heard have mostly to do with the interface
(although anyone not happy with the interface can download the PO files
and translate in the "classical" way), Launchpad not being Open Source
(does no longer apply) and Kubuntu translators modifying upstream
translations. Although we do still have issues, translation teams have
got a lot better in reviewing translations and using moderated policies
to control who can modify strings. They have also got resources on how
to get in touch and work with KDE upstream [5]. Finally, You are talking
of upstream translators, but I think we should not exclude Kubuntu
translators, which do have an interest in translating through Launchpad.
El dv 23 de 10 de 2009 a les 10:09 +0200, en/na Harald Sitter va
escriure:
>
> Using Rosetta is difficult from a maintenance POV. I think I outlined
> all concerns in a document that is yet to be published, so I will not
> state them right now, but to sum it up: we are always one step behind
> upstream, we are always one step behind Ubuntu, 95% of the cycle no
> one gives a crap, bugs fall through the cracks unless the UTC catch
> them, the translation quality is at times worse than what upstram got.
We do care about translation bugs, be it in Ubuntu or Kubuntu, and we
work hard at triaging and fixing them, or poking the relevant developers
to look at them. The ubuntu-translations project has helped a lot in not
letting translation bugs fall through the cracks in this cycle.
JohntheEchidna in particular (thanks!) has been rocking in assigning bug
tasks to the ubuntu-translations project for Kubuntu translation bugs,
and notifying the UTC team about them.
When talking about quality, I think we should make a difference between
technical quality and translation quality per se. On the latter, we
should not forget that there are a lot of Ubuntu and Kubuntu translation
teams with the same or even stricter reviewing processes, who are
working hard to have quality translations as well.
In conclusion, I think it is perfectly valid to discuss whether the
Kubuntu community wants to stop using Launchpad Translations, but I
would strongly discourage you of doing that. Despite the issues we all
know, I do believe it is a great collaborative translation tool for
distributions and projects, and I believe adopting an alternative at
this point would not only be more time consuming but would also
significantly raise the entry barrier for translators. If the discussion
is to be going further, I'd like to see the translation communities also
involved, and a concrete plan on an alternative infrastructure to manage
the translations of Kubuntu modifications or specific applications. Most
especially, also consideration on how a new translation community would
be built around this. In any case, I would instead prefer to focus on
the great work we've been doing together on this cycle and build upon it
for further improvement.
Thanks.
Regards,
David.
[1] https://wiki.ubuntu.com/UbuntuTranslationsCoordinators
[2] https://launchpad.net/ubuntu-translations
[] https://bugs.launchpad.net/ubuntu-translations/+bug/460984
[4]
https://wiki.ubuntu.com/Translations/Upstream/KDE/KubuntuTranslationsLifecycle
[5] https://wiki.ubuntu.com/Translations/Upstream/KDE
--
David Planella
Ubuntu Translations Coordinator
david(dot)planella(at)ubuntu(dot)com
www.ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: =?ISO-8859-1?Q?Aix=F2?= =?ISO-8859-1?Q?_=E9s?= una part
d'un missatge signada digitalment
Url : https://lists.ubuntu.com/archives/kubuntu-devel/attachments/20091104/b40b30d9/attachment.pgp
More information about the kubuntu-devel
mailing list