No matter what be the project you are working on whether you are creating an eclipse plugin, or a simple Java project you must deal with internationalization. To some extent the string externalization wizard provided by eclipse does solve some of the issues and hastens development speed.

However the code generated is definitely limited in purpose.

1. For parameters you are forced to create an object array and deal with indexes on your own when using the MessageFormat class. This approach is both inelegant and definitely not so object oriented.
2. You are forced to deal with  and manage keys in your code and the property file again without any elegance.

Design aspects that need to be made configurable are:-

1. What to cache and how to cache. Should one not do the caching at all as after all the Java API itself does some caching for the resource bundles.
2. Whether there will be only one locale (the default locale) or whether there will be multiple locales.
3. Toggling the key types between - String / int /enum and addressing related issues. (enum types will be used only for JDK1.5)
4. Whether message formatting is to be done by means of MessageFormat or the Formatter introduced in Java 1.5

Other issues

1. Can we avoid writing the properties files and managing them by hand?
2. Can the issue of plurals be dealt with automatically?
3. Can we forget the mechanical coding of creating the object array (this is less of an issue with Java1.5) and dealing with MessageFormat?
4. Can we have a more elegant code such as "String getKey1Msg(int param1, String param2, Date, param3, Integer param4) which can serve as a facade around the details of the actual object array creation" (In Java1.5 there is no need for the explicit object array and object creation because of varargs and auto-boxing and unboxing)?
5. Can the keys be kept as constants in a Java interface (or a enum type in JDK1.5 )?
6. Instead of dealing with a clutter of code and keys and properties files can we manage them in a more systematic manner.
7. Can the internationalization needs of exception classes also be addressed similarly?
8. Can we quickly locate keys for locales which do not have entries?
9. Can we use standard keyboard mappings for a locale and  transparently get the correct property file entries in a WYSIWYG fashion rather than feed in unicode by hand for any locale?
10. As we go about creating the entries against a locale and a key can we see a preview of the actual message that will be finally delivered to code that uses the generated code  taking into consideration the different parameters even before we actually were to generate the code and the properties files?

11. can we  transparently convert between  java.lang.String.format("pattern", varargs) and java.text.MessageFormat("pattern", varargs) code and resourcebundles without any effect on the client? [TODO have to provide for java.lang.String.format("pattern", varargs)  before this converter cam be used]

Yes we can address all these issues and more using the RB plugin! *

The RBPlugin provides you a set of wizards and editors to create and edit a XML metadata  file. This metadata rb file is where all the above mentioned and more issues are configured using the wizards and editors. The built in code-generator delivers the properties files and java code freeing the developer from all concerns of internationalization. at the minimum it reduces lines of code. When working with the resource bundles it eliminates ambiguity by ensuring that users work with identifiable names instead of the confusing index of object in a object array or varargs. Moreover it provides means for tweaking code internals for performance as per design requirement.

How

* point XI is a TODO

Copyright © R.Raghuraman. Distributable under LGPL license.	JXPRESS.