A.4 Internationalization
Internationalization is the process of designing an application so that it can be adapted to various languages and regions without engineering changes. Sometimes the term internationalization is abbreviated as i18n, because there are 18 letters between the first "i" and the last "n."
The system is an internationalized program that has the following characteristics:
-
The addition of localized data that allows the same executable to run worldwide
-
Textual elements, such as status messages and the GUI component labels, are not hard-coded in the program. Instead they are stored outside the source code and retrieved dynamically
-
Support for new languages does not require re-compilation
-
Culturally-dependent data, such as dates and currencies, appear in formats that conform to the end user's region and language
-
The application can be localized quickly.
Localization is the process of adapting software for a specific region or language by adding locale-specific components and translating text. The term localization is often abbreviated as l10n, because there are 10 letters between the "l" and the "n."
A.4.1 Internationalization
The support system internationalized framework is very intuitive and flexible, which allows Users to localize it for a particular language and character encoding schema.
The primary task of Users performing localization of the application is translating the user interface elements in the external text file - LiveTime.properties.
The following steps are a guide through the localization process. This example assumes French localization of the application and uses the ISO-8859-1 character set.
-
Ensure the Desktop’s Operating System has the appropriate character set installed
The localization file and rendering requires the character set to be available for data entry and data presentation.
-
Ensure the RDBMS is created using the appropriate character set
This is required so that French data entry can be successfully saved and retrieved from the database.
-
Specify the correct character set encoding for the system
Edit the ‘Properties’ file (/CONTAINER_APPS_PATH>/LiveTime/WEB-INF/LiveTime.woa/Contents/Resources folder) and specify the character set to use for presentation to the end user. This character set is sent to the end users to control presentation in both the user interface and outbound email.
-
Edit the UI strings in the external properties file
The ‘LiveTime.properties’ file (/CONTAINER_APPS_PATH>/LiveTime/WEB-INF/LiveTime.woa/Contents/Resources folder) stores the externalized user interface content. This file is stored in plain text, the default (English) is encoded using the ISO-8859-1 character set. Alternative versions of this file can be created in any text editor that allows the file to be saved in the necessary character set.
The first step in creating a local version of this file is to save a copy of it, representing the appropriate language. For this example of the French translation, there is no need to worry about the file encoding, simply save a copy of the file called ‘livetime_fr.properties’
A.4.2 Simple Messages
The copy of this file consists of a collection of name-value pairs, each are broken up into clusters representing user interface components.
For example:
ClassName.greetings=Hello
ClassName.farewell=Goodbye
ClassName.inquiry=How are you?
The ‘name’ or ‘key’ section (ClassName.greetings) of these strings is of little relevance to the end user except to note that if they are changed, the system is not able to look them up.
The ‘value’ component of these pairs (Hello) represents the corresponding user interface value. The (French) translator can safely edit these values and they will appear within the system.
ClassName.greetings=Bonjour.
ClassName.farewell=Au revoir.
ClassName.inquiry=Comment allez-vous?
A.4.3 Compound Messages
Compound messages contain variable data i.e., data that the support system substitutes into a message at run time. For example, given the message ‘Hello Sunshine’, the string Sunshine may vary. This message is difficult to translate because the position of the string in the sentence is not the same in all languages, or alternatively the value may need to be generated by the application based on some business logic.
Where this substitution is necessary, the localized strings have a set of braces containing an id number (a substitution variable). These blocks are replaced at run time by the system and are identified by its presence. The localized version of a given string must contain the same number of substitution variables.
For example:
ClassName.helloSunshine=hello {0}
This will render as “hello sunshine”, however we could modify this message to read “sunshine, hello” by doing this:
ClassName.helloSunshine={0}, hello
-
Edit the Locale Definitions file
The ‘LiveTimeLocales.xml’ file (/Resource folder) defines the language code and charset used in order to process the strings defined in the external properties file.
Typically, this is the charset used when the external properties file is saved.
By default the following language locale is selected:
<LOCALE language="en" country="" charset="ISO-8859-1"/>
To enable the French external properties file to behave correctly, comment the above line and uncomment the following line:
<LOCALE language="fr" country="" charset="ISO-8859-1"/>
For convenience, many values are already supplied in this file so it is just a matter of uncommenting the necessary entry.
If an entry for the locale language is non-existent, then define it in the file by supplying the language code, country code, and charset, as illustrated in the above examples.
-
File Names.
The names of the localized files do follow a standard. In the French example, livetime_fr.properties was the resulting file name. The ‘fr’ component of this name comes from iso 639-1. A full list of these codes is available here:
http://www.ics.uci.edu/pub/ietf/http/related/iso639.txt
Example of Login Page Translated:
