Curt,

That sounds like an interesting approach.  Unfortunately, I am not completely 
following what you are saying regarding regular expressions in a HashMap.  Would you 
mind giving a simple example of one of your log messages to clarify your approach?

Thanks,
Mark

-----Original Message-----
From: Curt Arnold [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 04, 2004 11:45 AM
To: Log4J Users List
Subject: Re: Internationalization with log4j ?



On Mar 4, 2004, at 9:17 AM, [EMAIL PROTECTED] wrote:

> Greetings,
>
> I intend to realize my logging in my project with the log4j package, 
> but I
> need the internationalization of looging messages, e.g. written in 
> German
> or English language in a file depend on an attribut setting.
> But I don't know to do this for the best, in a simple way.
> In SYSLOG their are codes for facility/severity, which can be 
> transformed
> into the right text.
> But how to manage the message itself, which normally is written in 
> const
> string in source code.
>
> Thoughts and ideas about possible solutions would be very appreciated.
>
>
> Regards,
> Juergen Bauer
>

If most of your messages are never actually logged, the expense of 
localizing the messages can be expensive.  In addition, if you are 
adding logging for diagnostics, if you require that a developer make 
changes in the source and several external resources to add a 
diagnostic log, then you are going to discourage developers from adding 
log statements.

The approach that I took in a similar situation using log4net was to 
write a custom appender that used regular expression substitution to 
"translate" the original message into the target language.   I 
anticipated that the first few characters of a message were fixed and 
could be used to find candidate regular expressions in a hashmap, 
checked the potential regexs (usually only one) for a match and then 
evaluated the substitution pattern.

This approach did not incur localization costs for un-logged messages, 
did not require reworking the message dispatching framework and 
separated localization from development.  It did require some 
discipline in the formatting of logged messages, it was beneficial if 
messages started with a fixed string and had clear separation between 
fixed and parameterized parts of the log message.

Keeping the log message locale specified in the appender is also useful 
in situations were the language of your user and the language of the 
diagnostian may not be the same.  If someone was using an application 
of mine with a German locale, ran into a problem and sent me a 
diagnostic log in German, I'd be pretty helpless.  Assuming that the 
log reader has the same locale preferences as the user is not always 
appropriate.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to