I18n support for all classes extending BaseOpenmrsMetadata

Going slightly further, as a minor refinement REST resources could provision for all backend supported locales, so typically we’d get something like this:

In locale ‘en’:

{
  "uuid": ...,
  "name": "Outpatient Visit",
  "label_en": "OPD Visit",
  "label_fr": "Visite ambulatoire",
  ...
}

In locale ‘fr’:

{
  "uuid": ...,
  "name": "Outpatient Visit",
  "label_en": "OPD Visit",
  "label_fr": "Visite ambulatoire",
  ...
}

And the frontend code would attempt to find a label in accordance to the user’s session locale, or default to the metadata name. On the frontend this would allow to switch between supported locales while minimizing server calls.

1 Like

Am fine with this as long as it is not the default.

Is there a reason why you are using label instead of name? For instance, label_en instead of name_en?

Because at first I was imagining this display string to be the L10n’d value of the new i18n code, that’s how it was differing from the name.

But it could as well be name_xy. Perhaps label_xy or display_xy is more explicit as to how it is supposed to be used by client side code.

I didn’t realise that PIH’s technique of i18n of metadata was already supported! As far as we are concerned, this is good enough to quite a large extent…

Although, having a way to provide the display values for all supported locales would be a really cool thing to have to enable a frontend logic to switch between locales without making much server calls.

@mksrom so this means that if for each piece of metadata we provide a value for the i18n key built as

Java class name + "." + entity UUID

then REST WS will provide a L10n’d display property accordingly for that metadata entity.

Example for the location “Amani Hospital” whose UUID is aff27d58-a15c-49a6-9beb-d30dcfc0c66e. Here is how the ‘messageproperties’ domain would be set up in the OpenMRS config:

locations_en.properties

org.openmrs.Location.aff27d58-a15c-49a6-9beb-d30dcfc0c66e=Amani Hospital

locations_kh.properties

org.openmrs.Location.aff27d58-a15c-49a6-9beb-d30dcfc0c66e=មន្ទីរពេទ្យអាម៉ានី

locations_fr.properties

org.openmrs.Location.aff27d58-a15c-49a6-9beb-d30dcfc0c66e=Hôpital Amani

And therefore here is how the metadata resources would look like:

REST resource in ‘en’

{
  "uuid":  "aff27d58-a15c-49a6-9beb-d30dcfc0c66e",
  "name": "Amani Hospital",
  "display": "Amani Hospital"
  ...
}

REST resource in ‘kh’

{
  "uuid":  "aff27d58-a15c-49a6-9beb-d30dcfc0c66e",
  "name": "Amani Hospital",
  "display": "មន្ទីរពេទ្យអាម៉ានី"
  ...
}

REST resource in ‘fr’

{
  "uuid":  "aff27d58-a15c-49a6-9beb-d30dcfc0c66e",
  "name": "Amani Hospital",
  "display": "Hôpital Amani"
  ...
}

That should be good enough for OpenMRS 3.0 right?

FWIW: UI Framework Reference Guide - Documentation - OpenMRS Wiki

@mksd this makes sense to me.

You could also imagine it being quite cheap to also support names as message codes, so in additional to checking message codes for fqn.uuid for a given piece of metadata, you also just tried checking message codes for “name” of a given piece of metadata. And having “display” property on the REST resource that returns this.

One the Iniz side, would be cool if each metadata domain could abstract this away too. For example, on the location domain if you add columns like “name_en”, “name_fr”, etc, then Iniz would basically add these with the appropriate keys to a message source that could return them at runtime for the given location.

This would greatly reduce errors and annoyances of having to copy lots of uuids around and use them as keys in configuration files…

Mike

2 Likes

I had forgotten we had implemented that for the REST web services module as well…

Longer-term, I think I’d be in favor of adding a “i18nCode” code property to BaseOpenmrsMetadata, and then support returning “display_en”, “display_fr”, etc as @mksd . My initial thought would be to use “display_" over "label_” or “name_*” but could be swayed by arguments…

Take care, Mark

Nice, I like that, it would be quite easy I think to make this a generic process for all domains. TBH when this exists in Iniz, there is not even much incentive to even touch REST WS further (in reference to supporting using the metadata name as a i18n code.)

@mogoodrich since there is already a display property, I think we should just stick with it.

Great stuff, thanks all for your input. Taking away:

  1. Ensure that Iniz makes it easy to provide i18n names as @mseaton suggested.
  2. Expand REST WS so that it can fill display_xy for all supported locales.
1 Like

Thankfully we have an encyclopedia among us :slight_smile: :point_right: Issue with OAuth2login user creation - #11 by mksd

I created the following ticket: