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 2:31:40 pm
List:org.slf4j.dev

On Aug 19, 2009, at 2:15 PM, Ceki Gulcu wrote:

Ralph Goers wrote:

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

Pushing the locale in every thread will not suite everyone.

Probably not. In those cases the method you described before using the LoggerContext would probably work.

But it depends on the use case. In a lot of systems the operations staff will want all the log messages in a single language of the locale where the software is running and the locale of the end user will be irrelevant. In cases like event logging it may be that the event logs are viewed by customer service reps speaking in multiple languages. In that case the locale of the person viewing the log is important (which may be days or months after the log entry was recorded). The least critical scenario, in my opinion, is where the log entry will be viewed by the end user. IMO this isn't the best use of a logging system. OTOH, in my case we would still put the locale of the end user in the MDC simply because other GUI components will want that information.

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.

Unless enums have some other advantage that we did not think of. Takeshi can you describe the advantages of enums that you see?

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

Bingo. a), b) or c) is the question. There is also a) and b) combined. See my previous message.

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.

If SLF4J or logback provided a reasonable solution, it would help developers in solving the logging i18n issue by the mere fact of offering and thus blessing a solution. It could only do harm if the offered solution was particularly stupid or bad. Moreover, the solution provided in slf4j or logback (or in both in part) could lay the foundation of a better solution imagined by one of our users.

+1. That is why we would want to consider several use cases. I don't think there is a one size fits all solution.

Ralph