On Wed, 11 Jun 1997, Chris Newman wrote:
> Yes, I'm referring to ACAP server messages (which are necessary since it's
> not possible to predict all errors for all potential implementations).
> One specific example raised was a plug-in kerberos module which may not
> have an appropriate localized error, even if the server does. Also,
> operating system error messages are an issue (even if I have the right set
> of ACAP errors for the client's preferred language, that doesn't mean the
> OS perror() strings have been localized).
>
> Such cases are far too likely to happen in real life to be ignored.
The best thing, in most cases, is to rely on numerical codes as long
as possible, and to convert to text as late as possible. This helps
with many things, such as:
- Giving software further down the channel a possibility to do something
reasonable (e.g. retrying some operation with better parameters,
instead of bothering the user)
- Giving software further down the channel a possibility to rephrase
the message in a way appropriate for that level (i.e.
speaking about datasets and attributes that are protected
or not, and not about "security objects" or whatever
Kerberos or another plugin might use).
- Giving the message in the lingo the user is expecting (which may
be different e.g. on a Mac vs. on a Windows box; messages
for system administrators vs. plain end users)
- Giving highly tailored messages to special user categories (e.g.
very short texts with good accustic support such as an
appropriate sound instead of just reading the long
error message in a computerized voice style in the
case of blind users).
- Allow to give more convenience to the user (icons, help,...)
- Allowing for as many languages as possible to be covered (which
is easier closer to the user)
Most operating systems and Internet protocols do a very good job at
trying to avoid real text messages. Of course, server and client
implementations get smaller if things are just passed through.
But it's not in the interest of end users. And one shouldn't
attempt to market a product as comming with messages in some
language if that's not true for all the messages.
The only occasion I have seen multilingual error messages (or
where I have actually produced them myself, because I converted
a system to work multilingual) is where the original system
put cryptic system error messages in brackets after a nicely
understandable message to the user. If I would have to tag
such a message, I would rather use the tag
cryptic-ignore-or-show-to-a-sysop
even if the original writer's mother tongue would qualify
for us-en.
The conclusion from these thoughts would be: If the user gets
mixed-language error messages, it may be a strong indication
that the system can (and should!) be improved.
> > I was thinking about writing an I-D for defining such a thing
> > (together with the response of the server), written so that it
> > could be easily used/adapted in various IETF protocols that need
> > it. Any comments/interest/showstoppers/coauthors?
>
> I've already seen two proposals written up to do this in the IMAP/ACAP
> context.
Would you care to give us a pointer? I think a proposal should be
as general as possible, so that other protocols can also use it.
Regards, Martin.
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:34 EDT