commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From micael <>
Subject Re: [logging] Internationalization of log messages
Date Fri, 23 Aug 2002 18:53:21 GMT
An option would be to decouple and then have a log reader that would be 
internationalized to the reader's language preference.  Code to do this 
would simply defer the internationalization option until the reader 
appeared on the scene, by whatever method and means.  The trick wouild be 
to decouple the log reader from the logger, but that should not be so hard.

At 11:55 AM 8/23/2002 +0200, you wrote:
>Hi people,
>I just had a look at the commons-logging package.
>As is clear from the documentation it is explicitly
>recommended that most log levels (fatal-info) should be
>This is an opinion which I can not share and where I must
>most strongly urge you to reconsider your position.
>Error messages fall into two categories.
>There are messages
>intended for the end user (who most often sits at the other
>end of a GUI). These messages should be internationalized,
>but you would normally not use a logging package to forward
>these messages anyway.
>Then there are messages intended for logging, most often
>to a file. These should _never_ be internationalized, but
>kept strictly in english. (To avoid any accusations about
>language-chauvinism: I am a Swede living in Germany.)
>In the first case it is reasonable that the end user receives
>an error message that he can understand and act upon.
>In the second case messages must be consist over different
>platforms and locales. Logged messages are intended for
>developers, debuggers or people otherwise seeking error
>in an "advanced way". Consider the case of the english author
>of a program who receives a log file with messages in
> >From the software development perspective one might also
>consider issues such as time lost finding a translation
>or the simplicity of finding a hard coded error message
>instead of a translation, when browsing through a source
>file. (I admit to considering such "pragmatic" issues
>In particular to the used formulation:
>"Expect these [the log messages] to be immediately visible on a console, 
>and MUST be internationalized."
>I would normally not expect log messages to be visible on a
>console (except for fatals). This is an indication that
>logging is not being properly redirected.
>In the non-gui/non-server context there might be valid
>reasons for messages being sent to the console (startup
>messages, "Oops I crashed etc."). One example would be a
>small command-line tool like sed or grep.
>In these cases internationalization would normally be valid,
>but then you are not actually logging -- although a separate
>logger instance could be used for such purposes.
>Let it be added that even this case is not completely clear.
>A beginner or someone with no knowledge of english is likely
>to prefer internationalized messages for command-line tools
>also (but is unlikely to use them anyway).
>More experienced users can be confused and/or irritated. I
>personally have for instance repeatedly been put in an
>environment where a shell, sql-client etc. has responded in
>German or Swedish, instead of the English I have expected.
>Having to map a poorly translated sentence back into
>something that actually makes sense has never amused me.
>To unsubscribe, e-mail:   <>
>For additional commands, e-mail: <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message