An i18n strategy largely depends on the framework you are using, as most of them have built in support for internationalisation and it wouldn't make sense to custom roll your own if your framework already supports it.
Spring MVC, for example, uses properties files and a locale resolver to display different versions of pages. They append
?language=xx into the URL to determine which properties file to look for to display the messages.
Most of the Java frameworks that I've worked with have achieved internationalisation in a similar fashion. Multiple properties files that are suffixed with language code and then using
<message>-type tags to render the content.
Does this only apply to static content?
No. Depending on how you are tracking what language the user has selected, you can easily pull dynamic content based on a language filter. If you're pulling data from a table, you can have a column in the table that specifies the language. That way, when you're SELECTing from the table you just do
WHERE language = xx to get back the content that matches the language the user has selected.
Is it possible to internationalize this way dynamic content? For instance, a page which results in some form submission, clicking a different language might result in undesirable consequences. Some dynamic requests where transactions are not involved (simple queries, for example) might present no problems with this.
A user changing their preferred language on your website shouldn't break their current session, regardless of whether they're currently filling in a form or not. Don't do a SUBMIT on the form when they change the language and it shouldn't have any unexpected results.
For authorized content, I guess I must ask for language in login page and use that language, i.e., disallow changing locale for authorized content, which, probably, has a lot of transactions. Is this correct?
You can do that if you like, it depends on how you structure your web app and how you are handling sessions within your authorised area. You could ask someone to choose their language at the login page and then not allow them to change after that.
You could also let them change their language at any time and just "refresh" their current page, pulling in the content from the "new" language rather than forcing them to log out and back in again. (This is the better way to do it, IMO).
How do I structure template files? One JSP for each of the languages? One JSP with a properties file for each of the languages?
Again this depends on the framework you're using. Don't create a different JSP for each language as if you need to change the page you need to change it for every language. Whilst this is also true for properties files, you're changing content in them and not page layout/design. A properties file for each language is how I've generally seen it done, and seems to be recommended by most frameworks.
How do I construct the link according to current request? I guess that url requested and param string should be remembered and reconstructed in JSP.
You guessed correctly. Once a user selects a language save it in their session scope and pass it along with them.