[slf4j-dev] slf4j i8ln

[Ceki Gulcu]

Ralph Goers wrote:
> 
> As I've said, I'm not at all in favor of SLF4J "doing" I18N. It is 
> better to do it under a framework such as Spring's MessageSource 
> interface where you can either use the default implementation, which 
> uses ResourceBundles, or easily provide your own. As I said, I'm also 
> planning on creating a framework to manage internationalized messages 
> using Commons Configuration and XML files.

In a way, MessageFormatter [1] performs a similar function to a ResourceBundle. 
It is also noteworthy that currently MessageFormatter.format() is invoked within 
  slf4j bindings. Previously, users had asked that the MessageFormatter 
implementation be pluggable. Unfortunately, this is not possible because if 
library A depends on MessageFormatter_A and library B depends on 
MessageFormatter_B, and if MessageFormatter_A and MessageFormatter_B use 
incompatible message formatting conventions, for example "hello {}" and "hello 
{0}", then choosing MessageFormatter_A as the implementation will screw up 
messages generated by library B. The same problem would occur with resource 
bundles or its spring equivalents.

> In that scenario the application either calls getMessage() and then 
> passes the resulting String to the log call or the application passes 
> the message key as the message on the log call, which is the approach I 
> would suggest. In the second scenario it is up to the Appender to 
> resolve the key by calling getMessage(). Ideally, the Appender should be 
> able to tell whether it is getting a key or the actual message text. 
> This can be done simply by convention - i.e. a log message like 
> "key=Message1" or by passing a parameter. There is no real need to 
> enhance SLF4J to be able to do this.

Assuming we had I18NLogger_1 wrapping/decorating o.slf4j.Logger, a printing 
method, say i18nInfo() could be implemented as:

public class I18NLogger_1 extends LoggerWrapper implements Logger

   I18NLogger(Logger logger) {
     super(logger, I18NLogger_1.class.getName());
   }

   void i18nInfo(String message, Object... params) {
     if(logger.isInfoEnabled()) {
       // aMessageSourceImpl is some implementation of
       // org.springframework.context.MessageSource or similar
       // interface
       String m = aMessageSourceImpl.getMessage(message, params, locale);
       logger.info(m);
     }
   }
}

In the above code, only aMessageSourceImpl and locale are not clearly defined.

Another possible implementation for I18NLogger is as follows:

public class I18NLogger_2 extends LoggerWrapper implements Logger

   I18NLogger_2(Logger logger) {
     super(logger, I18NLogger_2.class.getName());
   }

   void i18nInfo(String message, Object... params) {
     if(logger.isInfoEnabled()) {
       // I18N is a marker for all internationalized messages
       logger.info(I18N, message, params);
     }
   }
}

In this second implementation, internationalization is done within the 
appropriate appender or possibly a new logback component (e.g. 
ILoggingEventTransformer) which would know how to
internationalize messages. It would do so only for messages marked with I18N.

The advantage of this second approach is that Joran (logback's internal 
configuration framework) can be leveraged to configure things pretty much the 
end-user wants. See for example SiftingAppender [2] which is heavily based on Joran.

> The piece that SLF4J is missing is the ability to detect the target 
> Locale of the message. But even this can be handled without change to 
> SLF4J. Just adding the Locale to the MDC would allow the Appender to do 
> the right thing. Of course, you'd have to use a logging implementation 
> that supports the MDC.

FYI, all slf4j bindings, including slf4j-jdk14 and even slf4j-nop ship with 
functional MDC support. It's just that the underlying logging framework does not 
make use of the provided MDC data.

> In short, instead of asking for a change to SLF4J it would make more 
> sense to me for you to ask for an enhancement to Logback so that any 
> Appender can have the opportunity to internationalize the message. 
> Currently you'd have to do that in a Layout, but I don't believe all 
> Appenders support them.

I don't know. Logback is tempting because of all the customization it allows. I 
could even imagine adding a new component, say ILoggingEventTransformer, which 
could transform logging events with internationalization being one particular 
type of transformation. If ILoggingEventTransformer came before appenders, it 
could transform the event for all appenders. Nevertheless, the main advantage of 
logback is all the additional customization made possible.

For Web Beans, I am under the impression that all logging back ends need to be 
supported, hence I18NLogger_1.

What were the requirements again? :-)

> Ralph

[1] http://slf4j.org/xref/org/slf4j/helpers/MessageFormatter.html
[2] http://logback.qos.ch/manual/appenders.html#SiftingAppender

-- 
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch