# Request to join project as translation editor **Category:** [CKM](https://discourse.openehr.org/c/ckm/89) **Created:** 2023-06-30 10:31 UTC **Views:** 996 **Replies:** 34 **URL:** https://discourse.openehr.org/t/request-to-join-project-as-translation-editor/4170 --- ## Post #1 by @siljelb 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? ![image|388x174](upload://txpOs2pMeMLru491wwDO7MI44x8.png) ![image|396x219](upload://tsaTHDdb2Z7DpAsUadPgdbfdWAM.png) --- ## Post #2 by @sebastian.garde Hi Silje, Yes - interestingly I have recently created an issue to do exactly that. --- ## Post #3 by @sebastian.garde 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... --- ## Post #4 by @siljelb [quote="sebastian.garde, post:3, topic:4170"] 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… [/quote] 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 :grin: --- ## Post #5 by @sebastian.garde 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). --- ## Post #6 by @joostholslag [quote="sebastian.garde, post:5, topic:4170"] * 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). [/quote] 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. --- ## Post #7 by @siljelb [quote="sebastian.garde, post:5, topic:4170"] add an instance-wide role for translation editors for all languages [/quote] I think this could be useful, but it'd be even better if it could be assigned per language. [quote="sebastian.garde, post:5, topic:4170"] 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). [/quote] I hadn't thought of that. In that case I agree, it's not needed. --- ## Post #8 by @sebastian.garde 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: 1. Archetypes in (private) incubators would not typically be translated at that stage because they may well change considerably. 2. 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. --- ## Post #9 by @joostholslag [quote="sebastian.garde, post:8, topic:4170"] There are two reasons I can see why not: 1. Archetypes in (private) incubators would not typically be translated at that stage because they may well change considerably. 2. 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. [/quote] 1. is not a (authorisation/role) problem to me: Worst case, somebody wasted time translating. 2. Is an issue I didn’t think off. I didn’t know there were private incubators at all. Who uses them? --- ## Post #10 by @sebastian.garde [quote="joostholslag, post:9, topic:4170"] * is not a (authorisation/role) problem to me: Worst case, somebody wasted time translating. [/quote] 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. [quote="joostholslag, post:9, topic:4170"] * Is an issue I didn’t think off. I didn’t know there were private incubators at all. Who uses them? [/quote] 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. --- ## Post #11 by @joostholslag 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. --- ## Post #12 by @sebastian.garde [quote="joostholslag, post:11, topic:4170"] First is a problem for the user only, so to be fixed in the UI, simplest form it’s a warning dialog [/quote] That warning exists and appears when users want to translate non published archetypes. [quote="joostholslag, post:11, topic:4170"] We need more translations, not fewer. [/quote] Agree - but all the more no point in wasting time on translating something that is not ready to be translated either. [quote="joostholslag, post:11, topic:4170"] 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. [/quote] 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? --- ## Post #13 by @siljelb 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 ? --- ## Post #14 by @varntzen 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 :slight_smile: ), 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. :sun_behind_rain_cloud: --- ## Post #15 by @siljelb [quote="sebastian.garde, post:5, topic:4170"] Making [the translation editor role] global in the way it is (i.e. for all languages) would work. [/quote] 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? :innocent: --- ## Post #16 by @sebastian.garde Yes I promised, didn't I :innocent:. 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. ![image|476x312](upload://eEUwYdwD1VdUWKPZVyMoM3Hxwrh.png) --- ## Post #17 by @siljelb [quote="sebastian.garde, post:16, topic:4170"] It is part of the next release (1.20.0) [/quote] :partying_face: [quote] in the way you suggested with instance-wide ‘translation administrators’ per language [/quote] :100: :beers: :fireworks: This is great news, thank you @sebastian.garde! :star_struck: --- ## Post #18 by @joostholslag 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. --- ## Post #19 by @sebastian.garde 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: 1. 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. 1. If there are neither translation editors for the project nor translation administrators for the translation language, we fallback to the project editors. 1. 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. --- ## Post #20 by @joostholslag That seems well thought out. Thanks! --- ## Post #21 by @varntzen 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: * 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. --- ## Post #22 by @sebastian.garde [quote="varntzen, post:21, topic:4170"] Not many per language. 2-3? [/quote] 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. --- ## Post #23 by @Asa_Skagerhult This is so very much needed, thanks! --- ## Post #24 by @siljelb 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? --- ## Post #25 by @sebastian.garde [quote="siljelb, post:24, topic:4170"] Is there a way to make these notifications more targeted, or any other way to mitigate the fragmentation of responsibility? [/quote] The following was my attempt to make it more targeted, depending on assigned roles: [quote="sebastian.garde, post:19, topic:4170"] More precisely, the logic to determine the email recipients for submitted translations is: 1. 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. 2. If there are neither translation editors for the project nor translation administrators for the translation language, we fallback to the project editors. 3. 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. [/quote] 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). --- ## Post #26 by @varntzen [quote="sebastian.garde, post:25, topic:4170"] Is there anything you see that can be finetuned further? [/quote] To me it seems OK for now. Let's see how it works. [quote="sebastian.garde, post:19, topic:4170"] 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 [/quote] 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. --- ## Post #27 by @varntzen 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. --- ## Post #28 by @sebastian.garde [quote="varntzen, post:26, topic:4170"] 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. [/quote] Translation editors/admins can do this, either submit via file upload or by picking a translation from another branch. ![image|494x500](upload://lqe2ewXR4pCwiBRImBTMfs0Waxu.png) But only a user with appropriate rights for all the languages can commit that branch to the trunk. [quote="varntzen, post:27, topic:4170"] 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. [/quote] 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. --- ## Post #29 by @varntzen [quote="sebastian.garde, post:28, topic:4170"] But only a user with appropriate rights for all the languages can commit that branch to the trunk [/quote] 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. --- ## Post #31 by @varntzen Is this how it will be? o = Allowed, x = Not allowed: ![image|690x190](upload://1N841Ry4rQlyyBNJFJLQqlbGiNS.png) --- ## Post #32 by @sebastian.garde [quote="varntzen, post:31, topic:4170"] Is this how it will be? o = Allowed, x = Not allowed: [/quote] 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. --- ## Post #33 by @sebastian.garde This is how I would express it in your matrix: ![image|690x185](upload://5FNzf3kERmpqiUmospuYmt9cP1G.png) (Updated, minor correction and addition) --- ## Post #34 by @siljelb A post was split to a new topic: [How to manage archetypes in incubators](/t/how-to-manage-archetypes-in-incubators/4980) --- ## Post #35 by @varntzen 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. :partying_face: Which leads to the question: Who should have that role? I did propose [quote="varntzen, post:21, topic:4170"] * 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. [/quote] ..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)? Ping @Paulmiller @siljelb @vanessap @joostholslag --- ## Post #36 by @joostholslag 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 [quote="varntzen, post:21, topic:4170"] Should be appointed by the local (if exists) openEHR affiliate or equivalent. [/quote] 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. --- **Canonical:** https://discourse.openehr.org/t/request-to-join-project-as-translation-editor/4170 **Original content:** https://discourse.openehr.org/t/request-to-join-project-as-translation-editor/4170