How does a calling application override the message, if they wish?
On 2/3/07, Phil Steitz <[EMAIL PROTECTED]> wrote:
On 2/3/07, James Carman <[EMAIL PROTECTED]> wrote: > > 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. The problem with that is that generic handlers that display messages would not work. I like the idea of carrying the data along, though and exposing it, as well as providing translate (see http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/src/mantissa/src/org/spaceroots/mantissa/MantissaException.java?view=markup ) and getMessage(Locale) methods. That gives client apps the most flexibility. What do you think, Luc? Phil 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] > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
