GNOME Bugzilla – Bug 568770
Permanently assigned translator
Last modified: 2018-05-22 12:07: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.
(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.
Yes, Luca. This is exactly what I want/need to have in Vertimus/DL.
(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.
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... :-)
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.
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.
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.
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
(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.
-- 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.