How to use xPages translation files from Lotusscript and SSJS libraries

Question

I am using resource bundles to translate all my xpages into different languages. this works great for translating labels etc in xPages.

I do however have Lotusscript agents and server side javascript code in the database that send mail to users and I want these emails to also be translated using the translation files.

so my question is simple. is it possible to read the translation files from SSJS scriptlibraries and Lotusscript agents. If so please let me know how?

Image below show all my translation files, one for each language.

string_*.properties

Answer 1

In SSJS you can access the property files with getResourceAsStream method.

var data = "";
var ex = facesContext.getExternalContext();
var io:java.io.InputStream = ex.getResourceAsStream("strings_en.properties");

var i;
do{
   i = io.read();
   data += @Char(i)
}while( i != (-1) ) 

The variable data contains now the whole *strings_en.properties file.

An example to load the properties directly in a java.util.Properties instance can be found here:

http://openntf.org/XSnippets.nsf/snippet.xsp?id=access-.properties-files

In LS it is more complicated:

1. You need a lookup view for the design elements, with the field $FileNames as key
2. This allows you to search for the property file.
3. Then you can export the design document with dxl
4. In the exported DXL, you have to search for the $FileData item
5. In the item there is the BASE64 encoded property file
6. Decode it, skip the first 30 characters (header informations like size of the RT)
7. Parse it line by line

Answer 2

There is an article on developer works explaining i18n (the common referrer for internationalization. Follow those steps.

For LotusScript: follow Svens steps above or eliminate it from your XPages app.

An alternate approach: since your resource files only change at design time:

• link your NSF to an on disk project
• now all resource files are accessible to tools
• create a Java class that translates the resource file into LS source. You could either populate a list or use a class.
• in your on disk project's builders create a Ant task that runs your class and writes the LS into a library in the on disk project.
• the sync will write it back to your nsf

Have fun

Answer 3

There's nothing to add to Stefan's and Sven's answers, at least not in regards to the technical side of your question. I wonder however whether your basic approach to the problem couldn't be a different one:

Assuming that your application is mainly based on an Xpages frontend design I wonder what a LS agent could deliver to your users that needs to be translated. Maybe some mail content, or some field content printed into documents using backend classes. In both cases, however, you wouldn't have any chance using any localization parameters that come from either client preferences or from user preferences stored in user profiles or something like that: scheduled agents simply cannot react to those settings. What I want to say is: are you really sure that your LS code in fact needs to access translated strings? Or wouldn't it be easier to put that load onto SSJS code that in turn can access your resource bundles?

And yet another thought: I really like the Xpages' approach in using i18n, but there's always the drawback that you need a designer client to apply translations, and in same cases the database owner needs simple access to the translation sheets but doens't have the menas or the access rights to use Domino Designer. Therefor at least in some applications I prefer to use sets of config documents stored in the database itself, to be accessed by all kinds of codes, although I'm aware that this might impose a performance issue. So maybe Stefan's idea of using the server's file system for that could be a nice solution to that.