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