Hi!
My former colleague Elham Gholami discovered a strange behaviour of template content when exporting operational templates (OPT-files) with modified repeated (e.g. with renamed fields) occurences of an archetype inside a template. If you export the template with only one language you won’t notice the limitation though.
We reported this to Better and discovered it was a known limitation of the (now pretty old XML based) OPT format. Newer formats (including ADL2-based ones) do not have this problem. Borut Fabjan at Better explained the issue in detail and provided a workaround that he allowed us to share here in case somebody else runs in to the same issues, excerpt from Borut’s mail follows:
This is unfortunately an issue with openehr OPT format specification.
Let me explain.
Each archetype in the OPT is only present once with its ontology section where translations are stored.
This means that openEHR-EHR-SECTION.adhoc.v1 has only one set of translations (one of the appearances of the section in the template).
Default language (en) has more options as it can also use name overrides, i.e. besides the terminology/ontology section it can also set a name constraint - but name constraints don’t have language attribute
<archetype_id>
<value>openEHR-EHR-SECTION.adhoc.v1</value>
</archetype_id>
<template_id>
<value>SSIAD PRIeSM</value>
</template_id>
<term_definitions code="at0000">
<items id="text">Medical equipment at home evaluation</items>
<items id="description">A generic section header which should be renamed in a template to suit a specific clinical context.</items>
</term_definitions>
Translation goes into terminology per archetypeId:
<component_ontologies archetype_id="openEHR-EHR-SECTION.adhoc.v1">
<term_definitions language="fr">
<items code="at0000">
<items id="text">Medical equipment at home evaluation</items>
<items id="description">Un en-tête de section générique qui doit être renommé dans un modèle pour s'adapter à un contexte clinique spécifique.</items>
</items>
</term_definitions>
</component_ontologies>
Technically, in .OPT you can have only one translation per archetypeID. Therefore there’s no “place” to store all other instances of adhoc section translations.
Fortunately we bumped into limitation many years ago & came-up with a workaround.
You can preserve the translation using a simple annotation: L10n.twoLetterLanguageCode = Translated text goes here
See attached screenshot.
This will also “fix” the missing translations in the Studio/Forms.
Regards, Fabio.