Rosetta-Feedback - UDS Prague

[Danilo Šegan]

Hi Sebastian,

Thanks for taking the time to write this down.

Прошле среде у 10:02, Sebastian Heinlein написа:

> Hello Arne, Jerome, Danilo and Ubuntu translators,

It's Jeroen :)

> 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.

I'd disagree.  In practice, we've had quite a few problems with our
past implementation, but I think in the end, we can get there.  Of
course, it would be much faster if we didn't have to fight past
problems at the same time, but that's how life goes.

(note that we do have stricter privilege levels: it's just that Ubuntu
is using a relatively open one)

Also, we do have plans to improve the experience and make it all
easier and more natural.  See "find-programs-to-translate" spec for a
bunch of plans we've got there (i.e. it will be easy to see what
requires your attention), it's already easier to see what has someone
worked on (i.e. you can see only a single person's contributions per
PO file) and evaluate quality of his suggestions/translations.

Note that I am not speaking without any experience: I am an upstream
GNOME translator, and also GNOME Translation Project spokesperson.
I.e. I do care about how we work with upstream.

> 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.

Indeed, this is something where we need better sync with upstream
translations for it to be practical: i.e. as long as what you see in
Launchpad are the latest translations from upstream, I don't see any
problem with current Launchpad approach.  Of course, some minor UI
improvements are to be done (like grouping packages into
ubuntu-desktop, kubuntu-desktop,...), and we are planning on doing
them, but it all takes time.

> So the education of good translators is more important to us than
> getting a huge number of translated strings (of questionable quality).

That's what's important for any team.  It has been my opinion that we
have so far lacked important features in Launchpad Translations so far

> 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.

I believe the lack of documentation is to blame here.  Reviewing
suggestions would not speed you up short-term, but once you have
reviewed enough of someone's translations and start considering him a
good translator, you'd make him a reviewer as well, and then it would
be two of you translating, and two of you reviewing.

I admit we lack the contextual communication capabilities, and it's
been a while since we looked at it (we have a bug about having
discussions per-messages, but that seems too fragile imho [bug 25]:
i.e. it would be easy to miss any responses, unless a lot of care is
taken to present them to translators and reviewers in a nice way).

> 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.

This is mostly a practical issue.  It's impossible to perfectly decide
when a certain submission is worthy of being marked as a new one, so
we are doing just the extremes: either you accept the suggestion
as-is, or you modify it and submit it as your own.  I don't want to
add more complexity to our translating/review interfaces to provide a
checkbox along the lines of 'this is a small change', but I'd be
happy to look into automatically detecting typo-fixes and maybe even
terminology changes.

Anyway, I'd never lean on going all the way: keeping all versions of a
translation with contextual marking of who did what change and
similar.  That would unnecessarily complicate everything, and I
believe it would be for little gain (we are talking about relatively
short strings here).

> Furthermore high lightening the changes between suggestion and approval
> would make them more visible. Mostly there are wrong terms, typos or
> grammar issues.

Yeah, I am pretty sure we have a bug and/or blueprint about this.  Or
we've discussed it at length.  It should be simple to implement, but
with so much stuff on our plates, I am not sure it's going to raise in
priority anytime soon.

> 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.

So, maybe have something along the lines:

 [x] Modify then approve suggestion and comment on the change
 [Existing suggestion]
 [Type your comment

 ]

Again, I dislike cluttering the UI further, but this sounds like a
good idea.  However, deciding how this is going to get to the
translator (i.e. emailed-as-a-batch-of-comments, somewhere in the web
UI, public, making it easily accessible later as well, etc.) is the
tricky bit.  Again, this could be considered part of bug 25 and
related blueprints.

And while we are on the topic of reviewing, I suspect you might not
have seen the 'easy translator evaluation' functionality: you can now
go to person's translations page and click on a single PO file which
will list all contributions she made to that PO file in a compressed
form.  This should greatly help with reviewing someone's abilities.

Unfortunately, this is not nicely tied in with the rest of
Translations experience, which makes it hard to find.

Ideally, on your own Translations homepage you'd have a few options on
where to go:

 1. These programs need updates (and you previously showed interest in
    translating them)
    * Nautilus
    * Evolution
 2. You can review new suggestions in these modules
    * Gnome Panel
    * Language Selector
 3. You've recently reviewed suggestions by these people. Look at
    their recent contributions and decide whether you want to promote
    them to reviewers.
    * Karl (his work in _Evolution_, _gnome-desktop_)
...

> 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.

Right, I can see the reasoning behind this, and I fully agree.  The
problem is that our privilege levels are per project/distribution atm,
so we can't have that in an easy way.  FWIW, we were planning on
fixing this by introducing separate roles into translation teams
(reviewers/translators), where everything would be self-evident.
However, this blueprint implementation was post-poned because of some
internal reasons.

> 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.

Yeah, as I said, I fully agree with the reasoning behind this: what we
are spending a lot of time on is helping people not waste their time
on translating something which is not going to be used (which is why
we do upstream template approvals).

> 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.

As I said, this has been blocked on some internal issues.  We're
pretty short-handed, with a lot of work to do, and there are many old
issues to fight with.  It's something I am personally interested in as
well.  If it was at all possible, I'd start working on it this very
instant (it's actually blocking us from delivering many new
interesting improvements to how everything works in LP Translations).

I am pretty sure we'd be looking into finally working on this in the
next few months.

> 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)?

If by 'plan' you mean 'concrete idea about how and/or when' then the
answer is 'no'.  We do want to do this

> 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]).

They are not necessarily import _errors_.  I.e. in some strange set of
occurrences it can happen that this is the best Launchpad could figure
out.

I.e. imagine sequence of uploads:

 Last-Translator: Sascha
 msgid "File" msgstr "Datei"

 Last-Translator: Karl
 msgid "File" msgstr "DDatei"

 Last-Translator: Karl
 msgid "File" msgstr "Datei"

This may lead to a case of translator Sascha and reviewer Karl.  Also,
in the past, we didn't have the reviewer field, so when it was
introduced, all translators were copied into it for corresponding
translations.

The problem is that Launchpad keeps more meta-data than PO files do.
We can't solve this problem completely, so occasional mistake
shouldn't be too troublesome.

(not to mention how people frequently miss to update Last-Translator
altogether)

> 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.

The problems you are talking about here (and below) are of a different
nature: people have submitted translations through LP while upstream
translations came later.  So, we first got translation in LP, upstream
translations got imported later, but were never activated since we
prefer the LP translations.  This has been discussed at length, and we
are looking into mitigating the issue (I've actually already started
on it, but it had to be post-poned for a while).

> 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?

It is and was possible always, it's just a very high risk change,
meaning it would need extensive testing.  Extensive testing means a
lot of work hours.

To be honest, this is a step which we planned to do for those Ubuntu
translation teams want it.  So, yes, we will work on this, but as you
can see, we've seen a bunch of things we 'will work on' just in this
reply.

> 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.

Yeah, that's one of the big sources of such problematic strings.

> 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.

I'd rather make them suggestions that need review.

> 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.

Agreed.  Totally agreed.  I'd really like translation teams to
document their best practices on help.launchpad.net (and please
coordinate with Matt Revell: he's the LP doc team leader), and I'd be
happy to help whenever I can.

> 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)?

So indeed, we are handling support issues as well.  Not doing too good
a job out of it with all the other stuff we've got to do, but fwiw,
we've got answers.launchpad.net/rosetta where we are going to set
certain questions as FAQs.  If you feel any specific question needs
such care, just point us at it.  Jeroen or me will be happy to clarify
whatever is needed, and mark it as FAQ as well.

> 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.

I was just going to blame Ubuntu guys for not updating this, but it
seems we are missing an UI for this.  I just wrote a fix to make this
visible in the UI, but will ask for focus to be set manually because
this will take a few days to land.

> 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.

Indeed, I'd like to see some discussion going on.  I'd have my set of
suggestions for running a team as well, and probably a set of inside
tips as well. :)

Cheers,
Danilo