[slf4j-dev] slf4j i8ln

[Pete Muir]

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.

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

On 17 Aug 2009, at 22:41, Ralph Goers wrote:

> My 2 cents.
>
> ResourceBundles suck. Even in Java 1.6 it is difficult to change the  
> implementation and it only works if the application cooperates. The  
> default implementation finds the bundles in the classpath which  
> makes it difficult if you like to store the files outside of the  
> application. Also, since they are loaded on the classpath they  
> aren't automatically reloaded when modified.  My organization also  
> has "special" needs when it comes to internationalization - a single  
> application can support thousands of clients each of which may want  
> to override some of the keys in the bundles.
>
> In short, it seems to me to make far more sense to use a separate  
> I18n framework to deal with the actual message text and then just  
> make sure that SLF4J can accept the Locale as a parameter to be  
> passed to the Appender.
>
> Another option along the same lines would be to use the message  
> field as the message key, along with the parameters and pass those  
> to the Appender along with the locale. There again, an I18N  
> framework would deal with the messages.
>
> In short, SLF4J should support I18N but not implement it.
>
> FWIW - I have a need to implement an I18N framework based on Apache  
> Commons Configuration to support the needs I discussed in the first  
> paragraph. I'm considering doing it in the existing I18N project in  
> the Apache Commons Sandbox.
>
> Ralph
>
> On Aug 17, 2009, at 10:05 AM, Pete Muir wrote:
>
>> 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!
>>
>> Pete
>> _______________________________________________
>> dev mailing list
>> dev at slf4j.org
>> http://www.slf4j.org/mailman/listinfo/dev
>
> _______________________________________________
> dev mailing list
> dev at slf4j.org
> http://www.slf4j.org/mailman/listinfo/dev