Translate dashboard widgets

It has been great working with the new dashboard widgets framework. It was easy and straight forward for us here at PIH to modify the relationships widget to meet our requirements. How should we go about translating(i18n) those new type of widgets?

I noticed in the openmrs-contrib-uicommons that local messages.json files are used:

We would like to use the existing messages.properties files that are in the many different openmrs modules. One approach we used was to load all message codes via this fragment:

Does anyone have any other suggestions on how to add translation capabilities to those widgets? Thanks. fyi @raff, @mogoodrich

@raff any thoughts on this?

Thanks! Mark

In OWAs it’s a matter of adding https://github.com/rkorytkowski/openmrs-owa-conceptdictionary/blob/master/app/components/conceptDictionaryApp.module.js#L97-L102 to config. We use messages in json files there. I’m not sure, if it can handle plain properties. It uses https://angular-translate.github.io/ under the hood, which supports custom loaders, if it doesn’t work out of the box.

An example of usage is https://github.com/rkorytkowski/openmrs-owa-conceptdictionary/blob/master/app/components/conceptView/concept.html#L32 It may be changed to one-way binding for performance i.e {{::“Concept.name.localePreferred” | translate}}

Thanks @raff!

Anyone have design thoughts as whether it’s worth the effort to add functionality to the OWA angular-translate to pull in messages from existing messages.properties files, or should we just duplicate the translations we need in JSON? Duplication is annoying, but, I guess at the end of the day these OWAs are meant to be able to exist outside of a OpenMRS module, so maybe we will have to do it regardless…

@burke @darius @mseaton @cioan

Take care, Mark

@mogoodrich though OWAs are meant to be able to exist outside of an OpenMRS module, the reality is that a good number of them will not. So i personally feel it is worth the effort for those cases where duplication is not necessary. :slight_smile:

Maybe we need to implement both approaches?

  1. Add the ability to pull translated messages from existing modules and openmrs-core
  2. Add new message codes or overwrite server side messages on the client side JSON. Those new messages would only be relevant to the the new client side UI apps.

@cioan suggestion makes sense to me… seems like there is no objection to this approach?

One approach would be to pull the translations from transifex to the OWA in the build process.

-Darius (by phone)

fyi, added a ticket for this here:

To follow up, it seems like it was pretty straightforward to add a custom loader, see my comments here: https://issues.openmrs.org/browse/OWA-17