Host Software Internationalization Support

Hello there.

I had contact to Adrian and offered to integrate internationalization support into the host software. He said I should send him the changes I made to the current version and he might "try them out" and come back to me. Now that I have not received any reply to my mail, I figured I might just make the files public and see what the community thinks about it.
Do not misunderstand me: I do not mean any offense! I just believe the modifications make sense.

I attached a tarball of the changed files. Feel free to check it out. I appreciate any criticism of my work. Feel free to ask questions too!

Note that this is just a proof of concept, complete support would be made if the way I do it is all right.

HOWTO use this:

I added a simple Translation class to handle the String retrieval and added two (very short) example language files (under host\lib\translation).

the gui\BotConsoleFrame class was modfied to load the translated title from the language file that is currently specified by the Language= entry in your reprap.properties file.

reprap.properties.dist was changed to include a default language setting (en_G. You will need to set Language=de_DE in your own reprap.properties file to see that the bot console's window title changes to "Bot-Konsole".

The only thing a implementing class would need to do is call Translation.translate(); each time a possiby internationalized String is needed.

Hi,

Java already contains a couple of classes that should make i18n'ing simpler:

ResourceBundles:
[java.sun.com]
The basic PropertyResourceBundle behaves much like your description of the Translate function.

MessageFormat:
[java.sun.com]
As I'm sure you know if your a german speaker different languages have different word orders. For internationalizing this means that code like: Translate("before value ")+value+Translate("after value")
becomes very hard to translate, If there is more than one value it gets even harder. MessageFormat behaves a bit like printf in C, allowing the translation to contain a marker where the value should be placed.
It can handle date, numeric and other formatting and even, although not elegantly, plurals.

A nice article on both classes is:
[www.javaworld.com]

There is also the matter of JTextField and setting up how numbers/dates are displayed and or validated with it. Fortunately this is quite a common requirement and there are several extended versions available on the web that can do this.

I hope this helps,
Pete

P.S. if we want to support right to left, hebrew, or column based languages, chinese, it gets more complex still ;-}>

Hi Pete,

Yes I had a look at ResourceBundles before I startet. But the way I see it, you have to create a subclass of ResourceBundle each time you want to create a new translation. My approach was to make this easier to do for non-programmers by using the human readable properties files and making the current language a setting in the preferences window.

I believed it to be "overkill" to implement all these classes for each language. But you are right, this will not be enough for all languages.

MessageFormat looks promising too, yet I tried to look for an approach that does not require the code to be modified in so many places. I guess this is not possible if you want to get it correct, right from the start.

The PropertiesResourceBundle
[java.sun.com]
Reads from human readable properties files and doesn't need sub-classing per language.

The sub-classing per language is only used when an algorithm varies by country. The standard example is field value sanity checking: Consider the Zimbabwe Dollar currently the exchange rate is ZWD 30,000 to USD 1.00. A value of 1,000,000 in a shopping cart application using USD should fail the sanity check, but if the application was running using ZWD then values that are not multiples of 1,000 should fail.

Also does anyone know if NetBeans generates swing that can handle orientation and ordering changes between locales? e.g. placing labels to the right of input for Middle Eastern languages.

I'm worried I may put people off with all the different aspects there are to fully internationalizing a program. We don't have to do it all at once (or even ever ;-} ), for most European countries string translations will cover 99% of the GUI changes between locales.