Dynamic localization framework

Important note as of 2008-08-25

I abandoned the internationalization project and started with a new approach. (See A new start: NI18N). The old software will remain available on this site for the time being.

What is the dynamic localization framework?

The dynamic localization framework makes it easy to develop Swing desktop applications, or refactor existing applications, that can dynamically change the locale setting. Upon a locale change, all visible components will display localized values for the new locale automatically.

Why is this useful?

There may be circumstances that a user wants to view an application in another locale than the default locale of the machine he is working on. Reasons may be:

• The application is not translated (or badly translated) in the user's locale and the user is not familiar with the language of the application's default bundles. Possibly there is a translation that is understandable for the user. As an example, given an application with default bundles in English and no Portuguese translation, a Portuguese user may try to change the language settings until he finds a more understandable language (Spanish or Italian for example).
• A translator translates an application into some language and wants to directly see the results without stopping and restarting that application.

What must a developer do to use the framework in an application?

The framework must be made active. So, somewhere at startup time, one must code:

I18nInstaller.ensureInstalled();

(It does not matter if this method is repeatedly invoked).

The framework uses so called prefixed keys that can be used on many components and that represent localized values. These prefixed keys are assembled by the I18nInstaller from a ResourceBundle's basename and a ResourceBundle key.

As an example, given a ResourceBundle Resources and a key labelText, instead of coding:

JLabel label = new JLabel(ResourceBundle.getBundle("Resources") .getString("labelText"));

one would code:

JLabel label = new JLabel(I18nInstaller.getPrefixedKey("Resources", "labelText"));

The developer may also use AbstractI18nBundle as the super class for his bundle. Is that the case, then he simply codes:

JLabel label = new JLabel(Resources.labelText.autoKey());

How does it work?

The framework relies on Swing's ability to dynamically change the Look and Feel. When changing the Look and Feel, needed values are obtained from Swing's own ResourceBundles. This happens in the installUI methods.

This framework is build on top of a pluggable Auxiliary Look and Feel  implementation called EmptyX, that is running together with the chosen Look and Feel under management of the MultiLookAndFeel (also known as the Multiplexer Look and Feel). A internationalization plugin is registered in EmptyX in order to delegate installUI requests to that plugin.

What is supported?

• AbstractButton and JLabel "text" property
• JComponent "ToolTipText" property
• TitledBorder title (limitation: a TitledBorder may only be used on one component and cannot be changed. If the title must change, then create a new TitledBorder)
• JInternalFrame "title" property
• JProgressBar "string" property
• JFrame and JDialog title
• JTabbedPane "indexForTitle" property
• JTextComponent text value (makes only sense when non editable)
• JSplitPane if vertically split, the left and right component will swap when changing to a locale with right to left component orientation
• JFormattedTextField automatically switches to a localized Formatter

The bundle editor

A ResourceBundle Editor is available that scans for all ResourceBundles in the classpath and builds a dictionary from values found. This dictionary helps the translator by providing translation hints.

Miscellaneous

Some utility classes are available that help in structuring and organizing your ResourceBundles.

An Arrow icon is available, subclassed into LINE_END, LINE_START, PAGE_END and PAGE_START, that automatically points to a direction based on the current orientation.

No webstart demo

The framework will run in a webstarted demo. However, changing Locale will not be permitted by the Security Manager if the application's jar file is not signed. Moreover, the Bundle Editor, which is an important part of the demonstration, needs to write translated bundles to a directory that is contained in the current class path for the changes to be immediately in effect on the GUI. Since this is impossible, even with a signed jar file (I could not find a way to include a local directory in the class path when using a webstarted application) no webstart demo is available.

Download

Please see the download page and download the complete package. It contains a ReadMe file that explains how to run the demo.