Re: multipart/alternative extension

At 18.08 -0400 01-05-06, Keith Moore wrote:
>please explain to me how an existing UA will fare any better when
>presented with multipart/choices than it fares when presented
>with multipart/alternative.

Suppose a message contains three body parts, containing the
same text in German, English and French. Suppose the English
text is the original, the other are not-very good machine
translations.

Multipart/choices will work like multipart/mixed for MUAs
which do not support multipart/choices. This means that
all three parts are delivered to the user, and the user
can choose which part to read. If the parts are given
suitable file names using Content-Disposition, for example
"German-machine-translation", "English-original", "French-
machine-translation" most MUAs will show these file
names and thus help the users choose which attachment to
read.

Some MUAs show the first body part of multipart/mixed,
and treat the others as attachments. It might be better
in such a case to add an almost empty body part first
which just says that the other parts contain the same
info in multiple languages.

This, as well as how to provide translation of the
Subject, are issues which might be discussed if IETF
starts work on this issue.

(If IETF wants to start work on this, I have already
started a mailing list which can be used,
LANGTRANS@psychmax.psychology.su.se, use Listserv
conventions to subscribe. Archives at
http://salut.nu/forum/uno/6/1/.)

Multipart/alternative will mean that users of many existing
MUAs will be shown only one of the body parts, usually
either the first or the third. A user who prefers to read
the message in the language used in any of the other body
parts will not even be told that there are other language
versions.

It is obviously better to give a recipient a choice of
translations to different languages, than to give the
user only one single translation, which is not adapted
to the language preferences of the user.
-- 
Jacob Palme <jpalme@dsv.su.se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Received on Monday, 7 May 2001 07:27:08 UTC