Table Of Contents
1. Internationalization
2. Internationalization of Portlets
3. Steps for Internationalization
1. Creating the Directory Structure
2. Adding I18N Support for Locales
3. Adding I18N Support to the Portlet Source
1. JSP Page
4. Screenshots for User Group List
5. Advantages of Custom Tags over Scriptlets
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."
An internationalized program has the following characteristics:
- With the addition of localized data, the same executable can run in different locales .
- Textual elements, such as status messages and the GUI component labels, are not hardcoded in the program. Instead they are stored outside the source code and retrieved dynamically.
- Support for new languages does not require recompilation.
- Culturally-dependent data, such as dates and currencies, appear in formats that conform to the end user's region and language.
- It 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.
Internationalization of Portlets
Internationalization of portlets can be done using various different methods. Two of the simplest and most efficient methods are:-
- Using Scriptlets
- Using Custom Tags and Tag Libraries
This document explains internationalization using the second method i.e. using tag libraries and custom tags.
Steps for Internationalization
Internationalizing portlets involves adding internationalization support for locales, to the portlet source. The procedures described in this section are those used for internationalizing the User Group Portlet Pages.
Creating the Directory Structure
You need to have the following structure in your project’s Java Resources folder:
Java Resources --à Java Source-à resourceBundle -àresourceBundle.properties
-à resourceBundle_en.properties
-à resourceBundle_da.properties
à helloi18n -à HelloI18nPortlet.java
-à HelloI18nPortletSessionBean.jpg
Adding I18N Support for Locales
To add I18N support:
1. In the portlet.xml file, specify, by means of the
<supported-locale>ensupported-locale>
<supported-locale>dasupported-locale>
<resource-bundle>resourceBundle.resourceBundleresource-bundle>
Where “en” and “da” are the two locales that our portlets need to support, namely English and Danish. The resource bundle “resourceBundle.resourceBundle” is the default resource bundle that our application would be using in case if no resource bundle is specified.
2. Next you need to add the keys in the Resource Bundles corresponding to every element on your JSP page. Also we need to add three standard constants in all the Resource Bundles. These three standard constants are Title, Shot Title and Keywords and are added as follows in the .properties file:
javax.portlet.title=Hello Internationalization Portlet
javax.portlet.short-title=Hello I18n
javax.portlet.keywords=i18n, portlet
3. The code in the resourceBundle.properties along with the key – value pairs looks as below: resourceBundle_da.properties
javax.portlet.title=Hello Internationalization Portlet2
javax.portlet.short-title=Hello I18n2
javax.portlet.keywords=i18n,portlet
message.key.lblUserGroupName = Bruger Sammenstille Benævne
message.key.lblUserType = Bruger Skrive
message.key.lblUserList = Bruger Liste
message.key.lblSelectedUserList = Udsøgt Bruger Liste
message.key.lblUserGroupConfiguration = Bruger Sammenstille Konfiguration
message.key.btnEdit = Beholde
message.key.btnBack = Tilbage
Adding I18N Support to the Portlet Source
Adding I18N support to the portlet's source files involves a configuration of the JSP page.
Here are the steps to add support to the JSP page:
1. Define the JSP tag library for internationalization, that is, fmt.tld. as follows:
<%@ taglib uri=”/WEB-INF/tld/portlet.tld” prefix=”portletAPI” %>
<%@ taglib uri=”http://java.sun.com/jstl/fmt” prefix=”fmt” %>
Set up the resource bundle by defining the fmt:setBundle tag according to this syntax:
.resource_bundle_name"/>
This resource bundle, loaded for the specified locale, loads resource messages. If Portal Server cannot find the resource bundle for a specific locale, it follows the standard Java locale fallback mechanism.
For example, the tag in User Group List reads like this:
2. Fetch the messages from the resource bundle by defining the
3. You need to add a drop down on your page which can be used to select the language according to the locale. On the ‘onchange’ event of the drop down you need to call a function that will specify the keys from the resource bundle that need to be used for the elements. The function for the User Group List form is as below:
function setLocale()
{
var selected = document.getElementById('languageSelect');
var selectedValue = selected.options[selected.selectedIndex].value;
if(selectedValue == "English")
{
'
'
document.all.lblUserGroupView.innerText = '
document.all.lblShowRecords.innerText = '
document.all.btnNewUserGroup.value = '
document.all.btnShowHistory.value = '
document.all.btnNewUserGroup.style.width = '100px';
document.all.btnShowHistory.style.width = '80px';
document.all.headerUserGroupName.innerText = '
document.all.headerNoOfUsers.innerText = '
document.getElementById('languageSelect').options[0].text = '
document.getElementById('languageSelect').options[1].text = '
}
else if (selectedValue == "Danish")
{
'
'
document.all.lblUserGroupView.innerText = '
document.all.lblShowRecords.innerText = '
document.all.btnNewUserGroup.value = '
document.all.btnShowHistory.value = '
document.all.btnNewUserGroup.style.width = '140px';
document.all.btnShowHistory.style.width = '100px';
document.all.headerUserGroupName.innerText = '
document.all.headerNoOfUsers.innerText = '
document.getElementById('languageSelect').options[0].text
='
document.getElementById('languageSelect').options[1].text = '
}
}
Screenshots for User Group List
English Version
Danish Version
Advantages of Custom Tags over Scriptlets
Custom tags have been used instead of scriptlets because of the following reasons:
- Scriptlets mix logic with presentation--Scriptlets are islands of program code in a sea of presentation code. Changing either requires some understanding of what the other is doing to avoid breaking the relationship between the two. Scriptlets can easily confuse the intent of a JSP page by expressing program logic within the presentation.
Custom tags encapsulate program logic so that JSP pages can focus on presentation.
Scriptlets break developer role separation--Because scriptlets mingle programming and Web content, Web page designers need to know either how to program or which parts of their pages to avoid modifying. Poorly implemented scriptlets can have subtle dependencies on the surrounding template data.
Custom tags help the separation of developer roles, because programmers create the tags, and page authors use them.
- Scriptlets make JSP pages difficult to read and to maintain--JSP pages with scriptlets mix structured tags with JSP page delimiters and Java language code. The Java language code in scriptlets often uses "implicit" objects, which are not declared anywhere except in the JavaServer Pages specification. Also, even consistent indentation does not help readability much for nontrivial pages.
JSP pages with custom tags are composed of tags and character data, which is much easier to read. JSP pages that use XML syntax can be validated as well.
- Scriptlet compile errors can be difficult to interpret--Many JSP page compilers do a poor job of translating line numbers between the source page and the generated servlet. Even those that emit error messages often depend on invisible context, such as implicit objects or surrounding template data. With poor error reporting, a missed semicolon can cost hours of development time.
Erroneous code in custom tags will not compile either, but all of the context for determining the problem is present in the custom tag code, and the line numbers do not need translation.
· Custom tags maintain separation between developer roles. They encourage reuse of logic and state within a single source file. They also improve source code readability, and improve both testability and error reporting.
· Another very important advantage of custom tags is their ability to communicate with other tags on the same page. With traditional JSP tags, developers can set properties to control the behavior of a JavaBean component, but the bean simply does what it does on its own. By breaking down processes into smaller components, JSP developers can mix and match custom tags to build more complex processes for greater control of dynamic content.
- Using the output of one custom tag as the input for another increases the tags' reusability..
0 comments:
Post a Comment