JSF message bundles and locales

Java Server Faces supports localization or internationalization (I18N). You choose the term. I find them to be synonymous terms and will use them interchangeably.

If you want to split hairs go here:

http://www.w3.org/International/questions/qa-i18n

I18N allows you to accomodate your software to different languages whether it be English, German or Chinese; thereby supporting web clients around the world.

One easy way to make JSP localization work is use it in a JSF enabled dynamic web project inside an OEPE enabled Eclipse IDE.

You'll need to update the faces-config.xml file, adding properties files that you've made and locales that you support.

Here's a faces-config.xml file example:

<faces-config version="1.2">
<application>
<message-bundle>resources.application</message-bundle>
<message-bundle>resources.Greeting_fr</message-bundle>
<message-bundle>resources.Greeting_en</message-bundle>
<message-bundle>resources.Greeting_de</message-bundle>
<locale-config>
<default-locale>en</default-locale>
<supported-locale>fr</supported-locale>
<supported-locale>de</supported-locale>
</locale-config>
</application>
</faces-config>

Each message-bundle element tag lists a language locale property file. In my case I put the properties files under src/resources. Note that the properties files listed inside the message-bundle tags don't come with *.properties file extension. It's implied.

Under locale-config I place supported languages. In my case I have English, French and German. My default is English.

The great thing about OEPE is the ability to add message-bundle and locale-config elements to the faces-config.xml file by using the Faces Configuration Editor. You can easily add new languages that are supported and browse for new language message bundles.

When I do want to use message bundles I can test it with the loadBundle tag and outputFormat tags inside a JSF enabled JSP page.

Here's an excerpt from the JSP page:

<f:loadBundle basename="resources.Greeting" var="greeting1" />
<h:outputFormat value="#{greeting1['login']}">
<f:param value="Joe"></f:param>
<f:param value="05/19/2010"></f:param>
</h:outputFormat>
<h:outputFormat value="#{greeting1['welcome']}"></h:outputFormat>

Note that I specify "resources.Greeting" for basename.

The first part before the dot is the folder and the second half means all the Greeting_*.properties files.

My properties files are:

1) Greeting_de.properties
2) Greeting_en.properties
3) Greeting_fr.properties.

I don't need to add the underscore.properties to basename since it's implied, meaning any file will be used for a localized message depending on the client preferred language.

The country will be figured out by what the browser passes to the server. In Internet Explorer I can change my preferred language and see a different message. This is done under Tools > Internet Preferences > General > Languages. I can easily add and rearrange the preferred languages within that Internet Explorer dialog and reload the web page to see the language change on the fly.

Importance of quality, time and features

In an ideal world quality, time and features should be given equal weight in the software development lifecycle. The ranking for most firms it seems is: 1) quality 2) time 3) features. Quality should always be given precedence. If things need to go, due to scheduling, etc..., you need to throw out features first, then time and always try to maintain quality standards. Makes sense and we practice that here too.