So, as soon as there are two active translation branches, only an editor is able to resolve that. Is there a way to change that functionality or deal with that in a different way? It is annoying for translators, editors and translation admins and makes the process extremely slow.
The idea is that this needs the input of an editor to ensure all active branches are committed correctly - typically the editors integrate the translation of one branch into the other branch (which may be translation changes or also something more substantial) and then ensure that this is being committed to the trunk, typically as one patch. I see that this has been done with the two branches already in this case now.
Can this behaviour be changed? Sure - we can let translation admins commit even when there are other active branches…but that will leave editors with the problem of having to deal with the remaining - now outdated - active branch(es). If @siljelb and the other editors believe that is a better process, I am happy to relax the check accordingly. Personally, I believe this is just creating an extra burden for the editors.
In my opinion, it’s better to create a little extra work for editors to consolidate branches before anything is committed, instead of creating a lot of extra work to consolidate a number of outdated branches at a later point.
I don’t know whether it should be a behaviour change, as I don’t know the technical details behind it.
How hard is it to to deal with an outdated branch compared to integrating the translation of one branch into the other branch? Is it just integrating one into the other, or is it more messy? Would it be better to block new translations when there is an active branch?
Something definitely needs to change. New translations are regularly blocked from being committed, discouraging people from actually translating archetypes. @siljelb You say that it is a little extra work, but we are planning to translate a lot of archetypes to French in a relatively short amount of time (currently there are only 34), which will end up being a lot of work for editors.
This problem exists not only for active translation branches, but active branches in general. For example this branch in CLUSTER.service_direction.v1 with a few added elements, is active since 2022: https://ckm.openehr.org/ckm/archetypes/1013.1.3181/revisionhistory. As long as this is not resolved, adding translations is not possible. I just feel like it is quite messy and it’s worth having a discussion for potential solutions.
It’s generally more messy to deal with outdated branches because they often contain more than just translation changes, for example structural changes or improvements to the original language. This is further compounded when there are several different outdated branches, each starting from a different revision of the archetype.
I’m happy to discuss solutions, but I’d push strongly back against allowing leaving outdated branches again.
Are editors notified automatically when a branch conflict happens? What exactly are translation editors? How manual is the integration of one translation branch into another?
Optimal would be a technical redesign of how the branching works. These are the potential improvements I thought of without bigger technical changes:
Higher visibility of systemwide roles including translation admins. If I saw an active translation branch and could look up the respective translation admin, I could ask them to resolve their translation branch before I add another translation
Tooling to help with resolving multiple (translation) branches
Remove “active” translation branches after some time
Translation editor is a project-specific but language-independent role which allows running translation reviews and committing translation branches.
Integration of a translation-only branch into another branch is very simple; there’s a CKM function to submit a translation from one branch to another:
Automatic rejection of abandoned or stale branches could be a way to go, but IMO would require robust community discussion about the requirements for labelling a branch as abandoned or stale.
Regarding notification emails. When an translation is submitted to the editors, the recipients of the notification email vary depending on the status of the branches - in essence: if project editors are notified of a submitted branch it is because they have to deal with it because there is nobody else to do it. In detail:
If there is a competing active branch or the branch at hand is outdated because it was branched from an older trunk version, we notify full editors and translation editors of the project as well as the translation administrators for the language, if any.
Otherwise, and if there is at least one translation editor or translation administrator for the language, we notify translation editors and translation administrators only.
Finally, if there are no translation editors for the project and also no translation administrators, we fallback to the project editors.
