Hi Jörg, Thanks for your comments. See my comments inline. Cheers, Daniel > -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > 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) > > -----BEGIN PGP SIGNED MESSAGE----- > 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 Or - 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 why? > > 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? > > 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 sf.net does not get their svn service ready. > Anyways better than nothing: > > http://m-m-m.sourceforge.net/mmm-base/xref/index.html > http://m-m-m.sourceforge.net/mmm- > 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? > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFC+kV6mPuec2Dcv/8RAjOFAJ9E/VdhaSpMxo/kduAFwtD+7ZyK0QCeP/Km > giwovsPwiG+Bn/zVu7XlsxU= > =Zzw1 > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
