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 <[EMAIL PROTECTED]> wrote:
On 1/28/07, Stephen Colebourne <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
