Re: Question about localization
What about issues in regards to character encodings?
Some resources I have seen on the web, namely:
http://forums.itworld.com/webx?14@@.ee6bdcf/223!skip=185
claim that using UTF-8 encodings is still not the way to go when presenting
pages. Assuming this is the case, if we want, an English page, we need
something like:
<%@ page contentType="text/html; charset=ISO-8859-5" %>
at the top of our JSP page, and the following for say Chinese:
<%@ page contentType="text/html; charset=Big5" %>
Do people have any experience with handling these issues, where a single JSP
page is used for serving multiple locales which each may require different
output encodings using struts+message tags? I can imagine a couple of
solutions, but haven't had any real practical experience yet.
Cheers,
David
On Sat, 02 Dec 2000, Pierre Métras wrote:
> 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:
>
>
> locale
>
>
> true
>
>
>
> >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
> 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 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 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
Re: Question about localization
Andrew Cockburn wrote: > 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 ? > There is definitely some effect on performance, but it's been negligible in the apps I have played with -- especially given the low cost of throwing more hardware at a high volume web site. The messages are cached in memory after being accessed the first time, and are looked up via Hashtable.get() type calls, so it's pretty efficient. > > 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. My very first internationalized app started on the path of having separate pages per language, and the controller framework I built (essentially a predecessor to Struts) took care of things like appending a correct language suffix to the requested page name when forwarding to a JSP. However, when we went from four languages, to five, and then on up to eight, it became incredibly tedious and error prone to make changes in the UI across all the copies. Creating a preprocessor tool to do some of this for you would ease some of the burden, but puts you in the tools-maintenance business along with the application development business. Make sure you have sufficient developer time if you go this way. (And you will most likely still have some on-the-fly lookups of dynamic internationalized messages for things like error messages). > > Regards, > > Andrew > Craig
Re: Question about localization
Hi Piere, > If you have or are developping such a preprocessor, I'm sure the Struts > authors will be eager to include it in a future release... Not yet - I am still trying to convince myself it is worth doing it that way. I have a design, mostly in my head, but you have almost convinved me it is not necessary - I guess you can always throw more hardware at these problems, and as you say, most of it would be cached in practice. If people thought it was worthwhile I would be happy to put something together, but it is probably overkill for my current project. Regards, Andrew
Re: Question about localization
Hi,
The present approach allows also to process parameters in the message
string, which would not be possible with the preprocessor one.
For instance, you place the Zip code after the city in the US, but before in
France (and there's no need for a state). With the localized resource, you
are able to write in your message bundles:
# {0} is the city
# {1} is the Zip code
# {2} is the state
MyAppMessages_en_US.property file
myapp.address.city={0}, {2}, {1}
MyAppMessages_fr_FR.property file
myapp.address.city={1} {0}
And have the correct formatting, depending on the locale (not so good
example, but I haven't a better in mind where parameters are reversed) of
the user.
Pierre Métras
Re: Question about localization
Doesn't the current approach allow values to be "injected" into the messages at runtime? If so, the preprocessor wouldn't work in that case, would it? (If it doesn't currently allow that, well, my point is rather moot.) > 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. If you have or are developping such a preprocessor, I'm sure the Struts authors will be eager to include it in a future release... In the mean time, we're stuck with the dynamic approach. The burden added to the server is not that big, depending on the size of your application and the number of different languages you need to support. All messages are kept in a cache, so the penalty is paid by the first user asking for a language not already loaded. As always, this is a trade between cost (ease of coding) and performance. Depending on your wealth (and time), you'll write such a preprocessor or buy a CPU upgrade... Another solution is to form teams of local web programmers and have them code the application in their native language. Manual preprocessing ;-) Pierre Métras
RE: Question about localization
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:
>
>
> locale
>
>
> true
>
>
>
> 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
> 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 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 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.
*
Re: Question about localization
Hi Andrew, > 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. If you have or are developping such a preprocessor, I'm sure the Struts authors will be eager to include it in a future release... In the mean time, we're stuck with the dynamic approach. The burden added to the server is not that big, depending on the size of your application and the number of different languages you need to support. All messages are kept in a cache, so the penalty is paid by the first user asking for a language not already loaded. As always, this is a trade between cost (ease of coding) and performance. Depending on your wealth (and time), you'll write such a preprocessor or buy a CPU upgrade... Another solution is to form teams of local web programmers and have them code the application in their native language. Manual preprocessing ;-) Pierre Métras
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:
>
>
> locale
>
>
> true
>
>
>
> 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
> 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 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 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
>
>
>
Re: Question about localization (2)
Hi again, I just forgot to speak about "native2ascii". Sometimes it helps, for "exotic" languages, to process your message file with native2ascii. It translates your localized characters to ASCII with Unicode escapes for characters > 127. Pierre Métras
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:
locale
true
>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
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 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 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
RE: Question about localization
Title: RE: Question about localization I'm still learning too, so correct me if I'm wrong. I think you might consider localization as a server-side issue (i.e. keeping this as a user option stored on a database). Otherwise an English user on a French browser would have a problem. Or maybe that's just too contrived to be worth worrying about from your point-of-view. You could then access the Resource Bundle, which it would do for every hit, to get the correct formats. Steven -Original Message- From: Mike Campbell [mailto:[EMAIL PROTECTED]] Sent: Friday, December 01, 2000 2:24 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Question about localization I've just started playing with Struts, so I'm not sure about that, but my gut reaction is "no". From the small bit of code I've seen thus far, I'm not sure how a user could have more than one Locale, to be honest. (Simultaneously, anyway.) I don't think the server is an issue though, I think the locale setting is driven by the client. - Original Message - From: "Doug Ahmann" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, December 01, 2000 9:11 AM Subject: RE: Question about localization > Thanks Mike. > > Would this handle the case where more than one user with more than one Local > were logged in to the same server? > > > -Original Message- > > From: Mike Campbell [mailto:[EMAIL PROTECTED]] > > Sent: Friday, December 01, 2000 8:03 AM > > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > > Subject: Re: Question about localization > > > > > > I'm guessing here, but I would accomplish this with resource > > bundles which can be tailored per locale. Then use the tag libraries > > to reference the resource bundles in you JSP's rather than having > > static (non I18n) text there. The struts-example does this if you > > need a template to work from. > > > > - Original Message - > > From: "Doug Ahmann" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Friday, December 01, 2000 8:49 AM > > Subject: Question about localization > > > > > > > Greetings, > > > > > > I don't know a lot about localization, so I'm hoping you wise > > men and women > > > out there can point me in the right direction. > > > > > > Here is what we need to accomplish: > > > > > > 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)? > > > > > > Thanks, > > > Doug > > > > > > --- > > > Doug Ahmann > > > Macromedia, Inc. > > > (612) 840-9544 > > > > > > > >
Re: Question about localization
I've just started playing with Struts, so I'm not sure about that, but my gut reaction is "no". From the small bit of code I've seen thus far, I'm not sure how a user could have more than one Locale, to be honest. (Simultaneously, anyway.) I don't think the server is an issue though, I think the locale setting is driven by the client. - Original Message - From: "Doug Ahmann" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, December 01, 2000 9:11 AM Subject: RE: Question about localization > Thanks Mike. > > Would this handle the case where more than one user with more than one Local > were logged in to the same server? > > > -Original Message- > > From: Mike Campbell [mailto:[EMAIL PROTECTED]] > > Sent: Friday, December 01, 2000 8:03 AM > > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > > Subject: Re: Question about localization > > > > > > I'm guessing here, but I would accomplish this with resource > > bundles which can be tailored per locale. Then use the tag libraries > > to reference the resource bundles in you JSP's rather than having > > static (non I18n) text there. The struts-example does this if you > > need a template to work from. > > > > - Original Message - > > From: "Doug Ahmann" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Friday, December 01, 2000 8:49 AM > > Subject: Question about localization > > > > > > > Greetings, > > > > > > I don't know a lot about localization, so I'm hoping you wise > > men and women > > > out there can point me in the right direction. > > > > > > Here is what we need to accomplish: > > > > > > 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)? > > > > > > Thanks, > > > Doug > > > > > > --- > > > Doug Ahmann > > > Macromedia, Inc. > > > (612) 840-9544 > > > > > > > >
RE: Question about localization
Thanks Mike. Would this handle the case where more than one user with more than one Local were logged in to the same server? > -Original Message- > From: Mike Campbell [mailto:[EMAIL PROTECTED]] > Sent: Friday, December 01, 2000 8:03 AM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: Question about localization > > > I'm guessing here, but I would accomplish this with resource > bundles which can be tailored per locale. Then use the tag libraries > to reference the resource bundles in you JSP's rather than having > static (non I18n) text there. The struts-example does this if you > need a template to work from. > > - Original Message - > From: "Doug Ahmann" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Friday, December 01, 2000 8:49 AM > Subject: Question about localization > > > > Greetings, > > > > I don't know a lot about localization, so I'm hoping you wise > men and women > > out there can point me in the right direction. > > > > Here is what we need to accomplish: > > > > 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)? > > > > Thanks, > > Doug > > > > --- > > Doug Ahmann > > Macromedia, Inc. > > (612) 840-9544 > > > >
Re: Question about localization
I'm guessing here, but I would accomplish this with resource bundles which can be tailored per locale. Then use the tag libraries to reference the resource bundles in you JSP's rather than having static (non I18n) text there. The struts-example does this if you need a template to work from. - Original Message - From: "Doug Ahmann" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, December 01, 2000 8:49 AM Subject: Question about localization > Greetings, > > I don't know a lot about localization, so I'm hoping you wise men and women > out there can point me in the right direction. > > Here is what we need to accomplish: > > 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)? > > Thanks, > Doug > > --- > Doug Ahmann > Macromedia, Inc. > (612) 840-9544 >
