We have implemented an internationalisation interface to Log4J.
We are using a special class, called MessageCode to handle that. We use the
category name to store the message's identifier and the text to store the
parameters ('|' seperated).
The localisation can then be done directly in an Local
At 11:35 14.06.2002 +0200, Benoit Voisin wrote:
>Ceki,
>
>It would have been much simpler to use internationalization directly in the
>utility class or using the l7dlog. That is sure.
>
>But in our case it would not have fit, for two main reasons:
>
> - we want the user to choose which language h
Message-
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
Sent: 14 June 2002 11:30
To: Log4J Users List
Subject: RE: Internationalization/ResourceBundles in messages?
Benoit,
With hindsight, don't you think it would have been better/simpler to
provide support for internationalized logging in
Benoit,
With hindsight, don't you think it would have been better/simpler to
provide support for internationalized logging in your own utility
class? This utility class would internationalize log messages in an
appropriate way and instruct log4j to log these messages using the
correct character
I have also done a Internationalization but a display time one : only the
message code and the parameters are stored in the log file or DB and the
external process reading this info can use it´s own ResourceBundles to
localize the message.
We use it because the same log needs to be readable in di
I have implemented this... here's how I did it.
I have a subclass of Logger (call it "MyLogger", and I know there are
daily protestations on this list that "subclassing logger is a 'bad
idea'(tm)")
MyLogger does a few things, like push the host's IP address into the
NDC, provide convenience meth
