[logging] API - i18n and l10n support

[Tomas Znamenacek <to...@ca.ibm.com>]

This discussion thread is to summarize the previous responses regarding
support for internationalization and localization in the proposal posted by
Richard and to continue the discussions to arrive at a conclusion.

For each issue I have found in previous discussions I'm offering my
comments, if I have any.  Please keep in mind that the original proposal
was for a new version of Jakarta Commons Logging which could also end up as
a separate branch of JCL, building on top of existing JCL, keeping the
existing JCL unchanged.

1. Why not use the existing i18n project?

The JCL is a wrapper only, and as such, it would only define API for
i18n/l10n. Using the i18n project would create a dependency on that project
which is not desired.
Following is the text from current JCL user guide:
"NLS internationalization SHOULD be strongly considered for used for fatal,
error, warn, and info messages. It is generally considered optional for
debug and trace messages. Perhaps more direct support for
internationalizing log messages can be introduced in a future or alternate
version of the Log interface."
The proposed API simply follows this recommendation.


2. Use a separate object to encapsulate i18n/l10n functionality and rely on
the toString() method to obtain localized message.

This would mean more complexity and more work for developers. Such object
would need same parameters(message key, resource bundle name, message
parameters) as would be passed into the methods on the proposed interface.
Also, this approach will result in each project having to implement their
own i18n solution instead of deferring it to underlying logging
implementation. For example, Axis project uses this approach.


3. How would the resource bundle be selected and passed to the
implementation?

The proposal is for interface only, the implementations will decide if they
pass down the resource bundle names or instances(which might be
configurable).


4. The method formatMessage() does not belong into Log interface.

This method is not a logging method itself and it depends on community to
decide if it should or should not be added into proposed API. Having such
method might prove useful in cases where messages need to be translated not
only for purpose of logging, but other as well, such as for generating
exception message strings.


5. The proposed methods do not have default message as a parameter.

Without a default message, the users of this API are forced to use resource
bundles, which are the key part in the whole i18n/l10n approach. I would
say it enforces a certain good practice.


6. The JCL is used in Jakarta Commons libraries, the targeted users of the
JCL are developers and they do not need i18n.

As open source components gain more use around the world, there will be an
more interest in enabling them for i18n.  There is currently no path
encouraging the developers interested in this, nor is there a clear
direction on how to do this. The proposal will provide both encouragement
and direction.


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org