Support a new language

To support a new language to WebSphere Portal you add resource bundles and, where applicable, JSPs for the new language.

Some JSPs use resource bundles; others, such as help JSPs, are translated directly. Then you update the list of available languages by adding the new language to the portal. You do this by using the XML configuration interface. Use the example XML script CreateLanguage.xml to add the new language for the portal. The new language is then listed in the language selection menu boxes that are available in administration portlets, or for example, in Edit My Profile, Preferred language. The new language will be available only to portlets that you add to the portal, if these portlets support the newly added language and if you make the required language files available. None of the WebSphere Portal user interface or messages will be translated to the new language.


Add resource bundles for a new language

Resource bundles are used to store text displayed in JSPs or text used in Java code. In WebSphere Portal, resource bundles are located in the JAR files wp.ui.jar and wp.theme.customizer.ext.jar in the nls directory inside the file.

The JAR file wp.ui.jar is located under the following directory:

The JAR file wp.theme.customizer.ext.jar is located under the following directory:

To add new resource bundles for additional languages, place them into the following directory:

The naming convention for resource bundles is [bundle]_ [language]_ [country]_ [variant].properties . The ISO standard ISO-639 is used for the language codes of most languages. For Hebrew the old language code iw is used. The ISO standard ISO-3166 is used for the country/region codes. WebSphere Portal supports the use of [variant], although resource bundles supplied with the portal do not use it. If the portal configuration includes Lotus Collaborative Services, add a new CSRes_language.properties file for each additional language to the following directory:

WebSphere Portal uses properties files called by the Java class java.util.ResourceBundle to store text rendered in JSPs. The Java mechanism searches for the resource bundles in the following order:

  1. [bundle]_ [language]_ [country]_ [variant].properties

  2. [bundle]_ [language]_ [country].properties

  3. [bundle]_ [language].properties

  4. [bundle].properties

In WebSphere Portal, the default bundles [bundle].properties are in English.

It is required that all WebSphere Portal defined languages have resource bundles defined as well for the themes to function correctly. It is recommended that after a language is installed, the resource bundles located within wp.ui.jar and wp.theme.customizer.ext.jar are processed through the procedure outlined below.

To add a resource bundle, proceed with the following steps:

  1. Copy all existing resource bundles into WP_PROFILE/PortalServer/config/nls directory.

  2. Name it according to the naming convention for resource bundles using locale code for the language(s) installed.

  3. Translate the resource bundle files.

  4. Convert it into Unicode with the Native-to-ASCII converter native2ascii which comes as part of JDK. For more detail on native2ascii see the Java documentation native2ascii - Native-to-ASCII Converter.

  5. Restart Portal so that the new resource bundles can be recognized.


Add JSPs for a new language

Some JSPs that contain mostly text, such as help JSPs, are translated directly which means that the text is contained in the JSP and not in a resource bundle. For JSPs that do not use resource bundles, you need to copy and translate an existing JSP and store it in the appropriate location.

The location of JSPs can be, for example, jsp/ [mime-type]/ [language]/ [country]/ [variant]/files.jsp. For instance, existing help JSPs are already translated in WebSphere Portal and placed in the relevant [language]and [country] subdirectories. When deciding where to store new JSPs, you need to consider how the portal locates a JSP for rendering its content.

The following is an example of the order in which directories are searched, where path1 is a user-defined path, ie5 is the markup version (here: Internet Explorer 5), and the locale is en_US:

  1. /html/path1/ie5/en_US/mytemplate.jsp

  2. /html/path1/ie5/en/mytemplate.jsp

  3. /html/path1/ie5/mytemplate.jsp

  4. /html/path1/en_US/mytemplate.jsp

  5. /html/path1/en/mytemplate.jsp

  6. /html/path1/mytemplate.jsp

  7. /html/en_US/mytemplate.jsp

  8. /html/en/mytemplate.jsp

  9. /html/mytemplate.jsp

  10. /mytemplate.jsp

This means that if the user language is not supported, the portal will choose the file in the locale independent location, which in the example is the English file.


National language support for People Finder fields

All fields of the People Finder portlet must have associated language strings defined in each language property file, PeopleFinderUI_language_code.properties. The field names are the names of the corresponding attributes in Member Manager.

For each People Finder field, three strings are required:

Example: 

displayName = Name
displayName_Long = Preferred Name
displayName_Desc = Display name

The resource key for each field refers to the appropriate language property file, /nls/PeopleFinderUI_language_code.properties. Foreign language translations of People Finder fields must be stored in the appropriate language property file.

Language properties files are in the following location on the WebSphere Portal server (nnnnnnn represents a random number generated by the installation process when the lwppeoplefinder.jar file is installed):


Parent

Language support
Set the language fallback filter


Related tasks


Dynamically changing the language during the session
Sample XML configuration files


Change the character set for a language
Set the the language

native2ascii - Native-to-ASCII Converter

 


+

Search Tips   |   Advanced Search