On Aug 19, 2009, at 8:31 AM, Pete Muir wrote:

Let me rephrase. It isn't just that they suck. In my environment resource bundles don't work for I18N. I'm not in favor of having features implemented that I can't use. But my opinion doesn't really carry any more weight than yours.

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 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.

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.

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.

Ralph