[
https://issues.apache.org/jira/browse/MATH-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12878427#action_12878427
]
Luc Maisonobe commented on MATH-361:
------------------------------------
I finally found some time to look at this issue and the proposal.
I agree with the problems and not with the solution. I don't like adding a
dependency only for the sake of development ease and NOT for users. End users
will not see any improvement with this and they will have to manage yet another
dependency which is not widespread and on which we have no control. Adding
also a complex management to allow working without the dependency also misses
the point I tried to make in the previous discussions: it removes the
dependency but removes the localization entirely!
I tried another approach on last three days. My proposal is simply to address
the main problems with our current awkward implementation but without adding
any dependencies. It is simply a matter of adding one interface with one main
implementation (and another tiny dummy implementation for some compatibility
purposes and to add new exception constructors.
The interface is called Localizable and declares two methods getSourceString()
and getLocalizedString(Locale). A new enum called LocalizedMessages implements
the interface and all its constants (249 so far) provide one message format,
and mainly replaces the current MessageFormat class. The localization are
loaded from a properties file. In the commons-math code, we will use only the
enum constants, so there will not be any literal string spread throughout the
library. In the enum class, there will be the default english format, this is a
very important point as it allows to provide a formatted and understandable
default message even if a locale is not supported or if the properties file for
the locale is incomplete. I don't think cal10n does this. The properties file
for a locale does not contain the english message, it uses the name of the
constant as the key, so their is absolutely no duplication of any string
literal.
The exceptions can be built using an enum where they used to have a pattern
string. since the enum implements Localizable, the exception message can be
built both using getSourceString without localization or usgin
getLocalizedString(Locale) in any Locale (not only the default one). The
existing constructors are preserved (but deprecated). This is very important
for compatibility purposes because some of our exceptions are really intended
to be extended by users since this is the way they can generate errors in the
callback objects they implement themselves and provide to the library (ODE
problems, functions to solve, ...). Many users WILL have extended these
exception and used the only constructors we provided with String parameters. In
this case, a dummy implementation of the interface is also provided to still
get meaningful messages. As an added benefit, users will be able to also
localize their own messages if they want, they simply have to provide their own
implementation of the interface (hence we can separate several sets of
constants, as the commons-math enums will not clash with the users enums).
It is quite easy to switch progressively from the current implementation to the
one I propose. I also think we could have some very simple tools to check our
properties files are complete and we have no unused enum constants. Since we
use standard properties files and not a dedicated parser (which is what cal10n
uses, with some parsing bugs on single quotes I think), it will later be
possible to go to some more adequate tooling on the localization process (at
development time) by using for example the xliff oasis standard that allow
translators to use their own tools (including Machine Translation or Computer
Aided Translation) and create java properties files (their are some free tools
to transform xliff to standard java properties files).
As the changes in the commons-math code are really straightforward and can be
automatized, I can handle the transition of ALL existing messages.
> Localization and Error Handling
> -------------------------------
>
> Key: MATH-361
> URL: https://issues.apache.org/jira/browse/MATH-361
> Project: Commons Math
> Issue Type: Improvement
> Affects Versions: 2.1
> Reporter: Gilles
> Priority: Minor
> Attachments: l10n.tar.gz, res.tar.gz
>
>
> This proposal aims at easing the handling of error during algorithms
> development, and also enhancing the flexibility of the error reporting
> (provide meaningful exception classes and run-time selection of the
> localization formatting).
> More details at
> [http://www.mail-archive.com/[email protected]/msg14570.html]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
