A call to action for all non-US developers!

In my post titled “XPD – where do you live?” from the other day I discussed some problems with i18n (internationalisation) of applications developed in Java for the Notes 8+ platform using the built-in classes (java.util.Locale). Since that post I have been in dialog with IBM via the Domino NEXT Design Partner program.

It has been confirmed that this is indeed a problem and probably in the core Notes client. The problem probably stems from Lotus Expeditor.

Unfortunately not much light has been shed on the subject except IBM asking me to run a Danish Notes client which is among the worst thing I could imagine doing. I run software in English – period! I do however expect the software I run to be able to detect my computer locale as set in the operating system. As an aside it is actually quite common for non-English speaking Europeans to run English software despite the fact that a native-language edition is available.

As part of this process I have been thinking about the API’s that we need to have available for i18n. It is quite clear that we need

  • the possibility to obtain the language (as a java.util.Locale) of the client itself (that is the language of the menus etc.)
  • a way to obtain the java.util.Locale the OS is configured for
  • an official API for accessing the regional settings as configured in the Preferences for the calendar display in Mail

If we had these we should be able to create the kinds of localized products and plugins customers expect and demand.

What is your take? Can you see more API’s we need while we’re at it?

3 thoughts on “A call to action for all non-US developers!”

  1. I am surprised it’s not in the box at this time. Notes is supposed to the client that has the great built-in support for all kinds of languages and character sets.
    I agree 100% on what you’re saying here Mikkel. I also see lots of non-English customers running an English language client; usually large international cross-border companies.
    And I see customers where it’s mixed, admins and developers running the English language client and end user running a national language client.
    It’s very important to fix this issue.
    More so than the quick fix we got for week numbers in the 8.0 client.


  2. Not sure if I might say something very stupid here, but:
    isn’t the real problem, that you can’t set text labels in Notes Design elements with property-files and ressourcebundles like in java?
    Java i18n allways worked fine for me. But its more like a framework build inside the standard java-api than an api. You edit some lists of name value files in .properties files, name the property files according to the needed language codes like texts.dk.properties, texts.es.properties, text.en.us.properties etc and by certain client code your app is using the i18n without any extra work.
    Java-Webapps have some add ons to the general java framework for i18n, but they are based on the general java framework.
    I guess notes design elements should be extended to support the standard java i18n mechanism.
    Historically I’ve seen not one happy Global Workbench user. A lot of developers are building their own i18n frameworks on top of Notes, which tend to have performance issues for certain use cases.
    There is definitedly a need to support sound i18n inside Lotus Notes.


  3. If you need any assistance with testing, let me know. I hate Czech software versions, so I m running EN windows, EN clients, but I have to have Czech regional setting. Notes are quite OK, if I ommit 3 groups in start menu (english, czech and misspelled czech).
    Today I started to play with IBM support assitant workbench, also Expeditor based, which didn’t give me chance to change language and while running in Czech mode, I can’t even import files. After switching reginon to US, this tools started to work. I hate this. And I even more to hate with such problems at customers’ sites.


Comments are closed.