logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anders Kristensen <akristen...@dynamicsoft.com>
Subject Re: backend l10n
Date Tue, 06 Mar 2001 23:02:36 GMT

"Johnson, Clay" wrote:
> 
> L as in Localization.  It just looks like a Turkish I :)

It was the 0 (zero) I was wondering about. Shouldn't it be '8'?

> 
> A colleague thinks the answer may involve ObjectRenderer.  There's little
> said about it in the javadoc.  Is it, or can it be used as a plugin to alter
> the behavior of a predefined appender?  If so, could I use it perform l10n
> in the appender(s)?

Yes you probably could. Your ObjectRenderer would know about your
special type of Objects and would convert to String in locale specific
manner.

> 
> > -----Original Message-----
> > From: Anders Kristensen [mailto:akristensen@dynamicsoft.com]
> > Sent: Tuesday, March 06, 2001 3:29 PM
> > To: LOG4J Users Mailing List
> > Subject: Re: backend l10n
> >
> >
> > Do you not mean "l18n"?
> >
> > "Johnson, Clay" wrote:
> > >
> > > Folks,
> > >
> > > I have a requirement to defer l10n processing to appenders,
> > rather than at
> > > the publisher of the log event, in order that different
> > appenders may
> > > localize the same event according to different locales.
> > Since the l10n
> > > methods in Category rely on preregistered ResourceBundles,
> > that doesn't
> > > work. Furthermore, with only a cursory look at the
> > internals, it appears
> > > log4j converts the message Object to a String to construct
> > a LoggingEvent
> > > *prior* to distributing that to all appenders.  If that is
> > true, I worry
> > > whether my requirement can be met without substantial
> > > modification/extension.
> > >
> > > One approach is to marshall my ResourceBundle name, key,
> > and replaceables
> > > into a string, and then implement my own Appender that
> > unpacks these,
> > > localizes according to *its* Locale (determined at
> > construction), and then
> > > proceeds to log the localized String.  The immediate
> > concern with this
> > > approach is apparent forfeiture of all existing Appender
> > functionality that
> > > I otherwise want to leverage, as well as Layout processing,
> > since I would
> > > have co-opted it to marshall my Object.
> > >
> > > Please tell me there's a simpler way to do this that
> > doesn't up-end the
> > > framework.
> >
> > You should be OK. Just don't use the String which has already been
> > constructed or  else use it a as a key into the resource bundles (like
> > Category does). Judging from what you're saying you're planning on
> > passing in non-Strng object which you'll use in Appenders/Layouts to
> > create localized log messages in some way.  The LoggingEvent now
> > contains the original Object *in addition* to the String
> > version of same
> > Object so you can just use the Object.
> >
> > >
> > > Thanks,
> > > Clay
> >
> > --
> > Anders Kristensen
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: log4j-user-help@jakarta.apache.org
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: log4j-user-help@jakarta.apache.org

--
Anders Kristensen

Mime
View raw message