RosettaAndUpstreamCollaboration
This is a response to KDE's concerns about Rosetta and its relation to the KDE i18n project.
Many of these concerns are valid. Rosetta developers are working to alleviate some of the current problems, while allowing people to easily translate Ubuntu, Kubuntu and other derivatives via the web interface.
We intend to have fluid relations with our upstream translations, and we're trying to improve things as fast as we can. One of our first initiatives is the appointment of a Ubuntu Localisation Coordinator. This person will have, as one of his/her main tasks, communicating with upstream translation teams to avoid clashes and confusion.
1, 2) People discovering content in Rosetta is not the same as KDE SVN's.
This is a recurring problem. We can't do much about it with the current Rosetta, and I believe the best fix for this is promoting Ubuntu teams to communicate and collaborate with their "upstream teams" as much as they can. There are teams doing this and it works for them.
This is defeated by the "oversized teams" problem, but that's another story we hope the Ubuntu Translator Coordinator and the new guidelines we're preparing will be able to help with. (See #3)
3) Rosetta's low entry barrier.
This is one of our key strong points, but we need to find ways to improve quality control. There is work in progress to fix this.
The way we first designed Rosetta, it had no distinction between people who wanted to suggest translations for a language, and experienced translators for a project. This led to large teams of translators with highly varied skill levels. We have since fixed this.
In general, Ubuntu team leaders should try to keep their teams under control, granting membership only to those translators who have proven capable of doing correct translations. A team member should be equivalent to someone you would trust with CVS/SVN account in GNOME's or KDE's source code repositories; others are still able to post suggestions even if they are not members of the team in launchpad.
Also, communication between translator team members is strongly encouraged -- to minimise errors from lack of coordination, to reach consensus on difficult or new translations in your language, and so on. Joining the upstream mailing lists is maybe a good idea as well.
The Italian and Brazilian teams have very good documentation regarding some of their internal policies that have helped them improve the quality of their translations. As far as I can tell, they are only in Italian and Brazilian, though.
We should also mention the recent GNOME translation credits debate, when it appeared that some French Ubuntu translations didn't have the original translation credits, only those for the Ubuntu teams. We're very sorry about this happening. We're considering special-casing that kind of translation message, so that people can only add to, not replace, what comes from the upstream files.
4) Rosetta is not Free Software.
Most online services are not Free Software. (Even for those with source code available, such as Slashdot and SourceForge, the source code provided is different from the source code used on the site.) But we pledge that we will never lock people in: it will always be possible to download your data in a standard format. (In the case of translations, you can download any translations as PO files.)
Even if the code was published, it would not be particularly useful to individuals: Canonical funds a dedicated team of developers and administrators to keep Launchpad running. Nevertheless, Mark Shuttleworth has stated that Launchpad will be open sourced sometime in the future.
5) New upstream strings don't overwrite some Rosetta content.
We do this on purpose, to let fixes or Ubuntu-specific translations prevail over upstream's as new versions of Ubuntu are imported. The problem is that this has proven more harmful than helpful. To fix this, we are adding mechanisms to make it easy to compare Rosetta translations with upsteam translations, and to revert to upstream translations.
Related:
6. Unclear versions of imported strings.
Solution: Rosetta's main focus is to aid Ubuntu/Kubuntu localisation, which means that the strings in use come from the actual tarballs uploaded to the distribution's archive. Picking up further improvements from KDE's SVN is planned, but won't happen in the short term.
7. Ubuntu/Kubuntu-specific strings mixed with upstream strings.
The wiki authors propose adding these to a separate pot file, so things are clearly differentiated.
I don't think this is a big enough problem to take such a complex route. This can be handled with some msgmerging, to obtain a file which can be committed in KDE SVN.
RosettaAndUpstreamCollaboration (last edited 2009-07-20 13:30:56 by p54A13477)