Your customer wants a multi-lingual Domino web application that is able to switch languages in real time. Furthermore, it has to be possible to add and edit languages without much hassle. Besides that, your customer doesn’t want to invest in additional tools, so you can only use the Domino Designer.

The end result of the application has to look like the forms below. First, the form in English:



And the form in Dutch:



Solution:

As the customer doesn’t want to invest in any additional tools (neither licenses nor time to learn a free tool) you will have to stick to Domino Designer. Fortunately for us this is not going to be as problematic as you might first think.

One solution would be to create a form or a view for every language. But imagine the number of design elements in your database if you did this! Furthermore, you will have to do some fancy trickery to make sure the system uses the correct form for the specific language.

Another, much simpler (at least, that’s what we think) solution would be to make one form, and put all the languages on that form. Not using hide-whens, but using a more centralised and structured approach.

Let us try to explain the concept of our solution step by step:

1. Create a multi-value, computed-for-display field on every form for each language. Call this field TransXX, where XX is a language code, e.g. TransNL or TransEN for Netherland and England respectively. These fields are going to hold all text elements you want translated.
2. Create a multi-value, computed-for-display field on each form called TransID: this field is going to hold an identifier for every text element specified in 1.
3. Note that the position (list index) of an ID in the TransID field has to be same as the translated text in the TransXX fields, since we’ll be using this position later.

1. Using a URL parameter (http:///database.nsf?open&lan=NL”;
2. Retrieving it from the “HTTP_Language” CGI Variable or;
3. By setting a cookie somewhere in your application.

1. You open the form in a webbrowser;
2. The ‘form’ checks if you have specified a lan parameter;
3. If so it will use that as a language setting, if not it will check if your browser specified an accept-language header. If not it will revert to a default language;
4. The form will work out the corresponding translations from the TransXX field and will put those fields in the TransApplied field;
5. All the labels will show up using the correct language.

1. Make sure that the TransApplied and TransID fields are available as hidden HTML fields;
2. Create your own javascript function which returns and writes (‘document.write’) the correct translation given a certain id;
3. Instead of writing a column header in a view do a call to this javascript function which will then write out the correct translation.

• It’s fast! There are no dblookups to any other data in the database;
• It’s highly structured/standardisd, allowing other developers to easily read your code;
• All translations are stored centrally in the design. Adding a new language and chaging current ones is relatively easy, since you know where to look.

• Reading the form in designer mode is a bit more difficult;
• Translations are embedded in the design of the application. If you need a front-end to add/change languages, you will have to modifiy the described method.