Internationalization with log4j ?

[Ju...@sit.rohde-schwarz.com]

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


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org

Re: Internationalization with log4j ?

[Curt Arnold <ca...@houston.rr.com>]

On Mar 4, 2004, at 9:17 AM, Juergen.Bauer@sit.rohde-schwarz.com 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: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org