|
From: <ina...@wo...> - 2003-12-09 03:26:09
|
As you remember, in the beginning of the project we decided to
internationalize our
log messages. It seemed a good thing to do, back then, as we are aiming on
a wide
international audience.
However, looking at the experience, I am inclined to think that we really
overdid here
and made our code much harder to write, less readable. Internationalized
log messaging
code is, arguably, way too clumsy and long.
Compare two approaches for a simple log:
1) Using i18N:
//-- initialize logger, once per class:
private static Logger logger =
I18NHelper.getKernelLogger(RequestProcessor.class);
//-- Put the message in the appropriate resource.porperties file:
RequestProcessor.actionFormName=Action form name is {0}
//-- Code for each log in the source:
if (logger.isDebugEnabled()) {
logger.l7dlog(Level.DEBUG, "RequestProcessor.actionFormName",
new Object[] {newMapping.getAttribute()}, null);
}
2) Using simple logging:
//-- initialize logger, once per class:
private static Logger log = Logger.getLogger(RequestProcessor.class);
//-- Code for each log in the source:
log.debug( "Action form name is " + newMapping.getAttribute());
----------------------------------------------------------------------------------------------------
The second approach is, obviously, simpler, faster and code is much more
readable.
Do we loose much by not internationalizing logs? Not really. There are
open-source projects
with far wider outreach and audience than Digi can realistically get in
the nearest future
(e.g. Hibernate) that do not internationalize their logs.
We have our javadocs only in English, our mailing list is in English -
pretty much all
the resources and documentation are in English, so spending so much effort
on
internationalizing just logs - does not really seem reasonable, and I am
beginning
to think we are really doing an overkill here, which is worse - making our
code far less
readable and that is way worse than having logs only in English.
I propose we begin using simple approach to logging with neat and clear
log.debug(), log.info(), log.error(), log.fatal() etc. methods.
It does not mean anybody needs to spend precious time, now, and change the
existing
code - switch to the simpler logging, but I think we can use the
alternative approach for
the future development.
thank you
Irakli
|