Primary mentor


Backup mentor

Rafal Korytkowski

Assigned to

Mykola Vorobey


It is annoying for developers to make number of steps to provide default translation of single text message within OpenMRS. If developer needs to do it, he puts corresponding spring:message tag into jsp file. Then, he finds the file and appends default English translation for this message. If developer should provide translation into another language he needs to edit one more file etc. From the other hand, another person (translator) needs to complete a lot of steps to provide further qualitative translation of this message into other language (in the most common case, he needs to open default file to obtain message key, then open message properties file to put new translation into and to runs web-app to see translating message in context of web page). Obviously, this makes the translations process inconvenient, bit irritable and not efficient.

Currently, with use Spring's message taglib for putting strings onto our web pages.  This gives us the ability to translate openmrs very easily.  If you want to put a string into a jsp page into openmrs you put this spring:message in your jsp:

<spring:message code="MyPage.personSearchFieldPrompt" />: <input type="text" value="personId" />

And then you find the file and add this:

MyPage.personSearchFieldPrompt=Enter the person id

And if you're bilingual and not too lazy you find the file and append this:

MyPage.personSearchFieldPrompt=Entra el id de la persona

Now the text can be is displayed automatically in Spanish if the user has set their locale as Spanish.  If the user is in the English locale or any other, they will see the english translation.



Allow for in-line adding/editing of the translated text.


Implement and integrate pretty handy tool for in-page localization, which can greatly simplify work on translating OpenMRS.


Extra credit:

Design overview

Basically, from the structural perspective, in-page localization tool for OpenMRS can consist of two parts. First is a dynamic web widgets, which work inside client browser. The second one might be a DWR-based backend for serving AJAX requests from web widgets. Both these parts can be built on the top of [custommessages|] module 's codebase. 

There are couple of child pages with detailed descriptions of proposed design:

Proposed timeline

See this wiki page to get details of proposed timeline.

See Also

Interested Parties