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 Tue, 30 Jan 2007 12:43:05 GMT
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