Jacob Palme | 13 Nov 04:36 2000
Picon
Picon

Language translation in e-mail standards

I have been thinking many times on how to best support
language translation in e-mail standards. We have now
received a research grant, which will allow us to
implement this next year.

Some requirements on a language translation standard:

(1) It should cater for both machine and human translations.

(2) It should cater for more than one translation of the
     same message, usually first a machine translation and
     later on a human translation of the same message.

(3) It should cater for both the case where all language
     versions are sent at the same time, and when one
     language version is sent first and the translations
     are sent later.

(4) It should cater for sending a message to a human
     or machine for translation, with information on
     where to forward it after translation.

(5) It should cater for people to indicate that they
     can read more than one language, and to indicate
     preferences, like in HTTP where you can specify
     Accept-Language: da, en-gb;q=0.8, en;q=0.7.
     It should users to specify that they want
     for example the original language for French
     and English, and that they prefer a German
     original to a machine-translation to English,
(Continue reading)

Jacob Palme | 13 Nov 11:29 2000
Picon
Picon

Re: Language translation in e-mail standards

I have made some tests on how some existing mailers (Eudora,
Netscape, Outlook Express, Hotmail, First Class, Pine, KOM 2000)
handle different ways of sending a message translated to
multiple languages.

The full test report can be found at
ftp://ftp.dsv.su.se/users/jpalme/draft-palme-multipart-language-00.txt

I started with the simple case of multipart/alternative with
one language version in each body part. None of the mailers
could handle this very well. Some mailers choose one
language part, some another part, but my impression was
that this choice was not made based on the language
preferences of the user for any of the mailers.

When none of the mailers seemed to be able to handle this
very good, I tried different more complex constructs.
But none of them works well with all the tested mailers.

A new extension to e-mail standards to handle language
translation should ideally degrade gracefully, in that
existing mailers will at least show the message in some
format readable to all recipients. None of the formats
tested worked OK with all the mailers.

The best format if graceful downgrading to existing
mailers is wanted, seems not to be multipart/alternative
but multipart/mixed. If this is used, however, each
body part should have a title with its language,
since some mailers just concatenate all body parts
(Continue reading)

Harald Alvestrand | 13 Nov 16:31 2000
Picon

Re: Language translation in e-mail standards

At 11:36 13/11/2000 +0800, Jacob Palme wrote:
>I have been thinking many times on how to best support
>language translation in e-mail standards. We have now
>received a research grant, which will allow us to
>implement this next year.
>
>Some requirements on a language translation standard:

Before you talk about a language translation standard, I think you have to 
define a model within which language translation will work.

For example:

- is translation carried out locally, remotely or both?
- is the original always included in a message, so that a message is
   self-contained, or does the model depend on references between messages?
- does translation occur before sending, in transit (shudder) or after
   delivery?

Before being clear about this, it is not even clear to me that there is a
*need* for a standard; if all translation occurs locally and post-delivery, 
there is very little a standard contributes.

>(1) It should cater for both machine and human translations.
>
>(2) It should cater for more than one translation of the
>     same message, usually first a machine translation and
>     later on a human translation of the same message.
>
>(3) It should cater for both the case where all language
(Continue reading)

Keith Moore | 13 Nov 19:28 2000
Picon

Re: Language translation in e-mail standards

Jacob,

if the vendors don't implement multipart/alternative correctly,
how is defining a new extension going to help?  we already have
a well-defined construct; what's needed is for MUA vendors to use it.

though if they can't even do content-types correctly after 9 years, 
I have little optimism that they'll get languages right within my
lifetime.

Keith

Bill Janssen | 14 Nov 01:59 2000
Picon

Re: Language translation in e-mail standards

> if the vendors don't implement multipart/alternative correctly,
> how is defining a new extension going to help?  we already have
> a well-defined construct; what's needed is for MUA vendors to use it.

Hear, hear!  Perhaps this use of multipart/alternative would be a bit
of an incentive to them to get it right.  Though Outlook can't even
seem to get something as basic as threading right.

Bill

Jacob Palme | 14 Nov 13:42 2000
Picon
Picon

Re: Language translation in e-mail standards

At 13.28 -0500 00-11-13, Keith Moore wrote:
>if the vendors don't implement multipart/alternative correctly,
>how is defining a new extension going to help?  we already have
>a well-defined construct; what's needed is for MUA vendors to use it.

Apparently, most existing mailers understand that you should
only display one of the body parts in a multipart/alternative.
However, none of them seem to test on Content-Language,
so their choice of which body parts to show is sort of
arbitrary.

This indicates a basic problem with the whole multipart/alternative
construct. The problem is that there is no indication to the
mailers on what property to use for selecting which body
part to show to users.

Perhaps there should be an attribute to multipart/alternative
as in the following example:

Content-Type: multipart/alternative; boundary="==boundary-2";
               variable="Content-Language"

This would then tell a mailer, that if it does not have
a facility for automatically selecting based on the
variable, it might ask the user or show all the body
parts as for multipart/mixed?

--

-- 
Jacob Palme <jpalme <at> dsv.su.se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/
(Continue reading)

Jacob Palme | 14 Nov 13:37 2000
Picon
Picon

Re: Language translation in e-mail standards

At 16.31 +0100 00-11-13, Harald Alvestrand wrote:
>Before you talk about a language translation standard, I think you 
>have to define a model within which language translation will work.
>
>For example:
>
>- is translation carried out locally, remotely or both?
>- is the original always included in a message, so that a message is
>   self-contained, or does the model depend on references between messages?
>- does translation occur before sending, in transit (shudder) or after
>   delivery?
>
>Before being clear about this, it is not even clear to me that there is a
>*need* for a standard; if all translation occurs locally and 
>post-delivery, there is very little a standard contributes.

If translation is done locally and separately by each
recipient, no standard is needed.

Possible modes:

(1) The sender translates (or uses a translation-engine
to translate) before sending a message. The issue in
this case is how to send multiple versions in a single
message.

(2) The sender sends to a translation engine, which
translates and forwards to the intended recipients.
Same problem as (1), but one might also want to
standardize a format for sending a message to be
(Continue reading)

Jacob Palme | 15 Nov 14:10 2000
Picon
Picon

Language translation in e-mail

My proposal for translation in e-mail standards is now ready,
you can find it at http://dsv.su.se/jpalme/ietf/jp-ietf-home.html#translation
--

-- 
Jacob Palme <jpalme <at> dsv.su.se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Eric Burger | 16 Nov 16:47 2000

Critical Content for Internet Mail

The attached document has been floated on the vpim and ifax lists.  Keith
suggested we pass it by this list as well.

We would like to bring this document to last call.

Thank you for your prior comments.  I look forward to hearing about any
further refinements we can make to the draft.

Regards,
Eric Burger

Network Working Group                                           E. Burger
Internet Draft                                         SnowShore Networks
Document: draft-ietf-vpim-cc-01.txt                            E. Candell
Category: Standards Track                        Comverse Network Systems
Expires February 2001                                    October 18, 2000

 
                   Critical Content of Internet Mail 

 
Status of this Memo 

   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC2026 [1].  

   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups.  Note that 
(Continue reading)

Harald Alvestrand | 16 Nov 18:33 2000
Picon

Re: Critical Content for Internet Mail

Hm. The idea of a DSN being influenced by body-part headers is 
architecturally inelegant, but it (sadly) makes a fair amount of sense when 
dealing with gateways.

The case where a DSN is appropriate is the case of a content-converting 
gateway; after delivery, an MDN is the only reasonable thing to do.
The text saying so might be clearer.

This extension does not guarantee any notification, of course; this should 
be noted explicitly.

The specification should say exactly what values to put into the MDN or DSN 
when generating one for this reason; 5.6.1 "Media not supported" seems 
appropriate, or 5.6.3 "Conversion required but not supported", or you might 
want to exercise the process for adding new status codes. See RFC 1893.
I don't have any advice for the MDN generation, but the doc should have.

Apart from these points of incompleteness, I think it makes a reasonable 
amount of sense.

Have fun!

          Harald

--
Harald Tveit Alvestrand, alvestrand <at> cisco.com
+47 41 44 29 94
Personal email: Harald <at> Alvestrand.no

(Continue reading)


Gmane