commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <>
Subject Re: [all] exceptions and localization
Date Tue, 30 Jan 2007 07:36:18 GMT
On 1/28/07, Stephen Colebourne <> 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 <> 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 :-).



> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message