@mksd, @mogoodrich and I were having a discussion about localizing address hierarchy entries in this ticket, and it has morphed into discussing a more general solution to metadata localization. I wanted to move this conversation here so that we could take advantage of more ideas and feedback. I hope this is ok @mksd From that ticket:
This other module, that I intend to name something along the lines of “I18n Extended Support”, aims at covering further data or metadata i18n support than what OpenMRS currently does. Think for instance of visit types names and descriptions, person attribute types names and descriptions… etc. All those that should have leveraged similar classes to ConceptName, ConceptDescription… etc that associate a locale to a saved string, but haven’t hence causing all sort of troubles (in Bahmni in particular). I was thinking of moving AH i18n support into that new module as well as it participates to the same logic, what do you think?
I definitely am interested in broadening out support for internationalization in a way that all downstream distributions can leverage, and would love to have more public design discussions around this (without slowing you down ideally). There have been sporadic efforts to try to accomplish what you are suggesting in the past (i.e. this project from years ago that we abandoned but which has a lot of history to read).
@mksd, would you mind describing a bit as to the technical solution that you are thinking of implementing in your module?
In it’s barest form this might be the problem statement:
I guess at least the
description fields. Below are some examples that we have stumbled upon:
Our workaround is the combination of a “good” practise and of a piece of code.
The “good” practise:
Make sure to never save anything else than i18n messages keys for the
description members of a bunch of objects. And also to bring along the additional .properties files of course.
The piece of code (yet to come, except for AH):
An AOP method interceptor that ensures that whenever any instance of the listed classes are being sent back from the database, the target members are localized (
description) before letting the instance go downstream.
This works but it requires some discipline, as well with no doubt to face some limitations. For instance switching language from a UI front end like Bahmni Apps will require to make some server calls, it will never be 100% supported from the client-side only.
Another major limitation is that this will most likely prevent end users to ever create the covered data and metadata objects by themselves, thereby breaking a range of workflows that may have been envisioned for OpenMRS. A new visit type will have to go through a software update for instance… etc.
The idea for this ‘piece of code’ is to live in a separate module, perhaps named openmrs-module-exti18n, and that would also cover the i18n features needed for AH (they would then be migrated in there.)
This may just be enough for most implementors, but still IMHO represents a workaround, not a proper deep down solution.
Is there anyone else interested in this topic and willing to contribute in any way? By first scrutinize our above suggestion for a start, please do!