incubator-yoko-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <>
Subject Re: Logging guidelines
Date Sun, 25 Jun 2006 08:42:29 GMT
Lars K├╝hne wrote:
> Daniel Kulp wrote:
>>> So, INFO and higher messages should be localized?
>> I hate to say this after the last logging discussion, but that's 
>> something that probably should be open to discussion.   
> Sigh... :-/
>> I can say that for Celtix, our policy is that the WARNING and SEVERE 
>> should always be localized.   Those are the types of things that an 
>> administrator probably needs to know immediately to be able to 
>> diagnose and fix a problem.    
> Like I said in the earlier threads: Please make sure that it is at 
> least *possible* to enforce english messages somehow without affecting 
> the default locale.
> We send our technical support staff to other countries to do initial 
> system setup. It would be a nightmare for them to be confronted with 
> error messages in the local language. Same for support requests, we 
> won't be able to help our customers if we can't read the error 
> messages coming from our own software.
>> ("Could not connect to port 1234", "Could not resolve host name", 
>> etc..., although a lot of those things should propogate up via 
>> localized exceptions)
> Local admins of our systems typically speak english well enough to 
> understand messages like this, not having them localized won't be a 
> problem.
>> The FINE and lower stuff is really just targetted at us.   You need 
>> to be really familliar with the code to get much use out of that.   
>> Thus, not locallizing those is probably preferred.
> +1
>>     The INFO is in the "grey" area.   If it's something and 
>> administrator may need to know, go ahead, but I'm not so sure about 
>> requiring it.
> I think it would be easiest to not localize yoko log messages at all, 
> and that would be sufficient for the overwhelming majority of users.
I've always been of the opinion that forcing operations staff to slog 
through logs which were really made by developers for developers is 
cruel.  IMO, we need an orthogonal mechanism to guide the operator 
through the server's then current morass.


View raw message