Hai-Bang Pham wrote:
> >I created a JavaBean called "BundleBean" that had a series of methods
> >with calling sequences like this:
> >
> > String message = bundleBean.getMessage(locale, "label.username");
> >
> >and it looked in the correct resource bundle for the language of this
> >locale. The bundle bean is stored in the application context in a
> >startup servlet, by calling:
> >
> > getServletContext().setAttribute("bundleBean", bundleBean);
>
> Why not use the session? Which engine are you using? The reason I ask
> is because I don't think WebSphere 2.02 supports the setAttribute()
> method through the servlet context (correct me if I'm wrong!).
>
I used ServletContext.setAttribute because this object is a singleton that I
wanted to share across all servlets and JSP pages in the application. This
call was added in the 2.1 version of the Servlet API.
>
> >
> >to make it available to both servlets and JSP pages.
> >
> >(3) Internationalize the business logic
> >
> >We had to deal with things like the fact that many European cities have
> >different names in different languages, so our business object for a
> >city has two different property getters for the name:
> >
> > String getName() returns the name in the language of the default
> >Locale
> > String getName(Locale locale) returns the name in the language of
> >the
> > specified Locale, if it is different, or in the "canonical"
> >language.
> >
> >(4) Store a Locale object for the user's preferrred language in the
> >user's session
> >
> >When a user logs on, one of the things we know is their preferred
>
> How about before they login? How do you handle the default situation?
> I take it then that your first page (portal into the system) isn't
> internationalized?
>
There's actually two sub-cases. Before anyone has ever logged in (so there is
no session at all), I choose the system default locale. On the login page
itself, there is a mechanism to switch languages that works even before you've
logged in (it runs a little servlet that stores the new Locale, and forwards
to the login JSP page again -- which will now use the new Locale to look up
all the message strings.
If someone uses the app and logs out, I invalidate the old session and create
a new one, but I save the last Locale that was in use, and that is the default
for the new Login screen.
>
> >language (they can switch later, if they want). To record that
> >knowledge, we store a java.util.Locale instance based on that language
> >in the session object, under key "localeBean". If the user exercizes
> >the option to change languages, we just update the locale and the next
> >page display is auto-magically done in the newly chosen language.
> >
> >(5) Separate business logic and presentation logic
> >
> >I'm a big beliver in this separation, and it paid off in this
> >application. All my form submits go to a processing servlet (in the
> >real app, it's actually an action procedure called by a single servlet)
> >that does the appropriate business logic, which is mostly independent
> of
> >language choice, then stores appropriate beans in the session or
> >request, and forwards to an appropriate JSP page to display the next
> >result, using RequestDispatcher.forward().
> >
> >(6) A simplified internationalized login page using the above features,
> >then, looks something like this:
> >
> > <%@ page language="java" buffer="8kb" session="true" %>
> >
> > <jsp:useBean id="attemptBean" scope="request"
> > class="com.mycompany.AttemptBean" />
> > <%-- Contains username and password from previous attempt, if any
> >--%>
> >
> > <jsp:useBean id="bundleBean" scope="application"
> > imports="java.util.Locale"
> > class="com.mycompany.BundleBean" />
> >
> > <%
> > Locale localeBean = (Locale) session.getValue("localeBean");
> > if (localeBean == null) {
> > localeBean = Locale.getDefault();
>
> You might want to consider grabbing the Accept-Language header and
> use these values as the default(s) instead. Then you can use the
> user's settings. This way you get the client's defaults instead of
> the server's. BTW, following (5) of separating business logic from
> presentation logic shouldn't this chunk of code sit inside a servlet?
>
"Accept-Language" is something I only recently got reminded about ... I'm
going to do some investigation along that line.
Regarding code separation, you're absolutely right ... sometimes even the most
adamant of us have to compromise our principles :-). In this case, because
all my message lookups depend on a non-null value for localeBean, so I
"justified" this by calling it "presentation-related logic" instead of
"business logic". Kind of a cop-out, but it's not a perfect world ...
>
> > session.putValue("localeBean", localeBean);
> > }
> > %>
> >
> [snip][
>
> We also tried to have a single JSP handle i18n but the major problem we
> found was the translation messed up our interface. As an example,
> "Cancel" in german might be "Abbrechen" and "Password" in french might
> be "Mot de pass". The length of these translated words alone suggested
> that having a single template isn't going to cut it. Imaging the above
> template on languages such as Arabic or Japanese.
>
HTML helps some in dealing with the length issues, because you can let it
dynamically format buttons and column widths, and so on. But coming up with
reasonable translations is actually a lot harder that getting the software to
work!
>
> Cheers,
> -Hai
>
Craig
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
For JSP FAQ, http://www.esperanto.org.nz/jsp/jspfaq.html
