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 18, 2009 7:10:49 am
List:org.slf4j.dev

Interesting, but I personally would not be happy with that interface. 1. It relies on resource bundles. 2. None of the methods accept a Locale so the framework has to rely on the default locale. Without this it means that while the app can support any language a particular instance can only support one. That is fine in some use cases but not all.

I actually dealt with this kind of stuff years ago. Consider a use case where you have call centers in Japan, France and the U.S. each handling customers in their native country and the application is running in a single data center. a) either all your customer service reps have to understand a single language or b) the log records need to be written to a file using the message key and the substitution parameters. The message should not be localized until it is going to appear on the customer service reps console so they can read it in whatever language they are configured for.

To truly internationalize properly the translation needs to happen as late as possible. In that case the logging framework doesn't even really need to support resource bundles.

But, assuming you still want to have the framework "do" I18N, as I said in my earlier message, it can still be handled in the appender, not in the API layer.

Ralph

On Aug 18, 2009, at 6:38 AM, Pete Muir wrote:

To follow up on this, Mark Little pointed me at the Common Logging Framework developed by Arjuna as another way this problem has been addressed in the past.

See
http://docs.jboss.org/process-guide/en/html/internationalization.html#d0e4183

Hi,

As discussed here https://jira.jboss.org/jira/browse/WBRI-290, we would like to switch to slf4j as our logger (it offers a logging facade, supports MDC/NDC and parameter replacement).

However, as Takeshi highlights here https://jira.jboss.org/jira/browse/WBRI-214 , a needed feature is explicit i8n support, and it sounds like Ceki would be happy to accept a contribution for this directly to the slf4j.

Perhaps, to get started, we should discuss the overall design and aims. In the linked issue, Takeshi adds three features in the patch:

- ability to localize a message by providing a resource bundle, which has the same name as the class using the logger (the declaring class) - the ability to log an enum value (rather than using a static to hold the message/key) - the ability to associate the level at which to log with the message with the enum (via an annotation) rather than in the call from the declaring class

(Takeshi, correct me if this is incorrect). I think we can probably separate these features out when discussing.

I think we would also need:

- ability to specify the resource bundle to use when getting the logger - ability to use statics fields or just a string id embedded in call to logger

But I'm sure others have given this more thought than me!