[slf4j-user] Yet another facility for SLF4J i18n

[USHAKOV, Sergey]

Hi colleagues, and thanks for taking time and looking into.

'On-topic' first: I am really new to the SLF4J world (though I like it), 
so my judgements may be shallow. I admit that some new API for bridging 
SLF4J with substitution engines might make the whole design better. I'll 
be glad to support the new API, should it appear. Yet I do not feel that 
things are too bad now with substitution wrappers regarding CPU 
efficiency at trace/debug levels. The original org.slf4j.cal10n. 
LocLogger class does take necessary care to check if the requested 
logging level is enabled before doing anything CPU-expensive. So does my 
I15dLogger, as it was written under strong influence of the former one. 
Sorry if javadocs produce different impression. I'll get javadocs more 
clear on this in the next release.

Now maybe a little 'off-topic', if i18n is off-topic for SLF4J :) 
Gettext is really a great tool, and should I need to internationalize an 
existing application, it might be one of the first candidates to 
consider. Still its core design has a downside that 'consumer/resource' 
links are ordinary strings, like with standard ResourceBundle approach, 
and so are prone to getting out of sync; tools are available to detect 
these cases, but they require extra build phases. And extra build phases 
are also not an advantage IMHO... A definite advantage of gettext is in 
its pluralization facilities. This is something that my 'nobundle' 
library still needs to take care of...

But getting this discussion deeper may get off-topic indeed. And I'll be 
pleased to know your further comments. Should you prefer to continue in 
private mail, I'll be glad to :)  And I would especially appreciate if 
somebody could look into the I15dLogger code to see if everything is 
right with delicate SLF4J features...

Regards,
Sergey


On 19.06.13 03:24, Chris Pratt wrote:
> Toolforger, I totally agree.  I would love to merge the formatter from 
> http://code.google.com/p/anodyzed directly into a pluggable SLF4j 
> interface, now that the newest SLF4j supports variable arguments.  I 
> already check isLevelEnabled before doing any formatting, but it would 
> be much easier for end users if it was pluggable.
>   (*Chris*)
>
>
> On Tue, Jun 18, 2013 at 3:33 PM, Toolforger <toolforger at durchholz.org 
> <mailto:toolforger at durchholz.org>> wrote:
>
>
>     SOMEWHAT OFF-TOPIC FOR SLF4J
>
>     I'd seriously suggest reading the background information in the
>     gettext documentation.
>     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 <http://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.
>
>     NOW ON-TOPIC FOR SLF4J - FEATURE REQUEST
>
>     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.
>
>     _______________________________________________
>     slf4j-user mailing list
>     slf4j-user at qos.ch <mailto:slf4j-user at qos.ch>
>     http://mailman.qos.ch/mailman/listinfo/slf4j-user
>
>
>
>
> _______________________________________________
> slf4j-user mailing list
> slf4j-user at qos.ch
> http://mailman.qos.ch/mailman/listinfo/slf4j-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/slf4j-user/attachments/20130619/65492bcf/attachment.html>