So, nobody liked my idea of just providing the "data"?
On 1/30/07, James Carman <[EMAIL PROTECTED]> 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 <[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]
