skip to main content
Programmer's documentation > Building Web applications > JViews web applications globalization and multicultural support > Tips for multicultural support JViews web applications
 
Tips for multicultural support JViews web applications
Here are some useful tips for multicultural support of your JViews web applications.
JSF locale-determination process
Here are some tips for the JavaServer™ Faces (JSF) locale-determination process:
*When a JSF request arrives, the locale-determination process first searches for a match for the requested locale among the locales in the HTTP header "Accept-Language" attribute (set by the language options in the browser) and supported locales configured by element in faces-config.xml.
*If no language option is set in the browser, the process uses the default locale configured by element in faces-config.xml.
*If no locale can be matched, the process tries to use the default locale.
* If none of above locales is found, the process uses the JVM default locale on the server side. Note that after the locale has been determined, the JViews web application stores it in the current thread context and uses it directly for later tasks in the current thread. The stored locale is cleaned up when the request is finished.
JSF locale-identification priority
In JSF, the user can declare the supported locale in two ways:
1. Specify the locale by setting the locale attribute in f:view tag, for example <f:view locale="en_US">.
2. Specify the supported locales in faces-config.xml within the element.
 
         <application>
                <locale-config>
                     <default-locale>en_US</default-locale>
                     <supported-locale>en_US</supported-locale>
                </locale-config>
        ...
        </application>
 
Both of these ways work, but if you use them together, <f:view locale="..."> has the higher priority during locale determination.
Retrieve the ResourceBundle in JViews web applications
The JViews library supplies some utilities to work with ResourceBundle in a convenient way.
To do this:
*Create the messages.properties file and put the file in the same folder as the Java™ class.
*Organize message properties by ClassName.key=value format in the messages.properties file. For example:
 
            FrameworkBean.CustomImapGeneratorOn=Custom imap generator called on {0}
            FrameworkBean.onImageMap=on image map
            ...
Note that the messages.properties file should be put in the same package as the class FrameworkBean.
*Load ResourceBundle
As a convenience, the JViews library provides the class IlvResourceUtil to work with ResourceBundle, which does not require the user to hard code resource bundle paths and is also a convenient way to retrieve different locales when necessary.
Here are some rules to decide which locale should be applied:
*If the localized data should be shown in the browser (for example, information messages), use the API ilog.views.util.IlvResourceUtil.getCurrentLocaleString(Class clazz, String subkey) to retrieve the message property value. For example:
 
             ilog.views.util.IlvResourceUtil.getCurrentLocaleString(FrameworkBean.class, "onImageMap");
 
This finds the correct locale from the current JSF context and returns the localized message value from the key.
*If the localized data must be shown in the Server console only, (for example, log messages), use the API ilog.views.util.IlvResourceUtil.getServerLocaleString(Class clazz, String subkey) to retrieve the message property value. For example:
 
             ilog.views.util.IlvResourceUtil.getServerLocaleString(FrameworkBean.class, "CustomImapGeneratorOn")
 
This finds the JVM default locale and returns the translated message value from the key.
How to change your browser language settings
You can reference the documentation http://www.w3.org/International/questions/qa-lang-priorities for information about how to set language options in many different browsers.

Copyright © 2018, Rogue Wave Software, Inc. All Rights Reserved.