[slf4j-user] Yet another facility for SLF4J i18n

Toolforger toolforger at durchholz.org
Wed Jun 19 00:33:51 CEST 2013


I'd seriously suggest reading the background information in the gettext 
gettext is a great improvement over most of its would-be successors, and 
I'm awfully sorry to say that your approach does not constitute an 
exception. (I'm willing to elaborate in private mail, this is indeed 
off-topic for slf4j.)

Also, from the Javadoc, it seems that you're doing substitution in 
logger.info, logger.warn etc, before slf4j has a chance to check whether 
the message should even get printed.
That's negating SLF4J's mission statement of minimum overhead in the 
do-not-log case. This is a serious problem for trace messages, and 
sometimes for debug messages, too.


I18n for SLF4J's messages is essentially not very useful because some 
languages require a different sentence fragment order, which means that 
parameter order might have to be changed and SLF4J does not allow that. 
(Plural handling can be done, but it's not very
What I would like to see is an API for plugging in alternate 
substitution engines. This should be called afterSLF4J has determined 
that the message indeed needs to be logged.
Engines that I can easily see use cases for are: slf4j-native with {}; 
JDK MessageFormat with (among other things) {0}/{1}/...; gettext; and 
the i18n facilities of ICU4J. Since a program might consist of many 
libraries from different sources, this should probably be configurable 
on a per-package basis, and hardcoded in Java because the choice of 
substitution syntax is hardcoded, too.

Feedback on this feature request welcome.

More information about the slf4j-user mailing list