Take a look at the source for MessageResources. The bundles are cached in
static hashtables. You could even load you application on startup and
pre-cache for each of your supported locales.
Cheers
Mark
-----Original Message-----
From: Andrew Cockburn [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 01, 2000 2:11 PM
To: [EMAIL PROTECTED]
Subject: Re: Question about localization
I am just starting to think about this too -
A question :
Although it is convenient and neat to place internationalised messages in
resource bundles and load them on the fly, would this not add a big
performance hit to a large/heavily loaded system ?
In previous designs I have concluded that this may be a problem and proposed
designs based on a preprocessor to create multiple JSP files, one per source
file per language. The preprocessor would use resource bundles, but the file
reading and extraction would be done statically, not on the fly. Then the
running system just has to worry about serving pre-compiled JSPs, and not
doing expensive file operations. This is a lot more cumbersome, but if
performance is important to you I think it is worth considering.
Regards,
Andrew
----- Original Message -----
From: "Pierre Métras" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, December 01, 2000 3:37 PM
Subject: Re: Question about localization
> Hi Doug and others,
>
> > The server we're creating needs to be usable simultaneously by multiple
> > users in multiple languages. Our app uses Struts/JSP and the Model 2
> > architecture. What is the "best practice" or the "correct" Java/Struts
way
> > of accomplishing this?
> >
> > Is there a way to use the same JSP pages, or is it best to have multiple
> > contexts (/en/, /fr/, etc)?
> >
>
>
> Here is a brief presentation of what you can do with Struts to localize
your
> application.
>
> With version 1.0, you can set the ActionServlet to do locale negociation.
> Just put in you web.xml file:
> <init-param>
> <param-name>
> locale
> </param-name>
> <param-value>
> true
> </param-value>
> </init-param>
>
> From now, when a user connects to your application and he has defined a
> locale preference in his browser, Struts will set a locale in his user
> session. This locale is then used to select the appropriate message
resource
> file when your application displays a message through the <bean:message />
> tag.
> Different users can simultaneously use different languages, but generally
> (with Struts framework), a user only uses one language at a time.
>
> If you want to give to your user the ability to change the locale used,
you
> need to write a bit of code that changes the Locale in the user session.
And
> now, all the pages will use that new locale when displayed.
>
> If you have to display pages that keep the same structure from one
language
> to the other, then the simpler way to localize your application is to use
> the <bean:message /> tag.
> Store all your strings in the appropriate resource file. Don't put
> formatting in your code, but in the message strings, and use parameters.
For
> instance, taken from MessageFormat javadoc:
> "At {1,time} on {1,date}, there was {2} on planet
{0,number,integer}."
>
> Have a look at the java.text.MessageFormat and java.util.ResourceBundle
> documentation for more info. In particular, don't forget to double the
> quotes ' in the messages (like ''. This one turned me crazy...).
>
>
> When you want to include HTML formatting in your message other than line
> breaks, it's the time to think to create different pages for the different
> languages. I haven't investigated it yet, but I think that a lighter
> solution that language contexts can be found with conditional include,
using
> the new Struts template tags.
> Depending on the locale, you <template:insert /> the corresponding
localized
> page. This would allow a global framework for your application, but with
> various looks depending on the language selected by the user.
>
>
> Pierre Métras
>
>
>
*****************************************************************************
The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorized.
If you are not the intended recipient, any disclosure, copying, distribution
or any action taken or omitted to be taken in reliance on it, is prohibited
and may be unlawful. When addressed to our clients any opinions or advice
contained in this email are subject to the terms and conditions expressed in
the governing KPMG client engagement letter.
*****************************************************************************
