Primary mentor | |
Backup mentor | |
Assigned to |
Abstract
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 messages.properties file and appends default English translation for this message. If developer should provide translation into another language he needs to edit one more message.properties 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 message.properties 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).
...
Features list for future versions (2, 3 etc):
- Allow export of message bundles for core or another module that contain the sum of message from bundles + changes in database.
- Add a way to clean out changes in the database that are no longer different from message bundles.
Review of project requirements
Functional and non-functional requirements set to this project are currently collected into one document and placed on separate page.
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:
...
Jira Legacy TRUNK-1525 TRUNK-1525 - JIRA project is https://tickets.openmrs.org/browse/CSTM
- Related module is Custom Messages Module