Skip to content

Localiztion

Paul Schwartz edited this page Jun 1, 2015 · 3 revisions

Plain old localization

The normal model of Java is used throughout OpenELIS. The resource files are MessageRessources.properties, with the standard variations for each language.

We have added some convenience methods in us.mn.state.health.lims.common.util.StringUtil.

getMessageForKey(....) and getContextualMessageForKey(.....)

These methods will return the correct string for the current locale. getContextualMessageForKey was added to support the same label having different wording at different labs. For instance one lab may call an accession number "Accession Number" while a different lab may use the term "Lab. No." They are two different names for the same concept. This worked by post-pending the key with a lab specific identifier. We are moving away from using contextual keys because they are not maintainable at any scale, but you will still see them in the code.

#Localization of database values

The problem being solved is that values from the database are often displayed to the user as a list and even though the language on the page changes, the language for the list doesn't. There are five steps to add the localization.

  1. Add a new column to the table for a MessageResource key

    The recommended method is to use liquidbase files. But if you must:

    ALTER TABLE clinlims.panel ADD COLUMN display_key varchar(60);

  2. Override getDefaultLocalizedName() in the java object mapped to the table

    The actual code for handling the localization is in BaseObject.java. However if the key in the table is null or not found in MessageResources then something has to be displayed to the user. Each derived class supporting database localization should override this method. If not then unknown will be displayed.

  3. Add the mapping to the hibernate mapping file

    The following should be added to the hibernate mapping file

     <property name="nameKey" type="java.lang.String">
         <column name="display_key" length="60" not-null="false" />
     </property>
    
  4. Add the localized text to the MessageResource files.

    Just do it

  5. Consuming code should use getLocalizedName()

#Localization of user editable values

End users are able to edit meta data in the database.

For instance they can correct the spelling of panel names. To support this feature we are storing the localized values in the database in a table called localization. The record which is being localized will have a foreign key to this table. Accesses to the correct record in the localization table will be handled by the object being localized. For instance, the panel table has a column name_localization_id, the panel class has a member named getDefaultLocalizedName() which will get the correct value from the localization table. Remember that getDefualtLocalizedName() is called by getLocalizedName() in the base class.

There is also a LocalizationService class which given a localization object will get the correct value depending on the current locale.

Some other services also encapsulate the localization. For instance TestService has a method called getUserLocalizedTestName(...)

Clone this wiki locally