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:
A post was split to a new topic: How to manage archetypes in incubators
Hi, all!
Today is the day, the 1.20 version is being installed, and by this the new Instance-wide Translation Admin (per language) role will be available. 
Which leads to the question: Who should have that role? I did propose
…but those rules should defined by the CPB. That hasn’t been dealt with (and I’m the one to blame, among others).
Another question is guidance to how much of the translation is “good enough”. I see a lot of partly translated archetypes submitted to editor. I suggest to leave that to the Translation Administrator to accept or decline such partly translated archetypes.
Do we appoint Translation Admins from today, or do we await a more formal decision in CPB (or the planned CKAL role)?
Great news! And thanks a lot for this proposal.
I agree with most of what you’re saying.
I’d like to be a translation admin for Dutch. I think it should be decided on by CPB. either on a person or ideally on an organisation. But if we want to hurry we can decide as cpb, online on discourse.
Re
I like the idea. But I think we need to phrase it a bit more abstract, eg: “CPB can delegate administration of a language to an openEHR affiliate”.
Because affiliates are mostly geographic, while languages aren’t always. Eg English shouldn’t be administered by openehr uk. And I think CPB should keep the right to revoke such delegation.
