[enormous cc: list trimmed. Is that bad form? Do people like having two
copies?]
From: Tomas Fasth <tomas@???>
> I don't understand this kind of attitude. We
> can NEVER make a progress in this area as long as we think
> notifications to be pretty printed with sofisticated articulation in
> one specific language. It's a useless attitude for the non-english
> speaking world. It HAS to be interpretable by machines so it can
> translate to something users can understand INDEPENDENTLY of
> preferred language at the MTA site.
HEAR HEAR!!
I absolutely agree--your other comment about MUA progress being spurred by
standardisation on the MTA I believe is very convincing too.
Working in an international company where a significant number do not speak
particularly good English it seems ironic to me that so much effort goes into
wording these error messages where the subtlety/nuance becomes increasingly
restricted to an intellectual pursuit by the composers. (Without doubt a
useful one but missing the larger point of conveying information to the
recipient.)
It also surprises me that in this day and age of increasing web ubiquity that
software designers don't provide URLs to lengthy error descriptions that
could include 'tricks' like language selection (based on charset, perhaps)
and similar personalisation. For example, anchor that to the server who sent
it and tag it with a message-id you could have a personalised explanation
with full diagnostic info based on local config, etc.
"Your message didn't get delivered as well as you might've hoped. Here's why
http://mta.mycom.tld/oops.cgi?lang=en&code=552&msgid="
(I had started writing something like this.)
> The fact that some people still
> seem to live in the past where telnet against your SMTP and POP
> servers was the interface to internet messaging, is not a good enough
> argument to not use an available standard for delivery failure
> notifications.
I meet people who don't see a single use for HTML or non-ASCII in email
either. Baffling isn't it?
Paul
