Hi Jörg, 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.
Cheers, Daniel > -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Im Auftrag von Joerg Hohwiller > Gesendet: Mittwoch, 10. August 2005 18:40 > An: Jakarta Commons Developers List > Betreff: [i18n] (was Re: [lang]/[resources]: proposal for NLS/i18n support) > > -----BEGIN PGP SIGNED MESSAGE----- > 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 > org.apache.commons.i18n.bundles.MessageBundle > org.apache.commons.i18n.LocalizedException > > 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 > Jörg > > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFC+i3CmPuec2Dcv/8RAiA7AKCKcwkcTj5rM3KwxX1EgfEuU6cR0wCdFjfX > 18OUcY1tpH9GBVsoeRlt6wU= > =k8fq > -----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]
