As translation editor permissions aren’t global, there’s a constant need to add new people as translation editors for specific projects so they can commit translation branches. Currently the “Request to join project” dialog only allows the request for Reviewer, Terminology Reviewer and Translator permissions. Could Translation Editor be added to this list?
2 Likes
Hi Silje,
Yes - interestingly I have recently created an issue to do exactly that.
3 Likes
Alas I had a closer look now…and it gets more interesting than I thought.
CKM has an option that controls whether editors should be able to delegate editorial roles (all of editor, translation editor and terminology editor). This is turned on for the int’l CKM.
This option "Instance-wide configurable ability to prevent editors from assigning other editors and translation/terminology editors to a project/incubator" was introduced as CKM-1478 for you in the 1.17.0 release. You may remember the discussions, this was to avoid propagation of these roles unless sufficiently trained.
Now the natural consequence of this is that - in this configuration - editors cannot accept the request of someone else to join the project as an editor of any kind. Therefore it is not useful that they get notifications about requests they cannot act upon. This is why it is not possible to request to join a project as an editor of any kind in this configuration.
Now what to do about this…
We could turn the setting off again - as e.g. is the current configuration in the test server where you can see that you can request to be an editor because this option is turned off.
This is possible immediately - but then we are back to the old behaviour.
Other than that this is getting a bit complex (not only to implement but also to understand as a user).
One idea would be that membership requests for editor roles are diverted to the CKAs instead of the project editors - if and only if this setting is active…
1 Like
That could work in the short term at least. But the long term solution would in my opinion be to make both translator and translation editor permissions global (or at least for each subdomain), ideally per language 
1 Like
I knew you would say that 
Making it global in the way it is (i.e. for all languages) would work.
Per subdomain would probably work as well - pending something more solid than a Friday late afternoon analysis. Not sure though I see a compelling use case for it though that isn’t covered by global?
Controlling the rights “per language” is a different story though.
So, if it is deemed useful we can
- leave the Request Membership functionality as it is
- add an instance-wide role for translation editors for all languages
What I am less clear about is the use case for an instance-wide role for translators (especially when the checkout of resources is not restricted like in the int’l instance).
1 Like
I think these two proposals are a great approach!
The usecase is that the main authorisation criteria for translation editors is basic understanding of openehr. And expert understanding of the language they will translate to. (And original language). This is independent of project/specific domain expertise. E.g someone good enough at translating cardiology archetypes to eg Swahili can be trusted to translate any archetype to Swahili.
I think this could be useful, but it’d be even better if it could be assigned per language.
I hadn’t thought of that. In that case I agree, it’s not needed.
Agree that it is better per language, but the overhead and complexity here is an issue.
I will keep it in mind.
I assume that an instance-wide translation editor would also have the rights
- to start translation review rounds as well as
- commit to the trunk (with the existing restrictions of when this is possible)?
I agree that if a user can translate from English to Swahili for one archetype, that the user likely is able do so for other archetypes as well, the project-based roles are based on the assumption of projects being more autonomous (timelines, decisions, …) than they may be in practice.
However one question:
Would you want the instance-wide translation editor role to also apply to incubators and especially private incubators?
There are two reasons I can see why not:
- Archetypes in (private) incubators would not typically be translated at that stage because they may well change considerably.
- If this role includes private incubators, this would also make otherwise private incubators accessible to any translation editor, which may not be what is wanted.
-
is not a (authorisation/role) problem to me: Worst case, somebody wasted time translating.
-
Is an issue I didn’t think off. I didn’t know there were private incubators at all. Who uses them?
Well that’s true in a way…but it is generally not very useful at such an early stage.
I think this potential non-usefulness needs to be seen in combination with the second point, the impact it has on the visibility of these assets to - potentially - many more persons - only because they have a translation editor role they should likely not use on the archetypes in these private incubators.
One main intention is that you can set everything up without confusing anybody - and hopefully these incubators would be made public and later even upgraded to a full project, although there is no guarantee.
You can also move individual archetypes to a different project to make them available.
I disagree with authorisation as a solution for both problems. To me it’s like shooting at a mosquito with a bazooka. You are preventing the user to do something, because he might waste his/her time. that’s for the user to decide.
First is a problem for the user only, so to be fixed in the UI, simplest form it’s a warning dialog. But I also think it’s a non issue given the current practice in CKM. We need more translations, not fewer.
Regarding not confusing users, far easier solution would be to not return archetypes in incubators by default. Isn’t that default behaviour already? Otherwise there could be a flat on incubators: ‘hide from non-(translation) editors’.
But I wasn’t there when this feature was designed, so maybe I’m making wrong assumptions.
I just really hate authorisation because they’re a blunt instrument and have been wasting my time a lot in my career. So I’m definitely biased.
1 Like
That warning exists and appears when users want to translate non published archetypes.
Agree - but all the more no point in wasting time on translating something that is not ready to be translated either.
Well, I am just not giving that user extra access rights (in the case of private incubators).
To me:
- Private incubators have their use, but they should be used sparingly, because we really want to share and distribute the knowledge, not hide it away.
- When they are used, the access control is what it is and you most likely don’t want a general translation editor starting to take control of your archetypes. Even so, they can of course still be translated within the private incubator if needed.
- Coordination however is needed anyway and we could let instance wide translation editors manage the translations of archetypes in public incubators. I think this would be inline with your no-unnecessary authorisation line of thought. The warning message warning translators appears in any case. If after that they want to to translate, its their choice in my view.
Interested in other opinions as well @siljelb @varntzen @ian.mcnicoll maybe?
I agree an instance wide translation editor shouldn’t have access to a private incubator.
(and I also agree private incubators should be used sparingly)
Do you have an opinion about this, @heather.leslie ?
Jumping in from my summer vacation, here. Could not resist…
I think we should ask ourselves: “What is the international CKM for?”. Is it a repository of 1) all archetypes made, by someone, somewhere, and regardless of it’s maturity and fit for purpose? Or is it 2) a curated, well governed site for quality assured, proven and verified archetypes? These are two extremes, and we should not let the CKM be in either of them. Somewhere in between would be the best, but I must admit I tend to be more in the direction of 2) above.
Today, the private incubators act as a sandbox, with limited access. And should remain so, because it (should) act as a playing ground for the members to discuss very early versions of archetypes, tossing them around and move the rubbish ones to “the archetype graveyard” incubator (which we have in the Norwegian CKM, by the way). Those private incubators should be of a short lifetime, and made public - or the agreed archetypes moved to a public incubator, or a project. There are a lot of rubbish archetypes around, and should not be available neither for translation or download. That’s the purpose of private incubators.
Incubators. They’re the next level of archetype sandbox, publically available. Again, not a permanent place to store archetypes! Those archetypes can still be altered widely, and any translation or downloading will represent a major risk of spending time unneccesary or introducing technical debt by start using them. I know projects and vendors find archetypes in the incubators and start using them. Yes, it’s on their own risk, but as a community we should start thinking in the line of “If I leave my loaded handgun in the top drawer beside my bed, I’m to blame if my kid finds it and shoot its siblings”. (Excuse my morbid analogy, I’m on vacation, right?).
SO, the incubators should also have a short lifetime, moving the ready for review archetypes to a suitable project. “Someone” should be in charge of tidying up both private and public incubators, and move the old and outdated archetypes to the graveyard, or a “not currently in work-archetypes” project. Translation of archetypes in projects? OK, I don’t mind, go ahead. But be aware, and that’s also a warning about that when starting the translation.
Back to the start: In my opinion, the international CKM should act as a source of publically available quality assured archetypes. There are other ways of sharing archetypes, either in other CKM’s or in Git or whatever. And if someone wants to translate any archetype in a super-early draft status, it’s always possible to download it, modify and translate it, in for example Archetype Designer. On their own risk (and potential blame).
In order for the international CKM to become that source of quality assured archetypes, there has to be a assigned QA head (“Clinical lead” as an example ), and a group of well trained modellers and be given time (yes, I mean paid time) to perform their work.
Over and out, now I’m back to vacation. 
2 Likes
This requirement has come up again in the CKA coordination meetings, so I thought I’d check what the current status is. I can’t see this role among the currently available global roles, but could it be in the pipeline for a future update? 
Yes I promised, didn’t I .
It is part of the next release (1.20.0) - in the way you suggested with instance-wide ‘translation administrators’ per language. Doing it per language was at least 10x the effort, but nonetheless I think it is worth it because getting the increasing number of translations and translation languages organised is more and more important. Happy to give you a sneak preview if you like.
5 Likes
2 Likes
Very nice Sebastian!
Will this also stop me getting notifications about other language because I’m a translation editor for a project? (a)
This would increase the usefulness of CKM notification emails for me.
1 Like
Well, if you remain a Translation Editor for a project, you get the same notifications for archetypes of the project as before.
But for the purposes of the int’l openEHR CKM I would expect you to then (only) be a (CKM-wide) Translation Administrator (Dutch), in which case you would only get notifications for submitted Dutch translations, so that the answer to your question is yes.
More precisely, the logic to determine the email recipients for submitted translations is:
- If there is at least one translation editor or translation administrator for the language, we notify translation editors and translation administrators for the language only.
- If there are neither translation editors for the project nor translation administrators for the translation language, we fallback to the project editors.
- If there is a competing active branch or the submitted translation branch is outdated because it was branched from an older trunk version, we notify full editors of the project in addition to the translation editors of the project and the translation administrators for the language.
2 Likes
That seems well thought out. Thanks!
1 Like