The Universal Translator — Develop Notes and XPages Apps for Multiple Languages with a Single Solution

Julian Buss, YouAtNotes


August, 2010


Discover a new, streamlined approach to developing a Notes/Domino application for multiple languages. You won’t need to have a design element for each language, and you can use a single translation database for both your Notes and XPages versions of an application.


If you want to develop a Notes/Domino application for multiple languages, your choices are to use IBM Lotus Domino Global WorkBench (for Notes applications) or to tinker with Java property files (for XPages applications). Both ways work, but they present certain problems:
Translating Notes applications with Domino Global WorkBench has these issues:
  • It’s available for Notes applications only.
  • It creates one copy of each design element for each language, which consumes unnecessary disk space and prevents quick bug fixes (the developer has to implement the fix in each copy of a design element).
  • It sometimes offers strings for translation that should be used as they are in the code (for example, inline comments), which confuses translators and may cause bugs.
The problems with using Java property files for XPages are these:
  • The strings to be translated must be extracted into the property files, which is an additional step in the development workflow.
  • The property files contain both the strings and “control tags” (weird looking IDs marking the origin of the string), which makes them hard for non-developers to handle.
  • Any change in the XPages code either overwrites the translated property files or results in the change simply not being reflected at all — which forces the developer to plan each code change very carefully.
I think the biggest disadvantage of using either of the above solutions is that you don‘t have a single pool of translatable strings for both the Notes and XPages sides of an application. For Notes, the strings are in Domino Global WorkBench; for XPages, they are in the Java property files. The result is that the same translation work must be done twice if you have an application with both Notes and XPages user interfaces.
I have come up with a solution that eliminates all of those disadvantages by:
  • Separating strings and code at development time, not later, thus giving the developer perfect control over which strings are translated and which strings are not.
  • Having a single pool of strings and their translations for both Notes and XPages.
  • Providing a database to store the strings where translators can do their work easily and without needing to have any coding skills.
  • Keeping each design element only once; there’s no need for multiple instances of each design element.
  • Allowing code changes at any time, without the need to do a whole new run of the translation, thus allowing quick changes and bug fixes.

Would you like to see the full version of this article?

If you are an electronic license holder to THE VIEW, please log in to view this article.

If you would like information about becoming an electronic license holder — and having 24/7 unrestricted access to all articles and content in THE VIEW Online Knowledgebase — click here to see the available subscription options.

Or call 1-781-751-8813 to speak directly with a subscription and licensing specialist about customized access for you and your team.