In-Page Localization Requirements

Preface

The outcome of this project shall allow for potential users to do translations of text messages within OpenMRS web application by editing the content of different html elements.  Any volunteer person with knowledge of foreign language and basic experience in OpenMRS is intended to use this project.

Requirements List

As usual, there are two groups of requirements those can be set for in place localizations system. First one is functional requirements and they are listed below (I split this into multiple requirements, because eventually, each will require separate test cases):

1. Translation entering and editings.
   1. The system shall provide an ability to edit text message on web page by the next scenario: User clicks translatable text on any web page. Block of text becomes an input form. User edits contents and presses Enter or Tab key. New text is sent to server. Input becomes normal text again (any other messages, having the an identifier, which is equal to identifier of edited message, should be refreshed automatically within the same page) .
   2. The system shall provide background highlighting for any message that has not been translated yet in active locale.
   3. The user should be able to cancel in place editing by pressing Esc key or clicking mouse outside the input.
   4. Translation editing and entering may only occur if user has turned on Translation Mode
2. Translation mode
   1. There should be a special toggle button within each page footer. This button will be used for translation mode switching.
   2. If translation mode is on, then the text messages on current page (ones which can be translated) become available for in place editing.
   3. While translation mode is on, the user should be able to switch locales (using the existing footer links) and edit messages within that locale.
   4. By default, translation mode must be turned off. Translation mode switching button appears only for users with Manage translations privilege.
3. Translations persistence and restoration
   1. Any edit must be persisted immediately after the user accepts input.
   2. Translations must be persisted into corresponding messages source bundles.
   3. Translations must be taken from by using message key and locale attributes passed in.
   4. In case if there is no translation present inside messages source bundle for given key and locale, then the default message should be taken from JSP tag body.
4. Translation export functionality
   1. The system shall provide ability for user to export all in-place edits, he made so far, into messages_.properties files.
   2. Any export file must be written with using UTF-8 encoding.
5. Modules support.
   1. There should be possibility to support in place editing of translations for module messages.
   2. The distinguishing between affiliation of any message to certain module or core must be performed on basis of module naming conventions.
   3. If conventions are not followed, then the decision must be done using special attribute that overrides message inference.

The second group of requirements is non-functional ones. Requirements of this group are outlined below:

1. The client side of the system must be cross-browser.
2. The system shall be configurable through mechanism of Settings.
3. There should be user guide documentation on how to use this system.
4. Must be possible to extend system by adding new features for enabling in-place editing on module’s pages and for committing translations to the major server.
5. Portability ?
6. Your suggestions ?