Re: RFE: Vertimus and assigned translator

[Marcel Telka <marcel telka sk>]

Hi Luca,

On Tue, Jan 20, 2009 at 12:10:53PM +0100, Luca Ferretti wrote:
> Il giorno lun, 19/01/2009 alle 09.33 +0100, Marcel Telka ha scritto: 
> > Hi all,
> > 
> > In our localization team (Slovak) we are working in a way where a module
> > is assigned to particular translator. So it is not allowed to _anybody_
> > (e.g. other translator) to submit updated translation.
> 
> Marcel, this is currently the same behavior used on Italian team, of
> course it has the advantages you listed, but please note there is at
> least one shorcoming: the inability of currently assigned translator to
> work on assigned/maintained module

The same situation is today when a (random) translator choose "Reserve
for translation" and no real progress is done.

If I understand current DL & Vertimus correctly everybody is albe to
register there and join a L10N team. There is no approval required from
the L10N team to accept this new translator.

After that, the translator could (b)lock some random translations using
neverending "Reserve for translation" operation.

What is better? Who knows... :-)

> 
> You can "lock" a translation in current l10n.gnome.org too, just
> "reserve the translation" immediately after commit.

Exactly.

In all cases, when a translation is locked for too long time some
administrative intervention is needed.

Comment for Vertimus authors: Today it is not possible for me (as a
coordinator) to unlock such stuck translator and make it available to
someone else.

> 
> But what will happen if someone will not able to update him/her own
> translation in time for a release? GNOME Desktop is time based, so some
> translators in our (Italian) team start working after the string freeze.
> Sometimes they don't have the time to complete it, so the module is
> temporary assigned to another person.

No problem, the process could be workarounded. The SVN commit access is
not directly bound to Vertimus. So you could commit translations without
Vertimus (as we did for years :-).

> 
> Note also that in order to temporary reassign a translation, the team
> coordinator (and his/her privileges on l10n.g.o) could be needed, adding
> a bottleneck - at least I think so, I have only committer privileges, I
> don't know if team coordinator can retract a reservation.

No, see above.

> 
> IMHO, trying to merge the current l10n.g.o behavior and the "assigned"
> workflow, could be better add a "assigned-to" property to modules.
> 
> This property could act as follow: 
>       * on l10n.g.o each module can be assigned to an account

I agree.

>       * this account will receive email alerts for each action performed
>         on him/her assigned modules (comments could be useful to notify
>         typos/errors/proposal/memos/other)

I agree.

>       * if you claim a translation for a module assigned to another
>         account, this one have to "accept" the request 

In this case (at least for me) it is better to move ownership to the new
person.

>       * if the "assigned account" don't accept/reject the request within
>         a week, accounts with review (or commit? dunno, but something
>         below coordinator in order to make it faster) privileges can do
>         this 

Can do what? Accept the request?

I think most of teams are small, so we do not need to complicate things
more than needed. :-)

>       * other?
> 
> Something like this (maybe better, it's just a stub) could be more
> feasible than a simple lock.

Thanks for your valuable thoughts.

-- 
+-------------------------------------------+
| Marcel Telka   e-mail:   marcel telka sk  |
|                homepage: http://telka.sk/ |
|                jabber:   marcel jabber sk |
+-------------------------------------------+