Network Working Group Jacob Palme Internet Draft Stockholm draft-palme-e-mail-translation-03.txt University/KTH Sweden Category-to-be: Proposed standard Date: December 2001 Expires: June 2001 Support for Language Translation in E-Mail and Netnews Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright (C) The Internet Society 2001, 2002. All Rights Reserved. 1.1 Abstract This memo specifies extensions to e-mail and netnews standards, to allow for the submission of translations of messages, not only at initial submission time, but also at later time, and made by other translators than the original author of the message. Three new e-mail/netnews header fields are proposed, "Content-Translation-Of, "Content- Translator" and "Translation-Request". 1.2 Mailing list To write Further discussion of this memo can take place in the mailing list LANGTRANS@SU.SE. Comments on less important details may also be sent to the editor, Jacob Palme . To subscribe To subscribe to this mailing list, send a message to LISTSERV@SU.SE which contains the text SUB[SCRIBE] LANGTRANS To unsubscribe To unsubscribe from this list, send a message to LISTSERV@SU.SE which contains the text UNS[UBSCRIBE] LANGTRANS To access mailing list archives The archives are available for browsing from http://salut.nu/forum/uno/6/1/ Use the browsing command "All messages" to get everything written on a single web page. Table of Contents 1.1 Abstract 1.2 Mailing list Table of Contents 2 Language Support in Existing Standards 3 Multi-Language Scenario 4 The Content-Translation-Of Header Field 5 The Content-Translator Header Field 6 USE of The Multipart/Choices MIME Content Type 7 The Translation-Request Header 8 Examples 8.1 Separate Original and Translated Messages 8.2 Sending a Message to a Translator for Translation 8.3 Resending of the Message in 8.2 After Translation 9 For Further Study 10 Security Considerations 11 Copyright and Disclaimer 12 Acknowledgments 13 References 14 Author's Address Appendix B: An Investigation of Handling of Multipart/Alternative in some Common Mailers in November 2000 2 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, 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. 3 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. 4 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 or of a body part containing the original text 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". Example: Subject: (en) This is the English version 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. 5 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 should 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 or by an expert in the topic of the message, such as a medical expert for a message on a medical topic. 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. 6 Use of The Multipart/Choices MIME Content Type When several translations of the same message are sent in the same message, the content-type multipart/choices, as defined in [9]. An alternative is to use mulitpart/alternative in the way described in Appendix A.4 below. If translation is desired also of the "Subject" header, then the translated body parts have 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/choices. 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. 7 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/choices. Syntax: "Translation-Request:" CFWS language 1*(, CFWS language) CFWS CRLF 8 Examples 8.1 Separate Original and Translated Messages Message-ID: A@foo.bar.net From: John Smith To: Tropical Flowers Mailing List Content-Translator: None; Original Content-Language: en Message-ID: B@foo.bar.net From: John Smith To: Tropical Flowers Mailing List Content-Translation-Of: A Content-Translator: Erika Ernst ; human; native Content-Language: de Message-ID: C@foo.bar.net From: John Smith To: Tropical Flowers Mailing List Content-Translation-Of: A Content-Translator: Tomas Dürrenmatt ; expert Content-Language: de Message-ID: D@foo.bar.net From: John Smith To: Tropical Flowers Mailing List Content-Language: en Supersedes: A Message-ID: E@foo.bar.net From: John Smith To: Tropical Flowers Mailing List Content-Translation-Of: D Content-Translator: Supertrans Translation Engine ; machine Auto-Submitted: Auto-generated Content-Language: de Supersedes: A 8.2 Sending a Message to a Translator for Translation Message-ID: Z@foo.bar.net From: John Smith Translation-Request: en, fr, de Content-Type: Message/rfc822 Message-ID: Z-en@foo.bar.net From: John Smith To: Tropical Flowers Mailing List Content-Translator: None; Original Content-Language: en Subject: Orchids Orchids are beautiful. 8.3 Resending of the Message in 8.2 After Translation Resent-From: Supertrans Translation Engine Message-ID: Z@supertrans.bar.net From: John Smith Content-Type: Multipart/choices; boundary="boundary 1" To: Tropical Flowers Mailing List Subject: (en) Orchids --boundary 1 Message-ID: Z-@foo.bar.net From: John Smith Translation-Request: en, fr, de Content-Type: Message/rfc822 Message-ID: Z-en@foo.bar.net From: John Smith To: Tropical Flowers Mailing List Content-Translator: None; Original Content-Language: en Subject: (en) Orchids Original English Text --------------------- Orchids are beautiful. --boundary 1 Content-Type: Message/rfc822 Message-ID: Z-de@supertrans.bar.net From: John Smith Content-Translation-Of: A Content-Translator: Supertrans Translation Engine ; machine Content-Language: de Subject: (de) Orchideen Deutsche Übersetzung -------------------- Orchideen sind schön. --boundary 1 Content-Type: Message/rfc822 Message-ID: Z-fr@supertrans.bar.net Content-Translation-Of: A Content-Translator: Supertrans Translation Engine ; machine Content-Language: fr Subject: (fr) Orchidée Traduction français ------------------- Orchidée sont beau. --boundary 1-- 9 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. 10 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. However, 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. 11 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. 12 Acknowledgments Suggestions during the development of this memo has been given by Harald Alvestrand, Bill Jansson, Larry Masinter, Keith Moore and Henry Spencer. 13 References Ref. Author, title IETF status ---- ------------------------------------- -------- [1] J. Klensin: "Simple Mail Transfer Proposed Protocol", RFC 2821, April 2001. Standard [2] P. Resnick: "Internet Message Format" Proposed STD 11, RFC 2822, April 2001. Standard [3] M.R. Horton, R. Adams: "Standard for Not an interchange of USENET messages", RFC official 1036, December 1987. IETF standard, but in reality a de-facto standard for Usenet News [4] N. Freed & N. Borenstein: Draft "Multipurpose Internet Mail Standard, Extensions (MIME) Part One: Format of elective Internet Message Bodies." RFC 2045. November 1996. [5] N. Freed & N. Borenstein: Draft "Multipurpose Internet Mail Standard, Extensions (MIME) Part Two: Media elective Types." RFC 2046. November 1996. [6] H. Alvestrand: "Tags for the Proposed Identification of Languages", RFC standard, 1766, February 1995. elective [7] R. Fielding, J. Gettys, J. Mogul, H. Draft Frystyk, T. Berners-Lee: Hypertext standard Transfer Protocol -- HTTP/1.1, RFC 2616, June 1999. [8] J. Palme: The Auto-Submitted, Work in Supersedes and Expires Headers in progress E-mail and Netnews, draft-ietf- mailext-new-fields-14.txt, November 1998. [9] J. Palme: The multipart/choices Work in Content-Type. draft-palme-multipart- progress choices-00.txt, December 2000. [10] R. Troost, S. Dorner, K. Moore: Proposed Communicating Presentation standard Information in Internet Messages: the Content-Disposition Header field, RFC 2183, August 1997. 14 Author's Address Jacob Palme Phone: +46-8-16 16 67 Stockholm University/KTH Fax: +46-8-783 08 29 Skeppargatan 73 E-mail: jpalme@dsv.su.se S-115 30 Stockholm, Sweden Appendix A: A Discussion of Alternative Ways of Handling Translation in E-Mail A.1 Use Multipart/alternative The most natural solution might be to send a message in multiple languages as a multipart/alternative, with each body part in a different language. However, this solution downgrades disastrously bad with many existing mail clients, as is shown in Appendix B. Most existing mail clients will either show only the first or only the last body part in such a multipart/alternative. Thus, users will not have the option of getting the message in their preferred language, they will instead get the message in a language which they might not understand. A.2 Use Multipart/mixed Another solution would be to use multipart/mixed, and with a Content-Disposition file-name containing the language. Most mailers will then show the message as a list of attachments, listing their file names. The recipients can then click on the name of the attachment which contains their preferred languages. The disadvantage with this solution is that it does not support future mailers which really do support multiple languages and can select the language part according to the user's preferences. A.3 Use multipart/choices A third solution would be to use a new Content-Type "multipart/choices". Since the MIME standard says that a mailer should handle "multipart/xxx" where "xxx" is an unkown subtype, as multipart/mixed. So this solution has all the advantages but not the disadvantage of using multipart/mixed. If multipart/choices becomes a standard, mailers of the future can support it better than multipart/mixed. A.4 Use multipart/alternative with additional first and last body part. A fourth solution would be to send the message as a multipart/alternative with the following contents: First body part: A plain text version of all the translations after each other. Last body part: A HTML version with all the translations after each other, and with a list of languages at the top. The user seeing this part can just click on one of the languages to get this message in that language. All the other body parts, between the first and the last, contains the text in each of the available languages. The advantage with this is that it will downgrade well with existing mailers, they will show either the first or the last part, which both contains the text in all the languages. At the same time, a mailer which understands the combinaton of multipart/alternative with Content-Language can let the user select a language or automatically select language based on user preferences. A third advantage is that no new subtype to Multipart have to be defined. The disadvantage is that the message will be longer, each translation is repeated three times, in the first body part, in one of the middle body part and in the last body part. Appendix B: An Investigation of Handling of Multipart/Alternative in some Common Mailers in November 2000 and November 2001 As a basis for possible work on developing standards for language-translation in e-mail, I tested how some common mailers handled multipart/alternative with different Content-Language in the body parts in November 2000. The tests on the Windows Explorer 5.0 were done in November 2001. I used the following test messages: Test message 1: First part English, second part German Test message 2: Same as test message 1, but first part German, second part English Test message 3: Same as test message 2, but multipart/mixed instead of multipart/alternative. Test message 4: Same as test message 3, but with Content- Disposition: Attachment on all but the first body part. Test message 5: Multipart/mixed on an outer level, with the first part a directory of attachments, and the second part a multipart/alternative with the German and English parts as the two alternatives. Test message 6: Multipart/alternative with the first part containing all the translations in one body part, and the second part a multipart/alternative with one translation in each alternative. I tested this with the following mailers: Eudora 5 Macintosh, Pine 4.21 on Unix, Netscape 4.7 Macintosh, Outlook Express 5 Macintosh, First Class 5.611 Macintosh, KOM 2000 (our own system), and Hotmail. Result: None of the mailers seemed to test on the Content- Language value, and make a selection based on this. Eudora, Outlook Express, KOM 2000 and Hotmail only showed the first body part. Netscape only showed the second body part. Pine only showed the second body part, but provided a user command to see also the first body part. First Class displayed both body parts in sequence, i.e. i treated multipart/alternative as identical to multipart/mixed. The conclusion of this is that if IETF makes a standard, specifying that different translations of the same message should be sent with multipart/alternative with different Content-Language on the different body parts, then most mailers will not show a user the version in the preferred language of that user. Since backwards compatibility with existing mailers is very important, this seems to indicate that an IETF standard for handling of language translation in e-mail has to use some other format than multipart/alternative to indicate translations. I also tested some more complex messages. In test message 4, I used multipart/mixed with three body parts, the first a list of the rest of the body parts, which contained the message in different languages. This format was not ideal either with the existing mailers. Most of them showed all three body parts in sequence inline (even though all except the first were marked as Content-Disposition: Attachment) and some of them without any visible marker between the body parts. In test message 5, on the top level is a multipart/mixed with two body parts, the first a list of the body parts, the second a multipart/alternative with the different language parts. This had the same problem as all the other multipart/alternative test examples: Many of the mailers arbitrarily chooses one of the multipart/alternatives and only shows this, some mailers choose the first alternative, some the second. In test message 6, I had on the top level a multipart/alternative where the first body part was a text/plain with all the language versions in one text. The second body part was another multipart/alternative with the different language parts as body parts. A mailer which cannot discriminate between languages, should for this message only display body part 1. Only Outlook Express and KOM 2000 did this. Pine, Netscape and Hotmail arbitrarily showed only one language version. In test message 7, I tested the format proposed in this ietf-draft, as shown in section 8.3 above. Test message 8 uses a first body part with all language versions in plain text, a last body part with all language versions in HTML, and in-between separate body parts for each translation. This seems to work very well with existing mailers. Test message 1: --------------- Message-ID: Date: Wed, 21 Nov 2001 09:55:00 +0100 From: Jacob Palme MIME-Version: 1.0 To: jpalme@dsv.su.se, jptest@dsv.su.se Subject: Language test message no. 1 v1 Content-Type: multipart/alternative; boundary="==boundary-2" Text displayed only to non-MIME-compliant mailers --==boundary-2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Language: en Message in English. --==boundary-2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Language: de Nachricht auf deutsch. --==boundary-2-- Test message 2: --------------- Message-ID: Date: Wed, 21 Nov 2001 09:55:00 +0100 From: Jacob Palme MIME-Version: 1.0 To: jpalme@dsv.su.se, jptest@dsv.su.se Subject: Language test message no. 2 Content-Type: multipart/alternative; boundary="==boundary-2" Text displayed only to non-MIME-compliant mailers --==boundary-2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Language: de Nachricht auf deutsch. --==boundary-2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Language: en Message in English. --==boundary-2-- Test message 3: --------------- Message-ID: Date: Wed, 21 Nov 2001 09:55:00 +0100 From: Jacob Palme MIME-Version: 1.0 To: jpalme@dsv.su.se,jptest@dsv.su.se Subject: Language test message no. 3 Content-Type: multipart/mixed; boundary="==boundary-2" Text displayed only to non-MIME-compliant mailers --==boundary-2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Language: de Nachricht auf deutsch. --==boundary-2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Language: en Message in English. --==boundary-2-- Test message 4: --------------- Message-ID: Date: Wed, 21 Nov 2001 09:55:00 +0100 From: Jacob Palme MIME-Version: 1.0 To: jpalme@dsv.su.se,jptest@dsv.su.se Subject: Language test message no. 4 Content-Type: multipart/mixed; boundary="==boundary-2" Text displayed only to non-MIME-compliant mailers --==boundary-2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Attachment 1: Deutsch Attachment 2: English Nachricht auf deutsch. --==boundary-2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Disposition: Attachment Content-Language: de Nachricht auf deutsch. --==boundary-2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Disposition: Attachment Content-Language: en Message in English. --==boundary-2-- Test message 4b: --------------- Message-ID: Date: Wed, 21 Nov 2001 09:55:00 +0100 From: Jacob Palme MIME-Version: 1.0 To: jpalme@dsv.su.se,jptest@dsv.su.se Subject: Language test message no. 4 Content-Type: multipart/mixed; boundary="==boundary-2" Text displayed only to non-MIME-compliant mailers --==boundary-2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Attachment 1: Deutsch Attachment 2: English Nachricht auf deutsch. --==boundary-2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Disposition: Attachment Content-Language: en Message in English. --==boundary-2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Disposition: Attachment Content-Language: de Nachricht auf deutsch. --==boundary-2-- Test message 5: --------------- Message-ID: Date: Mon, 13 Nov 2000 12:12:00 +0100 From: Jacob Palme MIME-Version: 1.0 To: jpalme@dsv.su.se,jptest@dsv.su.se Subject: Language test message no. 5 v1 Content-Type: multipart/mixed; boundary="==boundary-2" Text displayed only to non-MIME-compliant mailers --==boundary-2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Attachment 1: Deutsch Attachment 2: English --==boundary-2 Content-Type: Multipart/alternative; boundary="==boundary- 1" --==boundary-1 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Language: de Nachricht auf deutsch. --==boundary-1 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Language: en Message in English. --==boundary-1-- --==boundary-2-- Test message 6: --------------- Message-ID: Date: Wed, 21 Nov 2001 09:55:00 +0100 From: Jacob Palme MIME-Version: 1.0 To: jpalme@dsv.su.se,jptest@dsv.su.se Subject: Language test message no. 6 v1 Content-Type: multipart/alternative; boundary="==boundary-1" Text displayed only to non-MIME-compliant mailers --==boundary-1 Content-Type: text/plain; charset=iso-8859-1 **** This message in English *** Message in English. **** Diese Nachricht auf deutsch Nachricht auf deutsch. --==boundary-1 Content-Type: multipart/alternative; boundary="==boundary-2" --==boundary-2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Language: en Message in English. --==boundary-2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Language: de Nachricht auf deutsch. --==boundary-2-- --==boundary-1-- Test message 7: -------------- Same as in section 8.3 above. Test message 8: -------------- From: Jacob Palme Content-Type: Multipart/alternative; boundary="boundary 1" To: Tropical Flowers Mailing List Subject: Test message 8 --boundary 1 Message-ID: Z-en@foo.bar.net From: John Smith To: Tropical Flowers Mailing List Content-Translator: None; Original Content-Language: en Subject: (en) Orchids --boundary 1 Content-Type: text/plain; charset=iso-8859-1 Content-Language: en, de, fr This message will be shown in English, German and French **** This message in English *** Orchids are beautiful. **** Traduction français *** Orchids sind schön. *** This message in French *** Orchidée sont beau. --boundary 1 Content-Type: text/plain Content-Language: fr Orchidée sont beau. --boundary 1 Content-Type: text/plain Content-Language: en Orchids are beautiful. --boundary 1 Content-Type: text/plain Content-Language: de Orchids sind schön. --boundary 1 Content-Type: text/html Content-Language: en, fr, de

This message will be shown in English, German and French

**** This message in English ***

Orchids are beautiful.

 

 

 

 

 

 

 

 

 

 

 

 

**** Traduction français ***

Orchidée sont beau.

 

 

 

 

 

 

 

 

 

 

 

  p> *** Deutsche Übersetzung: ***

Orchids sind schön. --boundary 1-- Test message 8: -------------- From: Jacob Palme Content-Type: Multipart/alternative; boundary="boundary 1" To: Tropical Flowers Mailing List Subject: Test message 8 --boundary 1 Message-ID: Z-en@foo.bar.net From: John Smith To: Tropical Flowers Mailing List Content-Translator: None; Original Content-Language: en Subject: (en) Orchids --boundary 1 Content-Type: text/plain; charset=iso-8859-1 Content-Language: en, de, fr This message will be shown in English, German and French **** This message in English *** Orchids are beautiful. **** Traduction français *** Orchidée sont beau. *** Deutsche übersetzung: *** Orchids sind schön. --boundary 1 Content-Type: message/rfc822 Subject: Traduction français Content-Language: fr Content-Type: text/plain Content-Language: fr Orchidée sont beau. --boundary 1 Content-Type: message/rfc822 Subject: This message in English Content-Language: en Content-Type: text/plain Content-Language: en Orchids are beautiful. --boundary 1 Content-Type: message/rfc822 Subject: Deutsche =?iso-8859-1?Q?=FCbersetzung=3A?= Content-Transfer-Encoding: 8bit Content-Language: de Content-Type: text/plain Content-Language: de Orchids sind schön. --boundary 1 Content-Type: text/html Content-Language: en, fr, de

This message will be shown in English, German and French

**** This message in English ***

Orchids are beautiful.

 

 

 

 

 

 

 

 

 

 

 

 

**** Traduction français ***

Orchidée sont beau.

 

 

 

 

 

 

 

 

 

 

 

  p> *** Deutsche Übersetzung: ***

Orchids sind schön. --boundary 1-- Mailer Test message 1&2 Test message 3 ------ ----------------- --------------- Eudora 5 Only displayed the Both shown in Macintosh first alternative, sequence, Content- version did not even headers shown, but indicate that not Content- there was any Language! No other alternative. indication that the different language of the two body parts. Pine 4.21 on Only the second Both versions are a Unix alternative is listed in sequence platform shown directly, with a divider but the user can indication in- ask to see the between, no first alternative indication that with the VIEW the different command. Nothing language of the is said to two body parts. indicate that the two alternatives contain the same text in two languages. Netscape 4.7 Only the second Both versions are on a alternative is listed in sequence Macintosh shown, did not with a horizontal even indicate that rule in-between, there was any no indication that other alternative. the different language of the two body parts. Outlook Only displayed the Both shown in Express 5, first alternative, sequence, on the Macintosh did not even Macintosh no and Windows indicate that divider and no 98 edition there was any indication that other alternative. the different language of the two body parts, in Windows a horizontal divider line between the two parts. First Class Both versions are Both versions are 5.611, listed in sequence listed in sequence Macintosh with no divider in- with no divider in- client between, no between, no indication that indication that the different the different language of the language of the two body parts. two body parts. KOM 2000 Only displayed the Both versions are first alternative, listed in sequence did not even with a blank line indicate that in-between, no there was any indication that other alternative. the different language of the two body parts. Hotmail Only displayed the Both shown in first alternative, sequence, blank did not even line in-between. indicate that there was any other alternative. Mailer Test message 4 Test message 5 ------ --------------- --------------- Eudora 5 All three body First and second Macintosh parts in sequence. body part shown version inline. Pine 4.21 on First message First message a Unix shown inline, the shown inline, the platform rest available by rest available by commands to commands to retrieve retrieve attachments. attachments. Netscape 4.7 All three body Only first and on a parts in sequence third body part Macintosh with a horizontal shown in sequence rule in-between. with two horizontal rules in-between. Outlook All three body First and third Express 5, parts in sequence body parts in Macintosh on the Macintosh. sequence. and Windows In Windows, only edition first and third body part shown in sequence. Reordering the second and third body parts with the German version last gave the same result: first and third (German) part shown only. First Class All three body 5.611, parts listed in Macintosh sequence. client KOM 2000 All three body First and third parts in sequence, body part in horizontal rule in sequence, between. horizontal rule in between. Hotmail All three body First and third parts in sequence. body part in sequence. Mailer Test message 6 Test message 7 ------ -------------- -------------- Eudora 5 The first and the All translations Macintosh second, but not inline in sequence version the third body with all headers, part is shown. including translation- headers shown on each body part. Pine 4.21 on Last body part All translations a Unix (the German listed as platform variant) shown attachments. inline, the other body parts available as attachments. Netscape 4.7 Only the last body All translations on a part (the German inline with some Macintosh variant shown, headers shown on nothing indicates each body parts. to the reader that anything more is available.) Outlook Only the first All translations Express 5, body part shown, inline with some Macintosh with both language headers shown on and Windows text within a each body parts on version single body part the Macintosh. On on the Macintosh! Windows, In Windows, only the second body part is shown. First Class All translations 5.611, inline in sequence Macintosh with all headers, client including translation- headers shown on each body part. KOM 2000 Only the first All translations body part is inline with some shown, containing headers shown on both language each body parts. versions in one body part. Hotmail Only the second All translations body part is inline with some shown, no headers shown on indication that each body parts. any more text is available. Mailer Test message 8 ------ -------------- Eudora 5 Only last part Macintosh shown, user has to version manually scroll down to his preferred language, clicking on the languages in the first line does not work. Note: User can use the Eudora-command "Open in Browser" and then clicking on the language links will work! Pine 4.40 on Last body part a Unix shown in-line with platform simulated clicking to view each language. The other body parts shown as attachments. Netscape 4.7 Last body part on Windows shown, clicking on 98 links will get the readers to the language they prefer. Outlook Last body part Express 5, shown, clicking on Macintosh links will get the and Windows readers to the version language they prefer. First Class Only the first 5.611, body part is Macintosh shown. client KOM 2000 Last body part only shown, clicking on links to select language works. Hotmail Last body part only shown, clicking on links to select language works.