Yeah, that would be nice, but "displaying" would require implementing a
dedicated viewer application, whereas now we can simply use any standard
tool, like vi, tail -f, grep, etc.
Actually, we do have some machinery to implement logging in multiple
languages at the same time. We end up with multiple logfiles, one in
english for our support team, and one in the local language. However,
that code is specific to log4j because only log4j allows passing in any
Object as the "message" parameter.
We log Localizable objects that carry resource bundle info, resource key
and params, and use a special log4j Layout that handles such objets by
calling getMsgForLocale().
interface Localizable {
String getMsgForLocale(Locale locale);
}
The difference to the standard j.u.l approach is that localization is
done by the Layout and occurs at the latest possible time, just before
the message is written to the log file by the appender. This means that
the appropriate locale can be chosen individually for each appender.
Unfortunately, I don't see how this approach could be generalized to
support j.u.l as well :-(
/Lars
Dain Sundstrom wrote:
In these cases wouldn't you want to log the raw data (message id and
parameters) and then localize when displaying? That way anyone could
view the logs.
-dain
On Apr 9, 2006, at 1:33 PM, Lars Kühne wrote:
Hi Edell,
Nolan, Edell wrote:
[...] As regards getting the wrong language - this won't happen
because this is actually based on the locale - The Logic ensures it
picks the most specific one to the more generic one.
So in the case if you are in germany you will never get thai etc.
you got me wrong: We are in developing in germany, our customers are
running our software in Thailand (or wherever). Hence we will get
error messages that are not helpful at all for our engineers.
Note from the Class ResourceBundle API:
Resource bundles contain locale-specific objects. When your program
needs a locale-specific resource, a String for example, your
program can load it from the resource bundle that is appropriate
for the current user's locale.
That is the point. For GUIs the current user's locale ist exactly
what you want. For logfiles, it's exactly *not* what you want,
unless your developer/support team speaks each customer's language.
For us (and I assume most globally active software vendors?) this is
not the case.
Regards,
Lars
