Request to join project as translation editor

Then we will need to identify some requirements to become a language-specific Translation Administrator. This should be defined by the CPB.

My take:

  • Not many per language. 2-3?
  • Should be appointed by the local (if exists) openEHR affiliate or equivalent.
  • Should have mandate to alter or impose standard phrases on certain sentences/wording from English to own language. Avoid multiple ways to document and explain between archetypes.

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.

Is this how it will be? o = Allowed, x = Not allowed:

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:

  • For the whole of CKM, appoint approx. 1-2 users as translation admin per (active translation) language. They can organise translations and informally (or formally) review submitted translations. They may need to coordinate with CKAs or editors if they want to commit multiple translations for an archetype at the same time.
  • For individual projects, it is still possible to use Project Translation Editors to organise the translations within the project only. This may be useful for very active projects with a special topic that we want to quickly translate in many languages for whatever reason.
  • In that case, it would also potentially be useful to officially add translators to the project, even if mainly to acknowledge them.
1 Like

This is how I would express it in your matrix:

(Updated, minor correction and addition)

1 Like

A post was split to a new topic: How to manage archetypes in incubators