Did you look at how we emulate the localization in the Log4j 1.x bridge? I wrote a LocalizedMessage to handle that. Personally, I don’t like the class because it was implemented solely to make Log4j 1.x work more or less the way it always did.
We people talk to me about localization I would tell them that if that is what you want you should be logging Messages that contain a message number and substitution data. The localization should happen in the application that is reading the log file, not writing it. However, I seem to have a hard time convincing people to do it that way. In any case, if you really want to do it that way then IMO the way to do it would be to use a ResourceBundleMessage or something similar. Ralph On Jan 31, 2014, at 7:16 AM, Gary Gregory <[email protected]> wrote: > On Fri, Jan 31, 2014 at 10:08 AM, Remko Popma <[email protected]> wrote: > Hm... I should have looked it up sooner... :-( > > We're all sync'd up now :) > > Gary > > > > On Sat, Feb 1, 2014 at 12:07 AM, Gary Gregory <[email protected]> wrote: > On Fri, Jan 31, 2014 at 3:06 AM, Remko Popma <[email protected]> wrote: > I should have looked this up... > l7dlog() methods replace the user-supplied key by its localized version from > the resource bundle. > > So this is about the log message text, not the level names. Please disregard > my previous email. > > Now I see this :) ah! Good digging Remko! > > Gary > > > One of my colleagues raised an interesting point: We have some systems where > the log files are tailed and monitored, and alerts are raised for certain > keywords. For those systems it is important that the format doesn't change > when upgrading. > > That may actually be a good argument in favor of supporting localization in > log4j 2.0... > > > > > On Friday, January 31, 2014, Remko Popma <[email protected]> wrote: > I asked a number of Japanese and Chinese colleagues, but nobody seemed to > want the level names translated in the log output. They were all happy with > the English names. About half advised against translating, half was > indifferent, and one person said he wouldn't use it himself but he thought > that other people might want it. > > So maybe this is a "nice-to-have" rather than a "must-have" feature? > > On Friday, January 31, 2014, Remko Popma <[email protected]> wrote: > What does the localization do? > Is it for translating the built-in level names? > > > On Friday, January 31, 2014, Gary Gregory <[email protected]> wrote: > In Log4j 1 we use: > > - org.apache.log4j.Category.setResourceBundle(ResourceBundle) > - org.apache.log4j.Category.l7dlog(Priority, String, Object[], Throwable) > > It seems v2 makes sidesteps the whole localization/i18n issue. > > What's the migration path for that? > > So we'll never play nice with some projects that require playing with > resource bundles. > > Should we recommend creating a Logger wrapper to hold a resource bundle? I'm > not sure what else we can do... we could provide it... > > Thoughts? > > Gary > -- > E-Mail: [email protected] | [email protected] > Java Persistence with Hibernate, Second Edition > JUnit in Action, Second Edition > Spring Batch in Action > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > > > > -- > E-Mail: [email protected] | [email protected] > Java Persistence with Hibernate, Second Edition > JUnit in Action, Second Edition > Spring Batch in Action > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > > > > > -- > E-Mail: [email protected] | [email protected] > Java Persistence with Hibernate, Second Edition > JUnit in Action, Second Edition > Spring Batch in Action > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory
