Re: Proposed addition to mail/news standards to support translations

Hello Jacob,

I think this is a very interesting proposal. But besides
mail and news, there is another part of the Internet that
could benefit quite a bit from this, namely the web :-).
I have included www-international@w3.org to the discussion,
and would like to ask everybody to include this in
crosspostings.

Many thanks in advance,

Regards,   Martin.


At 11:54 99/03/14 +0100, Jacob Palme wrote:
> Here is a proposal, based on the work in the Web4Groups
> EU-project, on how to extend e-mail and netnews standards
> to support translations, even if the translation is done
> after the submission of the original message.
> 
> I have not yet submitted this to the IETF drafts
> directories, but plan to do this soon.
> 
> --- --- ---
> 
> Network Working Group                                     Jacob Palme
> Internet Draft                               Stockholm University/KTH
> draft-palme-e-mail-translation-00X.txt                         Sweden
> Category-to-be: Proposed standard                    Date: March 1999
>                                               Expires: September 1999
> 
> 
>                   Support for Language Translation of E-Mail
> 
>                         Status of this Memo
> 
> 
> This document is not yet 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 1998. All Rights Reserved.
> 
> 
>       1.1.1.                            Abstract
> 
> This memo proposes extensions to e-mail and netnews standards, to allow
> for the submission of translation 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. Two new e-mail/netnews header
> fields are proposed, "Translation-Of" and "Translator".
> 
> 
>                          Table of contents
> 
> 1.   Introduction
> 2.   Multi-Language Scenario
> 3.   The Translation-Of Header Field
> 4.   The Translator Header Field
> 5.   Examples
> 6.   Security considerations
> 7.   Copyright and disclaimer
> 8.   Acknowledgments
> 9.   References
> 10.  Author's address
> 
> 
> 1.    Introduction
> 
> The "Language:" e-mail content header specified in RFC 1766 [5] 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] can be
> used to send the same text in more than one language. Each part is
> marked with the "Language:" header to indicate its language, and the
> recipient can choose the body part according to his or her language
> preferences.
> 
> In HTTP [6], a GET operation can indicate a list of preferred
> languages, and the server can then deliver the resource in the
> preferred language. 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.
> 
> 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. An automatic translation agent gets this
> message and translates it into German. The German translation is
> submitted to the same mailing list or newsgroup. Ernst D$B—S(Jrenmatt 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$B—S(Jrenmatt checks
> this translation, makes some corrections, and submits a final corrected
> version of the German translation of the original message.
> 
> 
> 3.    The Translation-Of Header Field
> 
> The "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, "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 "Translation-Of" should reference the
> version which was the basis of this translation.
> 
> 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" is only to be used when the original
> message is revised. Example:
> 
> 
> 4.    The Translator Header Field
> 
> The "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 "Translator" header field can
> indicate who made the translation.
> 
> The syntax of the "Translator" header field is:
> 
> translator           = "Translator:" CFWS mailbox-list
>                        *(";" translator-parameter) CFWS CRLF
> 
> translator-parameter = art / fluency / future-extension
> 
> art                  = "Human" / "Machine"
> 
> fluency              = "Expert" / "Native"
> 
> 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" [7]
>           header should also be added to the message heading.
> 
> Expert  = Translation was made by an expert translator.
> 
> Native  = Translation was made by a native speaker of the target
>           language.
> 
> 
> 5.    Examples
> 
> Message-ID: A
> From: John Smith <jsmit@foo.bar.net>
> To: Tropical Flowers Mailing list
> Language: en
> 
> Message-ID: B
> From: John Smith <jsmit@foo.bar.net>
> To: Tropical Flowers Mailing list
> Translation-Of: A
> Translator: Erika Ernst <eernst@foo.bar.de>; human; native
> Language: de
> 
> Message-ID: C
> From: John Smith <jsmit@foo.bar.net>
> To: Tropical Flowers Mailing list
> Translation-Of: A
> Translator: Tomas D$B—S(Jrenmatt <tdurrenmatt@foo.bar.de>; expert
> Language: de
> 
> Message-ID: D
> From: John Smith <jsmit@foo.bar.net>
> To: Tropical Flowers Mailing list
> Language: en
> Supersedes: A
> 
> Message-ID: E
> From: John Smith <jsmit@foo.bar.net>
> To: Tropical Flowers Mailing list
> Translation-Of: D
> Translator: Supertrans Super Translation Engine <supertrans@foo.bar>
> Auto-Submitted: Auto-generated
> Language: de
> Supersedes: A
> 
> 
> 6.    Security considerations
> 
> Translations made by other people than the original author of
> a message will of ourse 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, if the
> recipient has a choice of either not understanding a message
> at all, or getting a bad 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.
> 
> 
> 7.    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 (date). 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 implmentation 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.
> 
> 
> 8.    Acknowledgments
> 
> To be completed.
> 
> 
> 9.    References
> 
> Ref.    Author, title                                    IETF status
>                                                          (July 1996)
> -----   ---------------------------------------------    -----------
> [1]     J. Postel: "Simple Mail Transfer Protocol",      Standard,
>         STD 10, RFC 821, August 1982.                    Recommended
> 
> [2]     D. Crocker: "Standard for the format of ARPA     Standard,
>         Internet text messages." STD 11, RFC 822,        Recommended
>         August 1982.
> 
> [3]     M.R. Horton, R. Adams: "Standard for             Not an offi-
>         interchange of USENET messages", RFC 1036,       cial IETF
>         December 1987.                                   standard,
>                                                          but in
>                                                          reality a de-
>                                                          facto
>                                                          standard for
>                                                          Usenet News
> 
> [4]     N. Freed & N. Borenstein: "MIME (Multipurpose    Draft
>         Internet Mail Extensions) Part One: Format of    Standard,
>         Internet Message Bodies. RFC 2945. November      elective
>         1996.
> 
> [5]     H. Alvestrand: "Tags for the Identification      Proposed
>         of Languages", RFC 1766, February 1995.          standard,
>                                                          elective
> 
> [6]     R. Fielding, J. Gettys, J. Mogul, H. Frystyk,    Proposed
>         T. Berners-Lee: Hypertext Transfer Protocol -    standard
>         - HTTP/1.1, RFC 2068, January 1997.
> 
> [7]     J. Palme: The Auto-Submitted, Supersedes and     Work in
>         Expires Headers in E-mail and Netnews, draft-    progress
>         ietf-mailext-new-fields-14.txt, November
>         1998.
> 
> 
> 10.   Author's address
> 
> Jacob Palme                     Phone: +46-8-16 16 67
> Stockholm University/KTH        Fax: +46-8-783 08 29
> Electrum 230                    E-mail: jpalme@dsv.su.se
> S-164 40 Kista, Sweden
> 
> 
> 
> 


#-#-#  Martin J. Du"rst, World Wide Web Consortium
#-#-#  mailto:duerst@w3.org   http://www.w3.org

Received on Tuesday, 16 March 1999 12:08:52 UTC