Network Working Group
Internet Draft
draft-palme-e-mail-translation-01.txt
Category-to-be: Proposed standard

Jacob Palme
Stockholm University/KTH
Sweden
Date: November 2000
Expires: May 2001

1.1 Abstract *

2 Language Support in Existing Standards *
3 Multi-Language Scenario *
4 The Content-Translation-Of Header Field *
5 The Content-Translator Header Field *
6 The Multipart/Translations MIME Content Type *
7 The Translation-Request Header *
8 Examples *

9 For Further Study *
10 Security Considerations *
11 Copyright and Disclaimer *
12 Acknowledgments *
13 References *
14 Author's Address *

Appendix 1: An Investigation of Handling of Multipart/Alternative in some Common Mailers in November 2000 *

1. Language Support in Existing Standards

The "Content-Language:" e-mail content header specified in RFC 1766 [6] can be used to specify one or a list of natural languages used in that message body.

The "Content-Type: Multipart/alternative" defined in MIME [4] might be used to send the same text in more than one language. Each part would then be marked with the "Content-Language:" header to indicate its language, and the recipient might choose the body part according to his or her language preferences. The combination of Multipart/alternative with Content-Language is however not commonly supported and gives disastrous results with most mailers (November 2000), so this solution is not recommended in this specification.

In HTTP [7], a request operation can indicate a list of preferred languages, and the server can then deliver the resource in the preferred language. The request operation can also indicate how good each language is for a particular user, in the format:

Accept-Content-Language: da, en-gb;q=0.8, en;q=0.7

HTTP also has facilities for the server to tell the client which alternatives are available in different languages, letting the client choose between them. It is also possible, with HTTP, to deliver a resource in the "Multipart/alternative" format, if the recipient wants to store the resource in all available language versions. These HTTP features are however not commonly supported (November 2000).

All of these methods of transmitting information is based on the assumption that all language versions are ready and available when a message is sent.

 

2. Multi-Language Scenario

John Smith writes a message in English and submits it to a mailing list or to a Usenet newsgroup. The mailing list expander sends this message to an automatic translation agent which translates it into other languages and returns the translations to the mailing list expander. The mailing list expander might then either forward all translations to each member of the list, or forward to each member only the translation preferred by this member. Ernst Dürrenmatt has requested the mailing list to send him all language versions, but reads this message in English, because he has indicated that he prefers English original documents to automatic German translations. Hilda Schmidt reads the message in both English and German, decides that the automatic German translation is not very good, and cleans it up, submitting a new better translation to German. Ernst Dürrenmatt checks this translation, makes some corrections, and submits a final corrected version of the German translation of the original message.

 

3. The Content-Translation-Of Header Field

The "Content-Translation-Of" header field is used when submitting a translation to a message, which earlier has been sent in another language. The syntax for this header field is similar to the syntax for the "In-Reply-To" header, but only one value is allowed, since every translation can only be the translation of one previous message. The value contains the Message-ID of the original message before translation. If a message is available in more than one language, "Content-Translation-Of" should always reference the original message, even if the translation was actually based on a translated version. If the original message is available in more than one version, with "Supersedes" or "Replaces" references between the versions, then the "Content-Translation-Of" should reference the version which was the basis of this translation.

Translation is applied to the body content, and to the content of the "Subject:" header, but not to any other header contents. When a "Subject:" is translated, the language code enclosed in parenthesis" can be added to the beginning of the "Subject".

If more than one translation is available of the same original message, the "Supersedes" or "Replaces" header field should not be used between them. "Supersedes" or "Replaces" are only to be used when the original message is revised.

 

4. The Content-Translator Header Field

The "Content-Translator" header field indicates who made the translation. When a translation is submitted, the "From" header field should still indicate the original author, but the "Content-Translator" header field can indicate who made the translation.

The syntax of the "Content-Translator" header field is:

Content-Translator = "Content-Translator:"
        ( CFWS mailbox-list / Phrase )
        *(";" translator-parameter) CFWS CRLF

translator-parameter = art / fluency / future-extension

art = "Human" / "Machine" / "Original"

fluency = "Expert" / "Native" / "Other"

The meaning of these parameters are:

Human = Translation was made or revised/approved by a human
translator.

Machine = Translation was entirely automatic, with no human checking
of the translation. In this case, the "Auto-Submitted" [8]
header should also be added to the message heading.

Original = This is the original before translation. Absence of a
"Content-Translator" also indicates that the message is not
translated, but "Content-Translator: None; Original" can be
used to explicitly specify that this is not translated.

Expert = Translation was made by an expert translator.

Native = Translation was made by a native speaker of the target
language.

Other = Translation was made by someone who is not an expert nor
a native speaker of the target language.

 

5. The Multipart/Translations MIME Content Type

It might seem natural to use the Multipart/alternative content type [5], with different language versions in the different bodies. This should, however be avoided, because it downgrades disastrously to older mailers. Instead, a new content-type Multipart/translations is to be used. This will according to the Mime standard downgrade to Multipart/mixed, which downgrades much better for older mailers than Multipart/alternative does.

The Multipart/translations header is to be used when the different body parts contain the same information translated to different human languages. Each body part of Multipart/translations must contain a Content-Language header. Even if the body part itself is a multipart, such as a Multipart/mixed or Multipart/related. Content-Language is required both in the embedded multipart heading and in textual body parts within the embedded multipart.

If translation is desired also of the "Subject" header, then the translated body parts has to be of content-type Message/rfc822, since only that content-type allows different subject in different body parts.

It is recommended to add information about translation at the top of each body part (example, see section 8.3 below), because some mailers display multiple body parts in sequence inline with no indication of the Differences between them. This recommendation may be lifted at some future time when most mailers have support for Multipart/translations.

It is also recommended to add a blank line at the end of each translation, since this will show up neater on some old mailers, which display all body parts in sequence to the recipient.

 

6. The Translation-Request Header

The Translation-Request header is used when sending a message for translation to a human or machine translator. Its value is a list of the languages to which translation is requested. The languages are specified according to [6]. The language of the original can be included in the Translation-Request header, this tells the translator to include the original of the message when it is forwarded after translation, together with the translations to other languages.

When the Translation-Request header is used, the content-type should always be "Message/rfc822" [5] and the content should be the message to be translated. When the translation is ready, the translator is instructed to send the translation to the recipients in the "To:", "Cc:" and "Bcc:" headers and to leave non-translated headers of the message/rfc822 body as they were before the translation. When the translator resends the translation, Resent-From" is added with the name of the translator, and "Resent-Date" with the date of the translation. If translation to multiple languages is requested, the result is sent using the content-type multipart/translations.

Syntax:

"Translation-Request:" CFWS language 
1*(, CFWS language)
CFWS CRLF

7. Examples
   
   
1. Separate Original and Translated Messages

Message-ID: A@foo.bar.net
From: John Smith <jsmit@foo.bar.net>
To: Tropical Flowers Mailing List <tropflow@foo.bar.net>
Content-Translator: None; Original
Content-Language: en

Message-ID: B@foo.bar.net
From: John Smith <jsmit@foo.bar.net>
To: Tropical Flowers Mailing List <tropflow@foo.bar.net>
Content-Translation-Of: A
Content-Translator: Erika Ernst <eernst@foo.bar.de>; human; native
Content-Language: de

Message-ID: C@foo.bar.net
From: John Smith <jsmit@foo.bar.net>
To: Tropical Flowers Mailing List <tropflow@foo.bar.net>
Content-Translation-Of: A
Content-Translator: Tomas Dürrenmatt <tdurrenmatt@foo.bar.de>; expert
Content-Language: de

Message-ID: D@foo.bar.net
From: John Smith <jsmit@foo.bar.net>
To: Tropical Flowers Mailing List <tropflow@foo.bar.net>
Content-Language: en
Supersedes: A

Message-ID: E@foo.bar.net
From: John Smith <jsmit@foo.bar.net>
To: Tropical Flowers Mailing List <tropflow@foo.bar.net>
Content-Translation-Of: D
Content-Translator: Supertrans Translation Engine <supertrans@foo.bar>; machine
Auto-Submitted: Auto-generated
Content-Language: de
Supersedes: A
 

2. Sending a Message to a Translator for Translation

Message-ID: Z@foo.bar.net
From: John Smith <jsmit@foo.bar.net>
Translation-Request: en, fr, de
Content-Type: Message/rfc822
Message-ID: A@foo.bar.net
From: John Smith <jsmit@foo.bar.net>
To: Tropical Flowers Mailing List <tropflow@foo.bar.net>
Content-Translator: None; Original
Content-Language: en
Subject: Orchids
Orchids are beautiful.
 

3. Resending of the Message above After Translation

Resent-From: Supertrans Translation Engine
<supertrans@foo.bar>
Message-ID: Z@foo.bar.net
From: John Smith <jsmit@foo.bar.net>
Content-Type: Multipart/translations; boundary="boundary 1"
To: Tropical Flowers Mailing List <tropflow@foo.bar.net>
Subject: (en) Orchids

--boundary 1
Message-ID: Y@foo.bar.net
From: John Smith <jsmit@foo.bar.net>
Translation-Request: en, fr, de
Content-Type: Message/rfc822

Message-ID: A@foo.bar.net
From: John Smith <jsmit@foo.bar.net>
To: Tropical Flowers Mailing List <tropflow@foo.bar.net>
Content-Translator: None; Original
Content-Language: en
Subject: (en) Orchids

Original English Text
---------------------
Orchids are beautiful.
--boundary 1
Content-Type: Message/rfc822
Message-ID: B@foo.bar.net
From: John Smith <jsmit@foo.bar.net>
Content-Translation-Of: A
Content-Translator: Supertrans Translation
        Engine <supertrans@foo.bar>; machine
Content-Language: de
Subject: (de) Orchideen

Deutsche Übersetzung
--------------------
Orchideen sind schön.
--boundary 1
Content-Type: Message/rfc822
Message-ID: C@foo.bar.net
Content-Translation-Of: A
Content-Translator: Supertrans Translation Engine
     <supertrans@foo.bar>; machine
Content-Language: fr
Subject: (fr) Orchidée

Traduction français
-------------------
Orchidée sont beau.
--boundary 1--

 

8. For Further Study

The following is not yet resolved in this draft:

• How a user can register its language preferences with a mail server or a mailing list expander.
  
  
• Whether POP/IMAP should be extended with commands to request messages in only a certain language.
  
  
• How to handle translation in Usenet News. One might for example have a set of co-ordinated newsgroups, with the same articles in different languages. A newsgroup "alt.cultures.multiple" might be provided with English in "alt.cultures.multiple.en", German in "alt.cultures.multiple.de", etc., with automatic or manual translation of the messages between these newsgroups.
  
  
• Handling of signatures and seals.
  
  
9. Security Considerations

Translations made by other people than the original author of a message will of course entail the risk of intentional or unintentional incorrectness of the translation. But this is a risk we must accept if we want to have translations, and if everyone is not fluent in every language.

Some people claim that machine translation technology is so bad, that it should not be used at all. I do not agree, machine translation will often give a good understanding of the intent of the original text even if the translation is not perfect. And if the recipient has a choice of either not understanding a message at all, or getting a machine translation, the recipient may still prefer the automatic translation. Based on this, the recipient might decide whether the message is of enough interest to be willing to pay for a human to make a better translation.

The risk can be reduced, if the receiving user agent clearly shows that a message is a translator, who made the translation, and allows the user to check the original text and compare it with the translation.

A translation will invalidate any digital signatures or seals, but the translator might add its own signature and seals to ensure that the translation is not corrupted when sent from translator to readers. These signatures and seals will not promise any correspondence with the original text, except the promise which a translator might give of the correctness of its translations.

 

10. Copyright and Disclaimer

The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat."

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.

Copyright (C) The Internet Society (2000). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

 

11. Acknowledgments

Suggestions during the development of this memo has been given by Harald Alvestrand, Bill Jansson, Larry Masinter, Keith Moore and Henry Spencer.

Ref.

Author, title

IETF status

[7]

Draft standard

[8]

J. Palme: The Auto-Submitted, Supersedes and Expires Headers in E-mail and Netnews, draft-ietf-mailext-new-fields-14.txt, November 1998.

Work in progress

Mailer
------

Test message 1&2
-----------------

Test message 3
---------------

Eudora 5 Macintosh version

Only displayed the first alternative, did not even indicate that there was any other alternative.

Both shown in sequence, Content-headers shown, but not Content-Language! No indication that the different language of the two body parts.

Pine 4.21 on a Unix platform

Only the second alternative is shown directly, but the user can ask to see the first alternative with the VIEW command. Nothing is said to indicate that the two alternatives contain the same text in two languages.

Both versions are listed in sequence with a divider indication in-between, no indication that the different language of the two body parts.

Netscape 4.7 on a Macintosh

Only the second alternative is shown, did not even indicate that there was any other alternative.

Both versions are listed in sequence with a horizontal rule in-between, no indication that the different language of the two body parts.

Outlook Express 5, Macintosh edition

Only displayed the first alternative, did not even indicate that there was any other alternative.

Both shown in sequence, no divider and no indication that the different language of the two body parts.

First Class 5.611, Macintosh client

Both versions are listed in sequence with no divider in-between, no indication that the different language of the two body parts.

Both versions are listed in sequence with no divider in-between, no indication that the different language of the two body parts.

KOM 2000

Only displayed the first alternative, did not even indicate that there was any other alternative.

Both versions are listed in sequence with a blank line in-between, no indication that the different language of the two body parts.

Hotmail

Only displayed the first alternative, did not even indicate that there was any other alternative.

Both shown in sequence, blank line in-between.

Mailer
------

Test message 4
--------------

Test message 5
--------------

Eudora 5 Macintosh version

All three body parts in sequence.

First and second body part shown inline.

Pine 4.21 on a Unix platform

First message shown inline, the rest available by commands to retrieve attachments.

First message shown inline, the rest available by commands to retrieve attachments.

Netscape 4.7 on a Macintosh

All three body parts in sequence with a horizontal rule in-between.

Only first and third body part shown in sequence with two horizontal rules in-between.

Outlook Express 5, Macintosh edition

All three body parts in sequence.

First and third body parts in sequence.

First Class 5.611, Macintosh client

All three body parts listed in sequence.

KOM 2000

All three body parts in sequence, horizontal rule in between.

First and third body part in sequence, horizontal rule in between.

Hotmail

All three body parts in sequence.

First and third body part in sequence.

Mailer
------

Test message 6
--------------

Test message 7
--------------

Eudora 5 Macintosh version

The first and the second, but not the third body part is shown.

All translations inline in sequence with all headers, including translation-headers shown on each body part.

Pine 4.21 on a Unix platform

Last body part (the German variant) shown inline, the other body parts available as attachments.

All translations listed as attachments.

Netscape 4.7 on a Macintosh

Only the last body part (the German variant shown, nothing indicates to the reader that anything more is available.)

All translations inline with some headers shown on each body parts.

Outlook Express 5, Macintosh edition

Only the first body part shown, with both language text within a single body part!

All translations inline with some headers shown on each body parts.

First Class 5.611, Macintosh client

All translations inline in sequence with all headers, including translation-headers shown on each body part.

KOM 2000

Only the first body part is shown, containing both language versions in one body part.

All translations inline with some headers shown on each body parts.

Hotmail

Only the second body part is shown, no indication that any more text is available.

All translations inline with some headers shown on each body parts.