I'm in agreement of all the points you have made. In Hebrew Translators Team we've also discussed some of those issues. The biggest problem as I see it is (and as you said) that there is no good translation resource for guidelines and FAQ.
Also, there seems to be no way of knowing when new suggestions are submitted in Rosetta. And for two teams of suggestion and approval: we for example won't need suggestion team since we don't have much volunteers in general. Eyal On Wed, Jun 11, 2008 at 11:02 AM, Sebastian Heinlein <[EMAIL PROTECTED]> wrote: > 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 > > > -- > ubuntu-translators mailing list > ubuntu-translators@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators > >
-- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
