commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Florey" <>
Subject AW: [i18n] (was Re: [lang]/[resources]: proposal for NLS/i18n support)
Date Thu, 11 Aug 2005 08:18:03 GMT
Hi Jörg,
Thanks for your comments. See my comments inline.

> -----Ursprüngliche Nachricht-----
> Von:
> []
> Im Auftrag von Joerg Hohwiller
> Gesendet: Mittwoch, 10. August 2005 20:21
> An: Jakarta Commons Developers List
> Betreff: Re: [i18n] (was Re: [lang]/[resources]: proposal for NLS/i18n
> support)
> 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
> englishman).
You will not get an exception. You can throw/catch the LocalizedException.
If you display the error details in a language where no message is
available, it will either:
- Throw a MessageNotFoundException if you don't provide a default text 
- Print the given default text
Should I make this clear in the docs?

> 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.
I don't see how to get rid of the static methods in the MessageManager and
> Here are some of my suggestions:
> For your bundle (LocalizedBundle):
> - -create an interface
The LocalizedBundle contains some logic, so it cannot be an interface.
Should we introduce a new interface that gets implemented by
LocalizedBundle? I think this would introduce additional complexity, but
I'll think about it again.

> - -replace getArguments() with getArgument(int) and getArgumentCount()

> Why is LocalizedBundle not in the bundle package?
It's because of the lack of "friend" keyword in java.

> 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.
The message is not resolved in the constructor! It will be translated when
you retrieve it.

> - From your point of view the Locale and from my point of view the so
> called StringTranslator.
I don't see why to introduce StringTranslator. The approach using Locale
directly works fine.

> Do the same thing for printing stacktraces.
> Override the getLocalizedMessage() to do something appropriate (e.g.
> calling getMessage(Locale.getDefaultLocale()).
Good point!

> 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:
> base/xref/net/sf/mmm/nls/api/NlsMessageIF.html
> >
> > Cheers,
> > Daniel
> Regards
>   Jörg
> 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 -
> iD8DBQFC+kV6mPuec2Dcv/8RAjOFAJ9E/VdhaSpMxo/kduAFwtD+7ZyK0QCeP/Km
> giwovsPwiG+Bn/zVu7XlsxU=
> =Zzw1
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message