atom feed44 messages in org.slf4j.devRe: [slf4j-dev] slf4j i8ln
FromSent OnAttachments
Pete MuirAug 17, 2009 10:05 am 
Ralph GoersAug 17, 2009 2:40 pm 
Pete MuirAug 18, 2009 6:37 am 
Ralph GoersAug 18, 2009 7:10 am 
近藤 健Aug 18, 2009 9:59 am 
Pete MuirAug 19, 2009 8:31 am 
Ralph GoersAug 19, 2009 9:15 am 
Ceki GulcuAug 19, 2009 11:17 am 
Pete MuirAug 19, 2009 11:20 am 
Pete MuirAug 19, 2009 11:29 am 
Ceki GulcuAug 19, 2009 11:42 am 
Pete MuirAug 19, 2009 11:51 am 
Ceki GulcuAug 19, 2009 12:38 pm 
Ralph GoersAug 19, 2009 1:42 pm 
Ceki GulcuAug 19, 2009 1:58 pm 
Ceki GulcuAug 19, 2009 2:15 pm 
Ralph GoersAug 19, 2009 2:21 pm 
Ralph GoersAug 19, 2009 2:31 pm 
Ceki GulcuAug 19, 2009 2:40 pm 
近藤 健Aug 20, 2009 8:22 am 
Ralph GoersAug 20, 2009 8:35 am 
Takeshi KondoAug 20, 2009 10:07 am 
ralp...@dslextreme.comAug 20, 2009 10:20 am 
Ceki GulcuAug 20, 2009 1:58 pm 
Ceki GulcuAug 20, 2009 2:05 pm 
Takeshi KondoAug 21, 2009 10:28 pm 
Takeshi KondoAug 22, 2009 10:32 pm.jar, .jar
Ralph GoersAug 23, 2009 8:21 am 
Takeshi KondoAug 23, 2009 8:40 am 
Ceki GulcuAug 23, 2009 10:38 am 
Takeshi KondoAug 23, 2009 4:59 pm 
Ralph GoersAug 23, 2009 9:56 pm 
Ceki GulcuAug 24, 2009 6:14 am 
Takeshi KondoAug 24, 2009 10:02 am 
Ceki GulcuAug 24, 2009 10:22 am 
Takeshi KondoAug 24, 2009 11:05 am 
Ceki GulcuAug 24, 2009 11:27 am 
Takeshi KondoAug 24, 2009 12:36 pm 
Ceki GulcuAug 24, 2009 12:56 pm 
Takeshi KondoAug 24, 2009 1:15 pm 
Ceki GulcuAug 24, 2009 1:24 pm 
Ralph GoersAug 24, 2009 1:33 pm 
Takeshi KondoAug 24, 2009 2:02 pm 
Ceki GulcuAug 25, 2009 1:32 am 
Subject:Re: [slf4j-dev] slf4j i8ln
From:Ralph Goers (rgo@apache.org)
Date:Aug 19, 2009 1:42:38 pm
List:org.slf4j.dev

On Aug 19, 2009, at 11:21 AM, Pete Muir wrote:

I think we are making progress here, and actually there isn't too much work to do. Let me paraphrase to make sure I am understanding you correctly.

* The source of messages should be abstracted behind an interface. A default implementation that uses resource bundles could be provided for easy ootb experience. Yes, * The provision of the Locale should be an orthogonal concept to the logging of messages and the creation of the Logger. This should be handled via the MDC.

"could be handled via the MDC". There are other ways to do it but that is probably the simplest.

IMO there are still a few questions to answer:

* Takeshi original design allowed you to use Enums as keys for messages. I'm personally not sure about this, I'm not really sure what benefits it offers over Strings as keys

Enums are usually associated with an integer "value" and a String description. The only value is that you might be able to get some optimization by using the integer value of the enum in some cases. I don't know that it is worth the effort to support it.

* How does a framework provide translated messages [1] to i8ln layer? Can we also use the MDC here to push them in, and have the appender read them?

I'm not sure I understand the question. The framework will provide a method like: public String getMessage(String key, Object[] params); However the messages are stored is hidden behind the implementation of that interface. Something has to call getMessage(). Potential places are a) the application before calling SLF4J b) SLF4J before calling a logging implementation, c) In the logging implementation - such as in the Appender.

* Should there be a convention for the key used? For example a key should use a FQN.

No. The key is essentially a contract between the application and whatever the backing repository is. Everything else should be ignorant.

* How does the integrate with the various slf4j back ends? Do we somehow want to map it to the JDK logging i8ln support? What about log4j?

If you take the approach I recommend - do it as late as possible - then it is outside the scope of SLF4J. It might be done in the Appender for the logging framework in use or it might actually happen in the application that is reading the log files based on the Locale of the user reading them.

[1] I'm assuming that a framework developer will want to provide translations for it's logging messages

No. An I18N framework would only provide the format the messages have to be stored in. Applications using the framework will provide their own message sets and presumably have experts who can localize the message sets provided by the development team into the desired locales.

Regarding your suggestion to enhance logback - I want to be able to provide l10n for my log messages regardless of which logging back end is in use (for example, the framework I am currently working on currently targets JBoss AS, GlassFish, and Tomcat as possible runtimes, which use a combination of JDK logging and log4j).

Again, that depends. For example, Lillith
(http://freshmeat.net/projects/lilith-viewer ) is an event viewer for Logback. It would be very appropriate for it to do this. Likewise with Apache Chainsaw for Log4j. Doing the L10N further up the chain limits the flexibility these tools can provide. Sometimes that is desirable, but my recommendation is to always start from as far back as possible and move up the stack only as far as you have to.

Ralph

On 19 Aug 2009, at 17:16, Ralph Goers wrote:

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

Hi Ralph,

Whether or not resource bundles suck in our opinion, they are the standard approach to this so I believe we can't just dismiss them.

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.

I'm also unsure how, in your approach, a framework would provide i8ln'ized log messages which would be used?

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.