Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <42FCF10F.3070404@j-hohwiller.de>
Date: Fri, 12 Aug 2005 20:57:19 +0200
From: Joerg Hohwiller <joerg@j-hohwiller.de>
User-Agent: Debian Thunderbird 1.0.2 (X11/20050331)
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: AW: [i18n] (was Re: [lang]/[resources]: proposal for NLS/i18n
 support)
References: <E1E38GH-0006D8-00@smtp07.web.de>
In-Reply-To: <E1E38GH-0006D8-00@smtp07.web.de>
OpenPGP: id=60DCBFFF
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

-----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