In-page localization UI Mockups

Abstract

Design of pretty handy and unobtrusive web widgets might be considered as the major task of creating good tool for in-line localization.

Mockups design

Technically, client side part of this tool can be done as java-script bookmarklet within custommessages module. Using of bookmarklet will not set bounds for potential translator what browser to use. Bookmarklets work everywhere. From the other hand, OpenMRS server might run in two modes: let's name them normal and translate modes. There is some special with these modes. Activation of translate mode just simply turns OpenmrsMessageTag to produce any text enclosed into span tags with the special css-class "translatable". Also, in this mode we will show link with bookmarklet code in the bottom of the page at strip with languages (see callout 1 on mockup below the text). But in normal mode it would be better to do not show that link just to avoid confusion of users. Since all coding work should be done on top of custommessages module, then the easiest way to inject the link with java-script bookmarklet code into OpenMRS core footer page is to use mechanism of module extension points. 

The idea is next. Volunteer, who wants to help us to translate OpenMRS to French (for example), will need to switch his local OpenMRS server into translate mode and run OpenMRS in French locale. Thereafter, when this person moves mouse pointer over any "translatable" text on any OpenMRS core web page, the javascipt engine will handle this event and highlight that text with the rectange alike Chrome Firebug does (callout 1 on mockup below). If user wants to translate this text, he just clicks mouse on it and put his translations into popup dialog right below the translatable text (see callout 2 on mockup below this paragraph). To submit his translation he may click on Apply button. Javascript handles it and sends just created translation to local OpenMRS server. The server, in turn, processes the request and saves new translation into message_fr.properties file. 

Translator will not only be able to create new translations, he will be able to edit existing ones. To do this, he will need to click on any already translated text and correct it. This can be done by showing English variant of each text message within translations console popup. For example, when user sees that translation of menu item (lets say, - "Chercher/créer un patiente") needs some work, he just clicks on it and starts to edit. Translation console popup will contain read-only English variant "Find/Create patient" as original and editable "Chercher/créer un patiente". So, user can easily edit it. Mockup below illustrates this.

All translations, which user does, not only can be saved to user local server, but also can be committed to the master OpenMRS server. This ability will be provided via translator admin dasboard. This dashboard will be done on the basis of custommessages module admin interface. In order to commit local changes user will need to press on Commit Messages link-button within translation admin page (see mockup below the paragraph). Local server, which receives commit requests, will check the connection with master OpenMRS server. If the connection can be established, it will make something like svn diff of message properties files on both local and master servers. After creating the diff, local server will respond this diff in user-friendly format to client (callouts 2 and 3 on mockup below this paragraph). Client may review it, correct any conflicts and approve commit operation. In fact, local server will send approved diff to master server, which will try to apply received changeset. In case of succeed, master sends corresponding aknowledge to local server and person, who made these translations, will be notified with success message.

The conception of translations commitiing, saving and synchronizing will be reviewed in corresponding wiki pages here.