No problem, just let it flow ;) Actually I'm not sure why all this internationalization on internal error messages at all ^^
To be honest: it _s u c k s_ to have german error messages in my logs! Or imagine to live in Hungary: You can google almost _nothing_ that will help you if you only have the hungarian error message... You would be able to find tons of answers to an actual problem if you _would_ have the english version of the error message - but instead you are stuck with a useless german, hungarian, swedish or whatever error text. What is the benefit of having i18n logs at all? This will only be browsed by engineers anyway. Messages who address end users are certainly a different thing - but I would not handle those via a logger mechanism! But even error messages (shown to the end user via e.g. an error page) will not be handled via a logger. So for me all the i18n discussion is moot for the _logger_ backend (but certainly a valuable feature for a Error-Message system). LieGrue, strub --- On Sat, 6/11/11, Clark, Gil W. <gil_cl...@intuit.com> wrote: > From: Clark, Gil W. <gil_cl...@intuit.com> > Subject: Re: Get thee to the Core... > To: "Maven Developers List" <dev@maven.apache.org> > Date: Saturday, June 11, 2011, 4:06 PM > Oops, sorry all. I was > responding to Ralph about logging. This doesn't > really have much to do with Maven. > > On 6/11/11 9:03 AM, "Clark, Gil W." <gil_cl...@intuit.com> > wrote: > > >Interesting thread. So we are using Splunk as our > log "viewer" and it has > >built in ability to map message ids to the localized > strings. But, it's > >expensive for Splunk to do this (both in $ and > processing time). So while > >its architecturally more pure it requires a good log > viewer that everyone > >has access to. > > > >On 6/10/11 10:45 PM, "Ralph Goers" <ralph.go...@dslextreme.com> > wrote: > > > >>Actually, SLF4J's tie to Ceki's I18n project is one > thing I really > >>dislike. IMO, localization should be done at > the last possible moment. > >>If you really want an internationalized log then > you should be logging > >>message ids and data and then doing the > localization in your log viewer, > >>not as you are writing the records. > >> > >>Ralph > >> > >>On Jun 10, 2011, at 8:42 AM, Stephen Connolly > wrote: > >> > >>> personally, there are a number of issues I > have had with how > >>> slf4j/logback handles message formatting for > i18n... other than the > >>> logging frameworks I have rolled myself, slf4j > is the closest I've > >>> seen to logging done right... but it is still > a bit far off the right > >>> path... > >>> > >>> Oh logging why do you have to be so fragmented > and crap in java > >>> > >>> On 10 June 2011 16:28, John Casey <jdca...@commonjava.org> > wrote: > >>>> > >>>> > >>>> On 6/10/11 3:48 AM, Mark Struberg wrote: > >>>>> > >>>>> We partly use slf4j internally already > for tests, etc. > >>>>> But moving the whole Logger mess over > to slf4j would be really great. > >>>>> There are lots of tests (I sadly also > found productive code too) > >>>>>still using > >>>>> System.out.println. > >>>>> > >>>>> The question is if we (internally) > drop > >>>>>org.codehaus.plexus.logging.Logger > >>>>> completely and use slf4j directly, or > if we pimp up the plexus Logger > >>>>>and > >>>>> add various stuff. > >>>> > >>>> I've been thinking about this for some > time now, actually. If you look > >>>>at > >>>> the MAE stuff in the sandbox, I'm pretty > sure that's using log4j > >>>>directly. > >>>> > >>>> Personally, I don't understand what value > the Plexus > >>>>logger/loggermanager > >>>> has, especially given the configurability > of these other logging > >>>>frameworks. > >>>> > >>>> I'd be in favor of providing a "default" > logging configuration file in > >>>> either the Maven app directory or in > ~/.m2, and then letting people > >>>> customize from the command line to > highlight specific > >>>>components/packages. > >>>> > >>>> Although, having said that, one of my pet > peeves about the logging > >>>> frameworks is they haven't shifted to > using String.format, > >>>> MessageFormat.format, or whatever > under-the-covers as a way of > >>>>limiting > >>>> string concatenation in cases where a > particular log level has been > >>>> disabled. > >>>> > >>>> Even something as simple as the attached > code would be a nice facade > >>>>for > >>>> logging, IMO...but it's more of a > wish-list item than anything else. > >>>> > >>>> In short, yes, let's think about switching > to a better logging > >>>>framework. We > >>>> can deprecate the plexus logger, and > eventually get rid of it! > >>>> > >>>>> > >>>>> We would need to do some compat code > anyway, but I'm not sure if it > >>>>>pays > >>>>> off to restrict ourself. At least not > after I saw that even the > >>>>> LoggerManager uses > System.err.println: > >>>>> > >>>>> // TODO: use a logger! > >>>>> System.err.println( "There was no such > logger '" + key + "' " + > >>>>>hashCode() > >>>>> + "." ); > >>>>> > >>>>> dumdidum :) > >>>>> > >>>>> LieGrue, > >>>>> strub > >>>>> > >>>>> > >>>>> --- On Fri, 6/10/11, Ralph Goers<ralph.go...@dslextreme.com> > wrote: > >>>>> > >>>>>> From: Ralph Goers<ralph.go...@dslextreme.com> > >>>>>> Subject: Re: Get thee to the > Core... > >>>>>> To: "Maven Developers List"<dev@maven.apache.org> > >>>>>> Date: Friday, June 10, 2011, 5:03 > AM > >>>>>> > >>>>>> On Jun 9, 2011, at 2:45 PM, Benson > Margulies wrote: > >>>>>> > >>>>>>> I'd like to offer a small > suggestion. > >>>>>>> > >>>>>>> One of the big barriers to > maven happiness is the > >>>>>> > >>>>>> difficulty of > >>>>>>> > >>>>>>> understanding, in some cases, > why it does what it > >>>>>> > >>>>>> does. > >>>>>>> > >>>>>>> This suggests to me three > efforts that might offer an > >>>>>> > >>>>>> opportunity to > >>>>>>> > >>>>>>> learn core code without > drowning. > >>>>>>> > >>>>>>> 1: take up slf4j, and thus > allow component (indeed > >>>>>> > >>>>>> class) by component > >>>>>>> > >>>>>>> log control as an alternative > to the giant -X spew. > >>>>>> > >>>>>> Now that is an interesting idea. > For the past year I have > >>>>>> been working on creating Log4j 2.0 > pretty much by > >>>>>> myself. This would be a > great way to integrate it into > >>>>>> something useful. > >>>>>> > >>>>>> Ralph > >>>>>> > >>>>>> > >>>>>> > >>>>>>--------------------------------------------------------------------- > >>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >>>>>> For additional commands, e-mail: > dev-h...@maven.apache.org > >>>>>> > >>>>>> > >>>>> > >>>>> > --------------------------------------------------------------------- > >>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >>>>> For additional commands, e-mail: dev-h...@maven.apache.org > >>>>> > >>>> > >>>> -- > >>>> John Casey > >>>> Developer, PMC Member - Apache Maven (http://maven.apache.org) > >>>> Blog: http://www.johnofalltrades.name/ > >>>> > >>>> > >>>> > --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >>>> For additional commands, e-mail: dev-h...@maven.apache.org > >>>> > >>> > >>> > --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >>> For additional commands, e-mail: dev-h...@maven.apache.org > >>> > >> > >> > >>--------------------------------------------------------------------- > >>To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >>For additional commands, e-mail: dev-h...@maven.apache.org > >> > > > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >For additional commands, e-mail: dev-h...@maven.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
