Bahmni Apps locale not syncing OpenMRS locale (and vice versa)?

Hi Bahmni team,

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?

Suggestions?

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”:

https://angular-translate.github.io/docs/#/api/pascalprecht.translate.$translate

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.

Take care, Mark

1 Like

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.

Thanks @mogoodrich.

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?

Thanks @gsluthra!

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

Mark

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

  1. Apply workarounds or existing solutions.
  2. Provision resources for what is needed to be done to get there with G11n for our current project.

@darius, @sdeepak and @angshuonline: More relevant for you to comment on this, than me.

@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… :slight_smile:

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

Take care, Mark