wood burning stoves 2.0*
The moose likes Struts and the fly likes Struts: The Complete Reference - Internationalizaion ??? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Frameworks » Struts
Bookmark "Struts: The Complete Reference - Internationalizaion ???" Watch "Struts: The Complete Reference - Internationalizaion ???" New topic
Author

Struts: The Complete Reference - Internationalizaion ???

Nimchi Yung
Ranch Hand

Joined: Jan 27, 2004
Posts: 71
James,

WHat material does your book cover on internationalization?
I am interested in CJK locales. Does you book offer any
examples on these locales? How does real life application
handles IME?

THanks,
Nimchi
Ko Ko Naing
Ranch Hand

Joined: Jun 08, 2002
Posts: 3178
As far as I see in the TOC of the book, chapter-10 might have the internationalization issue that you have in your post... But for more details about the chapter, Mr.James must be the one who can tell you about it....


Co-author of SCMAD Exam Guide, Author of JMADPlus
SCJP1.2, CCNA, SCWCD1.4, SCBCD1.3, SCMAD1.0, SCJA1.0, SCJP6.0
somkiat puisungnoen
Ranch Hand

Joined: Jul 04, 2003
Posts: 1312

Internationalized Messages
A few years ago, application developers could count on having to support only residents of their own country, who are used to only one (or sometimes two) languages, and one way to represent numeric quantities like dates, numbers, and monetary values. However, the explosion of application development based on web technologies, as well as the deployment of such applications on the Internet and other broadly accessible networks, have rendered national boundaries invisible in many cases. This has translated (if you will pardon the pun) into a need for applications to support internationalization (often called "i18n" because 18 is the number of letters in between the "i" and the "n") and localization.

Struts builds upon the standard classes available on the Java platform to build internationalized and localized applications. The key concepts to become familiar with are:

Locale - The fundamental Java class that supports internationalization is Locale. Each Locale represents a particular choice of country and language (plus an optional language variant), and also a set of formatting assumptions for things like numbers and dates.
ResourceBundle - The java.util.ResourceBundle class provides the fundamental tools for supporting messages in multiple languages. See the Javadocs for the ResourceBundle class, and the information on Internationalization in the documentation bundle for your JDK release, for more information.
PropertyResourceBundle - One of the standard implementations of ResourceBundle allows you to define resources using the same "name=value" syntax used to initialize properties files. This is very convenient for preparing resource bundles with messages that are used in a web application, because these messages are generally text oriented.
MessageFormat - The java.text.MessageFormat class allows you to replace portions of a message string (in this case, one retrieved from a resource bundle) with arguments specified at run time. This is useful in cases where you are creating a sentence, but the words would appear in a different order in different languages. The placeholder string {0} in the message is replaced by the first runtime argument, {1} is replaced by the second argument, and so on.
MessageResources - The Struts class org.apache.struts.util.MessageResources lets you treat a set of resource bundles like a database, and allows you to request a particular message string for a particular Locale (normally one associated with the current user) instead of for the default Locale the server itself is running in.
Please note that the i18n support in a framework like Struts is limited to the presentation of internationalized text and images to the user. Support for Locale specific input methods (used with languages such as Japanese, Chinese, and Korean) is left up to the client device, whichis usually a web browser.

For an internationalized application, follow the steps described in the Internationalization document in the JDK documentation bundle for your platform to create a properties file containing the messages for each language. An example will illustrate this further:

Assume that your source code is created in package com.mycompany.mypackage, so it is stored in a directory (relative to your source directory) named com/mycompany/mypackage. To create a resource bundle called com.mycompany.mypackage.MyApplication, you would create the following files in the com/mycompany/mypackage directory:

MyApplication.properties - Contains the messages in the default language for your server. If your default language is English, you might have an entry like this: prompt.hello=Hello
MyApplication_xx.properties - Contains the same messages in the language whose ISO language code is "xx" (See the ResourceBundle Javadoc page for a link to the current list). For a French version of the message shown above, you would have this entry: prompt.hello=Bonjour You can have resource bundle files for as many languages as you need.
When you configure the controller servlet in the web application deployment descriptor, one of the things you will need to define in an initialization parameter is the base name of the resource bundle for the application. In the case described above, it would be com.mycompany.mypackage.MyApplication.


<servlet>
<servlet-name>action</servlet-name>
<servlet-class>
org.apache.struts.action.ActionServlet
</servlet-class>
<init-param>
<param-name>application</param-name>
<param-value>
com.mycompany.mypackage.MyResources
</param-value>
</init-param>
<!-- ... -->
</servlet>

The important thing is for the resource bundle to be found on the class path for your application. Another approach is to store the MyResources.properties file in your application's classes folder. You can then simply specify "myResources" as the application value. Just be careful it is not deleted if your build script deletes classes as part of a "clean" target.

If it does, here is an Ant task to run when compiling your application that copies the contents of a src/conf directory to the classes directory:


<!-- Copy any configuration files -->
<copy todir="classes">
<fileset dir="src/conf"/>
</copy>



Refernce Website
http://jakarta.apache.org/struts/userGuide/building_view.html#i18n


SCJA,SCJP,SCWCD,SCBCD,SCEA I
Java Developer, Thailand
somkiat puisungnoen
Ranch Hand

Joined: Jul 04, 2003
Posts: 1312
i18n with Struts


After many attempts to get internationalization working with Struts, I have decided to provide this brief tutorial in hopes of saving other's the anguish that I endured during this process. OK, it wasn't that bad, but it could have been documented better.

For this initial documentation, I am not going to go into the hows or the whys of the internationalization process. I may expand it in the future if people really want to know more or, if I get bored at work again. In any case, feel free to contact me (e-mail at bottom of this page) with questions and concerns.


1. First and foremost, read and understand this basic explanation of i18n'd messages as it relates to Struts, then follow the specifics listed below.

2. Create an alternate ApplicationResource.properties file and save it in the same directory as the original. For example, my original looks like this (MyResources.properties) and here is my Cyrillic Version (MyResources_ru.properties). It is important to Struts (actually, Java) to get the correct ISO language code, "ru", but you already read that right? =-)


3. Convert your alternate ApplicationResources.properties to UTF. To do this, use the tool named native2ascii, it is distributed with your JDK. It converts a file with native-encoded characters (characters which are non-Latin 1 and non-Unicode) to one with Unicode-encoded characters.

I used this command:

native2ascii -encoding UTF-8 MyResources_ru.properties MyResources_ru.propertiesX.

Have a look at the output file, you will see that all your internationalized words have been converted to Unicode(UTF-8) standards, now your browser can read it!


4. At the top of each JSP page that is going to be making use of the internationalized messages, include this page directive:

<%@ page contentType="text/html; charset=UTF-8" %>

This tells the browser that the page being rendered is going to be UTF-8 encoded, and should display any Unicode characters appropriately.


5. Test it out using a browser that let's you select default languages:
IE "Tools" -> "Internet Options", and select the "Language..." button at the bottom of the dialog. Change to the language you are hoping to see. Refresh the screen, you language should show up (you may have to start a new brower session).
NS 6.3 go to "Edit" -> "Preferences", expand "Navigator" in the tree and select "Languages". Add languages using the "Add..." button and move the desired language to the top
of the list'. Once again, refresh or start a new browser.

This is it for displaying messages in JSPs. However, there is a problem that arises when you try to submit internationalized characters in forms. The steps outlined below provide a simple solution to the problem.

7. Add this filter to you web application, it is part of the Tomcat documentation distributed by our friends at the Jakarta Project and Apache. Basically this filter will tell your ActionServlet that all request coming to it are from UTF-8 encoded forms, and that the attributes submitted should be manipulated that way.
NOTE: WebSphere AS 4 doens't follow this step, click here for details.

8. Add this code to your web.xml deployment descriptor, it assumes that your ActionServlet is referenced by the name action (default for struts distro).

<!-- Example filter to set character encoding on each request -->
<filter>
<filter-name>Set Character Encoding</filter-name>
<filter-class>filters.SetCharacterEncodingFilter</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>UTF-8</param-value>
</init-param>
</filter>

<!-- Define filter mappings for the defined filters -->
<filter-mapping>
<filter-name>Set Character Encoding</filter-name>
<servlet-name>action</servlet-name>
</filter-mapping>



9. Restart your app server and test it out....should work fine.



Dynamic Language Selection
Allowing the user to dynamically change the language the web application uses is straight forward. What you need to do is create a new java.util.Locale object and place it in the session. You would probably do this in an Action class. Here is some sample code:

java.util.Locale newLocale = new java.util.Locale( "ru" );

request.getSession().setAttribute( Action.LOCALE_KEY, newLocale );


Note: In the Action Class, there is a method, setLocale( HttpServletRequest, Locale ) that eliminates the need to manually set it in the session.


Reference Website
http://www.anassina.com/struts/i18n/i18n.html
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Struts: The Complete Reference - Internationalizaion ???
 
Similar Threads
To authors
Objectives of i18n
Need a hint on internationalization
Internatonalization in Liferay
NumberFormat does not show right currency symbol