[slf4j-user] Yet another facility for SLF4J i18n

[Chris Pratt]

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>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, 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
> http://mailman.qos.ch/mailman/**listinfo/slf4j-user<http://mailman.qos.ch/mailman/listinfo/slf4j-user>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/slf4j-user/attachments/20130618/a94948f4/attachment.html>