Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <42F7E622.2030907@j-hohwiller.de>
Date: Tue, 09 Aug 2005 01:09:22 +0200
From: Joerg Hohwiller <joerg@j-hohwiller.de>
User-Agent: Debian Thunderbird 1.0.2 (X11/20050331)
MIME-Version: 1.0
To: commons-dev@jakarta.apache.org
Subject: [lang]/[resources]: proposal for NLS/i18n support
OpenPGP: id=60DCBFFF
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

-----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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org