commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Hohwiller <>
Subject [i18n] (was Re: [lang]/[resources]: proposal for NLS/i18n support)
Date Wed, 10 Aug 2005 16:39:30 GMT
Hash: SHA1

Hi again,

Still bleeding for response on my mail, but:

It seems that my ideas are NOT completely new (not suprisingly since
they are quite obvious):

There is a similar thing in

but my idea was also to NOT use message-keys that end up in the
exception being not translateable if the according message for the
supplied key can not be found and is not as natural for the programmer
that wants to use constants like provided in my example.
Further I would like to have a more open architecture that uses
interfaces and allows the end-user to pass an instance of its own
implementation (e.g. for MessageBundle).

If there is a "i18n" community out there (heho, come on!) please discuss
with me - I want to get involved.

Take care

Joerg Hohwiller wrote:
> 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

- ---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional commands, e-mail:

Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message