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 19:44:50 GMT
So, nobody liked my idea of just providing the "data"?

On 1/30/07, James Carman <james@carmanconsulting.com> wrote:
> How about if we give the "data" for the localized message instead of
> localizing it ourselves?  I've done this for a class I call
> BusinessLogicException (used for when a user breaks a business rule
> like "already a user with that name in the system" since you would
> want to display that error message to the user).  What I did was
> create a message class like this:
>
> public class BusinessLogicException extends Exception
> {
>   private final String messageKey;
>   private final Object[] arguments;  // May have been called parameters?
>   // Constructors and getters here...
> }
>
> So, if an application wants to localize the message, they can use
> their own localization paradigm (i18n, resource bundles, Tapestry
> messages, etc.).
>
> On 1/30/07, Craig McClanahan <craigmcc@apache.org> wrote:
> > On 1/28/07, Stephen Colebourne <scolebourne@btopenworld.com> wrote:
> > >
> > > Phil Steitz wrote:
> > > > I am interested in what others have to
> > > > say about this as a general practice for commons.  For [math]
> > > specifically,
> > > > I think it is important that we can fit seamlessly into localized
> > > > applications, and we are refactoring our exceptions hierarchy anyway,
so
> > > I
> > > > say go for it.
> > >
> > > I disagree strongly with the whole concept of localized exception
> > > messages. Localization for users yes, but developers no.
> > >
> > > > On 1/28/07, Luc Maisonobe <Luc.Maisonobe@free.fr> wrote:
> > > > As a non-native english speaker, I am quite eager to provide users
> > > > with libraries that can be embedded seemlessly into localized
> > > > applications.
> > >
> > > IMO, a localized application actually means localization for users, and
> > > implies nothing for developers.
> > >
> > > Adding localized error messages is another place for the application to
> > > go wrong, so you're going to have to test this fully. After all, if you
> > > get it wrong, you could lose the real exception and just get a
> > > meaningless failed to localize exception. And thats a terrible outcome.
> > >
> > > For the record, I would -1 any code commit to add localized error
> > > messages to a component I actively commit to.
> >
> >
> > I'm late to the table on this thread, and only care about the Commons
> > libraries I care about :-), 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.
> >
> > 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.
> >
> > 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 :-).
> >
> > Stephen
> >
> >
> > Craig
> >
> >
> > ---------------------------------------------------------------------
> > > 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