After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 568770 - Permanently assigned translator
Permanently assigned translator
Status: RESOLVED OBSOLETE
Product: damned-lies
Classification: Infrastructure
Component: vertimus
unspecified
Other All
: Normal enhancement
: ---
Assigned To: damned-lies Maintainer(s)
damned-lies Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2009-01-22 21:59 UTC by Marcel Telka
Modified: 2018-05-22 12:07 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Marcel Telka 2009-01-22 21:59:40 UTC
Some translation teams want to use a bit different workflow than the current Vertimus offers:

Coordinator first assign a translator to the module. After that the translator become a module translation maintainer and only this translator is able to translate (and submit) new translations of the module.

Coordinator could reassign the module to another translator if needed. The current permanently assigned translator should be visible somehow somewhere.
Comment 1 Luca Ferretti 2009-01-27 10:36:03 UTC
(In reply to comment #0)
> Coordinator first assign a translator to the module. After that the translator
> become a module translation maintainer and only this translator is able to
> translate (and submit) new translations of the module.
> Coordinator could reassign the module to another translator if needed.

I'm for a more soft behavior: 
 * coordinator assigns module to translator Foo
 * assignment to translator Foo will appear in module summary (per language, of course)
 * translator Foo don't need to reserve for translation, he/she can directly upload
 * translator Foo will receive notification email for any action performed on his own modules

Soft 'cause this behavior don't lock a module on a single translator, allowing more and maybe better coordinated in-team effort.

> The current permanently assigned translator
> should be visible somehow somewhere.

IMHO we need at least:
 * an "Assigned modules" on account page (http://l10n.gnome.org/users/elle.uca/), a simple list like Working On
 * an "Assigned to: <username>" in module->lang page (http://l10n.gnome.org/vertimus/139/111/82), just below "State: xx" and using its appearance (bold)
 * list of unassigned modules in team summary http://l10n.gnome.org/teams/it 

The list of unassigned modules could be really really useful, to direct new translators to available stuff.
Comment 2 Marcel Telka 2009-01-27 12:48:44 UTC
Yes, Luca. This is exactly what I want/need to have in Vertimus/DL.
Comment 3 Milo Casagrande 2009-01-27 12:57:05 UTC
(In reply to comment #0) 
> Coordinator first assign a translator to the module. After that the translator
> become a module translation maintainer and only this translator is able to
> translate (and submit) new translations of the module.
> 
> Coordinator could reassign the module to another translator if needed.

I'm more for a soft approach as Luca said: not a lock per translator basis. There could be the unfortunate (and extreme) case of coordinator and translator that are absent or not responsive and there's the need to update that translation.

I would like to have a coordinator assignment feature, but not as a lock-in one.
Comment 4 Marcel Telka 2009-01-27 15:52:37 UTC
I agree, I do not need "lock" feature. Sorry for my first comment, it is confusing.

Just small note: Neither translator nor coordinator is doing final commit. The committer does. So always (when both coordinator and translator are unavailable) is possible to bypass DL/Vertimus... :-)
Comment 5 Lucas Lommer 2009-02-19 00:11:52 UTC
The list of "Assigned modules" (as Luca Ferretti wrote, and other similar lists) should contain an information about how much has been done. Would be at least nice to see which packages are 100% done.

This all should be accepted as feature request, would really help me.
Comment 6 Petr Kovar 2009-03-22 00:27:32 UTC
At present, another significant issue for teams utilizing the workflow aforementioned by Marcel is that there's no possible way to preserve long-term valid information dealing with the module reservation when a module branches. Then, the module stays in the "reserved state" on the, say, HEAD page, whereas the branch page seems like the module isn't being worked on at all. Thus the duplicating of translation work may easily happen.
Comment 7 Dimitris Glezos 2010-03-04 16:41:15 UTC
Would a simple button (and flag) "I am responsible for this module for this team" clickable by any team member make sense? This information could be shown a) on the Team page and b) when a member of team X visits the module he'll see that for his team person Y is responsible.
Comment 8 Dimitris Glezos 2010-03-04 16:44:35 UTC
FWIW (if it's worth anything on this bug report), I created a ticket on Transifex as well, since I liked this feature for large teams.

http://trac.transifex.org/ticket/533
Comment 9 Marcel Telka 2010-03-04 16:52:34 UTC
(In reply to comment #7)
> Would a simple button (and flag) "I am responsible for this module for this
> team" clickable by any team member make sense? This information could be shown
> a) on the Team page and b) when a member of team X visits the module he'll see
> that for his team person Y is responsible.

Yes. This would really help us. The optimal solution would be as I described in the Description, but this simple button & flag would be enough as a starting point.
Comment 10 GNOME Infrastructure Team 2018-05-22 12:07:40 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/damned-lies/issues/10.