Latin Terms - Discussion
Description
Coming from the Translation User Group, various countries would like to collaborate on common terms for Body Structures and Organisms where they are Latin. See https://projects.jira.snomed.org/browse/SCTF-88.
A more general requirement may exist of allowing country extensions to re-use "en" terms, rather than duplicating those homographs in other languages.
Objectives
Enumerate and discuss the various options for working with Latin terms.
Status | DISCUSSION |
|---|
Discussion
SI Internal Group Discussion 17 January 2024
The SI group felt that leaving the current terms as "en" would avoid confusion, while the introduction of a latin language refset would allow for the identification of these terms (with a view to reuse) in a way that's compatible with existing implementations. The phrase "used in language X" helps move us towards a pragmatic approach that is useful eg in text searching, and away from being stuck on "this text is language X".
The suggestion is that a country would take the latin language reference set and copy those values into their own language reference set. This avoids adding to the complexity of implementations needing to search using a set of language reference sets with graceful fallback. At this point this set of latin terms doesn't actually needs to be a language reference set, it could just be a simple set of descriptions.
Latin terms submitted for addition to the International Edition are expected to "en" (we can't change a Description language code and we're looking to avoid creating descriptions with a language code of "la")
Solution Options:
A language reference set maintained as a community content module. ← preferred solution
Enhance the Refset Tooling to support simple sets of descriptions, and maintain there
Enhance annotations to allow annotations on descriptions.
Use a simple refset of descriptions, with API based tooling - no UI support.
More generally (relating to SCTF-88), SI tooling should move towards allowing descriptions in some arbitrary language to be referenced in any available language reference set. We'll allow this to go back for discussion with the Translation Group before any tooling changes are made, and also before any community content area might be set up.
Note that work is already planned to add language and dialect annotations (or additional relationships) to language refset concepts.
Note that the additional prefix/suffix words in the Body Structure hierarchy (eg Structure of X, X structure) moves terms away from being purely latin . Compare 181700004 |Entire gastrocnemius (body structure)| which contains latin + english, with 7173007 |Cauda equina structure (body structure)| which has a latin term without "structure". Yong thought that having the synonym on the "Structure" concept in the SEP pattern would be more useful.
Option: Move existing latin "en" terms to "la"
This would be illegal as the langCode field has been declared as immutable, so sub-options exist for inactivating "en" descriptions and re-creating as "la", or alternatively leave the "en" terms as they are and create duplicate "la" terms.
Pro: This would be an alignment to our own specification and the original intention for Language Reference Sets that they would indicate acceptability regardless of language of origin.
Con: Effort required and potential disruption to existing implementations.
Question: Could we consider allowing modification of the language code, either as a one-off, or modify the RF2 spec more completely to allow such changes going forward.
Option: Put latin terms into a new module
Pro: this would be a good option if we were to have these terms maintained as community content.
Con: If the "la" terms would be a part of the International Edition, then country extensions would already inherit these terms in any event, and there is no need for the added complexity of a separately versioned module (with associated problems of dependency version compatibility).
Con: Leaving the la terms in the International Module would leave the maintenance burden with the International team.
Tooling Discussion
Authoring Platform Validation is currently set up to enforce alignment between the description language code and a particular set of language reference sets. This effectively forces these homograph terms to be recreated as sort-of-duplicates in other languages. This situation may also relate to ambiguity in the original RF2 specification.
This was partly done as a simplification for the user interface by reducing the number of language reference set drop downs that are displayed for each term. An option here is that an "la"
Issues
Where a language accept header of "en" is specified, we would fail to match an "la" term by default.
If we allow the flexibility of putting - say - English language terms into non-English Language Reference Sets, is the need for identifying Latin terms reduced to the point where we could avoid adding complexity.
Use Cases
Comments
Discussion 2 April 2024 with some members of Translations User Group (@Anne Randorff Højen unable to attend. Also CC @Terance Shird )
OV Epic are unable to provide multi-language support. This suggests +1 for Option A, assuming this is a general concern and not specific to Epic.
PWI In Option A, the copying can be done any time. Is not dependent on published content. Whereas for Option B because we're referencing something in another module, we need that module to be officially published before it can be referenced.
OV Option A: the tracking between Latin and the country extension can be mitigated with a report that shows changes to the Latin since the last release. PWI: Because we can't change a published description, we'll be able to match the description in the extension because it contains the same text. Then when a description is inactivated in the Latin Module, we can indicate where this should also be done in the country extension.
RL : Keen to keep "both" options available
OV: Germany (@Frank Geier ) need to handle country specific German. PWI hoped this could be addressed as per en → en-gb / en-us dialects. Note that in the US/GB case, we usually say that the other country's spelling is acceptable, but not preferred, where there is a variant.
The Swedish Latins sometimes uses a simplified grammar and a Swedified spelling. Is it the same for the other countries where a lot of Latin is used? It would , howeveer, help a lot with the anatomical translations as the Wnglish source text sometimes uses more terms than we have in Swedish, but the Latin would make this a no problem-zone.
In the German language, we have
Several degrees of "Germanification" of Latin terms (e.g. "Pankreas" vs. "Pancreas")
Latin terms with additional meanings (e.g. "Angina" also means Pharyngits)
Fusions with non-Latin words and word parts ("li. Pulmo", "Anginaverdacht", "Carotisstenose")
Neo-Latin expressions, some of them (e.g. "Vulnus lacero-contusum" ) only used in Austria (not understandable neither in Germany, Switzerland nor anywhere else).
The problem generalizes to loanwords and homographs from other languages, mainly English:
"Bypassoperation", "Bypaß-OP"
False friends, e.g. "Labor"
Restricted meaning, e.g. "Rehabilitation", "Inhibition"
My conclusion is that loanwords should just be considered as belonging to the host language. A separate Latin extension does not make sense. A pragmatic solution for re-using Latin content could be to retrieve identical, non-ambiguous terms with the same concept ID from the international version and at least one additional SNOMED CT translation. The resulting terms are very likely to be internationally used; most of them come from Latin or English, e.g. "Clostridium perfringens", "laser".
Discussion 18 March 2024 with Translations User Group:
Could they add missing latin terms, and if so, would that be in some community content module and would the new descriptions be "la" ?
PGW: The least amount of work is to put these into the International Edition and then they become quickly available to all countries. Could we have the latin language reference set also in the International Edition at that point?
OV: International "latin" terms are somewhat Anglicised and are not appropriate universally. May be a desire to do the additional work to create a separate community content module.
RL : Two options: a) that the terms could be copied in to the local extension (a1 with local language code and a2 with "la" code) and b) that the "la" terms be used directly.
FH: NL has continuing difference with case that would necessitate copying a term to a new description
ARH: In the (a) case, we might need to track the relationship between the original community content term and the copy in the national extension in case of future changes.
PGW: if we're saying that a given country might have preferred terms that are either the local language or latin (but not both), then that suggests that a single language reference set would be beneficial in which we pick one term or another to be preferred. That avoids complications with attempting to merge two language reference sets at runtime.
RL: Might copy the term into the EE language as "ee" (and into the EE langreset), but also include the latin reference set (PGW This would need to be a copy of this refset since it points to the original content, and if this has been copied into new descriptions, the new langrefset would also need to be modified to point to the new descriptions).
Diagrams Created:
Option A: https://docs.google.com/drawings/d/1iofYJtniZM9ZtCGqt2AHJZiRVqtFjhx6m55AQer2Dl4/edit?usp=sharing
Option B: https://docs.google.com/drawings/d/1stImksa3tpOw0z5KUpVEnrkNofzZt3Wt9PwBB5SRQqU/edit?usp=sharing