Internationalization Design Advice
In the 4th message in the thread below I write about an Internationalization plan for an application I'm working on.
http://forum.java.sun.com/thread.jspa?threadID=719315&tstart=0
To restate my second question a bit, what we want to do is test the text translation for various Locales from a single machine physically located in the USA.
Since I'm using Struts, would I be able to change the Locale in a custom RequestProcessor object, so that when the Action class gets the request it would have the Locale object added by the RequestProcessor, rather than the real one that stems from my OS?
Is there another way?
Any help or feedback is greatly appreciated.
I'm confused about your statement below about the Locale object "that stems from my OS".
You are creating a servlet/JSP web application, right? So wouldn't your only choice of getting the locale be the information provided by the browser Accept-Language parameter? Or are you using JavaScript to actually get the OS locale?
If you are using the browser information, then the real simple way to test different locales is to change the browser setting - something I use regularly to test our servlet/JSP implementations.
About properties files vs. list resource bundles for the localized strings: I have not seen any performance issues with using properties files for strings much bigger than the one you quote. And since they are much easier to deal with, I always go with properties files (only issue there would be a need to deploy on both EBCDIC and ASCII platforms - character encoding would come into play there).
> Since I'm using Struts, would I be able to change the
> Locale in a custom RequestProcessor object, so that
> when the Action class gets the request it would have
> the Locale object added by the RequestProcessor,
> rather than the real one that stems from my OS?
>
Forgot to mention: I assume that you will give the user the option to change locale, if the locale your code detects is incorrect according to the user's preferences? In which case that would also give you the opportunity to switch locales for testing purposes.
> If you are using the browser information, then the
> real simple way to test different locales is to
> change the browser setting - something I use
> regularly to test our servlet/JSP implementations.
Thank you. This is what I was looking for. By changing the Accept-Language parameter from language to language, we can then call up the JSP page and test that the application is grabbing the correct properties file.
I was under the impression that the Java code got the Locale from the JVM which in turn got it from the OS it is running on. I was wrong. Thanks for clarifying.
I wasn't planning to have an option for users to change Locale. I guess we are planning to depend upon the reliability of the code in the JSTL tag library and the JVM. Have you found this code to be faulty in some cases?
Could we code this functionality of changing the Accept-Language from our app? If we change the Locale in the Struts Action would this have the same effect, or any effect on what the tag library does in the JSP page?
Thanks again.
If we are talking about web pages here, java and technical reasons aside, you should have a tool on the page to switch locales as a matter of user convenience. I consider this a basic, basic feature and become extremely frustated when there is no way to get a different language version of a page without resorting to changing settings. Here are two non-hypothetical examples from my experience for why:
1) A person might be using a computer in a foreign country to view the page in his native language
2) A person might wish to peruse multiple language versions of the web page. Reasons for this would include a desire to view the page primarily in a language the reader is learning, but with recourse to the version in his native language when something comes up that he can't understand.
Drake
A good point. But it is trickier than you might think to implement that tool. Here's an example, not from the web-application world but still relevant:
My wife and I were in an Internet cafe while on vacation. When we started up MSN Messenger we found the previous user had changed the language to Dutch. Neither we nor the proprietor knew Dutch so it took quite a while to find the "Change Language" menu option, which was naturally in Dutch.
So sure, it's possible to implement the tool you suggest. But you wouldn't internationalize it in the same way as the rest of the application.
ah that's just crappy design. the swap language bits should be fairly visible, be localized (ie "french" in french, "thai" in thai, etc.) and be sticky across the whole app.
In any case it should not be too hard on a web page. Just put some nice looking national flags in the upper right.:)Drake
To sum up: you should never rely only on the Accept-Language of the browser to set language/locale. It can be very different from what the user wants to use in your specific case. So always allow the user to change it.
What I consider best practice is the display each language choice in the native language - that way, if you can't read the choice, you probably don't switch to it (or if you do, it's your own fault if you can't read the screens...).
So, the language list would read something like this:
Dansk
Deutsch
English
Francais
etc.
> To sum up: you should never rely only on the
> Accept-Language of the browser to set
> language/locale.
We will use the Accept-Language feature to test the application while it is in development stage. Thanks for pointing this out. It is a very simple technique to test the JSP tag libraries.
My question above was related to the comment about enabling the user to change language/Locale from the web application when in production.
How is this accomplished from the Java code on the Presentation tier?
Is there some parameter that should be set in the Response object sent from the Action?
Yes, I would implement the locale selection by passing the locale string in a parameter from the form action.
You should then allow the user to save his preference so that they don't have to select the locale every time. Depending on your implementation, the preferences could be saved either in a DB or as a cookie.
