Nice!
Then we will need to identify some requirements to become a language-specific Translation Administrator. This should be defined by the CPB.
My take:
More than 2 or 3 sounds excessive to me as well under typical circumstances and would just make any coordination and consistency such as typical wording more difficult.
This is so very much needed, thanks!
A related issue is the fragmentation of responsibility that happens when translation editors, editors, and in the future translation administrators, get the notification about translations which require committing. Currently all accounts assigned any of these roles get this notification, and I think this is one of the reasons why a majority of the notifications aren’t actioned.
Is there a way to make these notifications more targeted, or any other way to mitigate the fragmentation of responsibility?
The following was my attempt to make it more targeted, depending on assigned roles:
Is there anything you see that can be finetuned further? (There is a bit of extra complexity not mentioned here with private incubators, but let’s leave that aside as it is mostly irrelevant).
To me it seems OK for now. Let’s see how it works.
One question though to the above: Does the translation editor have the rights to upload one translation to another active branch? If not, it might not be worth notifying translation editors for that language, only the editors.
Oh, another thought: Does a translator have the right to work on another user’s branch? Given not Editor-rights, but only translator for a given language.
I see a lot of branches, one for Catalan and another for Spanish. It would be great if, when finished, another translator could do another language in the same branch.
Translation editors/admins can do this, either submit via file upload or by picking a translation from another branch.
But only a user with appropriate rights for all the languages can commit that branch to the trunk.
If with translator you mean that the user has the role of translator in the archetype’s project, then that user can upload translations to another branch (Upload Translation to This Branch in screenshot above). They cannot currently “Submit Translation to Branch → xyz”
(This may need some finetuning, but the reason for Upload “yes”, Submit to another Branch “no” is that the latter also resolves the source branch.)
Typically, I would let translators work on their own branch rather and if multiple translations from different branches should be combined into one branch before committing to the trunk, this should be managed by someone with more than translator rights.
OK, this means that if:
Jane, a ordinary translator in the project, translates to Finnish in her own branch, then only a Translation editor/administrator or an Editor can, for this branch 1) Submit Translation to Branch - xyz or 2) Commit the branch to the trunk.
AND, if 1), then the one committing the archetype, need to either be Translation editor/administrator for all languages in the branch, OR being an Editor.
Yes, but the role of Translation Admin is per language - whereas a (project-based) translation editor is for all languages, but restricted to archetypes owned by the project only.
So as a translation admin you can only commit if you have the role of translation admin for all the languages that have been changed.
“Translator” is a (fairly weak) role with in a project - it does give you limited extra rights. The most important right actually is that you can checkout the archetype even if the CKM is configured in a way that only users with special roles can checkout. This is negligible in the int’l CKM where this is currently configured so that everybody can do this anyway. It does give you the acknowledgement/recognition within the project. It is not restricted to a certain language.
I think, we need to look at the process here. How does openEHR want to organise the translations and if there is anything missing from the picture. We can always finetune.
My take:
