[slf4j-dev] slf4j i8ln

[Pete Muir]

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

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
* 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?
* Should there be a convention for the key used? For example a key  
should use a FQN.
* 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?

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

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


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.
>
> Ralph
>
> _______________________________________________
> dev mailing list
> dev at slf4j.org
> http://www.slf4j.org/mailman/listinfo/dev