WORK IN PROGRESS, NEEDS FORMATTING.
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, 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.
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).