[slf4j-user] Internationalisation of log messages

[Ceki Gulcu]

Hi Simon,

Comments inline.

simon wrote:
> Hi,
> 
> I have a number of questions about generating internationalised log
> messages.
> 
> (1)
> 
> In the java.util.logging API, a resource-bundle name can be provided
> when fetching a Logger instance:
> 
>  Logger log = Logger.getLogger("category", "logMsgBundle");
>  log.log("key1", arg1, arg2, arg3);
> 
> As far as I can see, slf4j supports the second part of this (multiple
> args), but not the first (specifying the resource bundle).

Yes, indeed.

> So with slf4j, how is the underlying log implementation supposed to find
> the right resource bundle to create the final message to output?
> 
> I see here that writing a "filter" is suggested:
>   http://www.nabble.com/Internationalization--to8698529.html

The first part of the answer in the message you mention is correct.

You could internationalize your message *before* calling a given SLF4J logger 
using a utility class of your own cooking.

The seconds part of the answer, namely that you could write an 
internationalization filter is  *incorrect* as for as log4j and JUL are 
concerned, precisely for the reasons you describe in point (2) of your message.

> But that code would be (a) specific to a particular logging
> implementation, and (b) have to be configured by the user in their
> logging configuration, yes?
> 
> And if the logging lib is just in a parent classpath, while the app
> doing the logging is in a child classpath, then aren't there problems
> with the filters not having the resource bundle on the classpath?
> 
> Why doesn't slf4j take a resource-bundle as a parameter to the getLog
> method? Is it because then:
>   Logger log1 = LogFactory.getLogger("cat1", "res1");
>   Logger log2 = LogFactory.getLogger("cat2", "res2");
> would require supporting multiple Logger objects for a single category,
> and this is tricky to implement efficiently?

As long as the resource-bundles are not inherited (by child loggers), I don't 
think the above would be tricky to implement. As for "would require supporting 
multiple Logger objects for a single category" you probably meant "would require 
multiple resource-bundles per logger". If so, supporting multiple 
resource-bundles per logger, is probably not something you would want in practice.

> (2)
> 
> It appears from the code that for slf-over-jcl and slf-over-log4j, if a
> call like this is made:
>    log.info("key1", arg1, arg2, arg3)
> then all that is passed to the underlying logging impl is the key,  ie
>    [INFO] key1
> is what gets output.
> 
> This kind of think would work:
>    log.info(
>     "A problem in {0} occurred because {1} did {2}",
>     arg1, arg2, arg3)
> but leads to some rather odd "keys" in the message bundles.

The slf4j adapters for log4j and JCL do *not* pass on the parameters to the 
underlying logging system. SLF4J does the the parametrization and passes on only 
the transformed message as a String.

How about if SLF4J offered support for internationalization without modifying 
the org.slf4j.Logger interface? That way, there would be one generic library 
offering support for internationalization, namely SLF4J, but without impacting 
the existing interfaces?

In any case Simon, I would like to thank you for your insightful questions/remarks.

Cheers,

-- 
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch