-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there,
in my project I started an approach for deep native language support (NLS). It is very simple and I start liking it. Because it is so fundamental, I would love to place it into the JDK. Since that is not going to happen (and the JCP is even after JSR-99 still far away from cathing up the spirit of open-source - mmhm this is not the harmony project here ... :) ) I though about suggseting the idea for commons lang. I can send some code, but I want to point out the idea in the first place. If you are familiar with NLS you will know java.text.MessageFormat. Additionally you might have experienced that the support of the JDK for NLS in multi-user applications is pretty poor if you say at all that it is there. Now why on earth do not just bundle the format pattern (which is the internationalized message) together with the arguments to fill in into an object that I call NlsMessage. Besides the getters to get the pattern and the arguments back, there will be a method to get the full message with filled in arguments using MessageFormat. Additionally there is a method that does the same thing but translates the message before by taking as argument a call-back interface that I call StringTranslator. That is the simplest interface possible for doing a translation: it has one method "String translate(String)" that translates a given String into a different language. Now where is this all leading to? An Exception takes a string as message. My enhancement is to take an NlsMessage instead - there can be still the String construtor available. This allows true NLS support on exceptions. You know what the getLocalizedMessage() was intendet to be for. Now lets come to the magic part how on earth the StringTranslator interface can be implemented without having a bablefish. I define an abstract class that I may call NlsResourceBundle (it might extend ResourceBundle and Serializable or go the commons-resources way) that adds a method to reverse-lookup the key of a message via reflection. So if I extend that class and call that MyBundle and add String constants as public static String ERROR_ILLEGAL_INT_VALUE = "The value was expected to be an integer. However the value \"{0}\" is no integer!"; Now I somewehere do throw new NlsException(MyBundle.ERROR_ILLEGAL_INT_VALUE, value); Now the string translator can be a component where MyBundle is registered so it can be used to reverse-lookup the key "ERROR_ILLEGAL_INT_VALUE" and that key will be used to get the message in the language choosen by the current users locale. So to keep the approach leight-weight the proposal would not contain a complete NLS service solving the full issue but only includes the core stuff to make this available by providing: NlsMessage (maybe as interface with default implementation to allow people to put their own magic in for direct translation from the toString() method, what would not really be my suggestion, however) StringTranslator (interface) NlsException with the constructors (String), (String, Throwable), (NlsMessage), (NlsMessage, Throwable) and a printStracktrace method that takes a StringTranslator. NlsResourceBundle (or however we may call it) Most people do not care about NLS in exceptions or at all. But esp. in open-source projects this should be an important issue for a world-wide community. The typical way to do translation is giving the message key into the nationalizeable object. This sucks if not even the english messages could be looked up for some reason. Feedback is most welcome. Regards Jörg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC9+YimPuec2Dcv/8RAn/RAJsEHUZdu1Wr9XZX42cStqFRyqe4fACdFcgX T6u/+jQBIMnWOe7rnlh35go= =Gwf9 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]