JavaScript Internationalization & placeholders


Some time ago I wrote about moving a Teamroom application up to IBM Bluemix. This month the XPages runtime is now general available.

In the post I mentioned I would come back on some design gotchas I saw while analyzing and preparing the Teamroom application for staging it to Bluemix. So here is (at least9 a first post.

What I noticed for example was the usage of the l18n library in SSJS and placeholders in properties files.

i18n formatting

This is a server script library with methods to format messages for localization, display dates in a locale-specific manner and miscellaneous Internationalization utilities.

So how does this works?

Create two or more strings properties file e.g.


The file content:

compliment=Handsome {0}

The file content:

compliment=Snygging {0}

Now create an XPage and place e.g. a Computed Field control on it and calculate it’s value:

<xp: text><xp: this.value><![CDATA[#{javascript:compliment = strings.getString(“compliment”);

return i18n.format(strings.getString(“”), compliment);}]]></xp: this.value></xp: text>

(Do not forget to enable Internationalization for your application in the Application Properties under section International Options)


Notice in the properties file the usage of a placeholder: {0} and how it is being referred: strings.getString(“”), compliment. Here the variable compliment (another string property value) is put in the placeholder.

As a result in the default language I get returned “Hello Handsome” and when I choose Swedish as default language in my browser I get returned “Hello Snygging”.

By wrapping it and formatting it with the L18n library you ensure it is fitted according the active language. This is very handy for dates, amounts etcetera.

Links of interest

More details about JavaScript Internationalization can be found in the IBM Notes Domino Application Development wiki.



Using the language bean from XPages Toolkit for Internationalization


You have people who tend to tick around where they live and work and you have people who tend to switch location now and then. Especially in Europe which is divided into many countries with many different languages, somehow operating under one flague,  you are sometimes amazed that organizations have not fully adapted to the trend of “travelling” co-workers.

different langiages

If you are lucky an application is presented bilingual but in a lot of occasions an application is presented either in English (when that is the official language of communication) or in a native language where the application is initiated and being used.

But what if that cross-border European co-worker enters the work floor?


Internationalization refers to the process whereby you prepare your application for users from varied geographies. There are two parts to this:

The need for localization is obvious; a German user wants to see an application in German and a French user in French, and so on. Localization involves making different language versions of all the application’s user interface available and ensuring the correct strings are used based on user preferences.

Support in XPages

In the IBM Notes and Domino Application Development wiki you can learn about the support for internationalization in XPages.

In this post I will describe how you can use the language bean that is part of the XPages Toolkit available in OpenNTF.

Sample application

In this post we will build a simple XPages UI which looks as followed:


In a combo-box you get presented a list with available language options. And based upon your selection values will be collected from a set of property files.

I will include a dropbox link to the sample application.


First: download & install the library. Beside the library there is also a sample application which comes in handy to borrow code from.

Java classes

The following files you will need:


Property files

The property files contain the actual string values. The amount of files depends on the number of languages you want to support. In our case 4: English (default), Swedish, German and Dutch. There will be three types of files: general, contacts and keywords.  That makes 12 (4*3) in total.


Here is what the files could look like. First the general poperties file:

AppTitle=Language Bean
NotAvailable=Not Available
SwitchLanguage=Choose Your Language
Header=Demo Language Bean
SubHeader=Register A Person

Which becomes in Swedish:

AppTitle=Språk Böna
NotAvailable=Inte Tillgänglig
SwitchLanguage=Välj Ditt Språk
Header=Demo Språk Böna
SubHeader=Registrera En person

The contacts properties files:

LastName=Last Name
FirstName=First Name

In German:


And at last the keywords properties file:


Which becomes in Dutch:


The properties files are “registrered” in the language bean via the following method:

public List<String> getPropertyFileNames() {
List<String> propertyFileNames = new ArrayList<String>();
return propertyFileNames;

Layout custom control

My demo app contains 2 pages which demonstrates the 2 options you have with the toolkit: use the language bean or the toolkit @formula.

<?xml version=”1.0″ encoding=”UTF-8″?>
<xp:view xmlns:xp=”; xmlns:xe=””&gt;
<xe:applicationLayout id=”applicationLayout1″><xp:this.facets>
<xp:panel xp:key=”LeftColumn”>
<xe:navigator id=”navigator1″>
<xe:pageTreeNode page=”/bean.xsp”>
<xe:pageTreeNode page=”/formula.xsp”>
<xp:callback facetName=”facet_1″ id=”callback1″></xp:callback>
<xe:simpleResponsiveConfiguration navbarText=”Language Bean”
label=”Kwintessential Notes” title=”Visit My Site”>
label=”XPages Toolkit” title=”Visit Project on OpenNTF”>

Bean XPage

I will spare you the  complete code for the Bean page. Check the download if you want the complete code.  The principle is simple. You collect the value via the following pattern

xptI18NBean.getValue(“[properties file].[key]”)

That could become something like:


Switching language

In order to switch language a combobox control is presented with the following code:

<xp:comboBox id=”cbSwitchLanguage” defaultValue=”#{javascript:xptI18NBean.getCurrentLanguage()}”>
<xp:eventHandler event=”onchange” submit=”true” refreshMode=”complete”>
<![CDATA[#{javascript:var sv = getComponent(“cbSwitchLanguage”).getValue()
if(sv != null && sv != “”) {
var locSet:Locale = new Locale(sv);

Language options

The getAllLanguages method in the language bean “registers” the available language options:

public List<String> getAllLanguages() {
List<String> languages = new ArrayList<String>();
return languages;

That is basically it!

Formula XPage

This page differs from the Bean page in the way it accesses the property files. It uses a formula which is defined in the XPages Toolkit library.

The formula follows the following pattern:

@XPTLanguageValue(“[properties file].[keyword]”)

Which could become something like:



A sample application for download is available under the following URL.


I am curious what method you use to make your applications available in multiple languages. Please drop a line how you have solved it.

I found the language bean in the XPages Toolkit very intuitive and easy to use. At least in some cases it solves the problem nice and quickly so my thanks go out to it’s project members.


Thank You Today (TYT) – Tommy Valand

With a project in development and facing some problems questions on XPages I thought I create a new category on my blog called “Thank You Today” (TYT could become tomorrow Thank You Tuesday hehe) and show my gratitude for those in the yellowsphere that blog about stuff sometime that helped me today fixing problems.

My TYT goes out to Tommy Valand for his post+comment on multi value fields:

Our workaround is adding input translation @Explode( @ThisValue ; separator ) (separator -> @NewLine, “,”, etc.), to the fields in the Notes form, and enable compute with form on the data source in the XPage.