At the Norwegian CKM http://arketyper.no, we’ve been doing quite extensive translation of international (English language) archetypes into Norwegian. During this process, we’re finding more and more translation isn’t a one-person job, but usually there’s a primary translator and one or more secondary translators. As of now there seems to be only one field in which to put translator information, so to attribute more than one person as the archetype translator, we need to put more than one name, organisation, etc into the same fields. This sort of works, but it’s not exactly elegant. Is there a better way to do this, either right now or in the works?
Kind regards, Silje Ljosland Bakke
Special Adviser, RN
R&D dept, E-health section, Bergen Hospital Trust
Coordinator, National Editorial Board for Archetypes, National ICT Norway
Having been in that position as a translator a couple of times, I think we put all our names in the field at that time.
This of course isn’t ideal if you have two or more translators that share the work equally.
However, it is the same with the original_author field - no real-world archetype has very been created by one person only.
Therefore, we have introdued the idea of other_contributors already where editors, reviewers etc. are given credit.
This is where potentially other translators could be added as well, e.g. if there is a prime/lead translator and several who check the translation.
BTW, for this checking translations, there is also the possibility to conduct translation reviews in CKM (ideally after the content has been published or it will be too burdensome I believe).
would that be enough, or do we need accreditation details for each translator? That would need a change to the Archetype Object model - easy to do but not until we get ADL 2.0 tooling.
If someone is interested in and would like to have some inspiration from how different IHTSDO member countries have dealt with translations of SNOMED CT descriptions (“terms”), the documents “Translation Guidelines” and “Translation Management Guidelines” can be found at the address http://www.ihtsdo.org/snomed-ct/snomed-ct-worldwide/translations-of-snomed-ct . (I guess that openEHR doesn’t have similar documents?)
Yes, I agree that that is a better place - but I think you will find that while this is in the rm, tooling support for TRANSLATION_DETAILS/other_details it is rather poor at present.
In CKM, we could add something like this to the translation pages, which would make it easy for the (main) translator to add this.
I have looked at the AE code and I think it may be a relatively simple fix that mirrors the work done for the general other_details section to support namespaces etc.
I will have a crack at updating AE and upload them to the Test CKM to see how we get on.
Using LinkEHR you can define the other_details in translations. We added an export function in order to generate archetypes as the AE is expecting (i.e. parse), so using LinkEHR once should not really be a problem
er hang on - can we see a clear proposal first for:
* the ideal solution - what we would do in ADL/AOM 2 - preferably
somewhere under this wiki page
<https://openehr.atlassian.net/wiki/display/ADL/ADL+2+Specifications>
* possible approaches to ADL 1.4 (preferably on this page
<https://openehr.atlassian.net/wiki/display/ADL/ADL+1.4+Change+Requests>\)
o short term - e.g. 'other_translators' inside 'other_details'
+ does this include deeper structure or not
o medium term - any kind of ADL 1.5/1.6 change that actually could
be implemented in current tools like AE, with on-the-fly
conversion of existing archetypes
* CKM changes
We don't want to create too much rework for later.
For now, the other_details attribute within TRANSLATION_DETAILS should do the trick. The main issue is to keep the different translators separated, which this seems to do:
There is also an older related issue on the specs tracker This issue highlights some potential problems as well, but doesn’t have a clear solution yet. I believe it should be considered at the same time. Cheers Sebastian
Right - exactly. Ideally, we need people who are developing archetypes and think there are limitations to say what they are. It isn't that hard to add more comprehensive meta-data to an archetype for translations, other_contributors etc. Of course, we don't want to go overboard - using links / addresses to other resources is good too.
Once changes are agreed, they can be put in ADL 2, and the ADL Workbench and other tools can fairly easily upgrade the existing archetypes into new structures.
There is also an older related issue on the specs tracker https://openehr.atlassian.net/browse/SPECPR-24
This issue highlights some potential problems as well, but doesn’t have a clear solution yet.
I believe it should be considered at the same time.
Hmmm, yes, 2009 … that is old. Here’s another oldie that we never got around to acting on as well. It talks about needing to know who the terminologist was …
Need ability to enhance the archetype translator details and to add a Terminologist doing the bindings
Reporter:
HeatherLeslie
Created:
21/Jan/10 7:25 PM
Need ability to add Terminologist to the Archetype and enhance the metadata about the Translator to cater for CKM requirements re identifying the primary people doing the initial authoring of the translation/binding plus those who contribute to the reviews of translations/bindings
These requirements are becoming a high priority in CKM development
Ian, is your proposal actually valid in 1.4?
My understanding is that other_details is a Hash<String, String>.
secondary_translators is the key, but “Ian…” and “Sebastian…” are two values - which is not possible (and probably not really desirable fpr general other_details either)
A further minor point, I would prefer other_translators over secondary_translators for consistency with other_contributors.
The way I see it the whole translation author block should ideally be repeatable, including separate elements for name, organisation, email and accreditation, which would of course require the accreditation element to ble moved inside the author block (why isn’t it there in the first place?).
this is doable as well, except not quite like that - multiples of the same thing have to have unique keys, so it would be more like the following. I also added in the 'version_last_translated' which was agreed in principle recently.
However.. it's not clear who did the most recently translation, and who only did some old translation. How do we deal with representing what's a current picture of affairs? It might not matter - it's ok if we assume that the translation work is recorded in some registry for example. Finding the balance is the challenge.
