David Mossakowski wrote:
> I wasn't sure if I should post this question to JSP list but
> anyways, here goes.
>
> I'm trying to implement internationalization and am thinking
> of doing this the following way. I would appreciate
> comments as what can be improved and/or how other people do
> this.
>
I had internationalization requirements in a recent servlet/JSP project, so I
can describe the choices I made below.
>
> When checking for existing session or creating a new one get
> appropriate bundle. Locale would be determined for each
> user either from user session, preferences in database or a
> cookie. Then put that bundle into session object for JSP to
> use. When user decides to change his/her preffered language
> replace that value from session with a new one.
>
> Issues:
> 1. Is it too expensive to load a bundle on creation of new
> session and have them in each session? It seems so.
If the bundle is shared among users, this seems quite wasteful. You'd be
better off sharing them in that case, as described below.
>
> 2. Should all the bundles be loaded into ServletContext
> instead? How would it work? Wouldn't you have to recompile
> the servlet when adding support for new language?
There's two aspects to this -- how do I deal with adding new languages, and how
do I deal with sharing.
For the first problem, I created a wrapper class called BundleManager that had
method signatures like this:
public String getMessage(Locale locale, String key);
to look up the message string for the particular key, in the context of the
specified locale. The first time you request a message for a particular
locale, the underlying ResourceBundle is loaded and then kept in a Hashtable.
After that, the resource bundle is already there, and you can just call the
underlying getString(key) method of the appropriate bundle.
Adding a new language is as simple as adding a new properties file (I use
PropertyResourceBundles) in the right place in your package hierarchy -- no
recompilation is required. Bundles are only loaded as they are used.
To share this stuff, store the BundleManager instance itself as a servlet
context attribute. I do this in the init() method of a servlet that is defined
to be loaded at startup time, like this:
BundleManager manager = new BundleManager(...);
getServletContext().setAttribute("bundles", manager);
and I can reference this in a JSP page like this:
<jsp:useBean id="bundles" class="com.mycompany.BundleManager"
scope="application" />
> 3. Should servlets not even care for this and let JSPs load
> bundles based on Locale of the given session?
As described above, I initialize the BundleManager at application startup time,
so that all servlets and JSP pages can use it.
How would I use it from a JSP page? The first thing to note is that I also
store a java.util.Locale object representing the user's current language choice
into his or her session, tagged with the id "locale". Now, I can generate a
Username: prompt, say for a login screen, like this:
<%= bundles.getMessage(locale, "prompt.username") %>
The JSP page doesn't care whether the bundle for this particular language has
ever been loaded before -- that responsibility is delegated to the
BundleManager.
>
> 4. ResourceBundle tries to load a class with the Locale
> name but if it's not there it tries to find a .properties
> file. What are the advantages/disadvantages of these two?
The class approach (ListResourceBundle) lets you define resources that are not
strings. It requires recompilation when you make a change. You can also write
your own custom extension of the ResourceBundle abstract class if you want,
perhaps because you want to create some resources dynamically, or look them up
in a database because there are too many to keep in memory.
The property file approach (PropertyResourceBundle) lets you modify properties
without recompiling, but they can only be strings. When you execute your app,
it occupies memory for all the message strings.
>
> 5. How do HTML designers work in this environment? Do they
> work with JSP and wait for the pages to recompile each time
> to see how it looks for different languages? Do they first
> create a mock up in English and then have programmer create
> the JSP and hope it looks OK in German?
>
In my case, the HTML designers were comfortable with programming syntax, so we
build JSP pages directly (with syntax like that above for the prompts), and
waited for them to recompile as necessary (it doesn't really take very long on
a fast development machine). For non-programmer designers, I would have had
them design in one language, and then gone in and replaced their literal
strings with resource bundle lookups.
The issue of "will it look the same in German" is actually quite important,
because many German words and phrases are *much* longer than their English
counterparts. In my case, most of the time the dynamic layout facilities of
HTML tables took care of things pretty well. In a few cases, though, we had to
resort to a separate page per language, coded directly in that language instead
of using resources. We tried to avoid this, because a change to the look and
feel for one language would need to be replicated manually to all the rest
(eight languages and counting).
>
> I would appreciate comments on this. I apologize for slight
> off-topickness(?).
>
I don't think it's off-topic at all -- internationalization is something far
too many developers ignore, or ignore until the very end of the project.
>
> dave.
>
Craig McClanahan
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
