Well, I wouldn't even provide a getMessage(Locale). I'd leave it up to the running application to resolve the message. For instance, in Tapestry, it doesn't use resource bundles to localize messages, at least not directly in application code. It uses a special Messages object. So, I would provide getKey()/getParameters() methods only and leave it up to the containing application to localize the text. That way, they can give some context to the error message instead of relying upon us to be general enough.
On 2/3/07, Niall Pemberton <[EMAIL PROTECTED]> wrote:
On 2/3/07, Phil Steitz <[EMAIL PROTECTED]> wrote: > On 1/30/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > Craig McClanahan wrote: > > > > > > > I'm late to the table on this thread, and only care about the Commons > > > libraries I care about :-) > > > > Thanks for your interest in this thread. > > > > > but you should be aware that this attitude will > > > disqualify the use of such libraries from use within code from > > organizations > > > that have strict rules about implementing localization. I work for such > > an > > > organization (Sun) ... the key rules are that any message that might be > > > visible to users *must* be localizable. > > > > I agree with you and thought localization should be provided by the layer > > which > > provides the message. Other people think this should be done at > > application > > level, if done at all. > > > > > For log messages, that tends to translate into a straightforward policy > > that > > > DEBUG and TRACE type messages do not need to be localized, but anything > > from > > > INFO level above must be. The issue for exception messages is a bit > > more > > > interesting. How does the library developer know whether or not the > > message > > > part of the exception will be displayed to end users? From a pragmatic > > > viewpoint, you can pretty much assume this will happen with exceptions > > in > > > webapps, while many Swing apps will hide that sort of stuff to some > > degree. > > > > I think that since low level components may be used almost anywhere, their > > messages *may* be displayed and this sole possibility is enough to justify > > a > > localized version should be made available. If the application gets an > > error it > > really doesn't know about, it can simply display it. > > > > > But, as a bottom line, if I'm interested in maximum adoption of a > > Commons > > > library I work on, I will diligently ensure that exception messages are > > > localizable :-). > > > > When I first started this long thread, I thought the need for localized > > error > > messages as provided by exceptions was acknowledged by everyone and asked > > for > > the way to implement it, starting from a simple one which already works. I > > was > > wrong. The disagreement started about the need itself and slipped to the > > level > > at which implementation should be done. > > > > I would really like to reach a compromise on this issue, something that > > could by > > accepted by everybody. I don't want to get banned with a -1 on a commit, > > but at > > least a few people would like localized error messages that can be simply > > forwarded upward from lower layers to upper layer for display without > > processing. Standard java already provides Throwable.getLocalizedMessage() > > since > > JDK 1.1. I could set up for [math] only an exception hierarchy that only > > add a > > few constructors and an implementation of this method without any change > > in the > > Throwable.getMessage() behaviour. Does this sound reasonable ? > > > Sorry I was out of pocket this week and could not reiterate my personal +1 > for moving forward as you suggest, Luc. I will add a few of more comments > below. If anyone still has serious reservations - especially those who now > or in the future may contribute to [math] - pls speak up; otherwise we can > move on. Thanks to all who provided comments. > > 1) My initial +1 was based on the fact that the error management that you > need to support this approach is in fact there in Mantissa and if you > *don't* support localization when text is being generated, you either need > to get into nonsense like parsing and translating error messages, > complicating your exceptions hierarchy, or losing/hiding information at > higher levels. If you do the work to localize when the string is generated, > that gives a choice at higher levels, which to me is goodness (assuming you > are prepared to do the work and the implementation is robust against missing > bundles, etc.). > > 2) Commons math generates error messages now, and should generate better > messages (as Mantissa does) in the future that using applications may want > to display to end users or in application logs. I would like for those > messages to be localizable. If one of our solvers does not converge because > initial values do not bracket a root, for example, I would like the > developer of a localized client application that uses the solver to be able > to display that message directly in a log or to the user. Whether or not > logging is good or bad is completely irrelevant to this discussion. > > 3) Apache is a do-ocracy and we have a proposal before us to significantly > improve exception management and error reporting in [math] by extending and > leveraging the framework in Mantissa. Luc is volunteering to do this and > the only other active contributor to [math] who has chimed in (yours truly) > is also in favor. The arguments against are either it is too much work to > implement exception error message localization or it may not be robust. Luc > is stepping up to *do* the work (actually, leverage work already mostly done > in Mantissa) and I don't see robustness or performance risk in what he has > implemented. Pls speak up if I am missing something in the latter case. > Therefore, appreciating the feedback from others and reservations about > applying across commons, for [math] we should let Luc JFDI - i.e., move > forward with the proposal. +1 to those that do the work decide the direction. The only comment I would make is that there are two scenarios for application localization in terms of the user - single or multiple. Single being your application runs in one Locale only and multiple where you have users with different Locale. If you want to cater for the later then the exceptions should contain keys/replacement values and message be resolved when the user's Locale is known - which I think is James Carman's suggestion. Messages could be resolved outside of Math or you could provide a getMessage(Locale) method in your exceptions. Niall > Thanks again, all, for this interesting discussion and thanks, Luc, for > helping make [math] more localization-friendly. > > Phil > > Luc --------------------------------------------------------------------- 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]
