>> Please note that there are huge number of localized trace messages exists >> today. Someone must have been diligent enough to make that happen. >> > > My guess is that all strings were arbitrarily localized at some point - just > a guess though.
This is exactly right -- historically, we localized all strings from the get-go, and then evolved towards that being overkill. It doesn't seem worth it to retroactively de-localize things, though, so we've never moved back in that direction. -Patrick On Jun 8, 2010, at 12:33 PM, Michael Dick wrote: > On Tue, Jun 8, 2010 at 11:30 AM, Pinaki Poddar <[email protected]> wrote: > >> >> >> TRACE = Debug by the user >> DEBUG = Debug by the support/developer >> >>> Mike wrote: >>> I submit that such messages are really info or warning messages (an >>> example that proves me wrong >>> might be good). >> >> The example use case for TRACE is seeing how mapping strategy is getting >> decided or PCEnhancer working -- the monikers are familiar to the user >> (because s/he had specified it) -- and s/he is looking at the trace to >> decipher how the mapping annotations are being interpreted by OpenJPA (or >> not). The data presented in those messages are informative from a user >> point >> of view and *does not* expose the internal data structures as much. >> > > I disagree that such information is often of use to a user. Certainly most > users are not concerned with how the PCEnhancer works, or _how_ a mapping > strategy is decided. The result of these operations may be interesting. E.g. > "OpenJPA cannot find a mapping strategy for field Foo.bar" is interesting > to users and should be an INFO / WARNING message. "OpenJPA is using the > default mapping for field Foo.bar2 - no alternate mapping was specified" is > not interesting and should be trace. > > I don't really see these examples as being justification for localizing > trace. > > >> DEBUG messages, on the other hand, is a tool for support/development -- >> describes state of internal data structures if necessary (say state of a >> bit >> flag on when a flush is being called), no need to be localized/user >> focused. > > > > TRACE has traditionally been localized and thousands of localized trace >> messages do exist in the code base is strong enough reason to retain that >> behavior. Any other choice now will offer the weird output where >> non-localized messages intermingle the localized messages. >> > > >> If we feel a message is important enough to translate, then it should be >>> using either the INFO or WARN level. >> >> TRACE is not about importance of a message -- INFO is for that. TRACE is to >> expose the inner operational logic/flow to the user as much as possible >> without inundating with internal details. > > >> It is just the use of localized message in TRACE are not consistent. I >>> noticed that there are trace >>> records that are localized and some are not >> > >> That is more of an oversight -- I had never noticed a non-localized message >> in OpenJPA till recently. >> > > There are a few cases in 1.2.x which have been there for quite some time > (2008). Haven't checked 2.0.x, but there might be more there. One could > argue that this indicates that localizing trace is a surprise to most > contributors. > > >> Please note that there are huge number of localized trace messages exists >> today. Someone must have been diligent enough to make that happen. >> > > My guess is that all strings were arbitrarily localized at some point - just > a guess though. > >> Historically, we made the following choices: 2. Don't bother localizing >>> trace statements, >> >> Not supported by code. See PCEnhancer. >> >> ----- >> Pinaki >> -- >> View this message in context: >> http://openjpa.208410.n2.nabble.com/DISCUSS-localized-trace-messages-tp4877982p5154475.html >> Sent from the OpenJPA Developers mailing list archive at Nabble.com. >> -- Patrick Linskey 202 669 5907
