WORK IN PROGRESS, NEEDS FORMATTING.
Why internationalise?
Internationalisation is about users being presented with interfaces that are displayed in their preferred language. If your portlet provides options for a user to configure the portlet, or displays headings and other strings on screen, this is an essential step. And it is simple!
For your portlet to support multiple languages (eg French, German, Japanese) or even variants of the same language where spelling may be different (e.g. English (US), English (Australian), all hardcoded strings must be moved into a properties file. This properties file can then be translated into various languages. Your portlet then refers to the keys within the properties file, rather than the actual text. To accomplish this we use the JSTL fmt tag library, which is part of core JSTL.
For example, the following is a hardcoded string and will only ever appear in the language it is written in.
<p>This is some text</p>
In order to fix this we need to first move these strings into a properties file where it can be translated, then add some additional setup to our pages to read the correct language version of the text into our page.
It's easy, lets do it!
First, create a properties file. Conventionally this is called messages.properties but it can be called anything.
messages.propertie
my.internationalised.string = This is some text
Include the JSTL fmt tag library in your JSP:
<%@ taglib prefix="fmt" uri="http://java.sun.com/jsp/jstl/fmt" %>
Setup a language parameter in your JSP, and use that to set the Locale using the fmt:setLocale tag. This is important so that the fmt library knows what language file to get the property from.
<c:set var="language" value="${not empty param.language ? param.language : not empty language ? language : pageContext.request.locale}" scope="request" /
<fmt:setLocale value="${language}" />
Include the properties file in your JSP using the fmt:setBundle tag. The basename is like a package and refers to the directory that the file is in, in your classpath.
<fmt:setBundle basename="au.com.flyingkite.myportlet.utils.messages" />
This indicates the messages.properties file is located at au/com/flyingkite/myportlet/utils/messages.properties
Output the string using the fmt:message tag:
<fmt:message key="my.internationalised.string" />
Now for all strings you just add them to the properties file and refer to them by their key, and they will be retireved from the properties file.
People can then translate the file into a different language, store it with the language suffix, eg messages_fr.properties and if a user's locale is set to French for example, it will use the properties from that file instead.
Missing properties will always fall back to the base properties file, so whatever language that file is in will be the default (generally English but not always so).
Important things to note
If you have a combination string where data is added later, perhaps from a variable, such as "Hello my name is USERNAME." or even "Click here to configure this item, or here to go back", where 'here' is a link, you must NOT concatenate strings together within your code. The properties file system contains the facility for placeholders to be set. This is because the way you structure may not be the same way a user from a different locale structures the same sentence. using placeholders allows the correct sentence structure to be set for each locale.
Do this:
greeting.text=Hello {0}.
configure.link.text=Click {0} to configure this item or {1} to go back.
In your JSP you then provide a list of values that will be substituted for the palceholders
TODO