1 / 62

Localizing J2EE Web Applications

Internationalization. ?Internationalization is the process of generalizing a product so that it can handle multiple languages and cultural conventions without the need for redesign. Internationalization takes place at the level of program design and document development." 1AKA: Internationalisatio

tulia
Download Presentation

Localizing J2EE Web Applications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


    2. Localizing J2EE Web Applications Tony Jewtushenko Principal Product Manager LRC Localisation Summer School, June 2004 This paper will describe how to localize J2EE Web Applications, with specific focus on the Jakarta Struts application development framework. We’ll explore the basics of Java’s built in language and locale support, JSP and JSTL tag support for translatable resources, applications architecture scenarios for multilingual applications, and briefly review business component libraries that dramatically simplify the development of multilingual applications.This paper will describe how to localize J2EE Web Applications, with specific focus on the Jakarta Struts application development framework. We’ll explore the basics of Java’s built in language and locale support, JSP and JSTL tag support for translatable resources, applications architecture scenarios for multilingual applications, and briefly review business component libraries that dramatically simplify the development of multilingual applications.

    3. Internationalization “Internationalization is the process of generalizing a product so that it can handle multiple languages and cultural conventions without the need for redesign. Internationalization takes place at the level of program design and document development.” 1 AKA: Internationalisation – UK Spelling and i18n. Internationalization can be characterized as design and engineering required to support BiDi language support, Asian double-byte character sets, Internationalization can be characterized as design and engineering required to support BiDi language support, Asian double-byte character sets,

    4. Localization “Localization involves taking a product and making it linguistically and culturally appropriate to the target locale (country/region and language) where it will be used and sold.” 1 AKA: Localisation - the UK English spelling and L10n - the techie contraction The terms “Localization”, “Internationalization” are sometimes used interchangeably, and often misunderstood. To provide us with a frame of reference, we turn to LISA, the Localization Industry Standards Association (http://www.lisa.org) for clear industry standard definitions. Localization includes translation – the process of converting strings written in one language, to another. The terms “Localization”, “Internationalization” are sometimes used interchangeably, and often misunderstood. To provide us with a frame of reference, we turn to LISA, the Localization Industry Standards Association (http://www.lisa.org) for clear industry standard definitions. Localization includes translation – the process of converting strings written in one language, to another.

    5. Multilingual Application Basic Concepts Data representation: charter set support Data manipulation: collation, direction of text and internal representation Data display: display strings, currency, number, date formats weights and measures Data input: understand the format of the data submitted to the application Multilingual Application Basic Concepts To be considered “Multlingual”, an application has to support the following 4 elemental categories of features:[1] ·         Data representation: support all the character set encodings that any end users may use ·         Data manipulation: basic data functions, such as collation, direction of text and internal representation, must bs supported ·         Data display: display strings, currency, number, date formats weights and measures , etc., in a format an end user will understand. Data input: must understand the format of the data submitted to the application. For example, a British user submits the date “02/09/04” for the 2nd September 2004, while an American would submit the same date as “09/02/04”. Knowing the format of submitted data is essential to data integrity. Multilingual Application Basic Concepts To be considered “Multlingual”, an application has to support the following 4 elemental categories of features:[1] ·         Data representation: support all the character set encodings that any end users may use ·         Data manipulation: basic data functions, such as collation, direction of text and internal representation, must bs supported ·         Data display: display strings, currency, number, date formats weights and measures , etc., in a format an end user will understand. Data input: must understand the format of the data submitted to the application. For example, a British user submits the date “02/09/04” for the 2nd September 2004, while an American would submit the same date as “09/02/04”. Knowing the format of submitted data is essential to data integrity.

    6. Stages of a Multilingual Development Process Internationalization Localization Identify / isolate / extract Translation Re-use Translations (optional) Stages of a Multilingual Application Development Process Every organization has their favorite development and process improvement methodologies. However, in order to develop multilingual applications, at least the first three of the following processes must be incorporated into their development process: 1.       Internationalization is the process of designing a generalized product so that it supports multiple languages, locale and cultural requirements. This process must be mostly complete before the other processes can begin. It is known by its nickname i18n, which stands for “18 characters between i and n”. 1.       Localization is the process of making a product appropriate for a particular locale’s linguistic (language), cultural or financial requirements. It is sometimes referred to as l10n, which stands for “10 characters between l and n”. a.       Translation is the process of converting text written in one language to another language. 3rd party tools for terminology management and translation memory. b.       Re-use Translation (optional) once the first three processes have been successfully completed, reusing previous translations can save a lot of money especially if you’re making only a few small changes. You can develop your own tools to leverage translation, or you can choose among a number of 3rd party tools that are purpose built for the task. More on this later. Stages of a Multilingual Application Development Process Every organization has their favorite development and process improvement methodologies. However, in order to develop multilingual applications, at least the first three of the following processes must be incorporated into their development process: 1.       Internationalization is the process of designing a generalized product so that it supports multiple languages, locale and cultural requirements. This process must be mostly complete before the other processes can begin. It is known by its nickname i18n, which stands for “18 characters between i and n”. 1.       Localization is the process of making a product appropriate for a particular locale’s linguistic (language), cultural or financial requirements. It is sometimes referred to as l10n, which stands for “10 characters between l and n”. a.       Translation is the process of converting text written in one language to another language. 3rd party tools for terminology management and translation memory. b.       Re-use Translation (optional) once the first three processes have been successfully completed, reusing previous translations can save a lot of money especially if you’re making only a few small changes. You can develop your own tools to leverage translation, or you can choose among a number of 3rd party tools that are purpose built for the task. More on this later.

    7. What’s Localized in Web Applications: Titles Button Text (UIX) Button Graphics / Text (JSP) Links Labels HTML and XML Markup Error and validation messages Database Row or Column names Hint (balloon) text Help

    8. J2EE: “Java 2 Platform Enterprise Edition” Sun’s Java-centric platform independent environment for developing, building and deploying Web-based enterprise applications. EJB, JSP, JAX-RPC, Java Servlets, J2EE Connector Architecture, J2EE Management Model, J2EE Deployment API, JMX, J2EE Authorization Contract for Containers, JAXR, JMS, JNDI, JTA, CORBA, and JDBC data access API. The Java 2 Platform Enterprise Edition, or J2EE as it’s commonly known, consists of a set of coordinated specifications and practices providing solutions for developing, testing, localizing, deploying, and managing multitier server-centric applications. It extends the Java 2 Standard Edition Platform (J2SE) with capabilities that provide a stable, secure, and fast Java platform for the Enterprise. It reduces the complexity and cost of developing and deploying multitier solutions, enabling rapid development and deployment of corporate applications. The main J2EE technologies include: Enterprise JavaBeans components (EJB), JavaServer Pages (JSP), Java API for XML-Based RPC (JAX-RPC), Java Servlets, J2EE Connector Architecture, J2EE Management Model, J2EE Deployment API, Java Management Extensions (JMX), J2EE Authorization Contract for Containers, Java API for XML Registries (JAXR), Java Message Service (JMS), Java Naming and Directory Interface (JNDI), Java Transaction API (JTA), CORBA, and JDBC data access API. Typically, at the Client level, J2EE supports HTML, and Java apps or applets. The HTML that is presented to the end user is dynamically created by servlets or JSPs. At the logic level, EJB’s transparently provide basic functions for memory management, threading, concurrency and security. Connectivity with back-end data sources is provided by JDBC.The Java 2 Platform Enterprise Edition, or J2EE as it’s commonly known, consists of a set of coordinated specifications and practices providing solutions for developing, testing, localizing, deploying, and managing multitier server-centric applications. It extends the Java 2 Standard Edition Platform (J2SE) with capabilities that provide a stable, secure, and fast Java platform for the Enterprise. It reduces the complexity and cost of developing and deploying multitier solutions, enabling rapid development and deployment of corporate applications. The main J2EE technologies include: Enterprise JavaBeans components (EJB), JavaServer Pages (JSP), Java API for XML-Based RPC (JAX-RPC), Java Servlets, J2EE Connector Architecture, J2EE Management Model, J2EE Deployment API, Java Management Extensions (JMX), J2EE Authorization Contract for Containers, Java API for XML Registries (JAXR), Java Message Service (JMS), Java Naming and Directory Interface (JNDI), Java Transaction API (JTA), CORBA, and JDBC data access API. Typically, at the Client level, J2EE supports HTML, and Java apps or applets. The HTML that is presented to the end user is dynamically created by servlets or JSPs. At the logic level, EJB’s transparently provide basic functions for memory management, threading, concurrency and security. Connectivity with back-end data sources is provided by JDBC.

    9. J2EE: Key Benefits Rapid development Support for Web services Standardized connectivity to existing data sources and applications Platform independence – no “vendor lock-in” Faster product lifecycle. J2EE provides containers that simplify development of applications by separating business logic from resource and lifecycle management. Since enterprise infrastructure is provided as part of J2EE, developers need only focus on the business aspect of their application. J2EE provides a framework for developing and deploying Web services to the Java platform. JAX-RPC (Java API for XML-based RPC) provides Java developers with the technology required to develop SOAP based portable web services. J2EE technology provides connectivity between existing systems and the web. J2EE offers Java Message Service for loosely integrating applications, CORBA for integrating systems using remote procedure calls. And J2EE provides for connectivity between various enterprise systems such as HR, Payroll, ERP, CRM, etc. by using J2EE Connectors. “Write Once, Deploy Anywhere”: Standard based development means implementers can choose both their server vendors, as well as vendors who provide applications solutions. The J2EE Compatibility Test Suite (CTS) is provided by Sun to J2EE licensees, and helps ensure portability for J2EE applications. Choosing J2EE avoids single sourcing and vendor lock-in.Faster product lifecycle. J2EE provides containers that simplify development of applications by separating business logic from resource and lifecycle management. Since enterprise infrastructure is provided as part of J2EE, developers need only focus on the business aspect of their application. J2EE provides a framework for developing and deploying Web services to the Java platform. JAX-RPC (Java API for XML-based RPC) provides Java developers with the technology required to develop SOAP based portable web services. J2EE technology provides connectivity between existing systems and the web. J2EE offers Java Message Service for loosely integrating applications, CORBA for integrating systems using remote procedure calls. And J2EE provides for connectivity between various enterprise systems such as HR, Payroll, ERP, CRM, etc. by using J2EE Connectors. “Write Once, Deploy Anywhere”: Standard based development means implementers can choose both their server vendors, as well as vendors who provide applications solutions. The J2EE Compatibility Test Suite (CTS) is provided by Sun to J2EE licensees, and helps ensure portability for J2EE applications. Choosing J2EE avoids single sourcing and vendor lock-in.

    10. MVC Design Pattern MVC = Model / View / Controller Model components maintain backend data View provides end user presentation layer Controller provides page flow logic, and validation Model-View-Controller design pattern (MVC) was developed at Xerox Palo Alto Research Center (PARIC) in the 70’s. It’s primary function was to simplify the three main functions that exist in all applications: Model Component: access to a back-end database or remote system View Component: provides a User Interface layer. Controller Component: Workflow automation and design logic of the application, event and error handling. It’s certainly possible to provide support for all three of these functions in the same module – and early JSP code in fact usually was done that way – but HTML designers are usually different developers than those who write Java code for controlling processing. MVC provides the ability to segregate project artifacts between HTML and Java developers. But, optimally, we’d want to move page and exception handling to a single servlet based controller. This is exactly what was proposed in Java Server Pages (JSP) version 0.92 spec as “Model 1” and “Model 2” MVC implementations. The key differences between Model 1 and Model 2 are: In Model 1, an HTTP request is sent to the JSP file, and all the processing is done by the JSP itself (or Bean it interacts with), and the HTTP response comes directly from the JSP. For Model 2, a servlet rather than a JSP file, receives the initial HTTP request, processes the tasks required for the request, stores data to the bean, passes the data onto the JSP, which then pulls the data from the bean and renders the HTTP response. With MVC Model 2, the presentation layer is separated from the underlying code. In a typical localization process, identifying and extracting program resources for localization is one of the more tiresome and error producing tasks. MVC Model 2 takes care most of this work automatically, and thus simplifies and improves the localization engineering process.Model-View-Controller design pattern (MVC) was developed at Xerox Palo Alto Research Center (PARIC) in the 70’s. It’s primary function was to simplify the three main functions that exist in all applications: Model Component: access to a back-end database or remote system View Component: provides a User Interface layer. Controller Component: Workflow automation and design logic of the application, event and error handling. It’s certainly possible to provide support for all three of these functions in the same module – and early JSP code in fact usually was done that way – but HTML designers are usually different developers than those who write Java code for controlling processing. MVC provides the ability to segregate project artifacts between HTML and Java developers. But, optimally, we’d want to move page and exception handling to a single servlet based controller. This is exactly what was proposed in Java Server Pages (JSP) version 0.92 spec as “Model 1” and “Model 2” MVC implementations. The key differences between Model 1 and Model 2 are: In Model 1, an HTTP request is sent to the JSP file, and all the processing is done by the JSP itself (or Bean it interacts with), and the HTTP response comes directly from the JSP. For Model 2, a servlet rather than a JSP file, receives the initial HTTP request, processes the tasks required for the request, stores data to the bean, passes the data onto the JSP, which then pulls the data from the bean and renders the HTTP response. With MVC Model 2, the presentation layer is separated from the underlying code. In a typical localization process, identifying and extracting program resources for localization is one of the more tiresome and error producing tasks. MVC Model 2 takes care most of this work automatically, and thus simplifies and improves the localization engineering process.

    11. MVC Web Application Architecture The MVC Architecture process flow for Web Applications is as follows: Client Web UI issues an HTTP request to the application. Controller receives the HTTP request, and proceeds based on business rules. The Model interacts with back-end data systems Data processed and returned from Model components is prepared by the Controller for the View components to render. View component renders the HTTP response sent to the Web Browser UI. The MVC Architecture process flow for Web Applications is as follows: Client Web UI issues an HTTP request to the application. Controller receives the HTTP request, and proceeds based on business rules. The Model interacts with back-end data systems Data processed and returned from Model components is prepared by the Controller for the View components to render. View component renders the HTTP response sent to the Web Browser UI.

    12. Jakarta Struts Created in 2000 Current version = 1.1 Open source J2EE applications development framework Primarily based on JSP and Servlet technology. Subproject of Apache Jakarta Supports MVC Model 2 architecture View and Controller are separated Cleanly separates page design from underlying Java code Struts is an XML based MVC 2 framework for building Web Applications. It’s primarily based on servlet and JSP technology, and has been in existence since about 2000. The current revision is 1.1. Struts is distributed under the Apache Software Foundation license. The code is copyrighted, but is free to use in any application. See the the ASF License for specifics: http://www.apache.org/LICENSE-1.1 Struts implements MVC Model 2 as follows: The model is an Action class that provides the business logic as defined by a the application. The struts-config.xml file defines the flow from controller to Action class. The view contains a number of JSP custom tag libraries that can render forms quickly and work together with the controller. The controller servlet sends incoming requests to an appropriate Action class. A number of utility classes are provided to support internationalization, access to JavaBean properties, and XML parsing. These custom tag libraries are especially helpful since JSP’s are notoriously difficult to localize. Other important components of Struts: web.xml: Struts contains a web.xml XML file that contains rules about how to redirect a request upon it’s arrival. This file configures the application and is used by the JSP server when initializing the application.. Struts-config.xml The struts-config.xml file is the backbone of the entire framework. Where web.xml defines where a request goes upon arrival, struts-config.xml defines what happens to it. It describes how the various components fit together, and defines the action mappings. This file also contains the setting describing from where our message resources are loaded.Struts is an XML based MVC 2 framework for building Web Applications. It’s primarily based on servlet and JSP technology, and has been in existence since about 2000. The current revision is 1.1. Struts is distributed under the Apache Software Foundation license. The code is copyrighted, but is free to use in any application. See the the ASF License for specifics: http://www.apache.org/LICENSE-1.1 Struts implements MVC Model 2 as follows: The model is an Action class that provides the business logic as defined by a the application. The struts-config.xml file defines the flow from controller to Action class. The view contains a number of JSP custom tag libraries that can render forms quickly and work together with the controller. The controller servlet sends incoming requests to an appropriate Action class. A number of utility classes are provided to support internationalization, access to JavaBean properties, and XML parsing. These custom tag libraries are especially helpful since JSP’s are notoriously difficult to localize. Other important components of Struts: web.xml: Struts contains a web.xml XML file that contains rules about how to redirect a request upon it’s arrival. This file configures the application and is used by the JSP server when initializing the application.. Struts-config.xml The struts-config.xml file is the backbone of the entire framework. Where web.xml defines where a request goes upon arrival, struts-config.xml defines what happens to it. It describes how the various components fit together, and defines the action mappings. This file also contains the setting describing from where our message resources are loaded.

    13. Oracle J2EE Application Development Framework (ADF) The Oracle J2EE architectural layers are represented as follows: Business Services Provides declarative building-blocks to implement scalable business services, data access objects, and business objects that enforce business rules and handle database persistence. Model Provides consistent, declarative data-binding against a multiple backend technologies accommodating business services implemented as ADF Application Modules, custom JavaBeans, EJB's, and Web Services. View Provides declarative page definition and a rich UI component set for HTML and wireless UI's, complementing ADF's support for JSP pages and JSP tag libraries like JSTL, Jakarta Struts, ADF DataTags, and others. The ADF JClient layer dovetails with Swing to simplify building sophisticated rich client UI's. Controller Integrated support for Jakarta Struts allows data-binding and business services to work seamlessly with this popular controller-layer framework, while the ADF Controller layer provides the option of a more sophisticated, fully-declarative page flow engine. The Oracle J2EE architectural layers are represented as follows: Business Services Provides declarative building-blocks to implement scalable business services, data access objects, and business objects that enforce business rules and handle database persistence. Model Provides consistent, declarative data-binding against a multiple backend technologies accommodating business services implemented as ADF Application Modules, custom JavaBeans, EJB's, and Web Services. View Provides declarative page definition and a rich UI component set for HTML and wireless UI's, complementing ADF's support for JSP pages and JSP tag libraries like JSTL, Jakarta Struts, ADF DataTags, and others. The ADF JClient layer dovetails with Swing to simplify building sophisticated rich client UI's. Controller Integrated support for Jakarta Struts allows data-binding and business services to work seamlessly with this popular controller-layer framework, while the ADF Controller layer provides the option of a more sophisticated, fully-declarative page flow engine.

    14. Exercise 1 Create a Basic JSP Page

    15. Exercise 2 Create a Basic UIX Page

    16. Challenges in J2EE i18n Encoding – Locale specific character set support Messaging – Isolation and Translation of UI resources such as text Formatting – Handling input and output of locale conventions for formatting of numbers, dates, currency

    17. Encoding in J2EE JSP is Java, so Unicode is used internally, but… 3 types of encoding must be considered for JSP’s Request: Encoding in which parameters in an incoming request are interpreted. Page (JSP pages) the encoding of the bytes in the JSP page itself. If not set, encoding defaults to contentType charset attribute setting. Response encoding to be used for generated web pages, based on the capabilities of the targeted browsers.

    18. Request Encoding Parameters submitted as byte values, in the specified charset Set automatically to Accept-Language header using: <fmt:requestEncoding/> or first i18n action Or set explicitly with <fmt:requestEncoding value=“UTF-8”/>

    19. Page Encoding Usually determined by editing tools conventions Set in page directive <%@ page pageEncoding=“Shift_JIS” contentType=“text/html;charset=UTF-8” %> Must be extension of ASCII charset (ie, no EBCDIC or UTF-16) so UTF-8 is OK If not explicitly set, defaults to contentType charset attribute value, but recommended to explicitly set

    20. Response Encoding Identifies the encoding of the generated web page Set in contentType attribute <%@ page pageEncoding=“Shift_JIS” contentType=“text/html;charset=UTF-8” %>

    21. Exercise 3 Encoding

    22. Java ResourceBundles: Localizable content ListResourceBundle .java file Can contain binary data Compiled into class file PropertyResourceBundles .properties file Contain strings only Values acquired at runtime Requires 8859-1 encoding Non 8859-1 characters represented as UTF8 escape codes (ie, \uxxxx) native2ascii to convert non 8859-1 content The abstract class ResourceBundle has two subclasses: PropertyResourceBundle and ListResourceBundle. A PropertyResourceBundle is stored in a properties file. A properties file is a plain-text file that contains translatable text. Properties files are not part of the Java source code, and they can contain values for String objects only. If you need to store other types of objects, use a ListResourceBundle instead. The PropertyResourceBundle contents must be encoded as ISO 8859-1. Any characters not in that charset must be stored as escaped Unicode. The ListResourceBundle class manages resources in a name, value array. Each ListResourceBundle is contained within a class file (compiled Java file). You can store any locale-specific object in a ListResourceBundle. To add support for an additional Locale, you subclass the base class, save it to a file with an locale / language extension, translate it, and compile it into a class file. The ResourceBundle class is flexible. If you first put your locale-specific String objects in a PropertyResourceBundle, you can still move them to a ListResourceBundle later. There is no impact on your code, since any call to find your key will look in both the ListResourceBundle as well as the PropertyResourceBundle. Note that the precedence order is class before properties. So if a key exist for the same language in both a Class file (ListResourceBundle) as well as a Properties file, the value in the Class file (ListResourceBundle) will be the value presented to the user.The abstract class ResourceBundle has two subclasses: PropertyResourceBundle and ListResourceBundle. A PropertyResourceBundle is stored in a properties file. A properties file is a plain-text file that contains translatable text. Properties files are not part of the Java source code, and they can contain values for String objects only. If you need to store other types of objects, use a ListResourceBundle instead. The PropertyResourceBundle contents must be encoded as ISO 8859-1. Any characters not in that charset must be stored as escaped Unicode. The ListResourceBundle class manages resources in a name, value array. Each ListResourceBundle is contained within a class file (compiled Java file). You can store any locale-specific object in a ListResourceBundle. To add support for an additional Locale, you subclass the base class, save it to a file with an locale / language extension, translate it, and compile it into a class file. The ResourceBundle class is flexible. If you first put your locale-specific String objects in a PropertyResourceBundle, you can still move them to a ListResourceBundle later. There is no impact on your code, since any call to find your key will look in both the ListResourceBundle as well as the PropertyResourceBundle. Note that the precedence order is class before properties. So if a key exist for the same language in both a Class file (ListResourceBundle) as well as a Properties file, the value in the Class file (ListResourceBundle) will be the value presented to the user.

    23. ResourceBundle Search Algorithm (baseclass)+(specific language)+(specific country)+(specific variant) (baseclass)+(specific language)+(specific country) (baseclass)+(specific language) (baseclass)+(default language)+(default country)+(default variant) (baseclass)+(default language)+(default country) (baseclass)+(default language) In Java we use the ResourceBundle.getBundle method to get the correct ResourceBundle. The search algorithm for determining which subclass to load is as follows: 1.     (baseclass)+(specific language)+(specific country)+(specific variant)  2.     (baseclass)+(specific language)+(specific country) 3.     (baseclass)+(specific language) 5.     (baseclass)+(default language)+(default country)+(default variant) 6.     (baseclass)+(default language)+(default country) 7.     (baseclass)+(default language) The following example selects the TextLabel ResourceBundle for the Locale that matches the French language, and the country of Canada: <fmt:setLocale value=“fr_CA”/> <setBundle basename=“strings”/> setBundle tries to find the closest match to our locale, but if a bundle doesn’t exist for the specified language/locale it must look for a close match among the other available ResourceBundles. So if TextLabel_fr_CA is the desired class and the default Locale is en_US, getBundle will look for classes in the following order: 1. ButtonLabel_fr_CA 2. ButtonLabel_fr 3. ButtonLabel_en_US 4. ButtonLabel_en 5. ButtonLabel getBundle seeks out default Locale classes before it returns the base class TextLabel. But if getBundle fails to find a match, it throws a MissingResourceException error. A base class with no suffixes should always exist in order to avoid throwing this exception In Java we use the ResourceBundle.getBundle method to get the correct ResourceBundle. The search algorithm for determining which subclass to load is as follows: 1.     (baseclass)+(specific language)+(specific country)+(specific variant)  2.     (baseclass)+(specific language)+(specific country) 3.     (baseclass)+(specific language) 5.     (baseclass)+(default language)+(default country)+(default variant) 6.     (baseclass)+(default language)+(default country) 7.     (baseclass)+(default language) The following example selects the TextLabel ResourceBundle for the Locale that matches the French language, and the country of Canada: <fmt:setLocale value=“fr_CA”/> <setBundle basename=“strings”/> setBundle tries to find the closest match to our locale, but if a bundle doesn’t exist for the specified language/locale it must look for a close match among the other available ResourceBundles. So if TextLabel_fr_CA is the desired class and the default Locale is en_US, getBundle will look for classes in the following order: 1. ButtonLabel_fr_CA 2. ButtonLabel_fr 3. ButtonLabel_en_US 4. ButtonLabel_en 5. ButtonLabel getBundle seeks out default Locale classes before it returns the base class TextLabel. But if getBundle fails to find a match, it throws a MissingResourceException error. A base class with no suffixes should always exist in order to avoid throwing this exception

    24. ResourceBundle and Locale Locale objects identify locales combining an ISO 639 lowercase language code (e.g., fr for French), and an ISO 3166 uppercase country code (e.g., CA for Canada), and additionally a non-standardized variant extension identifier string that may define platform or sub-region. Note that HTTP and XML use the same ISO standards for its locale identifiers as used by Java and JSTL / JSP, so no conversion is required. A messages resource bundle might, for example, define the key “greeting-evening” with the default English value “Hello”. Additional language and country-specific bundles are then defined with filenames names consist of the base name with with suffixes indicating the language and country codes and the variant. The localized values are then added to the contents. For example, a French Messages_fr resource bundle have the value “Bonsoir“ for the key greeting-evening. Resource bundles can be implemented as Java classes or as simple "properties" text files. Each ResourceBundle is a set of related subclasses sharing the same base name. The following list that shows a set of related subclasses the comprise a ResourceBundle: TextLabel is the base name. The characters following the base name indicate the language code, country code, and variant of a Locale. TextLabel_en_CA refers to English language, Canada locale. TextLabel_fr_CA refers to French language, Canada locale. TextLabel_en_GB refers to English language, Great Britain locale. Locale objects identify locales combining an ISO 639 lowercase language code (e.g., fr for French), and an ISO 3166 uppercase country code (e.g., CA for Canada), and additionally a non-standardized variant extension identifier string that may define platform or sub-region. Note that HTTP and XML use the same ISO standards for its locale identifiers as used by Java and JSTL / JSP, so no conversion is required. A messages resource bundle might, for example, define the key “greeting-evening” with the default English value “Hello”. Additional language and country-specific bundles are then defined with filenames names consist of the base name with with suffixes indicating the language and country codes and the variant. The localized values are then added to the contents. For example, a French Messages_fr resource bundle have the value “Bonsoir“ for the key greeting-evening. Resource bundles can be implemented as Java classes or as simple "properties" text files. Each ResourceBundle is a set of related subclasses sharing the same base name. The following list that shows a set of related subclasses the comprise a ResourceBundle: TextLabel is the base name. The characters following the base name indicate the language code, country code, and variant of a Locale. TextLabel_en_CA refers to English language, Canada locale. TextLabel_fr_CA refers to French language, Canada locale. TextLabel_en_GB refers to English language, Great Britain locale.

    25. Oracle ADF ResourceBundle Implementation ListResourceBundle Model entity properties such as Column names, Hint Text, custom messages Validation Errors PropertyResourceBundle All text, titles, etc. E.g., button text, headers, titles, error messages Slightly slower performance than ListResourceBundle In Oracle’s Applications Framework provides someIn Oracle’s Applications Framework provides some

    26. Localizing ListResourceBundles Subclass the base java ResourceBundle Append the constructor with language suffix e.g., public MyMsgBundle_es() Translate all strings, modify format masks, etc Recompile, explicitly specifying character encoding if other than ISO8859-1 java.util.ListResourceBundle is a subclass of java.util.ResourceBundle. It implements both handleGetObjects and getKeys for you. This bundle contains localizable elements within a two-dimensional array of <key, value> pairs.  Create a ListResourceBundle by subclassing java.util.ListResourceBundle, which contains a single method getContents() that returns an array of key/value pairs. ListResourceBundle allows you to store any class of object.. Although value objects can be any type, keys must be strings object in both ListResourceBundle and PropertyResourceBundles. ListResourceBundles are classes, so you store them in a .java file. Of course, you must compile them to byte-code before using them. Note that all non-ASCII characters within the ListResourceBundle must be either be UNICODE escaped or the encoding must be explicitly specified when compiling into byte-code. Example: javac -encoding ISO8859_5 MyResource_ru.java java.util.ListResourceBundle is a subclass of java.util.ResourceBundle. It implements both handleGetObjects and getKeys for you. This bundle contains localizable elements within a two-dimensional array of <key, value> pairs.  Create a ListResourceBundle by subclassing java.util.ListResourceBundle, which contains a single method getContents() that returns an array of key/value pairs. ListResourceBundle allows you to store any class of object.. Although value objects can be any type, keys must be strings object in both ListResourceBundle and PropertyResourceBundles. ListResourceBundles are classes, so you store them in a .java file. Of course, you must compile them to byte-code before using them. Note that all non-ASCII characters within the ListResourceBundle must be either be UNICODE escaped or the encoding must be explicitly specified when compiling into byte-code. Example: javac -encoding ISO8859_5 MyResource_ru.java

    27. package model.common; import oracle.jbo.common.JboResourceBundle; // --------------------------------------------------------------- // --- File generated by Oracle Business Components for Java. // --------------------------------------------------------------- public class PmViewRowImplMsgBundle_es extends PmViewRowImplMsgBundle { /** */ public PmViewRowImplMsgBundle_es() { } /** * * @return an array of key-value pairs. */ public Object[][] getContents() { return super.getMergedArray(sMessageStrings, super.getContents()); } static final Object[][] sMessageStrings = { {"PmId_LABEL", "Número de identificación"}, {"Email_LABEL", "Dirección del Correo Electrónico"}, {"Phone_LABEL", "Número De Teléfono"}, {"Jobtitle_LABEL", "Título Del Trabajo"}, {"Pmname_LABEL", "Nombre del P.M."}}; }

    28. Translating PropertiesResourceBundles: Create language / locale specific properties files in the same location as base properties file E.g., create: ApplicationsResources_es.properties in same directory as base file: ApplicationsResources.properties Add keys and translated values Any keys not found in language/locale subclass will inherit values from the base class values

    29. Exercise 4 Creating and Localizing a ListResourceBundle

    30. PropertiesResourceBundles and Character Sets: Properties files may only contain characters in the ISO 8859-1 character set. Important: all non-8859-1 character sets must be converted to escaped UTF-8 characters, or they will appear corrupt in the browser! After translating text files, save to native properties file (text file) Convert to Unicode Escaped characters (i.e., € = \u20ac) by using the “native2ascii” utility in the JDK (ie, native2ascii –encoding UTF8 Errors_ja.properties Errors_ja_88591.properties)

    31. errorpage.title=Página Del Error errorpage.apperror=Error Del Uso error.Validate3=<li>         {0}</li> error.Validate2=<li>      {0}</li> error.Validate1=<li>   {0}</li> error.Validate0=<li>{0}</li> errors.header=<h3><font color\="red">Error De la Validación</font></h3>Usted debe corregir el error(es) siguiente antes de proceder\:<ul> errors.prefix=<li> globalerror.jboException=Error Del Uso errorpage.message=Mensaje De Error\: errors.footer=</ul><hr> errors.suffix=</li> titleGlobal=Acontecimientos De la Gerencia De Producto titleBrowseEvents=Hojee Los Acontecimientos (Página Principal) titleAddPaper=Agregue El Papel titleSelectAnd=Seleccione y globalbuttonBrowsePM=Hojee los PM globalbuttonBrowsePaper=Hojee Los Papeles globalbuttonBrowseEvent=Hojee Los Acontecimientos buttonSubmit=Someta buttonCancel=Cancelación buttonAdd=Agregue buttonDelete=Quite buttonEdit=Corrija

    32. Exercise 5 Creating and Localizing a PropertyResourceBundle

    33. Multi-lingual Web Application Design Considerations Typical Multilingual Implementations: Clone & Translate User Selects Language / Locale at Home Page Language / Locale Set to Browser preferred Language/Locale Settings Repository based locale preference lookup Before localizing your Web Applications, you must first decide upon the architecture that your Application will employ for site navigation. The choice you make will determine how you will go about internationalizing and localizing your application. There a a number of established multilingual architectural models to choose from: Clone and translate the entire application. GUI User Language Locale Selection: using Java ResourceBundle architecture, select and load the language / locale resources based on user selection. Dynamic Language / Locale settings based on Browser Settings: using Java ResourceBundle architecture, select and load the language / locale resources based on browser’s default language / locale settings. Repository based locale preference: the user account information, stored in a database or other repository, contains the user’s preferred language / locale settings. Use Java ResourceBundle architecture to load the selected language / locale resources.Before localizing your Web Applications, you must first decide upon the architecture that your Application will employ for site navigation. The choice you make will determine how you will go about internationalizing and localizing your application. There a a number of established multilingual architectural models to choose from: Clone and translate the entire application. GUI User Language Locale Selection: using Java ResourceBundle architecture, select and load the language / locale resources based on user selection. Dynamic Language / Locale settings based on Browser Settings: using Java ResourceBundle architecture, select and load the language / locale resources based on browser’s default language / locale settings. Repository based locale preference: the user account information, stored in a database or other repository, contains the user’s preferred language / locale settings. Use Java ResourceBundle architecture to load the selected language / locale resources.

    34. Design Option: Clone and Translate In this instance, we create our application for a given language/locale, and then make a copy, storing it in its own language/locale. For our example below, we created the application in English initially, and then cloned the entire folder to another language/locale folder, repeating as necessary. Thus our application consists of 4 different JSP’s, illustrated below. Although “Clone and Translate” is a viable option, it’s not practical if future modifications are required. For example, if you create full clones of your application for just 3 languages, any change made to one will require an identical change to all the others language versions. Keeping the code in sync will require considerable development resources. If more than a couple of languages must be supported, this becomes a totally impractical option.   The advantages this architecture provides are: 1/the code is somewhat easier to debug 2/when content differs substantially from locale to locale Other than for these two requirements, Clone and Translate is not an efficient option, and is not recommended.In this instance, we create our application for a given language/locale, and then make a copy, storing it in its own language/locale. For our example below, we created the application in English initially, and then cloned the entire folder to another language/locale folder, repeating as necessary. Thus our application consists of 4 different JSP’s, illustrated below. Although “Clone and Translate” is a viable option, it’s not practical if future modifications are required. For example, if you create full clones of your application for just 3 languages, any change made to one will require an identical change to all the others language versions. Keeping the code in sync will require considerable development resources. If more than a couple of languages must be supported, this becomes a totally impractical option.   The advantages this architecture provides are: 1/the code is somewhat easier to debug 2/when content differs substantially from locale to locale Other than for these two requirements, Clone and Translate is not an efficient option, and is not recommended.

    35. Design Option: One JSP / Multiple Languages In this option we have just one JSP, and many locale / language specific resources stored in Java ResourceBundles. This works nicely if your application layout and formatting doesn’t differ much across languages, and the real advantage lays in the fact that there’s only one JSP to maintain. The advantages of this design are: The content and logic are the same for all language/locales, so it’s easier to maintain code. Just one change the JSP and the modification is also applied to all language / locales. It’s much easier to add support for additional language locales – just add another set of resources for the language / locale of choice. The main disadvantage is that it’s more difficult to customize content and logic for a specific locale. Choosing the User Locale: When implementing this design architecture, you’ll still need to decide how to set the user’s language / locale. There are three main models to choose from: Manual Language Selection : the initial homepage displays in the base language (say, English) and the user chooses their preferred language / locale. Once the selection is made, the application sets the user’s locale to the one selected, and the specified language’s resources will be loaded and displayed subsequently until the session terminates, or another language / locale is selected by the user. Automatic Language /Locale Determination: In this navigation scenario, there is no initial index JSP for selecting the preferred language / locale from a list. Instead, when a user requests the action page, the HTTP request contains the user's most preferred language/locale as set in their browser per “Accept-Language” header. Further pages are sent to the user in this language. It is possible to combing this with “Manual Language Selection” so that the user can override their browser setting by selecting the language from a list. From that point onward, further pages will be sent to the user in their selected override language/locale. Repository Based Settings: In this navigation scenario, once again there is no initial index JSP for selecting the preferred language / locale from a list. The action page is initially presented in the base language, and once a user successfully logs in, or if a cookie exists, the application looks up their settings from a repository and sets their language / locale preferences accordingly. Subsequent requests for pages will be returned in their preferred language / locale. It is possible to combing this with “Manual Language Selection”, especially if using cookies to set the language. In this option we have just one JSP, and many locale / language specific resources stored in Java ResourceBundles. This works nicely if your application layout and formatting doesn’t differ much across languages, and the real advantage lays in the fact that there’s only one JSP to maintain. The advantages of this design are: The content and logic are the same for all language/locales, so it’s easier to maintain code. Just one change the JSP and the modification is also applied to all language / locales. It’s much easier to add support for additional language locales – just add another set of resources for the language / locale of choice. The main disadvantage is that it’s more difficult to customize content and logic for a specific locale. Choosing the User Locale: When implementing this design architecture, you’ll still need to decide how to set the user’s language / locale. There are three main models to choose from: Manual Language Selection : the initial homepage displays in the base language (say, English) and the user chooses their preferred language / locale. Once the selection is made, the application sets the user’s locale to the one selected, and the specified language’s resources will be loaded and displayed subsequently until the session terminates, or another language / locale is selected by the user. Automatic Language /Locale Determination: In this navigation scenario, there is no initial index JSP for selecting the preferred language / locale from a list. Instead, when a user requests the action page, the HTTP request contains the user's most preferred language/locale as set in their browser per “Accept-Language” header. Further pages are sent to the user in this language. It is possible to combing this with “Manual Language Selection” so that the user can override their browser setting by selecting the language from a list. From that point onward, further pages will be sent to the user in their selected override language/locale. Repository Based Settings: In this navigation scenario, once again there is no initial index JSP for selecting the preferred language / locale from a list. The action page is initially presented in the base language, and once a user successfully logs in, or if a cookie exists, the application looks up their settings from a repository and sets their language / locale preferences accordingly. Subsequent requests for pages will be returned in their preferred language / locale. It is possible to combing this with “Manual Language Selection”, especially if using cookies to set the language.

    36. Design Option: One JSP per language, w/ResouceBundles This is the recommended way of localizing a JSP when you need to adjust the layout of the content to the specific locale. We have one JSP per language with matching locale / language specific resources stored in Java ResourceBundles. This does not mean it’s OK to put lots of hard coded text in the JSP’s – the objective of this design is to modify the layout and styles, etc., to suit each individual language as needed. The advantages of this design are: Flow and logic is same for all language/locales, so it’s easier to maintain code. It’s much easier to add support for additional language locales – just add another JSP and a set of resources for the language / locale of choice. The main disadvantage is that it is quite challenging to synchronize code modifications across customized language JSP’s. Choosing the User Locale: If implementing this design architecture, you’ll need a method for loading the specific language / locale page One useful trick to implementing this design is to store the page name in each language properties file, and use the <fmt:message> tag to automatically generate a link to a separate page for each locale. For example, our ApplicationsResources_es.properties file contains: index_page=index_es.jsp Index_link_text=en Español So we can dynamically generate a link to the page with the following code: <a href=“<fmt:message key=“index_page” /> <fmt:message key=“index_link_text”/> </a>This is the recommended way of localizing a JSP when you need to adjust the layout of the content to the specific locale. We have one JSP per language with matching locale / language specific resources stored in Java ResourceBundles. This does not mean it’s OK to put lots of hard coded text in the JSP’s – the objective of this design is to modify the layout and styles, etc., to suit each individual language as needed. The advantages of this design are: Flow and logic is same for all language/locales, so it’s easier to maintain code. It’s much easier to add support for additional language locales – just add another JSP and a set of resources for the language / locale of choice. The main disadvantage is that it is quite challenging to synchronize code modifications across customized language JSP’s. Choosing the User Locale: If implementing this design architecture, you’ll need a method for loading the specific language / locale page One useful trick to implementing this design is to store the page name in each language properties file, and use the <fmt:message> tag to automatically generate a link to a separate page for each locale. For example, our ApplicationsResources_es.properties file contains: index_page=index_es.jsp Index_link_text=en Español So we can dynamically generate a link to the page with the following code: <a href=“<fmt:message key=“index_page” /> <fmt:message key=“index_link_text”/> </a>

    37. Exercise 6 Create Page with User Selected Language

    38. JSTL – JavaServer Pages Standard Tag Library Collection of standard JSP actions Latest version 1.1 Main libaries: XML processing support: “xml” library SQL DBMS access: “sql” library Variable manipulation, flow control, URL actions: “core” library I18n and formatting: “fmt” library The JavaServer Pages Standard Tag Library (JSTL) contains a collection of custom actions covering several areas of functionality commonly used in JSP pages. The library provides a standard interface that applications independent of the servers they run on. The JavaServer Pages Standard Tag Library (JSTL) contains a collection of custom actions covering several areas of functionality commonly used in JSP pages. The library provides a standard interface that applications independent of the servers they run on.

    39. JSTL – i18n Tags I18n and L10n support Prefix = fmt Support for: Setting locale context Fetching locale context sensitive content Handling locale specific numeric and date formatting Many functions reused by other tag libraries: Struts <bean:message> tag Jakarta i18n Tags At top of JSP, specify the tag library directive : <%@ taglib uri="http://java.sun.com/jstl/fmt" prefix="fmt"%>

    40. JSTL Locale <fmt:setLocale value=“en_IE" scope="session" /> Scope default is “page” Optional variant attribute <fmt:requestEncoding value=“UTF-8”/> value attribute is optional

    41. JSTL Resource Set the base bundle: <fmt:setBundle basename=“strings” scope=“session”/> Replace the hard coded strings in the JSP with the <fmt:message> <fmt:message key="buttonsubmit"/> Pass parameters: <fmt:message key=“Totals"> <fmt:param value=“${subtotal_1}”/> <fmt:param value=“${subtotal_2}”/> </fmt:message>

    42. JSTL Format Format date for output: <fmt:formatDate value=“${now}” type=“date” datestyle=“short”/> Parse submitted date <fmt:parseDate value=“${param.birthday}” type=“date” pattern=“yyy-MM-dd”/> Format Numbers <fmt:formatNumber value=“200.00” type=“currency” currencySymbol=“£”/> Parse Numbers <fmt:parseNumber value=“${param.carPrice”} type=“currency” parseLocale=“en_IE”/>

    43. Struts <bean> tag The same as JSTL <fmt:message> tag Configure ResourceBundle location in Struts-Config.xml file <message-resources parameter="view.ApplicationResources"/> At top of JSP, add this directive: <%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean“%> Then replace hard coded strings with <bean:message key="empmaintitle"/>

    44. Jakarta i18n tag Library i18n tags similar to Struts “message” tag, but more robust Use in JSP’s - Struts not required Includes many JSTL i18n tags I18n Management Tags: Ifdef, Ifndef, Locale, Message, Bundle, MessageArg Formatting Tags: FormatDateTime, FormatDate, FomatTime, FormatCurrency, FormatPercent, FormatNumber, FormatString The Jakarta Project I18N tag library The I18N custom tag library from Apache (http://jakarta.apache.org/taglibs/doc/i18n-doc/intro.html) and provide much the same support as is available in Struts. These tags are tightly coupled with the previously mentioned Java classes, and they support the creating and management of multi-lingual Web applications. Although similar to the Struts “message” tag, since they are within a standalone tag library, they do not require using the Struts components and can be used in any JSP. These tags consist of: Ifdef: Specified if JSP is evaluated or not on a per-locale basis Ifndef: Specified if JSP is evaluated or not on a per-locale basis Locale: Defines a locale context Message: Returns internationalized text from a resource bundle Bundle: Defines a resource bundle MessageArg: Specifies arguments to be used by the message tag's MessageFormat And the following format tags provide support for locale specific numeric and date formatting: FormatDateTime: Format date/time FormatDate: Format date FomatTime: Format time FormatCurrency: Format currency FormatPercent: Format percentage FormatNumber: Format number FormatString: Format stringThe Jakarta Project I18N tag libraryThe I18N custom tag library from Apache (http://jakarta.apache.org/taglibs/doc/i18n-doc/intro.html) and provide much the same support as is available in Struts. These tags are tightly coupled with the previously mentioned Java classes, and they support the creating and management of multi-lingual Web applications. Although similar to the Struts “message” tag, since they are within a standalone tag library, they do not require using the Struts components and can be used in any JSP. These tags consist of: Ifdef: Specified if JSP is evaluated or not on a per-locale basis Ifndef: Specified if JSP is evaluated or not on a per-locale basis Locale: Defines a locale context Message: Returns internationalized text from a resource bundle Bundle: Defines a resource bundle MessageArg: Specifies arguments to be used by the message tag's MessageFormat And the following format tags provide support for locale specific numeric and date formatting: FormatDateTime: Format date/time FormatDate: Format date FomatTime: Format time FormatCurrency: Format currency FormatPercent: Format percentage FormatNumber: Format number FormatString: Format string

    45. Specifying location of resources in Struts / JSP Define message file locations in struts-config.xml A <message-resources> element with no key attribute defines the default message resource. Secondary message resources identify their key by specifying a value for the key attribute.

    46. PropertyResourceBundles in Struts/JSP PropertiesResourceBundles may be referenced in the JSP page by using <bean:message> tag:

    47. PropertyResourceBundles and JSTL / Struts / JSP Declare the custom JSTL library in the JSP header <fmt:bundle> defines resource location within <body>. Optional “prefix” attribute simplifies key name

    48. Exercise 7 Internationalize and Localize JSP using tags

    49. Oracle ADF-UIX Components Pre-translated content - Over 30 languages supported Loads resources based on browser setting Limit language support by configuring uix-config.xml <supported-locales> <default-locale>en-US</default-locale> <supported-locale>es</supported-locale> </supported-locales> Simplifies development, i18n, l10n Extends Java Server Faces Seamless upgrade to full JSF

    50. PropertyResourceBundles in Struts / ADF UIX Define provider in each UIX file

    51. Exercise 8 Internationalize and Localise a UIX Page

    52. JDeveloper 10g IDE L10N Features Real-time access to resource bundles

    53. JDeveloper 10g IDE L10N Features Generates List Resource Bundle from Entity Editor

    54. Large Project Considerations Include i18n and l10n in design phase Commence i18n and l10n work early Create a separate properties files for each module / subsystem Never check in code with static text Implement Pseudo Translation test cycle early in the development project cycle, and repeat often. Reuse previous translations using commercial Translation / Localisation tools

    55. L10n Productivity Tools One 3rd party localization tool is Alchemy Software’s Catalyst 5.0, which provides many productivity features such as : customized parsing filters. Other highly effective tools include: Multilizer, PASSOLO, SDLX, TRADOS and WizTom. One 3rd party localization tool is Alchemy Software’s Catalyst 5.0, which provides many productivity features such as : customized parsing filters. Other highly effective tools include: Multilizer, PASSOLO, SDLX, TRADOS and WizTom.

    56. Localization Tool Features - Pseudo Translation Most L10n tools support the validation of the internationalization of your application by Pseudo Translating it. Pseudo Translation enables your development team to run a test cycle early in the development project cycle, before a single word is translated.

    57. Localization Tool Features - Resource Format Support Ensure the tool you choose correctly interprets resource bundles. Most tools provide customizable input and output filters which can easily support both PropertiesResourceBundles and ListResourceBundles Consider transforming resources to / from XLIFF, the XML Localization Interchange File Format emerging standard (www.xliff.org)

    58. Localization Tool Features- Translation Memory 3rd party localization tools will often provide tools for reusing previous translations when your project changes. Frequently retranslating your strings when versions change is a needless expense. Translation Memory provides reuse of existing translations.

    59. Localization Tool Features - Automation Automation and scripting are important when you need to maintain consistency of your process across many different languages, or when you have many individual files being sent out to translators as well as translations coming back in that must be integrated into your application.

    61. Resources for further study Oracle Tech Net Whitepaper: http://otn.oracle.com/products/jdev/collateral/papers/10g/jdev10g_multilingual.pdf “The Multilingual World Wide Web“, Gavin Nicol, http://www.oasis-open.org/cover/nicol-multwww.html W3C: http://www.w3c.org/international “Best Practices in Internationalizing Web-Based EnterpriseApplications”, Greg Murray: http://java.sun.com/javaone/javaone2001/pdfs/2335.pdf “J2EE Internationalization and Localization”, Greg Murray: http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/i18n/i18n5.html

    62. Oracle Resources Oracle Technology Network: http://otn.oracle.com Download Jdeveloper 10g http://otn.oracle.com/software/products/jdev/index.html JDeveloper 10g White papers, samples, product information: http://otn.oracle.com/products/jdev/index.html

More Related