Dear All There are many issues that have to be addressed when translation becomes the norm. In the meantime, it is clear that there will need to be a block on double translations - that is into one language and then into another. For this reason, I propose that in the first version of openEHR that we do the following:
1. Force each versioned transaction to have a single root language. 2. Allow 'branch versions' that translate the original versions to another language - but make these read only. This would mean some changes to the model - but would ensure that we did not get translations of translations happening and would enable read only translations. This would mean that if a care plan was to be updated in another language for example - a new versioned transaction would have to be created. The application could do this quite quickly. The previous versioned transaction - if it clashed with the later - would have to be archived or moved to another folder. This might mean that the folders at the highest level might be used for language. I think that we need to get more experience with this before we will make sensible choices in this regard. Cheers, Sam Heard > -----Original Message----- > From: owner-openehr-technical at openehr.org > [mailto:owner-openehr-technical at openehr.org]On Behalf Of Thomas Beale > Sent: Monday, 1 July 2002 10:21 AM > To: open-ehr technical > Subject: Language translation > > > > The following posted on behalf of Dr Jean-Luc Mommaerts > > I would take as general principle the following: > "One meaning - one transaction (or 'equivalent' transaction, cf. infra); > difference in meaning - different transactions." > This goes more or less against what has been previously said, but still I > think it to be a logical solution. A doctor primarily wants to convey > meaning in his writings, independent of the format. Whether it's there on > paper, in bits and bytes, in codes or in another human language doesn't > matter for that. > > Some notes: > 1) I am well aware that a translation never provides 100% the > same meaning. > But we talk about intentions now. If you (as reader of the EHR) know that > the intention of the writer was to convey the same meaning, you know that > you only have to look at one version, namely that of which you know the > language best. > > 2) In many cases, a doctor will understand some of the meaning, > even if the > text is in another language. Medicine has many terms that etymologically > come from the same roots. So, partial translations will be common. But > almost always a partial translation will be supplemented with additional > information. > > 3) Not only can one go to Brazil on holiday. One can move to that country. > Then after a year or two (or twenty?), one moves again. And > again. Anything > is possible. > This is only to depict reality. The solution that I propose > transcends these > difficulties. > > Let's take a look at some use cases now: > 1) A translator translates one or more transactions and wants to indicate > that he translated them 'as good as possible', i.e. without intention to > change anything of the meaning. In that case, I would not make a > new 'direct > ' instance of <TRANSACTION>. The translator needs to be able, though, to > indicate his intention of conveying the same meaning in another > language. In > any case, at this point one just has two 'forms' of the same > thing, i.e. the > same transaction. Maybe make it an instance of <EQUIVALENT TRANSACTION>. > <EQUIVALENT TRANSACTION> can be a conceptual child of > <TRANSACTION>, with an > additional attribute indicating its reason for existence, in this case: > language translation. Additional attributes can be where and by whom the > translation is done and with what degree of reliability > (according to ISO). > > 2) A translator translates a transaction only partially, with no > additional > information. Same result. It is the same ('equivalent') transaction. There > is a fuzzy border now between the 'primary languages'. But the > migration is > from language A to language B. Let the translator be able to > indicate this. > You can not ask from a doctor who translates parts of a > transaction, that he > always indicates for each part whether his translation is 'pure' or with > additions. > > 3) There is a (complete or partial) translation + at the same time > additional information. In this case, it's a different > transaction. Treat it > as any other new transaction, but with an indication of the language > migration. > > 4) There is an automatic translation of (some of the) terms. Here, one can > look at what happens, completely from the level of concepts instead of > terms. The same thing is there inside the computer. The only difference is > how the user looks at it. So: same transaction. In fact, wherever > possible, > a user should always be able to take a look at terms in different > languages. > Terms explicitly related to concepts shouldn't be present in the > computer as > unrelated terms, but always as concepts (concept-ID's). > > 5) The doctor doesn't know anything of the language and no translation is > done at all. Then a new transaction is made with indication of language. > > We come back to the general principle: "One meaning - one > transaction", but > WITH an indication that it concerns a translation (whether partial or > complete). In all other cases, make a new transaction. As for 'primary > language', I think it's best to always have it indicated on the level of > transaction, instead of versioned transaction. This avoids possible errors > when a person moves and moves and moves. > > This solution is simple and IMO encompassing enough. But: I don't know the > arguments why it was previously said to make a translated > transaction always > a different transaction. In a sense, an 'equivalent transaction' IS also > different. Thus as an alternative, you can put it in the same list > (versioned transaction). The version identification scheme doesn't have to > be changed. The most recent transaction is then always the latest > transaction in the list, but if it's an instance of <EQUIVALENT > TRANSACTION>, then the one before is also the latest one, which, > by meaning, > is true. > > Kind regards > > Jean-Luc Mommaerts > > > > > > - > If you have any questions about using this list, > please send a message to d.lloyd at openehr.org > - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
