You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Luc Maisonobe <Lu...@free.fr> on 2007/01/28 13:33:23 UTC
[all] exceptions and localization
Hello,
As a non-native english speaker, I am quite eager to provide users with
libraries that can be embedded seemlessly into localized applications.
This implies that either the getMessage() and getLocalizedMessages() of
Exception instances provide two different messages, or that the
getMessage() already provides an localized message. In either case,
since some messages have both fixed parts and variable parts, some
localization layer should be used at the time of Exception creation,
i.e. in the commons components themselves.
I am willing to implement that for [math] (prior to retrofit the
Mantissa packages already selected), and was wondering how this is
handled by other components. The only two things I found were the
Fulcrum Localization Component in Turbine and the I18n component in sandbox.
I think building localized error messages is important so I would like
to change the current practice.
The first question I ask is what localization framework should be used
for that: standard java, i18n in sandbox, fulcrum localization ? My
personal choice would be standard java with embedded property files
(PropertyResourceBundle) first and i18n from sandbox second as I don't
want to add new dependencies to [math] and if a dependency is added it
should belong to commons obeying [math] proposal.
The second question I ask is at which stage should the localization
layer be triggered: before creating the exception or inside the
exception constructors ? My personal choice as implemented in Mantissa
is depicted in the example at the bottom of this message. It only adds
new constructors, thus allowing smooth transition towards providing
fully localized components with variable parts messages. I think it is
compatible with java 1.3 (but am not sure). From the user points of
view, the messages will be already localized in the getMessage() method,
however it is quite easy to change this implementation to provide both
english and localized messages.
What do you think about it ?
Luc
public class SomeException
extends Exception {
private static ResourceBundle resources =
ResourceBundle.getBundle("org.apache.commons.some.ExceptionsResources");
/** Translate a string. */
public static String translate(String s) {
try {
return resources.getString(s);
} catch (MissingResourceException mre) {
return s;
}
}
/** Translate a message. */
public static String translate(String specifier, String[] parts) {
return new MessageFormat(translate(specifier)).format(parts);
}
/* some more traditional constructors go there, with message
* only, or message and cause ...
*/
/** Simple constructor. */
public SomeException(String specifier, String[] parts) {
super(translate(specifier, parts));
}
}
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Latest Commons-Net 2.0 RC ready
Posted by Rory Winston <rw...@eircom.net>.
Hi all
I have cut a new RC, with some changes and fixes, many of which were
distribution-related and suggested by Niall earlier (thanks Niall).
RC (minus MD5s etc for now) is here:
http://people.apache.org/~rwinston/commons-net-2.0/
Some users have been testing out this 2.0 branch for a while, so I'm
going to kick off a vote pretty soon.
Any comments welcome.
Cheers
Rory
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] exceptions and localization
Posted by Henri Yandell <fl...@gmail.com>.
On 1/28/07, Stephen Colebourne <sc...@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.
Java's cool in that you could code much of it in a localized way, but
our libraries are generally all written for US-English. If we're
expecting the developers to be able to read our methods and Javadoc, I
don't see why we can't expect them to read the error messages too.
So I'm in agreement with Stephen. Users need it, developers don't for
the large majority of our components.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] exceptions and localization
Posted by Luc Maisonobe <Lu...@free.fr>.
Stephen Colebourne a écrit :
> I disagree strongly with the whole concept of localized exception
> messages. Localization for users yes, but developers no.
[snip]
> IMO, a localized application actually means localization for users, and
> implies nothing for developers.
I agree with both your rationale and your conclusion, but not with the
implications. For me, error messages are users oriented, not developers
oriented.
Here are the few rules experience has teached me in the past 20 years:
- error messages should be meaningful to end users who do not
know the application design
- meaningful error messages should include references to run time
data, not only a fixed message. For example if a file access fails,
I want both the name of the file and the reason (file not found,
permission denied ...)
- the previous item implies that error messages should be set up in the
lowest layers where the information is available
- an error at low level can be worked around at an upper level, or
dismissed or displayed thanks to an application-dependent medium.
Hence the message fate should be handled in the highest layer
(aplication)
- errors semantics may change as they bubble up through the layers. A
critical error in a low level algorithm (say no solution to some
problem) may be considered only as an end condition in some
intermediate search loop or even be the result that was seeked (I
used that operationally for years in order to compute launch windows
for satellites)
- as errors semantics change along their path through the middle
layers, the error message may be reset to become more user-friendly
if needed. For example "no solution found in the [0.2 0.7] interval"
may become "attitude constraints not fulfilled for launch date
2007-01-28T21:39:45Z".
- exceptions are great for handling the four previous items (creation
in the low layers, decision in the high layers, interception in
the middle layers, wrapping within other exceptions if needed)
- developer-oriented information is not a substitute to user-oriented
error handling. If only one is set up, it should be the user-oriented
one
- developer-oriented information should not be pushed in front of users
- developer-oriented information may be put in log files for later
analysis
If I understand your remark correctly, you do make the same strong
difference between users and developers, but you seem to consider
exceptions are for the latters. What do you provide to the formers for
error messages ? And to what purpose do you use logging ?
> 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.
You are right. In the current Mantissa codebase, I used the english
error message format as the key to find the translation and use it
directly if no translation is found for that key. If some resource file
gets outdated, the end user will end up with an untranslated message,
which is a somewhat fail-safe behaviour. It's not perfect, for sure, but
it is quite efficient.
> For the record, I would -1 any code commit to add localized error
> messages to a component I actively commit to.
So we really have to sort out this issue before I start any work about
it, regardless of the fact that you commit or not to [math]. Your
opposition is strong enough and shows there is a serious
misunderstanding between us that must be ironed out.
Luc
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] exceptions and localization
Posted by James Carman <ja...@carmanconsulting.com>.
So, nobody liked my idea of just providing the "data"?
On 1/30/07, James Carman <ja...@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 <cr...@apache.org> wrote:
> > On 1/28/07, Stephen Colebourne <sc...@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 <Lu...@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
Re: [all] exceptions and localization
Posted by James Carman <ja...@carmanconsulting.com>.
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 <cr...@apache.org> wrote:
> On 1/28/07, Stephen Colebourne <sc...@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 <Lu...@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
Re: [all] exceptions and localization
Posted by Phil Steitz <ph...@gmail.com>.
On 2/3/07, James Carman <ja...@carmanconsulting.com> wrote:
>
> How would they subclass? The commons math code will be throwing these
> exceptions themselves, no? They wouldn't be able to tell commons math
> to throw a specific type of exception class that they wrote.
Yes, you're right.
I agree that the default case (the JDK's getMessage() method) should
> work so that nobody has to know about the special i18n facilities.
> But, if you're truly looking to provide a rich i18n framework for
> exceptions, you need to make it extensible/adaptable.
I think exposing the key and parts and adding getMessage(Locale) is probably
good enough.
Phil
Re: [all] exceptions and localization
Posted by James Carman <ja...@carmanconsulting.com>.
How would they subclass? The commons math code will be throwing these
exceptions themselves, no? They wouldn't be able to tell commons math
to throw a specific type of exception class that they wrote.
I agree that the default case (the JDK's getMessage() method) should
work so that nobody has to know about the special i18n facilities.
But, if you're truly looking to provide a rich i18n framework for
exceptions, you need to make it extensible/adaptable.
On 2/3/07, Phil Steitz <ph...@gmail.com> wrote:
> On 2/3/07, James Carman <ja...@carmanconsulting.com> wrote:
> >
> > How does a calling application override the message, if they wish?
>
>
> They could subclass and override translate() or, assuming we take your
> suggestion and carry the data along, they could access the data and do
> whatever they want with it. I agree that it is a good idea to persist and
> expose the key and parts. I just also think it is good for getMessage() and
> getMessage(Locale) to provide default localization out of the box.
>
> Phil
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] exceptions and localization
Posted by Phil Steitz <ph...@gmail.com>.
On 2/3/07, James Carman <ja...@carmanconsulting.com> wrote:
>
> How does a calling application override the message, if they wish?
They could subclass and override translate() or, assuming we take your
suggestion and carry the data along, they could access the data and do
whatever they want with it. I agree that it is a good idea to persist and
expose the key and parts. I just also think it is good for getMessage() and
getMessage(Locale) to provide default localization out of the box.
Phil
Re: [all] exceptions and localization
Posted by James Carman <ja...@carmanconsulting.com>.
How does a calling application override the message, if they wish?
On 2/3/07, Phil Steitz <ph...@gmail.com> wrote:
> On 2/3/07, James Carman <ja...@carmanconsulting.com> wrote:
> >
> > Well, I wouldn't even provide a getMessage(Locale). I'd leave it up
> > to the running application to resolve the message. For instance, in
> > Tapestry, it doesn't use resource bundles to localize messages, at
> > least not directly in application code. It uses a special Messages
> > object. So, I would provide getKey()/getParameters() methods only and
> > leave it up to the containing application to localize the text. That
> > way, they can give some context to the error message instead of
> > relying upon us to be general enough.
>
>
> The problem with that is that generic handlers that display messages would
> not work. I like the idea of carrying the data along, though and exposing
> it, as well as providing translate (see
> http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/src/mantissa/src/org/spaceroots/mantissa/MantissaException.java?view=markup
> )
> and getMessage(Locale) methods. That gives client apps the most
> flexibility. What do you think, Luc?
>
> Phil
>
> On 2/3/07, Niall Pemberton <ni...@gmail.com> wrote:
> > > On 2/3/07, Phil Steitz <ph...@gmail.com> wrote:
> > > > On 1/30/07, luc.maisonobe@free.fr <lu...@free.fr> wrote:
> > > > >
> > > > > Craig McClanahan wrote:
> > > > >
> > > > >
> > > > > > I'm late to the table on this thread, and only care about the
> > Commons
> > > > > > libraries I care about :-)
> > > > >
> > > > > Thanks for your interest in this thread.
> > > > >
> > > > > > 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.
> > > > >
> > > > > I agree with you and thought localization should be provided by the
> > layer
> > > > > which
> > > > > provides the message. Other people think this should be done at
> > > > > application
> > > > > level, if done at all.
> > > > >
> > > > > > 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.
> > > > >
> > > > > I think that since low level components may be used almost anywhere,
> > their
> > > > > messages *may* be displayed and this sole possibility is enough to
> > justify
> > > > > a
> > > > > localized version should be made available. If the application gets
> > an
> > > > > error it
> > > > > really doesn't know about, it can simply display it.
> > > > >
> > > > > > 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 :-).
> > > > >
> > > > > When I first started this long thread, I thought the need for
> > localized
> > > > > error
> > > > > messages as provided by exceptions was acknowledged by everyone and
> > asked
> > > > > for
> > > > > the way to implement it, starting from a simple one which already
> > works. I
> > > > > was
> > > > > wrong. The disagreement started about the need itself and slipped to
> > the
> > > > > level
> > > > > at which implementation should be done.
> > > > >
> > > > > I would really like to reach a compromise on this issue, something
> > that
> > > > > could by
> > > > > accepted by everybody. I don't want to get banned with a -1 on a
> > commit,
> > > > > but at
> > > > > least a few people would like localized error messages that can be
> > simply
> > > > > forwarded upward from lower layers to upper layer for display
> > without
> > > > > processing. Standard java already provides
> > Throwable.getLocalizedMessage()
> > > > > since
> > > > > JDK 1.1. I could set up for [math] only an exception hierarchy that
> > only
> > > > > add a
> > > > > few constructors and an implementation of this method without any
> > change
> > > > > in the
> > > > > Throwable.getMessage() behaviour. Does this sound reasonable ?
> > > >
> > > >
> > > > Sorry I was out of pocket this week and could not reiterate my
> > personal +1
> > > > for moving forward as you suggest, Luc. I will add a few of more
> > comments
> > > > below. If anyone still has serious reservations - especially those
> > who now
> > > > or in the future may contribute to [math] - pls speak up; otherwise
> > we can
> > > > move on. Thanks to all who provided comments.
> > > >
> > > > 1) My initial +1 was based on the fact that the error management that
> > you
> > > > need to support this approach is in fact there in Mantissa and if you
> > > > *don't* support localization when text is being generated, you either
> > need
> > > > to get into nonsense like parsing and translating error messages,
> > > > complicating your exceptions hierarchy, or losing/hiding information
> > at
> > > > higher levels. If you do the work to localize when the string is
> > generated,
> > > > that gives a choice at higher levels, which to me is goodness
> > (assuming you
> > > > are prepared to do the work and the implementation is robust against
> > missing
> > > > bundles, etc.).
> > > >
> > > > 2) Commons math generates error messages now, and should generate
> > better
> > > > messages (as Mantissa does) in the future that using applications may
> > want
> > > > to display to end users or in application logs. I would like for
> > those
> > > > messages to be localizable. If one of our solvers does not converge
> > because
> > > > initial values do not bracket a root, for example, I would like the
> > > > developer of a localized client application that uses the solver to be
> > able
> > > > to display that message directly in a log or to the user. Whether or
> > not
> > > > logging is good or bad is completely irrelevant to this discussion.
> > > >
> > > > 3) Apache is a do-ocracy and we have a proposal before us to
> > significantly
> > > > improve exception management and error reporting in [math] by
> > extending and
> > > > leveraging the framework in Mantissa. Luc is volunteering to do this
> > and
> > > > the only other active contributor to [math] who has chimed in (yours
> > truly)
> > > > is also in favor. The arguments against are either it is too much
> > work to
> > > > implement exception error message localization or it may not be
> > robust. Luc
> > > > is stepping up to *do* the work (actually, leverage work already
> > mostly done
> > > > in Mantissa) and I don't see robustness or performance risk in what he
> > has
> > > > implemented. Pls speak up if I am missing something in the latter
> > case.
> > > > Therefore, appreciating the feedback from others and reservations
> > about
> > > > applying across commons, for [math] we should let Luc JFDI - i.e.,
> > move
> > > > forward with the proposal.
> > >
> > > +1 to those that do the work decide the direction.
> > >
> > > The only comment I would make is that there are two scenarios for
> > > application localization in terms of the user - single or multiple.
> > > Single being your application runs in one Locale only and multiple
> > > where you have users with different Locale. If you want to cater for
> > > the later then the exceptions should contain keys/replacement values
> > > and message be resolved when the user's Locale is known - which I
> > > think is James Carman's suggestion. Messages could be resolved outside
> > > of Math or you could provide a getMessage(Locale) method in your
> > > exceptions.
> > >
> > > Niall
> > >
> > > > Thanks again, all, for this interesting discussion and thanks, Luc,
> > for
> > > > helping make [math] more localization-friendly.
> > > >
> > > > Phil
> > > >
> > > > Luc
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] exceptions and localization
Posted by James Carman <ja...@carmanconsulting.com>.
Why not getMessage(ResourceBundle) so that the client apps can use
their own resource bundle if they wish? Or, provide a common
interface and "adaptors" that adapt different i18n mechanisms to your
paradigm. So, you'd have:
String getMessage( MessageSource src );
And, you'd have different "flavors" of MessageSource, one for
ResourceBundles, one for HiveMind messages, one for commons i18n, etc.
On 2/3/07, Phil Steitz <ph...@gmail.com> wrote:
> On 2/3/07, James Carman <ja...@carmanconsulting.com> wrote:
> >
> > Well, I wouldn't even provide a getMessage(Locale). I'd leave it up
> > to the running application to resolve the message. For instance, in
> > Tapestry, it doesn't use resource bundles to localize messages, at
> > least not directly in application code. It uses a special Messages
> > object. So, I would provide getKey()/getParameters() methods only and
> > leave it up to the containing application to localize the text. That
> > way, they can give some context to the error message instead of
> > relying upon us to be general enough.
>
>
> The problem with that is that generic handlers that display messages would
> not work. I like the idea of carrying the data along, though and exposing
> it, as well as providing translate (see
> http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/src/mantissa/src/org/spaceroots/mantissa/MantissaException.java?view=markup
> )
> and getMessage(Locale) methods. That gives client apps the most
> flexibility. What do you think, Luc?
>
> Phil
>
> On 2/3/07, Niall Pemberton <ni...@gmail.com> wrote:
> > > On 2/3/07, Phil Steitz <ph...@gmail.com> wrote:
> > > > On 1/30/07, luc.maisonobe@free.fr <lu...@free.fr> wrote:
> > > > >
> > > > > Craig McClanahan wrote:
> > > > >
> > > > >
> > > > > > I'm late to the table on this thread, and only care about the
> > Commons
> > > > > > libraries I care about :-)
> > > > >
> > > > > Thanks for your interest in this thread.
> > > > >
> > > > > > 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.
> > > > >
> > > > > I agree with you and thought localization should be provided by the
> > layer
> > > > > which
> > > > > provides the message. Other people think this should be done at
> > > > > application
> > > > > level, if done at all.
> > > > >
> > > > > > 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.
> > > > >
> > > > > I think that since low level components may be used almost anywhere,
> > their
> > > > > messages *may* be displayed and this sole possibility is enough to
> > justify
> > > > > a
> > > > > localized version should be made available. If the application gets
> > an
> > > > > error it
> > > > > really doesn't know about, it can simply display it.
> > > > >
> > > > > > 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 :-).
> > > > >
> > > > > When I first started this long thread, I thought the need for
> > localized
> > > > > error
> > > > > messages as provided by exceptions was acknowledged by everyone and
> > asked
> > > > > for
> > > > > the way to implement it, starting from a simple one which already
> > works. I
> > > > > was
> > > > > wrong. The disagreement started about the need itself and slipped to
> > the
> > > > > level
> > > > > at which implementation should be done.
> > > > >
> > > > > I would really like to reach a compromise on this issue, something
> > that
> > > > > could by
> > > > > accepted by everybody. I don't want to get banned with a -1 on a
> > commit,
> > > > > but at
> > > > > least a few people would like localized error messages that can be
> > simply
> > > > > forwarded upward from lower layers to upper layer for display
> > without
> > > > > processing. Standard java already provides
> > Throwable.getLocalizedMessage()
> > > > > since
> > > > > JDK 1.1. I could set up for [math] only an exception hierarchy that
> > only
> > > > > add a
> > > > > few constructors and an implementation of this method without any
> > change
> > > > > in the
> > > > > Throwable.getMessage() behaviour. Does this sound reasonable ?
> > > >
> > > >
> > > > Sorry I was out of pocket this week and could not reiterate my
> > personal +1
> > > > for moving forward as you suggest, Luc. I will add a few of more
> > comments
> > > > below. If anyone still has serious reservations - especially those
> > who now
> > > > or in the future may contribute to [math] - pls speak up; otherwise
> > we can
> > > > move on. Thanks to all who provided comments.
> > > >
> > > > 1) My initial +1 was based on the fact that the error management that
> > you
> > > > need to support this approach is in fact there in Mantissa and if you
> > > > *don't* support localization when text is being generated, you either
> > need
> > > > to get into nonsense like parsing and translating error messages,
> > > > complicating your exceptions hierarchy, or losing/hiding information
> > at
> > > > higher levels. If you do the work to localize when the string is
> > generated,
> > > > that gives a choice at higher levels, which to me is goodness
> > (assuming you
> > > > are prepared to do the work and the implementation is robust against
> > missing
> > > > bundles, etc.).
> > > >
> > > > 2) Commons math generates error messages now, and should generate
> > better
> > > > messages (as Mantissa does) in the future that using applications may
> > want
> > > > to display to end users or in application logs. I would like for
> > those
> > > > messages to be localizable. If one of our solvers does not converge
> > because
> > > > initial values do not bracket a root, for example, I would like the
> > > > developer of a localized client application that uses the solver to be
> > able
> > > > to display that message directly in a log or to the user. Whether or
> > not
> > > > logging is good or bad is completely irrelevant to this discussion.
> > > >
> > > > 3) Apache is a do-ocracy and we have a proposal before us to
> > significantly
> > > > improve exception management and error reporting in [math] by
> > extending and
> > > > leveraging the framework in Mantissa. Luc is volunteering to do this
> > and
> > > > the only other active contributor to [math] who has chimed in (yours
> > truly)
> > > > is also in favor. The arguments against are either it is too much
> > work to
> > > > implement exception error message localization or it may not be
> > robust. Luc
> > > > is stepping up to *do* the work (actually, leverage work already
> > mostly done
> > > > in Mantissa) and I don't see robustness or performance risk in what he
> > has
> > > > implemented. Pls speak up if I am missing something in the latter
> > case.
> > > > Therefore, appreciating the feedback from others and reservations
> > about
> > > > applying across commons, for [math] we should let Luc JFDI - i.e.,
> > move
> > > > forward with the proposal.
> > >
> > > +1 to those that do the work decide the direction.
> > >
> > > The only comment I would make is that there are two scenarios for
> > > application localization in terms of the user - single or multiple.
> > > Single being your application runs in one Locale only and multiple
> > > where you have users with different Locale. If you want to cater for
> > > the later then the exceptions should contain keys/replacement values
> > > and message be resolved when the user's Locale is known - which I
> > > think is James Carman's suggestion. Messages could be resolved outside
> > > of Math or you could provide a getMessage(Locale) method in your
> > > exceptions.
> > >
> > > Niall
> > >
> > > > Thanks again, all, for this interesting discussion and thanks, Luc,
> > for
> > > > helping make [math] more localization-friendly.
> > > >
> > > > Phil
> > > >
> > > > Luc
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] exceptions and localization
Posted by James Carman <ja...@carmanconsulting.com>.
I agree with Stephen that the commons libraries probably don't need
this type of support. They aren't doing anything that's "businessy"
enough (and they're not supposed to) to make it relevant to the user
(the user doesn't care that I'm using StringUtils to eat the white
space out of a String). My point was that if you *are* going to do
it, at least make it easy to extend/adapt.
I don't necessarily agree that the exceptions aren't used to convey
information to the user. As I've said, I use a BusinessLogicException
class in my code sometimes. I do this so that I don't have to come up
with many different exception types (UsernameAlreadyExistsException,
InsufficientFundsException, etc.) that really add no logic, but just
let me know something different is going on. I can use localized
messages for that case.
On 2/4/07, Stephen Colebourne <sc...@btopenworld.com> wrote:
> I'm sorry, but I find this extremely complicated and unreasonable. It
> really, really, really isn't a direction I want commons to take.
>
> Firstly, the use of a static will annoy the IoC (Spring) crowd, so that
> aspect of the proposal seems flawed.
>
> Secondly, this proposes adding a whole ream of new interfaces, classes,
> resources, factories and strategies to achieve this. All of this
> additional code will need to be documented in detail, with explanations
> of how to customise each part.
>
> Thirdly, we can be sure that you haven't met all the weird requirements
> that the users of the library will come up with. They will start asking
> for changes which will add even more bloat.
>
> Fourthly, since none of this is standard, each commons library will
> probably do it slightly differently, making using all of them together
> nigh on impossible.
>
>
> Let me be clear, this is a (mostly) well-designed solution to the
> perceived set of requirements. Its just that the requirements are in my
> view completely inappropriate.
>
> Exceptions are a programming tool. They are used by developers. They are
> not intended for user interaction. Ever.
>
> Adding ANY kind of localization behaviour to [math] or any other commons
> component is completely OUT OF SCOPE!!! [math] is a library of
> mathematics routines. Under no circumstances should I need to know or
> learn or have to worry about this or that localized configuration.
> Localization is completely orthogonal to the concept of well-tested
> robust mathematical routines.
>
> Finally, what is being proposed here is the creation of a FRAMEWORK. I
> am so opposed to this because I believe it is the antithesis of what the
> best commons components are, which is LIBRARIES.
>
> A library is simple. It does what it says it does. Without complication
> or need to buy into its specific religion.
>
> A framework is religious. You have to agree to its terms, and its way of
> doing things. Or choose not to use it.
>
> Commons has done pretty well in resisting the complications and
> religions of frameworks - we are a repository of libraries.
>
>
> So, what is appropriate?
>
> It is good to have multiple different exception classes, even as many as
> one for each different possible error.
>
> It is also good for those classes to store the data that caused the
> error as instance variables accessed by get methods.
> (http://joda-time.sourceforge.net/xref/org/joda/time/IllegalFieldValueException.html)
>
> But they should only have one error message, and no way to localize it
> (ie. there should be no error code for looking up resources). That is
> the role of the application/framework that embeds the library - and it
> can use the exception classname and get methods to access the data if
> required. Why? because every application/framework that does want to
> localize wants to do it differently. And in all probability, 90%+ of
> applications/frameworks don't want to localize at all.
>
> Stephen
>
>
> Luc Maisonobe wrote:
> > Two main classes would be used: the MathException base class and a
> > MessageFactory base class. MathException would delegate to
> > MessageFactory the task to build the message from its String key and
> > Object[] parameters (point 2). Both the key, parameters and message
> > would be available with appropriate getters (point 4 and 5). A static
> > method in MathException would allow upper layers to prepend a customized
> > MessageFactory instance (point 1) in front of already registered
> > factories following a chain of responsibility. The initial chain would
> > contain three different MessageFactory instances :
> > - a LocalizedMessageFactory using the key to retrieve a pattern from
> > a ResourceBundle for the default Locale (Locale.geDefault()) and
> > MessageFormat to build the message (point 3)
> > - a NonLocalizedMessageFactory using the key directly as a pattern
> > for MessageFormat
> > - a RawMessageFormat simply concatenating everything with toString
> >
> > The chain of responsibility is intended to provide robustness (point 6):
> > the first message factory providing a non null message is used. If a
> > factory fails, the next one is used. The last factory cannot fail.
> >
> > A user who simply wants to get messages localized for a Locale which is
> > not the default one would therefore only need to do :
> >
> > MathException.prependMessageFactory(new
> > LocalizedMessageFactory(myLocale));
> >
> > This would work even if its locale is not supported as its factory would
> > always fail but the following ones would be triggered as needed.
> >
> > I think an appropriate policy would be to always use US-english patterns
> > as keys as it would allow to get meaningful messages even if everything
> > else fails, and as it would help the translators tasks.
>
> ---------------------------------------------------------------------
> 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
Re: [all] exceptions and localization
Posted by Stephen Colebourne <sc...@btopenworld.com>.
I'm sorry, but I find this extremely complicated and unreasonable. It
really, really, really isn't a direction I want commons to take.
Firstly, the use of a static will annoy the IoC (Spring) crowd, so that
aspect of the proposal seems flawed.
Secondly, this proposes adding a whole ream of new interfaces, classes,
resources, factories and strategies to achieve this. All of this
additional code will need to be documented in detail, with explanations
of how to customise each part.
Thirdly, we can be sure that you haven't met all the weird requirements
that the users of the library will come up with. They will start asking
for changes which will add even more bloat.
Fourthly, since none of this is standard, each commons library will
probably do it slightly differently, making using all of them together
nigh on impossible.
Let me be clear, this is a (mostly) well-designed solution to the
perceived set of requirements. Its just that the requirements are in my
view completely inappropriate.
Exceptions are a programming tool. They are used by developers. They are
not intended for user interaction. Ever.
Adding ANY kind of localization behaviour to [math] or any other commons
component is completely OUT OF SCOPE!!! [math] is a library of
mathematics routines. Under no circumstances should I need to know or
learn or have to worry about this or that localized configuration.
Localization is completely orthogonal to the concept of well-tested
robust mathematical routines.
Finally, what is being proposed here is the creation of a FRAMEWORK. I
am so opposed to this because I believe it is the antithesis of what the
best commons components are, which is LIBRARIES.
A library is simple. It does what it says it does. Without complication
or need to buy into its specific religion.
A framework is religious. You have to agree to its terms, and its way of
doing things. Or choose not to use it.
Commons has done pretty well in resisting the complications and
religions of frameworks - we are a repository of libraries.
So, what is appropriate?
It is good to have multiple different exception classes, even as many as
one for each different possible error.
It is also good for those classes to store the data that caused the
error as instance variables accessed by get methods.
(http://joda-time.sourceforge.net/xref/org/joda/time/IllegalFieldValueException.html)
But they should only have one error message, and no way to localize it
(ie. there should be no error code for looking up resources). That is
the role of the application/framework that embeds the library - and it
can use the exception classname and get methods to access the data if
required. Why? because every application/framework that does want to
localize wants to do it differently. And in all probability, 90%+ of
applications/frameworks don't want to localize at all.
Stephen
Luc Maisonobe wrote:
> Two main classes would be used: the MathException base class and a
> MessageFactory base class. MathException would delegate to
> MessageFactory the task to build the message from its String key and
> Object[] parameters (point 2). Both the key, parameters and message
> would be available with appropriate getters (point 4 and 5). A static
> method in MathException would allow upper layers to prepend a customized
> MessageFactory instance (point 1) in front of already registered
> factories following a chain of responsibility. The initial chain would
> contain three different MessageFactory instances :
> - a LocalizedMessageFactory using the key to retrieve a pattern from
> a ResourceBundle for the default Locale (Locale.geDefault()) and
> MessageFormat to build the message (point 3)
> - a NonLocalizedMessageFactory using the key directly as a pattern
> for MessageFormat
> - a RawMessageFormat simply concatenating everything with toString
>
> The chain of responsibility is intended to provide robustness (point 6):
> the first message factory providing a non null message is used. If a
> factory fails, the next one is used. The last factory cannot fail.
>
> A user who simply wants to get messages localized for a Locale which is
> not the default one would therefore only need to do :
>
> MathException.prependMessageFactory(new
> LocalizedMessageFactory(myLocale));
>
> This would work even if its locale is not supported as its factory would
> always fail but the following ones would be triggered as needed.
>
> I think an appropriate policy would be to always use US-english patterns
> as keys as it would allow to get meaningful messages even if everything
> else fails, and as it would help the translators tasks.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] exceptions and localization
Posted by Luc Maisonobe <Lu...@free.fr>.
Phil Steitz wrote :
> My recommendation is that we just modify the Mantissa class to
> expose the key and parts (so add members for them) and add
> getMessage(Locale). That is simple, not far from what we already have, and
> sufficient to meet localization needs and support other sorts of processing
> for clients who want to do that.
OK. I'll do that.
Luc
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] exceptions and localization
Posted by Phil Steitz <ph...@gmail.com>.
On 2/4/07, Luc Maisonobe <Lu...@free.fr> wrote:
>
> Phil Steitz wrote :
> >
> > The problem with that is that generic handlers that display messages
> would
> > not work. I like the idea of carrying the data along, though and
> exposing
> > it, as well as providing translate (see
> >
> http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/src/mantissa/src/org/spaceroots/mantissa/MantissaException.java?view=markup
> >
> >
> > )
> > and getMessage(Locale) methods. That gives client apps the most
> > flexibility. What do you think, Luc?
>
> Trying to synthetize all use cases, here is what I think is expected by
> everyone who has expressed views :
>
> 1) allow application level code to contribute to/configure message
> building
> 2) allow low layers to build messages with variable parts
> 3) allow localized messages
> 4) expose message parts (key and parameters)
> 5) allow handlers using only no arguments getMessage() to work as usual
> 6) use a mechanism robust enough to work even in case of code changes
> and missing localization data (of course in degraded, i.e. non
> localized
> mode)
>
> The following proposal is an attempt to address all these points.
>
> Two main classes would be used: the MathException base class and a
> MessageFactory base class. MathException would delegate to
> MessageFactory the task to build the message from its String key and
> Object[] parameters (point 2). Both the key, parameters and message
> would be available with appropriate getters (point 4 and 5). A static
> method in MathException would allow upper layers to prepend a customized
> MessageFactory instance (point 1) in front of already registered
> factories following a chain of responsibility. The initial chain would
> contain three different MessageFactory instances :
> - a LocalizedMessageFactory using the key to retrieve a pattern from
> a ResourceBundle for the default Locale (Locale.geDefault()) and
> MessageFormat to build the message (point 3)
> - a NonLocalizedMessageFactory using the key directly as a pattern
> for MessageFormat
> - a RawMessageFormat simply concatenating everything with toString
>
> The chain of responsibility is intended to provide robustness (point 6):
> the first message factory providing a non null message is used. If a
> factory fails, the next one is used. The last factory cannot fail.
>
> A user who simply wants to get messages localized for a Locale which is
> not the default one would therefore only need to do :
>
> MathException.prependMessageFactory(new
> LocalizedMessageFactory(myLocale));
>
> This would work even if its locale is not supported as its factory would
> always fail but the following ones would be triggered as needed.
>
> I think an appropriate policy would be to always use US-english patterns
> as keys as it would allow to get meaningful messages even if everything
> else fails, and as it would help the translators tasks.
>
> Does this seems sensible ?
I don't think we are going to please everyone here, Luc, and I agree with
Stephen that we don't want to over-complicate or get into the
framework-building business, but I disagree with the statement that we
should make localization impossible in generating strings (even exception
messages). My recommendation is that we just modify the Mantissa class to
expose the key and parts (so add members for them) and add
getMessage(Locale). That is simple, not far from what we already have, and
sufficient to meet localization needs and support other sorts of processing
for clients who want to do that.
Phil
Re: [all] exceptions and localization
Posted by Luc Maisonobe <Lu...@free.fr>.
Phil Steitz wrote :
>
> The problem with that is that generic handlers that display messages would
> not work. I like the idea of carrying the data along, though and exposing
> it, as well as providing translate (see
> http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/src/mantissa/src/org/spaceroots/mantissa/MantissaException.java?view=markup
>
>
> )
> and getMessage(Locale) methods. That gives client apps the most
> flexibility. What do you think, Luc?
Trying to synthetize all use cases, here is what I think is expected by
everyone who has expressed views :
1) allow application level code to contribute to/configure message
building
2) allow low layers to build messages with variable parts
3) allow localized messages
4) expose message parts (key and parameters)
5) allow handlers using only no arguments getMessage() to work as usual
6) use a mechanism robust enough to work even in case of code changes
and missing localization data (of course in degraded, i.e. non
localized
mode)
The following proposal is an attempt to address all these points.
Two main classes would be used: the MathException base class and a
MessageFactory base class. MathException would delegate to
MessageFactory the task to build the message from its String key and
Object[] parameters (point 2). Both the key, parameters and message
would be available with appropriate getters (point 4 and 5). A static
method in MathException would allow upper layers to prepend a customized
MessageFactory instance (point 1) in front of already registered
factories following a chain of responsibility. The initial chain would
contain three different MessageFactory instances :
- a LocalizedMessageFactory using the key to retrieve a pattern from
a ResourceBundle for the default Locale (Locale.geDefault()) and
MessageFormat to build the message (point 3)
- a NonLocalizedMessageFactory using the key directly as a pattern
for MessageFormat
- a RawMessageFormat simply concatenating everything with toString
The chain of responsibility is intended to provide robustness (point 6):
the first message factory providing a non null message is used. If a
factory fails, the next one is used. The last factory cannot fail.
A user who simply wants to get messages localized for a Locale which is
not the default one would therefore only need to do :
MathException.prependMessageFactory(new
LocalizedMessageFactory(myLocale));
This would work even if its locale is not supported as its factory would
always fail but the following ones would be triggered as needed.
I think an appropriate policy would be to always use US-english patterns
as keys as it would allow to get meaningful messages even if everything
else fails, and as it would help the translators tasks.
Does this seems sensible ?
Luc
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] exceptions and localization
Posted by Phil Steitz <ph...@gmail.com>.
On 2/3/07, James Carman <ja...@carmanconsulting.com> wrote:
>
> Well, I wouldn't even provide a getMessage(Locale). I'd leave it up
> to the running application to resolve the message. For instance, in
> Tapestry, it doesn't use resource bundles to localize messages, at
> least not directly in application code. It uses a special Messages
> object. So, I would provide getKey()/getParameters() methods only and
> leave it up to the containing application to localize the text. That
> way, they can give some context to the error message instead of
> relying upon us to be general enough.
The problem with that is that generic handlers that display messages would
not work. I like the idea of carrying the data along, though and exposing
it, as well as providing translate (see
http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/src/mantissa/src/org/spaceroots/mantissa/MantissaException.java?view=markup
)
and getMessage(Locale) methods. That gives client apps the most
flexibility. What do you think, Luc?
Phil
On 2/3/07, Niall Pemberton <ni...@gmail.com> wrote:
> > On 2/3/07, Phil Steitz <ph...@gmail.com> wrote:
> > > On 1/30/07, luc.maisonobe@free.fr <lu...@free.fr> wrote:
> > > >
> > > > Craig McClanahan wrote:
> > > >
> > > >
> > > > > I'm late to the table on this thread, and only care about the
> Commons
> > > > > libraries I care about :-)
> > > >
> > > > Thanks for your interest in this thread.
> > > >
> > > > > 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.
> > > >
> > > > I agree with you and thought localization should be provided by the
> layer
> > > > which
> > > > provides the message. Other people think this should be done at
> > > > application
> > > > level, if done at all.
> > > >
> > > > > 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.
> > > >
> > > > I think that since low level components may be used almost anywhere,
> their
> > > > messages *may* be displayed and this sole possibility is enough to
> justify
> > > > a
> > > > localized version should be made available. If the application gets
> an
> > > > error it
> > > > really doesn't know about, it can simply display it.
> > > >
> > > > > 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 :-).
> > > >
> > > > When I first started this long thread, I thought the need for
> localized
> > > > error
> > > > messages as provided by exceptions was acknowledged by everyone and
> asked
> > > > for
> > > > the way to implement it, starting from a simple one which already
> works. I
> > > > was
> > > > wrong. The disagreement started about the need itself and slipped to
> the
> > > > level
> > > > at which implementation should be done.
> > > >
> > > > I would really like to reach a compromise on this issue, something
> that
> > > > could by
> > > > accepted by everybody. I don't want to get banned with a -1 on a
> commit,
> > > > but at
> > > > least a few people would like localized error messages that can be
> simply
> > > > forwarded upward from lower layers to upper layer for display
> without
> > > > processing. Standard java already provides
> Throwable.getLocalizedMessage()
> > > > since
> > > > JDK 1.1. I could set up for [math] only an exception hierarchy that
> only
> > > > add a
> > > > few constructors and an implementation of this method without any
> change
> > > > in the
> > > > Throwable.getMessage() behaviour. Does this sound reasonable ?
> > >
> > >
> > > Sorry I was out of pocket this week and could not reiterate my
> personal +1
> > > for moving forward as you suggest, Luc. I will add a few of more
> comments
> > > below. If anyone still has serious reservations - especially those
> who now
> > > or in the future may contribute to [math] - pls speak up; otherwise
> we can
> > > move on. Thanks to all who provided comments.
> > >
> > > 1) My initial +1 was based on the fact that the error management that
> you
> > > need to support this approach is in fact there in Mantissa and if you
> > > *don't* support localization when text is being generated, you either
> need
> > > to get into nonsense like parsing and translating error messages,
> > > complicating your exceptions hierarchy, or losing/hiding information
> at
> > > higher levels. If you do the work to localize when the string is
> generated,
> > > that gives a choice at higher levels, which to me is goodness
> (assuming you
> > > are prepared to do the work and the implementation is robust against
> missing
> > > bundles, etc.).
> > >
> > > 2) Commons math generates error messages now, and should generate
> better
> > > messages (as Mantissa does) in the future that using applications may
> want
> > > to display to end users or in application logs. I would like for
> those
> > > messages to be localizable. If one of our solvers does not converge
> because
> > > initial values do not bracket a root, for example, I would like the
> > > developer of a localized client application that uses the solver to be
> able
> > > to display that message directly in a log or to the user. Whether or
> not
> > > logging is good or bad is completely irrelevant to this discussion.
> > >
> > > 3) Apache is a do-ocracy and we have a proposal before us to
> significantly
> > > improve exception management and error reporting in [math] by
> extending and
> > > leveraging the framework in Mantissa. Luc is volunteering to do this
> and
> > > the only other active contributor to [math] who has chimed in (yours
> truly)
> > > is also in favor. The arguments against are either it is too much
> work to
> > > implement exception error message localization or it may not be
> robust. Luc
> > > is stepping up to *do* the work (actually, leverage work already
> mostly done
> > > in Mantissa) and I don't see robustness or performance risk in what he
> has
> > > implemented. Pls speak up if I am missing something in the latter
> case.
> > > Therefore, appreciating the feedback from others and reservations
> about
> > > applying across commons, for [math] we should let Luc JFDI - i.e.,
> move
> > > forward with the proposal.
> >
> > +1 to those that do the work decide the direction.
> >
> > The only comment I would make is that there are two scenarios for
> > application localization in terms of the user - single or multiple.
> > Single being your application runs in one Locale only and multiple
> > where you have users with different Locale. If you want to cater for
> > the later then the exceptions should contain keys/replacement values
> > and message be resolved when the user's Locale is known - which I
> > think is James Carman's suggestion. Messages could be resolved outside
> > of Math or you could provide a getMessage(Locale) method in your
> > exceptions.
> >
> > Niall
> >
> > > Thanks again, all, for this interesting discussion and thanks, Luc,
> for
> > > helping make [math] more localization-friendly.
> > >
> > > Phil
> > >
> > > Luc
> >
> > ---------------------------------------------------------------------
> > 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
>
>
Re: [all] exceptions and localization
Posted by James Carman <ja...@carmanconsulting.com>.
Well, I wouldn't even provide a getMessage(Locale). I'd leave it up
to the running application to resolve the message. For instance, in
Tapestry, it doesn't use resource bundles to localize messages, at
least not directly in application code. It uses a special Messages
object. So, I would provide getKey()/getParameters() methods only and
leave it up to the containing application to localize the text. That
way, they can give some context to the error message instead of
relying upon us to be general enough.
On 2/3/07, Niall Pemberton <ni...@gmail.com> wrote:
> On 2/3/07, Phil Steitz <ph...@gmail.com> wrote:
> > On 1/30/07, luc.maisonobe@free.fr <lu...@free.fr> wrote:
> > >
> > > Craig McClanahan wrote:
> > >
> > >
> > > > I'm late to the table on this thread, and only care about the Commons
> > > > libraries I care about :-)
> > >
> > > Thanks for your interest in this thread.
> > >
> > > > 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.
> > >
> > > I agree with you and thought localization should be provided by the layer
> > > which
> > > provides the message. Other people think this should be done at
> > > application
> > > level, if done at all.
> > >
> > > > 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.
> > >
> > > I think that since low level components may be used almost anywhere, their
> > > messages *may* be displayed and this sole possibility is enough to justify
> > > a
> > > localized version should be made available. If the application gets an
> > > error it
> > > really doesn't know about, it can simply display it.
> > >
> > > > 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 :-).
> > >
> > > When I first started this long thread, I thought the need for localized
> > > error
> > > messages as provided by exceptions was acknowledged by everyone and asked
> > > for
> > > the way to implement it, starting from a simple one which already works. I
> > > was
> > > wrong. The disagreement started about the need itself and slipped to the
> > > level
> > > at which implementation should be done.
> > >
> > > I would really like to reach a compromise on this issue, something that
> > > could by
> > > accepted by everybody. I don't want to get banned with a -1 on a commit,
> > > but at
> > > least a few people would like localized error messages that can be simply
> > > forwarded upward from lower layers to upper layer for display without
> > > processing. Standard java already provides Throwable.getLocalizedMessage()
> > > since
> > > JDK 1.1. I could set up for [math] only an exception hierarchy that only
> > > add a
> > > few constructors and an implementation of this method without any change
> > > in the
> > > Throwable.getMessage() behaviour. Does this sound reasonable ?
> >
> >
> > Sorry I was out of pocket this week and could not reiterate my personal +1
> > for moving forward as you suggest, Luc. I will add a few of more comments
> > below. If anyone still has serious reservations - especially those who now
> > or in the future may contribute to [math] - pls speak up; otherwise we can
> > move on. Thanks to all who provided comments.
> >
> > 1) My initial +1 was based on the fact that the error management that you
> > need to support this approach is in fact there in Mantissa and if you
> > *don't* support localization when text is being generated, you either need
> > to get into nonsense like parsing and translating error messages,
> > complicating your exceptions hierarchy, or losing/hiding information at
> > higher levels. If you do the work to localize when the string is generated,
> > that gives a choice at higher levels, which to me is goodness (assuming you
> > are prepared to do the work and the implementation is robust against missing
> > bundles, etc.).
> >
> > 2) Commons math generates error messages now, and should generate better
> > messages (as Mantissa does) in the future that using applications may want
> > to display to end users or in application logs. I would like for those
> > messages to be localizable. If one of our solvers does not converge because
> > initial values do not bracket a root, for example, I would like the
> > developer of a localized client application that uses the solver to be able
> > to display that message directly in a log or to the user. Whether or not
> > logging is good or bad is completely irrelevant to this discussion.
> >
> > 3) Apache is a do-ocracy and we have a proposal before us to significantly
> > improve exception management and error reporting in [math] by extending and
> > leveraging the framework in Mantissa. Luc is volunteering to do this and
> > the only other active contributor to [math] who has chimed in (yours truly)
> > is also in favor. The arguments against are either it is too much work to
> > implement exception error message localization or it may not be robust. Luc
> > is stepping up to *do* the work (actually, leverage work already mostly done
> > in Mantissa) and I don't see robustness or performance risk in what he has
> > implemented. Pls speak up if I am missing something in the latter case.
> > Therefore, appreciating the feedback from others and reservations about
> > applying across commons, for [math] we should let Luc JFDI - i.e., move
> > forward with the proposal.
>
> +1 to those that do the work decide the direction.
>
> The only comment I would make is that there are two scenarios for
> application localization in terms of the user - single or multiple.
> Single being your application runs in one Locale only and multiple
> where you have users with different Locale. If you want to cater for
> the later then the exceptions should contain keys/replacement values
> and message be resolved when the user's Locale is known - which I
> think is James Carman's suggestion. Messages could be resolved outside
> of Math or you could provide a getMessage(Locale) method in your
> exceptions.
>
> Niall
>
> > Thanks again, all, for this interesting discussion and thanks, Luc, for
> > helping make [math] more localization-friendly.
> >
> > Phil
> >
> > Luc
>
> ---------------------------------------------------------------------
> 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
Re: [all] exceptions and localization
Posted by Niall Pemberton <ni...@gmail.com>.
On 2/3/07, Phil Steitz <ph...@gmail.com> wrote:
> On 1/30/07, luc.maisonobe@free.fr <lu...@free.fr> wrote:
> >
> > Craig McClanahan wrote:
> >
> >
> > > I'm late to the table on this thread, and only care about the Commons
> > > libraries I care about :-)
> >
> > Thanks for your interest in this thread.
> >
> > > 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.
> >
> > I agree with you and thought localization should be provided by the layer
> > which
> > provides the message. Other people think this should be done at
> > application
> > level, if done at all.
> >
> > > 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.
> >
> > I think that since low level components may be used almost anywhere, their
> > messages *may* be displayed and this sole possibility is enough to justify
> > a
> > localized version should be made available. If the application gets an
> > error it
> > really doesn't know about, it can simply display it.
> >
> > > 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 :-).
> >
> > When I first started this long thread, I thought the need for localized
> > error
> > messages as provided by exceptions was acknowledged by everyone and asked
> > for
> > the way to implement it, starting from a simple one which already works. I
> > was
> > wrong. The disagreement started about the need itself and slipped to the
> > level
> > at which implementation should be done.
> >
> > I would really like to reach a compromise on this issue, something that
> > could by
> > accepted by everybody. I don't want to get banned with a -1 on a commit,
> > but at
> > least a few people would like localized error messages that can be simply
> > forwarded upward from lower layers to upper layer for display without
> > processing. Standard java already provides Throwable.getLocalizedMessage()
> > since
> > JDK 1.1. I could set up for [math] only an exception hierarchy that only
> > add a
> > few constructors and an implementation of this method without any change
> > in the
> > Throwable.getMessage() behaviour. Does this sound reasonable ?
>
>
> Sorry I was out of pocket this week and could not reiterate my personal +1
> for moving forward as you suggest, Luc. I will add a few of more comments
> below. If anyone still has serious reservations - especially those who now
> or in the future may contribute to [math] - pls speak up; otherwise we can
> move on. Thanks to all who provided comments.
>
> 1) My initial +1 was based on the fact that the error management that you
> need to support this approach is in fact there in Mantissa and if you
> *don't* support localization when text is being generated, you either need
> to get into nonsense like parsing and translating error messages,
> complicating your exceptions hierarchy, or losing/hiding information at
> higher levels. If you do the work to localize when the string is generated,
> that gives a choice at higher levels, which to me is goodness (assuming you
> are prepared to do the work and the implementation is robust against missing
> bundles, etc.).
>
> 2) Commons math generates error messages now, and should generate better
> messages (as Mantissa does) in the future that using applications may want
> to display to end users or in application logs. I would like for those
> messages to be localizable. If one of our solvers does not converge because
> initial values do not bracket a root, for example, I would like the
> developer of a localized client application that uses the solver to be able
> to display that message directly in a log or to the user. Whether or not
> logging is good or bad is completely irrelevant to this discussion.
>
> 3) Apache is a do-ocracy and we have a proposal before us to significantly
> improve exception management and error reporting in [math] by extending and
> leveraging the framework in Mantissa. Luc is volunteering to do this and
> the only other active contributor to [math] who has chimed in (yours truly)
> is also in favor. The arguments against are either it is too much work to
> implement exception error message localization or it may not be robust. Luc
> is stepping up to *do* the work (actually, leverage work already mostly done
> in Mantissa) and I don't see robustness or performance risk in what he has
> implemented. Pls speak up if I am missing something in the latter case.
> Therefore, appreciating the feedback from others and reservations about
> applying across commons, for [math] we should let Luc JFDI - i.e., move
> forward with the proposal.
+1 to those that do the work decide the direction.
The only comment I would make is that there are two scenarios for
application localization in terms of the user - single or multiple.
Single being your application runs in one Locale only and multiple
where you have users with different Locale. If you want to cater for
the later then the exceptions should contain keys/replacement values
and message be resolved when the user's Locale is known - which I
think is James Carman's suggestion. Messages could be resolved outside
of Math or you could provide a getMessage(Locale) method in your
exceptions.
Niall
> Thanks again, all, for this interesting discussion and thanks, Luc, for
> helping make [math] more localization-friendly.
>
> Phil
>
> Luc
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] exceptions and localization
Posted by Phil Steitz <ph...@gmail.com>.
On 1/30/07, luc.maisonobe@free.fr <lu...@free.fr> wrote:
>
> Craig McClanahan wrote:
>
>
> > I'm late to the table on this thread, and only care about the Commons
> > libraries I care about :-)
>
> Thanks for your interest in this thread.
>
> > 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.
>
> I agree with you and thought localization should be provided by the layer
> which
> provides the message. Other people think this should be done at
> application
> level, if done at all.
>
> > 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.
>
> I think that since low level components may be used almost anywhere, their
> messages *may* be displayed and this sole possibility is enough to justify
> a
> localized version should be made available. If the application gets an
> error it
> really doesn't know about, it can simply display it.
>
> > 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 :-).
>
> When I first started this long thread, I thought the need for localized
> error
> messages as provided by exceptions was acknowledged by everyone and asked
> for
> the way to implement it, starting from a simple one which already works. I
> was
> wrong. The disagreement started about the need itself and slipped to the
> level
> at which implementation should be done.
>
> I would really like to reach a compromise on this issue, something that
> could by
> accepted by everybody. I don't want to get banned with a -1 on a commit,
> but at
> least a few people would like localized error messages that can be simply
> forwarded upward from lower layers to upper layer for display without
> processing. Standard java already provides Throwable.getLocalizedMessage()
> since
> JDK 1.1. I could set up for [math] only an exception hierarchy that only
> add a
> few constructors and an implementation of this method without any change
> in the
> Throwable.getMessage() behaviour. Does this sound reasonable ?
Sorry I was out of pocket this week and could not reiterate my personal +1
for moving forward as you suggest, Luc. I will add a few of more comments
below. If anyone still has serious reservations - especially those who now
or in the future may contribute to [math] - pls speak up; otherwise we can
move on. Thanks to all who provided comments.
1) My initial +1 was based on the fact that the error management that you
need to support this approach is in fact there in Mantissa and if you
*don't* support localization when text is being generated, you either need
to get into nonsense like parsing and translating error messages,
complicating your exceptions hierarchy, or losing/hiding information at
higher levels. If you do the work to localize when the string is generated,
that gives a choice at higher levels, which to me is goodness (assuming you
are prepared to do the work and the implementation is robust against missing
bundles, etc.).
2) Commons math generates error messages now, and should generate better
messages (as Mantissa does) in the future that using applications may want
to display to end users or in application logs. I would like for those
messages to be localizable. If one of our solvers does not converge because
initial values do not bracket a root, for example, I would like the
developer of a localized client application that uses the solver to be able
to display that message directly in a log or to the user. Whether or not
logging is good or bad is completely irrelevant to this discussion.
3) Apache is a do-ocracy and we have a proposal before us to significantly
improve exception management and error reporting in [math] by extending and
leveraging the framework in Mantissa. Luc is volunteering to do this and
the only other active contributor to [math] who has chimed in (yours truly)
is also in favor. The arguments against are either it is too much work to
implement exception error message localization or it may not be robust. Luc
is stepping up to *do* the work (actually, leverage work already mostly done
in Mantissa) and I don't see robustness or performance risk in what he has
implemented. Pls speak up if I am missing something in the latter case.
Therefore, appreciating the feedback from others and reservations about
applying across commons, for [math] we should let Luc JFDI - i.e., move
forward with the proposal.
Thanks again, all, for this interesting discussion and thanks, Luc, for
helping make [math] more localization-friendly.
Phil
Luc
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [all] exceptions and localization
Posted by lu...@free.fr.
Craig McClanahan wrote:
> I'm late to the table on this thread, and only care about the Commons
> libraries I care about :-)
Thanks for your interest in this thread.
> 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.
I agree with you and thought localization should be provided by the layer which
provides the message. Other people think this should be done at application
level, if done at all.
> 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.
I think that since low level components may be used almost anywhere, their
messages *may* be displayed and this sole possibility is enough to justify a
localized version should be made available. If the application gets an error it
really doesn't know about, it can simply display it.
> 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 :-).
When I first started this long thread, I thought the need for localized error
messages as provided by exceptions was acknowledged by everyone and asked for
the way to implement it, starting from a simple one which already works. I was
wrong. The disagreement started about the need itself and slipped to the level
at which implementation should be done.
I would really like to reach a compromise on this issue, something that could by
accepted by everybody. I don't want to get banned with a -1 on a commit, but at
least a few people would like localized error messages that can be simply
forwarded upward from lower layers to upper layer for display without
processing. Standard java already provides Throwable.getLocalizedMessage() since
JDK 1.1. I could set up for [math] only an exception hierarchy that only add a
few constructors and an implementation of this method without any change in the
Throwable.getMessage() behaviour. Does this sound reasonable ?
Luc
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] exceptions and localization
Posted by Craig McClanahan <cr...@apache.org>.
On 1/28/07, Stephen Colebourne <sc...@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 <Lu...@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
>
>
Re: [all] exceptions and localization
Posted by Stephen Colebourne <sc...@btopenworld.com>.
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 <Lu...@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.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] exceptions and localization
Posted by Phil Steitz <ph...@gmail.com>.
On 1/28/07, Luc Maisonobe <Lu...@free.fr> wrote:
>
> Hello,
>
> As a non-native english speaker, I am quite eager to provide users with
> libraries that can be embedded seemlessly into localized applications.
> This implies that either the getMessage() and getLocalizedMessages() of
> Exception instances provide two different messages, or that the
> getMessage() already provides an localized message. In either case,
> since some messages have both fixed parts and variable parts, some
> localization layer should be used at the time of Exception creation,
> i.e. in the commons components themselves.
>
+1
I am willing to implement that for [math] (prior to retrofit the
> Mantissa packages already selected), and was wondering how this is
> handled by other components. The only two things I found were the
> Fulcrum Localization Component in Turbine and the I18n component in
> sandbox.
>
> I think building localized error messages is important so I would like
> to change the current practice.
>
> The first question I ask is what localization framework should be used
> for that: standard java, i18n in sandbox, fulcrum localization ? My
> personal choice would be standard java with embedded property files
> (PropertyResourceBundle) first and i18n from sandbox second as I don't
> want to add new dependencies to [math] and if a dependency is added it
> should belong to commons obeying [math] proposal.
+1 for including this in the exceptions refactoring that we discussed before
for [math] and +1 for the "standard java" approach.
The second question I ask is at which stage should the localization
> layer be triggered: before creating the exception or inside the
> exception constructors ? My personal choice as implemented in Mantissa
> is depicted in the example at the bottom of this message. It only adds
> new constructors, thus allowing smooth transition towards providing
> fully localized components with variable parts messages. I think it is
> compatible with java 1.3 (but am not sure). From the user points of
> view, the messages will be already localized in the getMessage() method,
> however it is quite easy to change this implementation to provide both
> english and localized messages.
>
> What do you think about it ?
The approach below looks fine to me. 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. Thanks!
Phil
public class SomeException
> extends Exception {
>
> private static ResourceBundle resources =
> ResourceBundle.getBundle("org.apache.commons.some.ExceptionsResources
> ");
>
> /** Translate a string. */
> public static String translate(String s) {
> try {
> return resources.getString(s);
> } catch (MissingResourceException mre) {
> return s;
> }
> }
>
> /** Translate a message. */
> public static String translate(String specifier, String[] parts) {
> return new MessageFormat(translate(specifier)).format(parts);
> }
>
> /* some more traditional constructors go there, with message
> * only, or message and cause ...
> */
>
> /** Simple constructor. */
> public SomeException(String specifier, String[] parts) {
> super(translate(specifier, parts));
> }
>
> }
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>