|
|
|
|
|
|
Creating Localized Applications with Internationalization Tags
This section includes the following topics:
What Is the I18N Framework?
WebLogic Personalization Server provides a simple framework that allows access to localized text labels and messages. The internationalization ( I18N) framework is accessible from JavaServer Pages (JSPs) through a small I18N tag library. An example is shown in Figure 7-1. The JSP extension tag library provides the following services:
Figure 7-1 An Example of Internationalization Code
Localizing Your JSP
The conventions used in the I18N tag library are based on the more general conventions used to internationalize Java applications. To understand the conceptual foundations for the <i18n:getMessage> tag, see the Javadoc for java.text.MessageFormat in the Sun Microsystem, Inc. Java 2 SDK, Standard Edition documentation. To better understand the ideas that served as the foundation for these tags, study the Javadoc for java.util.ResourceBundle and java.util.Locale.
The following tags are included in the I18N framework:
<i18n:getMessage>
<i18n:localize>
<i18n:getMessage>
This tag retrieves a localized label or message (based on the absence/presence of an args attribute). The tag optionally takes a bundle name, language, country, and variant to aid in locating the appropriate properties file for resource bundle loading.
This tag is used in the localization of JSP pages. All pages that have an internationalization requirement should use this tag.
For more information about the <i18n:getMessage> tag, see JSP Tag Library Reference.
<i18n:localize>
This tag allows you to specify a language, country, variant, and resource bundle name to use throughout a page when accessing resource bundles via the <i18n:getMessage> tag. This is a convenient way to specify these attributes once, so that you do not have to specify them again each time you use <i18n:getMessage> to retrieve localized static text or messages.
The <i18n:localize> tag also specifies a character encoding and content type to be specified for a JSP page. Because of this, the tag should be used as early in the page as possible - before anything is written to the output stream - so that the bytes are properly encoded. If you intend to display text in more than one language, pick a character set that encompasses all the languages on the page.
When an HTML page is included in a larger page (for example, as portlets are included in portal pages), only the larger page can use the <i18n:localize> tag. This is because the <i18n:localize> tag sets the encoding for the page, and the encoding must be set in the parent (including) page before any bytes are written to the response's output stream. Therefore, be careful that the encoding for the parent page is sufficient for all the content on that page as well as any included pages. The child (included) pages may continue to use the <i18n:getMessage tag>.
Note: Do not use the <i18n:localize> tag in conjunction with the <%@ page contentType="<something>" > page directive defined in the JSP specification. The directive is unnecessary if you are using this tag, and can result in inconsistent or wrong contentType declarations.
For more information about the <i18n:localize> tag, see JSP Tag Library Reference.
The JspMessageBundle
The <i18n:getMessage> tag uses the com.beasys.commerce.i18n.jsp.JspMessageBundle class. Unlike a ResourceBundle, the JspMessageBundle looks only for properties files (like the PropertyResourceBundle) within the ServletContext (on the doc path). This means that you can keep MessageBundle properties files relative to the associated JSP page, instead of having to have them on the CLASSPATH.
Another difference is that JspMessageBundles are specified using the "/" character instead of the ".". For instance, the path to a JspMessageBundle might look like this: /jsp/ordersystem/placeOrder.
If a bundle name is specified, then it can be specified absolutely or relatively. Absolute paths are treated as such if they begin with a "/". Paths not beginning with "/" are searched for relative to the JSP page's location.
If no bundle name is specified, then bundle name defaults to the name of the JSP page. For instance, if you have a JSP page called placeOrder.jsp, then JspMessageBundle would look in the same directory for a placeOrder.properties file to serve as the JspMessageBundle for the placeOrder.jsp page.
When searching for a JspMessageBundle, both the doc root and repository directories are searched, in that order. Repository directories are directories specified during servlet registration and serve as a place to store common files such as images. If no message bundle can be found, a MissingResourceException occurs. For a more in-depth description of the repository directory convention, see Repository.
How the localization Tag Works The <i18n:localize> tag first examines all provided attributes and default attributes, and then performs the following three steps:
If a base bundle name is not provided, the bundle name defaults to the name of the JSP page with .properties appended.
For example, if the name of the JSP page is placeOrder.jsp, then the default bundle name would be placeOrder.properties.
The tag will first look for resource bundles that correspond to the language parameter passed in to the tag.
If no match between bundle and language is found, then the tag will try to find a match between resource bundles and languages defined in the request header.
If a match can be made, the first language that matches is the language that is used.
If no language is specified, the default is US English (en_US).
If no message bundle can be found, then language is set to nothing ("") and "UTF-8" encoding will be used unless otherwise specified.
If character encoding is not specified, a charset appropriate for the language determined in step 2 is chosen.
If a character encoding is specified, then that will be the charset used by the page, regardless of what language was chosen in step 2.
Once the charset is determined, it is specified for the page by calling the setContentType() method on the servlet response. A call to setContentType() might look like this:
response.setContentType("text/html; charset=ISO-8859-1");
Character Encoding
When specifying the encoding, it is important to note that some encodings may not be supported for your particular operating system, virtual machine, or client browsers. To see what Sun Microsystem, Inc. supports in the J2SE package, see http://www.java.sun.com/products/jdk/1.2/docs/guide/internat/encoding.doc.html
If for any reason an encoding for a language cannot be determined and none is specified, UTF-8 encoding is used.
Displaying More than One Character Set on a Page
In general, it is best is to leave the charsetc parameters unspecified since this is more flexible and fault tolerant. An exception might be when two languages (such as Greek and Japanese) need to be displayed in the same page. In that case, you can set the charset to "UTF-8".
For a page with multiple charsets to display correctly, the end users must have the appropriate fonts installed on their machines. If a font cannot be found, non-printable characters will typically display in place of the missing characters. (Non-printable characters often look like rows of empty boxes.)
Default Character Encodings
Figure 7-1 shows how the <i18n:localize> tag maps languages to character encodings. These are the default settings.
You can override these defaults by providing any charset tag parameter you choose. For example, in the table below, the default charset for Japanese is Shift_JIS, but you could pass in x-sjis, EUC_JP, or iso-2022-jp instead. Or, as another example, to use Chinese Taiwan locale in place of Chinese, override GB2312 with Big5.
Table 7-1 Default Character Encodings
Steps for Localizing Your Application
For example: <%@ taglib uri="i18n.tld" prefix="i18n" %>
For example: <i18n:localize language="<%=language%>"
Note: When HTML pages are being included inside a larger page, only the larger page can use the <i18n:localize> tag.
For example: Use <i18n:getMessaage messageName="greeting"/> instead of hardcoding "Welcome!"
For example:
If the JSP is in public_html\mypage.jsp, then the bundle location could be
(absolute) "/mypage/text_us.properties" or
(relative) "text_us.properties".
Localizing the BEA WebLogic Personalization Server
Up to this point, this chapter has discussed localizing the application that you are building with the BEA WebLogic Personalization Server.
In developing your application, you may be required to localize some of the portal tools in the WebLogic Personalization Server. This section provides information for developers who need to localize the administration tools that are provided with this product, or who are deriving their application from examples that ship with the WebLogic Personalization Server.
The WebLogic Personalization Server administration tool is supported by JSP bean objects which employ Java internationalization conventions in the practice of presenting error and status messages. These beans use a BEA utility object called com.beasys.commerce.i18n.MessageBundle in conjunction with text-based properties files to produce two types of locale-specific display text. The two types of text are as follows:
Static Text
WebLogic Personalization Server uses the following convention when naming static text entries in the properties files:
propertyName.txt=propertyValue
For example: error.txt=Error Occurred
A static text property is acquired from a loaded MessageBundle using the following method:
public String getString(String propertyName)
For example: System.out.printin(messageBundle.getString("error.txt"));
For more information, see the Javadoc for the Portal API documentation.
Constructed Messages
The localized display text generated at runtime often depends on one or more variables, and the order of these variables in a text segment is locale-specific. In this case, the WebLogic Personalization Server provides a means for constructing message segments for display.
WebLogic Personalization Server uses the following convention when naming message entries in properties files:
propertyName.msg=propertyValue
For example:
fieldRequired.msg={0} is a required field.A constructed message is acquired from a loaded MessageBundle using the following method:
public String getMessage(Object[] args, String propertyName)
For example:
Object[] args = new Object[] {"ContentURL"};System.out.println(messageBundle.getMessage(args, "fieldRequired.msg"));
For more information, see the Javadoc for the Portal API documentation..
Note: The MessageBundle's getMessage() method internally uses a java.text.MessageFormat object. To understand how the getMessage() method works, look at the Javadoc for java.text.MessageFormat.
Resource Bundles Used in the
WebLogic Personalization Server Tools
Each properties file that supports a particular bean includes the bean name and a properties extension. For example, the properties file that supports the com.beasys.portal.admin.jspbeans.PortalJspBean bean resides in the i18n directory beneath com/beasys/portal/admin/jspbeans, and is called PortalJspBean.properties.
Localizing System Messages
You can localize the resource bundles that contain system messages related to the WebLogic Personalization Server administration tools and sample applications.
Use the following properties files to localize system messages. These property files are found under < WL_COMMERCE_HOME>/classes:
com/beasys/commerce/axiom/util.i18n/JSPBeanBase.properties
com/beasys/commerce/user/jsp/beans/i18n/LDAPConfigBean.properties
com/beasys/commerce/user/jsp/beans/i18n/ProfileTypeBean.properties
com/beasys/commerce/user/jsp/beans/i18n/PropertyBean.properties
com/beasys/commerce/user/jsp/beans/i18n/PropertySetBean.properties
com/beasys/commerce/user/jsp/beans/i18n/RealmConfigBean.properties
com/beasys/commerce/user/jsp/beans/i18n/UserBean.properties
com/beasys/commerce/portal/admin/jspbeans/i18n/PortalJspBean.properties
com/beasys/commerce/portal/admin/jspbeans/i18n/PortletJspBean.properties
com/beasys/commerce/portal/admin/jspbeans/i18n/PortalPersonalization.properties
com/beasys/commerce/portal/admin/jspbeans/i18n/PortalRemoveJspBean.properties
com/beasys/commerce/portal.jspbeans/i18n/PortalAppearanceBean.properties
com/beasys/commerce/axiom.util/i18n/JspBeanBase.properties
|
|
|
|
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|