Fwd: Rosetta-Feedback - UDS Prague

Wed Jun 11 09:32:52 BST 2008

Algunes propostes interessants

Salut

---------- Forwarded message ----------
From: Sebastian Heinlein <glatzor at ubuntu.com>
Date: Wed, Jun 11, 2008 at 10:02 AM
Subject: Rosetta-Feedback - UDS Prague
To: ubuntu-translators at lists.ubuntu.com
Cc: Arne Goetje <arne at canonical.com>

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 at lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators

-- 
Jordi Irazuzta Cardús
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: signature.asc
Url: https://lists.ubuntu.com/archives/ubuntu-l10n-ca/attachments/20080611/4dba5c79/attachment.asc 