[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: Lokalize & xliff
From:       Chusslove Illich <caslav.ilic () gmx ! net>
Date:       2009-05-16 10:10:13
Message-ID: 200905161210.14354.caslav.ilic () gmx ! net
[Download RAW message or body]


> [: mvillarino :]
> Of course, this requires manpower, time, and not get obsessed with the
> green bars of the hundred percents ;-)

Mmmm, lure of the green hundred...

Anyway. I've no problem with neglecting absolute values for the moment (team
size vs. number of words in the project) for the moment. What I'm concerned
with is how to achieve the desired level of quality most efficiently, e.g.
in terms of person-seconds per word shipped; and that this measure scales
well with growing team and project size.

> [...] Bruno (reviewer), can mark translated units as ok or not-ok, and add
> explanations [...] but can not modify the content. [...] when he completes
> the work, it is sent back to Anton, who can honour the remarks done by
> Bruno, or ignore them.

Indeed I didn't think of this workflow, but now that you mention it, I've
two problems with it.

First, assume the proposed modification is accepted by Anton. Then he
commits it under his ID for modification, and Bruno's for review:

  unit quaak;
      modified: anton; revision: 123;
      modified: anton; revision: 145;
      reviewed: bruno; revision: 145;

The problem here is that, historically, one cannot see what is it that Bruno
modified (i.e. proposed for modification). The above series of ascriptions
might also have come by Anton translating first, some time later correcting
himself on his own, and only then Bruno comming along. This prevents later
examining Bruno's review prowess and learning from Bruno's review
modifications.

Second, assume the proposed modification is not accepted by Anton. What
happens then? Does the unit get no new tag:

  unit quaak;
      modified: anton; revision: 123;

or review is nevertheless ascribed to Bruno:

  unit quaak;
      modified: anton; revision: 123;
      reviewed: bruno; revision: 123;

First solution leads to no indication of review; when Bruno (or Dora, the
master reviewer) revisits the catalog, this unit will pop up as plain
unreviewed. Second solution leads to the unit being declared as OK by Bruno,
although he actually does not agree with it; later someone could ask him,
"how did you let this through?".

Instead, if we stick to my original ascription sequence:

  unit quaak;
      modified: anton; revision: 123;
      modified: bruno; revision: 145;
      reviewed: bruno; revision: 145;

then I see the actual workflow around it iteratively.

First approximation is that the reviewer is infallible, the every
modification from his side is improving the translation. So, Bruno does
change the unit, and commits ascriptions as above. Now, every translator
should examine changes made to his work, in order to learn from the
infallible reviewers, making less mistakes in the future. So Anton checks
what happened between his and Bruno's modifications above.

Second approximation is that reviewer may have been wrong. If Anton suspects
this for some (and if first approximation holds, this should be few) units
that Bruno had changed, he takes the issue up (e.g. on the project mailing
list). There, Dora makes the cut. If Bruno is right, the unit stays as is,
and Dora adds her own review to it:

  unit quaak;
      modified: anton; revision: 123;
      modified: bruno; revision: 145;
      reviewed: bruno; revision: 145;
      reviewed: dora; revision: 145;

If Bruno was wrong, then the modification is reverted, again by Dora's
authority:

  unit quaak;
      modified: anton; revision: 123;
      modified: bruno; revision: 145;
      reviewed: bruno; revision: 145;
      modified: dora; revision: 168;
      reviewed: dora; revision: 168;

This provides full history of what had happened, which not only serves to
learn about reviewers and from reviews, but additionaly points out units
reviewed with higher than average scrutiny.

Now, back to the original problem, of inappropriateness same person both
translating and reviewing own work, which such a sequence could indicate:

  unit quaak;
      ...
      modified: bruno; revision: 145;
      reviewed: bruno; revision: 145;
      ...

One observation is that there is no problem if some people would exclusively
review, and other exclusively translate. This division, however, I find
unacceptable in self-motivated engagements (such as KDE), where everyone
should have the fun of translating pristine catalogs.

Another observation is that reviewers should be team members with some
experience, and that it can be relied upon them not to mark own translations
as reviewed by themselves.

Also, most common misascribed reviewes can be automatically detected. E.g.
this is clearly wrong:

  unit quaak;
      modified: bruno; revision: 145;
      reviewed: bruno; revision: 145;

as well as this:

  unit quaak;
      modified: bruno; revision: 145;
      modified: _merge_; revision: 179;
      modified: bruno; revision: 192;
      reviewed: bruno; revision: 192;

In fact, the tool by which the reviewer selects units for review should
filter out units which are like the two above, thus automatically avoiding
misascription.

> When Anton completes it's third round on the file, sends the file to
> approvers. These ones can decide to swap Anton by James on translation
> side.

Setting aside commercial translation environments for the moment, I don't
get the need for distinct "approvers", as in another special type of
reviewers. What's the problem of making this a matter of team policy, such
as "only catalogs with more than 50% of units reviewed can ship", or "only
catalogs with more than 80% of units reviewed by Dora can ship", etc.? Based
on such policy and on ascription tags, an automatic tool would sort out what
is to be shipped and what not.

-- 
Chusslove Illich (Часлав Илић)
Serbian KDE translation team

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]