commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <ja...@carmanconsulting.com>
Subject Re: [all] exceptions and localization
Date Sat, 03 Feb 2007 21:03:15 GMT
How does a calling application override the message, if they wish?

On 2/3/07, Phil Steitz <phil.steitz@gmail.com> wrote:
> On 2/3/07, James Carman <james@carmanconsulting.com> 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 <niall.pemberton@gmail.com> wrote:
> > > On 2/3/07, Phil Steitz <phil.steitz@gmail.com> wrote:
> > > > On 1/30/07, luc.maisonobe@free.fr <luc.maisonobe@free.fr> 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: 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
> >
> >
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message