We have noticed that when we switch locale in Bahmni Apps, the same switch is not happening in OpenMRS. And we need this for the i18n of Address Hierarchy and forms/concepts. Hence my question(s):
Is this intended in which case what are we missing?
If this is not intended, then we would envision to fix this so that wherever the locale switch happens in Angular should trigger a server call to basically do this down the line:
Context.setUserLocale(locale);
Where locale is the locale set through Bahmni Apps.
I havenāt looked yet deeper into it, so perhaps is there already a REST end point to achieve the above, but if not, where should it live: Bahmni Core or REST WS?
Iāve noticed this as well (and it had me confused for a bit as well).
The Bahmni team will have to discuss in further detail, but I believe Bahmni uses functionality built into the Angular translate filter to handle locale management. This is the call that happens in angular when the locale gets changed on the home page:
$scope.$watch('selectedLocale', function () {
$translate.use($scope.selectedLocale);
});
Angular docs to imply that this sets the language in the āconfigured storeā:
I also fear that just setting Context.setUserLocale(locale) will not be possible, because I think in some cases Bahmni relies on fetching concepts by fully-qualified name in the English locale, and itās possible that changing the underlying OpenMRS locale may break thisāthough Iām not sure about that, the Bahmni team will have to weigh in.
Thereās also an bug that I have been meaning to comment on: it looks like, at least on the login page, if the user happens to select a locale of which there are no translations for, it just displays the message codes on the login pageāthere is no fallback language. An unfortunate side effect of this is that because the message codes are so lengthy, they end up messing up the display, so that the dropdown to select your language is no longer visibleāmeaning if you switch to a locale with no translations by accident, thereās no way to recover, short of browsing in Incognito Mode.
One way to fix this is to clear your cache bahmni (or localhost) domain. This fixes the problem. I think we have fixed this issue in the upcoming v0.89 which will be released this week.
I was assuming that the form definitions were processed according to the default locale? But that changing the back-end locale should not break this, otherwise i18n is simply not supported anymore. If Iām correct then the current behaviour should most likely change and there should be set somewhere a āconfiguration localeā on which Bahmni Apps should base itself to interpret the form definitions.
This is our exact use case btw: we would like the default locale set to ākm_KHā while providing the form definitions in āenā (with appropriate concepts translations of course).
Can anyone from the Bahmni team shed some light and provide guidance/insight?
@mksd for what itās worth, I just double-checked to remind myself, on our Bahmni endTB instance, if I go to the underlying OpenMRS instance and change the locale via the links on the bottom of the page, when I go back to Bahmni I start getting lots of errors. Not sure if this is specific to the endTB implementation.
Just to be sure: you also changed the locale through Bahmni Apps, not just in OpenMRS?
I could imagine that things get screwed up if the two locales are not in sync (which is basically what we experience already with the address hierarchy).
We seem to have come across other cases where i18n is not properly supported, I will report in more details but it seems that some OpenMRS metadata object names are just taken as is (such as VisitType, Location, IdentifierType and PersonAttribute names).
We are thinking of capturing and localizing them through a method interceptor (in a similar way as what we did with Address Hierarchy, see here).
I think the bottom line here is that Bahmni supports i18n, as in: you may be able to set it up entirely in a target language, but it doesnāt support G11n (globalization).
@gsluthra, we would be grateful if you could skim up this thread and provide input so that we can
Apply workarounds or existing solutions.
Provision resources for what is needed to be done to get there with G11n for our current project.
@mksd I changed my locale through OpenMRS, not just Bahmni Apps. However, Iām doubting my last comment now because I realized there were other issues on the system I was testing. Anyway, best to let the Bahmni team weigh in, Iāll stop trying to guess beyond what I knowā¦
@mksd to your globalization issue, not sure I understand 100% what you are asking, but we had a discussion about localizing metadata within Bahmni here:
We havenāt gotten around to implementing any of this yet, for what itās worth.
