Colin,
I don't know what's "normal," but I can tell you how we plan to I14E user
and log messages here (we're still in the process of defining Distributed
Application Standards that we will use going forward, and Log4J is part of
those emerging standards).
We plan to use ResourceBundles for every supported language, with the
default bundle being US English (where our headquarters are).
Each message has a key.
Each message also has embedded parameters that can be substituted with
information supplied by the User or from I14ED tables. No
message/log/display text is directly supplied by the application.
The applications know about message keys, parameter ids, and where to get
the data for parameter substitutions.
We have a MessageFormatter that uses the message key to obtain the
Locale-Specific message from the proper ResourceBundle and performs the
parameter substitutions.
We supply the completed message to Log4J if the message must be logged.
However, this general mechanism is more often used to simply display
informational messages to the Users.
So far, we have set the language for all our Log4J messages to US-English
(by virtue of that being the Default Locale), but translated messages can
be displayed to Users in their preferred language. However, if we ever
need to deploy our applications to a non-English speaking country, the
mechanism we are building should easily accommodate the language of that
country.
For the most part, our message framework is working well in design, with
only a few problems when we have to log a message that is displayed to a
non-English speaker. We try to ensure that parameters are language
neutral, but occasionally we must display back a column name or entered
data. In those cases, if we must also log the message then the
non-English words will be logged. We have decided that this is a support
training issue.
In the FWIW category, we wrap the log4j Logger so our message object (the
one containing the message key and a Map of parameter key-value pairs) can
be processed by the MessageFormatter before the message is passed to
o.a.log4j.Logger.
Your mechanism of translating the English language messages to some other
language has two potential problems that I see:
1. If you need to change the text of your English message, you must
change it in the code that generates the text as well as in each
ResourceBundle that has that text as a key.
2. You must subclass ListResourceBundle for each Language supported, or
you must create your own ResourceBundle subclass that can use plain English text as
the key. The most straight-forward
ResourceBundle for multilingual messages, the PropertyResourceBundle, does
not allow the use of spaces in its keys.
Mike McAngus
Associate Chief Engineer
Wendy's International
Knowledge Management
614-764-6776
"Colin MacDonald" <[EMAIL PROTECTED]>
06-05-2002 09:58 AM
Please respond to "Log4J Users List"
To: "Log4j-User" <[EMAIL PROTECTED]>
cc:
Subject: I18n via Renderer
So, what's the normal way of setting up log4j to display locale-specific
messages? I've messed around a bit with creating a Renderer to do it, but
I
haven't been able to get that to work.
The idea was to have a custom Renderer for java.lang.String, so you could
have a normal logger call like:
debugLog.error( "Something has gone wrong here" );
The Renderer class would take the message string and use it as a key for a
ResourceBundle. You could have a debugMessages_de.properties file with an
entry like:
Something has gone wrong here=Etwas ist los
(Sorry if that's wrong - my German is pretty minimal)
and the Renderer would spit out the translated message string.
I'm not sure if this approach is clever or grotesquely hackish. ;)
I added a line to my log4j.properties file like:
log4j.renderer.java.lang.String=my.RendererClass
The renderer is getting loaded and instantiated, but its doRender(Object)
method is never getting called.
Any ideas? Thanks!
-----------------------------------------------------------------
Colin MacDonald | Software Developer | Templar Corporation |
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.368 / Virus Database: 204 - Release Date: 5/29/2002
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
