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
[email protected]
http://www.slf4j.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
[email protected]
http://www.slf4j.org/mailman/listinfo/dev
