commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Sitze <rsi...@us.ibm.com>
Subject Re: [logging] Internationalization of log messages
Date Fri, 23 Aug 2002 14:26:25 GMT
It's a tough call... there are very valid arguments (including end-user 
requirements) for NLS enabled logs.

Please remember that the guidelines are just that : guidelines.  They are 
not rules.  Use the logging as you will in your application.  As you work 
with others in the open-source community on TOOLING and MIDDLEWARE 
solutions, please be sensative to differing needs of the user community - 
and that generally means that NLS enabled components are appreciated 
(strongly, in my case).

We welcome your participation in correcting problems with language 
translations, directly or indirectly via bug reports.

*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development


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
internationalized.

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
swedish...

>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
secondary.)

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.

GrĂ¼sse,

Michael

--
To unsubscribe, e-mail:   <
mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <
mailto:commons-dev-help@jakarta.apache.org>



--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message