@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?