You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Joerg Hohwiller <jo...@j-hohwiller.de> on 2005/08/10 18:39:30 UTC
[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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
-----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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [i18n] (was Re: [lang]/[resources]: proposal for NLS/i18n support)
Posted by Joerg Hohwiller <jo...@j-hohwiller.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Daniel, Hi i18n-*,
is this thread done or is everybody waiting for my "sunday"? ;)
I would be interested to continue the discussion.
Anyways feel free to say that this is going to far bejond the scopes
and you would like to focus strongly on the existing approach.
Regards
Jörg
Joerg Hohwiller wrote:
> Daniel Florey wrote:
>
>>>Hi Jörg,
>
> Hi Daniel,
>
>>>Thanks for your comments. See my comments inline.
>>>Cheers,
>>>Daniel
>
> Am quite busy at the moment - hope to find more time on sunday.
> Anyways some quick answers.
>
> [cut]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDOw1DmPuec2Dcv/8RAmdHAJ4quENjO0lFli63TDkl2PtbkzCtigCghmTB
LIScn8uoQ7SngFtVIjhbwV0=
=5Ncy
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: AW: [i18n] (was Re: [lang]/[resources]: proposal for NLS/i18n
support)
Posted by Joerg Hohwiller <jo...@j-hohwiller.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Daniel Florey wrote:
> Hi Jörg,
Hi Daniel,
> Thanks for your comments. See my comments inline.
> Cheers,
> Daniel
Am quite busy at the moment - hope to find more time on sunday.
Anyways some quick answers.
BTW my thunderbird is unable to quote the response properly.
I can see why... Are you using outlook?
Anyways it looks more like a problem in my mailer...
>
>
>>-----Ursprüngliche Nachricht-----
>>Von: commons-dev-return-75482-daniel.florey=web.de@jakarta.apache.org
>>[mailto:commons-dev-return-75482-daniel.florey=web.de@jakarta.apache.org]
>>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)
>>
> 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
This is what I meant - you get an exception. So its when you display the
exception message. I personally think this is not a good idea.
Think of a mission critical situation where you need to find a problem
quickly and all you get is something like "there was a servere error but
the message explaining the problem could not be nationalized to your
locale. Please switch your locale, restart the system and try to
reproduce the crash."
Sorry, I exaggerated.
>> Or
>> - Print the given default text
>> Should I make this clear in the docs?
Documenting can never be something bad :)
>
>
> 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?
Mhm. The static way of coding ties these classes tight together. There
is no way to integrate or enhance code without touching the existing
code. Thats no problem for you cause you maintain it. But imagine of
someone using you library and having a very specific need. Its hard to
find solutions where no one on earth is completely happy with it as is.
Be also aware that this singleton style static coding will always
require your code to be thread safe. Maybe a software component will be
loaded while the application is already running, but that component
wants to register his i18n messages.
Of cause you can have your code thread-safe, but you are bound.
Look for things like "singleton antipattern" on the web - I do not want
to start the IoC discussions on this list.
Join me at JContainer or got to any other IoC Container mailing list
to discuss this toppic. We do not want to get flamed here :)
>
>
> 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.
okay. we had this above. Seems I miss this scanning your code...
>
>
> - 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.
You see my approach contains an sepcific Exception class that depends on
two interfaces (NlsMessage and StringTranslator). It is very simple but
gives you the possibility to have the full power of your solution.
But since it is open using interfaces there can be a much simpler
solution and an even more powerfull one that we might not yet think of.
>
>
> 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?
Take care
Jörg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFC/PEPmPuec2Dcv/8RAnjtAJwKX9wwqrwfmwyFYhArAI2CJVHSdwCfc9kt
zwBLR+PtBgCiDN6Dk/9jOyU=
=Uo3F
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
AW: [i18n] (was Re: [lang]/[resources]: proposal for NLS/i18n support)
Posted by Daniel Florey <da...@web.de>.
Hi Jörg,
Thanks for your comments. See my comments inline.
Cheers,
Daniel
> -----Ursprüngliche Nachricht-----
> Von: commons-dev-return-75482-daniel.florey=web.de@jakarta.apache.org
> [mailto:commons-dev-return-75482-daniel.florey=web.de@jakarta.apache.org]
> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [i18n] (was Re: [lang]/[resources]: proposal for NLS/i18n support)
Posted by Joerg Hohwiller <jo...@j-hohwiller.de>.
-----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).
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 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
AW: [i18n] (was Re: [lang]/[resources]: proposal for NLS/i18n support)
Posted by Daniel Florey <da...@web.de>.
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: commons-dev-return-75478-daniel.florey=web.de@jakarta.apache.org
> [mailto:commons-dev-return-75478-daniel.florey=web.de@jakarta.apache.org]
> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
> -----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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org