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."
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’
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?
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: