commons-dev mailing list archives

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

Daniel Florey wrote:
> Hi Jörg,
Hi Daniel,
> I looked at your proposal for quite a while but couldn't figure out the
> advantage of your approach.
> If you want to improve the i18n component every comment or suggestion is
> very welcome as we try to push it towards to a 1.0 release and move it to
> commons proper once all remaining issues are resolved.
> So: Maybe I'm dumb but please give me a simple example that shows me what
> exactly you want to improve.
Im am sure you are not, maybe I did not make it very clear...

Exceptions occure in critical situations and should help to figure out
what went wrong. Now if your MessageManager fails for whatever reason to
get the appropriate text you only have a message key and currently you
even throw another exception. So creating an exception might cause
another exception. In my oppinion there should always be a fallback to
get the message in the "default" language which is english (I am not an
Further there are many guys out there that discovered that static coding
is not always the best thing to do (e.g. talk to all the IoC container
freaks). So if the design would be a more open (so the mechanism for
lookup can be replaced without getting into your code) you would not
scare away those folks.

Here are some of my suggestions:
For your bundle (LocalizedBundle):
- -create an interface
- -replace getArguments() with getArgument(int) and getArgumentCount()

Why is LocalizedBundle not in the bundle package?

Do not resolve the message in the constructor of the exception, but
store the acutal bundle object. Override the getMessage() method
to return the actual message from the bundle (in my case in english) and
add a getMessage() method that takes a parameter for the localization.
- From your point of view the Locale and from my point of view the so
called StringTranslator. Do the same thing for printing stacktraces.
Override the getLocalizedMessage() to do something appropriate (e.g.
calling getMessage(Locale.getDefaultLocale()).

I can see the missunderstanding now:
The object that you call bundle (LocalizedBundle) and I called message
(NlsMessage) do not completely match:
Your bundle stands for a set of informations (title, summary, details)
while my message stands for one information.
I put the information in english language into the message object, but
keep the arguments separate. The english message just comes by filling
the arguments with MessageFormat. For n8n the core english message
(without arguments) is translated to another language before.
I can currently imagine of a compromise of both approaches, but it might
not be an easy process. Anyways I actually think we could both learn
from the other approach and get an improvement to both solutions. The
question is if the both improved solutions could be the same :)
So if you want to have your 1.0 done soon I'd not suggest to get too
deep into this, but maybe you are interested.

To get a little impression you might look at the following URLs. The
problem is that I am in big trouble with my project because I could not
live with cvs anymore after I got addicted to svn. So the sourceforge
cvs of my project is more than a year old. But the current svn is not
accessible right now and does not get their svn service ready.
Anyways better than nothing:

> Cheers,
> Daniel
ps: would you mind turning off your n8n for mail prefixes (AW instead of
RE) to not get "Re: Aw: Ref: Re:" constructions?
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -


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

View raw message