On 1/28/07, Luc Maisonobe <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
