commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From micael <caraun...@harbornet.com>
Subject Re: [logging] Internationalization of log messages
Date Mon, 26 Aug 2002 17:27:22 GMT
If the log reader, and not the log writer, makes the decision on the 
language issue, there is no problem.  The problem is in any design where 
the logging writer makes the decision on the language.  The problem is that 
we think of logs as GUIs rather than data.  Well, that is the problem the 
way I see it anyway.  Logs should be data, with readers that convert the 
data as we like.  The data should be language neutral.

At 05:20 PM 8/26/2002 +0200, you wrote:

>Craig R. McClanahan wrote:
>>On Mon, 26 Aug 2002, Nicola Ken Barozzi wrote:
>>
>>>Date: Mon, 26 Aug 2002 10:50:50 +0200
>>>From: Nicola Ken Barozzi <nicolaken@apache.org>
>>>Reply-To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>,
>>>     nicolaken@apache.org
>>>To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
>>>Subject: Re: [logging] Internationalization of log messages
>>>
>>>
>>>Eriksson, Michael wrote:
>>>
>>>>>...
>>>>>
>>>>>At my company (Sun) -- and I wouldn't be surprised if it were true at
many
>>>>>others -- our internal software development standards for i18n are
>>>>>reasonably close to what these guidelines say, but we still use a MUST
for
>>>>>all log messages designed to be seen by normal users.
>>>>
>>>>
>>>>Now there is a very interesting point. As I see it "normal users", would
>>>>normally not be involved with logging at all. Instead other means should
>>>>be used for communicating problems to the users. At the point where
>>>>a user actively examines the log files he, to me, indicates that he
>>>>is a power user, developer, ... or is at least likely to develop into
>>>>such. People in this category will normally be competent in
>>>>english (or else they will have many other problems, e.g. reading this 
>>>>mailing
>>>>list, getting good literature etc.)
>>>
>>>This is the conclusion we have come to @ the Cocoon project.
>>>One thing is Logging, another is user information.
>>This conclusion assumes that system administrators are not "users" worthy
>>of being paid attention to.
>
>Never said that.
>
> > Limiting i18n to only the people executing an
>>app (versus those installing and maintaining it) is way to narrow for my
>>taste.
>
>Again, never said that.
>
>>The assumption that everyone in the latter category will be familiar with
>>English is totally bogus.
>
>?
>
>Ok, I haven't been clear enough.
>
>The ones that just need English are the developers of the system.
>
>The site users, definately need informative localized error messages, but 
>usually it's the webapp that must supply nice screens, and remain 
>consistent with the l&f of the site.
>The i18n is defined in the app.
>
>Sysadmins are basically in between, hence they will be more near to the 
>users if less experienced, and to developers if more experienced.
>
>Now, the messages that they will have to cope with are not log dumps
>or Webapp infos, but the server error screens, like the white and
>blue ones that Tomcat has taken (cool :-) from Cocoon.
>
>*These* can be localized, and as I said I want the notification package to 
>attempt to do just that.
>
>message --(  notification (i18n, faqs, templates)  --(  logging
>
>Basically this package would decouple the creation of a more meaningful 
>error message from the creation of the log entry.
>
>A server using "notification" can decide where it wants the i18n to happen 
>and how, along with other beautifications of the message or templating.
>
>--
>Nicola Ken Barozzi                   nicolaken@apache.org
>             - verba volant, scripta manent -
>    (discussions get forgotten, just code remains)
>---------------------------------------------------------------------
>
>
>--
>To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
>



--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message