FHIR Chat · Representation of Translations · implementers

Stream: implementers

Topic: Representation of Translations

Grahame Grieve (Dec 12 2017 at 05:46):

I've just spent a few days working with translations on string and mark down types. I want to dig up an old thread and see whether this is a good time to progress it or not.

Grahame Grieve (Dec 12 2017 at 05:46):

currently, a translation on a CodeSystem.description would be represented like this:

Grahame Grieve (Dec 12 2017 at 05:49):

  <description value=" The gender of a person used for adminstrative purposes (as opposed to clinical gender)">
      <extension url="http://hl7.org/fhir/StructureDefinition/translation">
          <extension url="lang">
            <valueString value="nl"/>
          </extension>
          <extension url="content">
            <valueString value="Het geslacht van een persoon bedoeld voor administratieve doeleinden (in tegenstelling tot klinisch geslacht)"/>
          </extension>
        </extension>
  </description>

Grahame Grieve (Dec 12 2017 at 05:50):

I promised a little (well, not so little) while ago to bring up the subject of improving this. Specifically, we could say that for this extension (and this one alone), there's a XML and JSON specific way to have a more efficient serialization.

Grahame Grieve (Dec 12 2017 at 05:50):

 <description
    value="The gender of a person used for adminstrative purposes (as opposed to clinical gender)"
    value:nl="Het geslacht van een persoon bedoeld voor administratieve doeleinden (in tegenstelling tot klinisch geslacht)"/>

Grahame Grieve (Dec 12 2017 at 05:51):

or in Json:

Grahame Grieve (Dec 12 2017 at 05:51):

{
  "description" : "The gender of a person used for adminstrative purposes (as opposed to clinical gender)",
  "description:nl" : "Het geslacht van een persoon bedoeld voor administratieve doeleinden (in tegenstelling tot klinisch geslacht)"
}

Jose Costa Teixeira (Dec 12 2017 at 05:54):

Does this apply for resource and attribute type descriptions only, or also for resource content?

Grahame Grieve (Dec 12 2017 at 05:54):

I propose this as a special case. There's several reasons why no other extension could be or should be treated like this. And the way we represent translations has come up consistently for implementers

Grahame Grieve (Dec 12 2017 at 05:55):

Don't understand the question. As proposed, it applies to the types string, code and markdown

Grahame Grieve (Dec 12 2017 at 05:55):

(as the extension does)

Jose Costa Teixeira (Dec 12 2017 at 05:59):

so we could have something like:
{
"resourceType": "Location",
"address": {
"line:nl": ["Brusselsesteenweg, 121"]
"line:fr": ["Chaussée de Bruxelles, 121"]

?

Jose Costa Teixeira (Dec 12 2017 at 06:02):

(i did not understand if this was for supporting translation of the specification, or for supporting multilangual content)

Grahame Grieve (Dec 12 2017 at 06:28):

multi-lingual content. So yes, you could have what you have above, though I need to think about arrays. but we've generally held that addresses are not the target audience here

Jose Costa Teixeira (Dec 12 2017 at 06:30):

ok then it seems to make sense. Is there an assumption that :en is the default language?

Jose Costa Teixeira (Dec 12 2017 at 06:31):

or that if your default language is :fr then you can leave all attributes without any reference?

Jose Costa Teixeira (Dec 12 2017 at 06:32):

in other words: if default language is fr, do you have

  "description" : "je ne parle pas français",
  "description:nl" : "Het geslacht van een persoon bedoeld voor administratieve doeleinden (in tegenstelling tot klinisch geslacht)"

or

  "description:fr" : "je ne parle pas français",
  "description:nl" : "Het geslacht van een persoon bedoeld voor administratieve doeleinden (in tegenstelling tot klinisch geslacht)"

Jose Costa Teixeira (Dec 12 2017 at 06:33):

in any case i think the concept is useful.

Lloyd McKenzie (Dec 12 2017 at 06:33):

The presumption that the base attribute would have the string expressed in the language of Resource.language (or the environment-presumed default for that attribute)?

Jose Costa Teixeira (Dec 12 2017 at 06:34):

ah, resource.language. Thanks!

Jose Costa Teixeira (Dec 12 2017 at 06:36):

makes sense.

Michel Rutten (Dec 12 2017 at 11:02):

Looks nice, but the proposal seems incompatible with XML syntax?
i.e. XML deserializer will interpret attribute name "value:nl" as namespace = "value", attributename = "nl"

Michel Rutten (Dec 12 2017 at 11:03):

(and probably complain about missing namespace declaration "value")

Grahame Grieve (Dec 12 2017 at 12:08):

hmm. yes. have to use a different separator

Grahame Grieve (Dec 12 2017 at 23:08):

would make sense to use "." - so

Grahame Grieve (Dec 12 2017 at 23:09):

<description
    value="The gender of a person used for adminstrative purposes (as opposed to clinical gender)"
    value.nl="Het geslacht van een persoon bedoeld voor administratieve doeleinden (in tegenstelling tot klinisch geslacht)"/>

Grahame Grieve (Dec 12 2017 at 23:09):

to see any example of translations at work, see http://build.fhir.org/v3/AdministrativeGender/cs.html

Lloyd McKenzie (Dec 13 2017 at 04:40):

How would this work with FHIR-path?

Lloyd McKenzie (Dec 13 2017 at 04:40):

(I'm thinking the "." might cause problems there...)

Grahame Grieve (Dec 13 2017 at 05:15):

it would be transparent to fhirpath

Lloyd McKenzie (Dec 13 2017 at 05:54):

So FHIRPath would grab the extension using the URL the same as any other extension?

Michel Rutten (Dec 13 2017 at 10:19):

@Ewout Kramer?

Ewout Kramer (Dec 13 2017 at 11:45):

How is this transparent to FhirPath? Which "value" would a path return if it has two values? What would CodeSystem.description return?

Ewout Kramer (Dec 13 2017 at 11:45):

Is Lloyd saying this would become visible as an extension in the "logical" model underlying FhirPath?

Lloyd McKenzie (Dec 13 2017 at 15:48):

If it's just a syntax generator, it'd be no different than the "_birthdate" in JSON. In FHIRPath you'd still need to use the full URL to access the translation - unless we come up with something special in FHIRPath too...

Grahame Grieve (Dec 13 2017 at 19:13):

yes that's my proposal.

Lloyd McKenzie (Dec 13 2017 at 20:45):

same as any other extension or coming up with something special in FHIRPath too?

Richard Townley-O'Neill (Dec 13 2017 at 23:56):

This looks like an extension that does not get wrapped in an extension element. Is that right?

Grahame Grieve (Dec 14 2017 at 00:33):

well yes, though a little bit more than just 'not wrapped in an extension element

Christiaan Knaap (Dec 18 2017 at 09:35):

In FHIR the Resource is essentially the atomic unit of communication. To me it sounds more reasonable to then translate a resource as a whole. But being a server dev I'm generally not the client, so I may not understand the use case for this.

Grahame Grieve (Dec 18 2017 at 09:46):

it's whether you prospectively or retrospectively translate

Christiaan Knaap (Dec 18 2017 at 15:58):

Should I understand that as:
- prospectively: POST a Resource including translations of some of the elements in it, vs
- retrospectively: GET a Resource and have it translated in your favourite language?

Grahame Grieve (Dec 18 2017 at 18:13):

prospectively: the resource carries the translations for when you want them
retrospectively: you ask for the translations from some magic translations when you want them

Grahame Grieve (Dec 18 2017 at 18:13):

the extension is for the first case

Last updated: Apr 12 2022 at 19:14 UTC