Subject: Re: error codes

From: Antoine Leca <[email-masked]>
Date: Fri, 09 Apr 1999 10:19:42 +0200

Doug Royer ha escrit:
> 
> > From: "Lisa Lippert (Dusseault) (Exchange)" <[email-masked]>
> > Date: Thu, 8 Apr 1999 14:02:22 -0700
> >
> > There seems to be an assumption that whenever there is human-readable text
> > included, that the server must be able to translate that into the
> > appropriate language for the user.  Why is that?

"must" is too strong as a request, as I shown, but Doug have a point when
he said:
>         2) Forcing a CUA in France or Japan to display CS status
>            messages of a non-critical nature in English is bad manners.

So the answer is to me: "good-behaved".

But I believe everybody see that another criteria is coming into play:
"criticalness".

To give you a different example, we have here a firewall that is
derived of English-speaking work; we are mainly Frenchies to use it,
so the people quick complained that the first version only displayed
the error message (like "host not found") in English.

The present version displays:
- a banner showing the general meaning of the message, in French;
   this is part of the localization of the firewall
- an explanation in French that explains what can had happen usually;
   this is also part of the localization
- a banner to refer the user to the support if needed; this is generic,
   and is configured by the admin people here
- then, the same explanations as 1st and 2nd parts in English, giving
   also all the transcription of the faulty interchange with full
   messages.

Of course, usually people only read the beginning, which are in French,
and are in effect the same as numeric codes as we discuss.  Critical
informations, if any, has to go in this area.

OTOH, techies do read the whole page (when something not normal happens),
and so are required to read English; here non-critical messages in
English won't hurt (of course, the more near from my current LOCALE,
the better).

> Perhaps a compromise.
> 
> Maybe we can have some kind of tag or rule so that the CUA knows
> that a specific status message from the CS is not a typical status
> message, but something that the CUA really needs to display to the user.

Yes, I like this idea.
In fact, I was thinking about the contrary: adding a brief translation
of message code to English as a form of comment, but saying that they
are "non-normative" and what really matters is the numeric code.  But
allowing also non-comment messages for the kind of things I was talking 
about.

But I believe your idea is better, in the sense that the critical
messages are now an additionnal form, thus they are likely to *not*
being overused (at least at the beginning).

Antoine

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 9 Apr 1999 09:14:16 +0200

Regarding error codes, please check the discussions / drafts etc from 
the ftpext working group working with internationalization and 
standardization of ftp.

There might be some ideas you can borrow from that wg.

   Patrik
------------------------------------------------------------------
Area Director, Applications Area               Email: [email-masked]
IETF                                             URL: http://paf.se
                                          PGP Key ID: 0xBD236602

   In theory there is no difference between theory and practice,
   but in practice, there is.

---

From: Doug Royer <[email-masked]>
Date: Thu, 8 Apr 1999 19:06:08 -0700 (PDT)

> appropriate language for the user.  Why is that?

I see it as two valid new points.
	
	1) There are some status messages that can't be covered
	   with generic messages numbers.

> Antoine's example of a
> specific dialect is a good example why we can't expect that to happen.
> ...
> 
> Instead, I've always understood text-based error messages in protocols to be
> a convenience for protocol and implementation designers, testers, coders,
> debuggers, system administrators, etc.  This makes it possible to use
> strings which are brief but informative to techies, like "BADLY FORMATTED
> VCAR".

Perhaps a compromise.

Perhaps a '*' could be used to mean "this really needs to be seen
by a user":

	1.2.3 cap://host.com/a/b/c * "this needs to be displayed"
	
Most IMAP server messages are not displayed to the users. So adding
them in the same way as IMAP I think would simply not gain anything
at all. They would not be displayed anyway.

Also I think the standard status messages should be optional.

-Doug