Hello Arne, Jerome, Danilo and Ubuntu translators, at UDS Prague I had a short discussion with Arne and other translators about Rosetta and the general translation process. Here is a summary of the raised issues.
1. Policies As far as I know Canoncial wants to target a Wikipedia-like approach with Rosetta: Many people provide suggestions and correct each other with a kind of quality assurance through the translation team. This policy could be perhaps ok for translations with very few upstream translations, but it doesn't scale for the majority of the European languages. As western Ubuntu translators we only have to translate a small subset of packages, basically the ones written under the Ubuntu umbrella, and the documentation. Furthermore we have to spot for import errors and keep an eye on single missing or changed strings. What we want to avoid is a brain split between upstream and Ubuntu translations. For this task we only need a team of about 5 to 10 active translators, who are capable and interested in polishing. So the education of good translators is more important to us than getting a huge number of translated strings (of questionable quality). Furthermore it is also very time consuming to review and approve suggestions. I don't see a real speedup compared to writing them on my own. Especially since there is no way to provide feedback to the translators in Rosetta. If there is no contact outside of Rosetta I have to correct the same errors again and again. 2. Review instruments Although Rosetta provides some reviewing features there are still some issues. At first a changed and approved suggestion gets submitted under the approver's name and the original suggestion gets lost. This makes it impossible for the original submitter to see what was changed. Furthermore his or her credits get lost. I am not aware to which extend this is a bug. Furthermore high lightening the changes between suggestion and approval would make them more visible. Mostly there are wrong terms, typos or grammar issues. Secondly it would be nice to have a kind of comment field for changed suggestions. Currently I have to open up a chat window or write on a wiki page all the changes with comments to provide feedback to a new translator. This involves a lot of copy and paste work. 3. Quality assurance For the German team I would like to limit the persons who are allowed to make suggestions for out of two reasons: At first I would like to force them to get into contact us before working on the translation to help them to improve their quality, see above. Secondly most suggestions just get not approved since they have not been done systematically enough to send them to upstream. Personally I won't accept translations for non-Ubuntu projects if I don't know that the translator will cooperate with upstream. Currently many people just start to translate and in the end waste their time, since the output does not meet the standards. This is a pity. And I always have a bad feeling telling the people so. Therefor I would support splitting the team into two parts: a translator team who is allowed to only make suggestions and an approver or qa team. This issue has been discussed for ages now. I remember talking with Carlos about this on my first UDS Paris back in 2006. I don't want to enforce this structure for all teams, but I know of some teams who would welcome this more fine grained privilege system. 4. Upstream collaboration Are there any plans to support a version control system import/export like in the RedHat tool? Or to generally improve the system? What is the status on automatically importing from upstream version control system (GNOME, KDE)? 4. Import issues If you take a look at the German translations [1] you will notice a lot of packages with only one to ten changed terms in Launchpad. In many cases these are import errors, since the submitter and approver are registered automatically in Launchpad (e.g. Sascha Herres and Karl Eichwalder for the German gettext translation [1]). As far as I know the Finish team made a manual clean up of their translation. But to be honest this involves a lot of click-click work and I am not sure if I find anybody who is willing to do so for the German translation. 5. Resetting Would it be possible to reset the translations of one language? Mark proposed this solution in a small talk at UDS Sevilla. I already discussed this with Carlos and Danilos some time ago, but at this time they were afraid of manipulating the database directly. Have there been any internal changes that would make this possible now? Next to the import errors we face a lot of old strings of questionable quality in the German translation, since the team had a questionable policy and allowed nearly everyone to join. This ended in about 170 more or less active members. Resetting the database would allow us to make a clear cut here. Before resetting we would make sure that all "valuable" translation would be backed up as po file or included by upstream. 6. Documentation Currently there is not sufficient documentation of Rosetta especially introductions for new translators. In this area the translation teams could collaborate and write a common documentation. Furthermore the policies of Rosetta internals are not available in a central place. E.g. I often get asked by upstream, team members and from outside how "we" handle e.g. overwrites in Rosetta. Most times I can only give them an "AFAIK" answer. Would be nice to have document to point to. FAQs: What happens with the overwrites if upstream includes them? Do we follow upstream again? Get translations of the current stable branch (hardy) automatically applied to the same string in the development version (intrepid)? By the way the "current translation focus for Ubuntu is 7.10" on the central Ubuntu translations page [2]. having a look at my mail inbox I am sure that I could come up with more questions. 7. Best practice It would be nice to see a kind of best practice discussion among the translation teams. How do you handle qa? What are the formal requirements to join your team? Does it make sense to raise the barrier for you (in a non technical way)? Do you have got translators with clear responsibilities (e.g. a special set of packages)? How do you manage the contact with upstream: the large projects e.g. GNOME and KDE and the smaller ones? For example the German KDE translators have got a member in our team, who does a great job. Or just to share tricks and tips e.g. manipulating the batch attribute of the URL [3] to get a better overview or adding custom search engines for Rosetta to your browser. Perhaps Canonical could even sponsor some translation team heads for the next UDS. Cheers, Sebastian [1] https://translations.launchpad.net/ubuntu/hardy/+source/gettext/+pots/gettext-tools/de/+translate [2] https.//translations.launchpad.net/ubuntu [3] https://translations.launchpad.net/ubuntu/hardy/+lang/de/+index?batch=300
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
-- ubuntu-translators mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
