commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Luc Maisonobe (JIRA)" <j...@apache.org>
Subject [jira] Commented: (MATH-361) Localization and Error Handling
Date Sun, 13 Jun 2010 19:35:13 GMT

    [ 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/dev@commons.apache.org/msg14570.html]

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message