Re: RFE: Vertimus and assigned translator

[Luca Ferretti <elle uca libero it>]

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

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

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.

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.

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
      * 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)
      * if you claim a translation for a module assigned to another
        account, this one have to "accept" the request 
      * 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 
      * other?

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