最近、翻訳精度が向上したと言われるGoogle翻訳。その実力の程は如何にということで、技術文書を翻訳できるかどうか、やってみました。
今回のお題はRFC2045のイントロダクション！
1. Introduction
Since its publication in 1982, RFC 822 has defined the standard
format of textual mail messages on the Internet. Its success has
been such that the RFC 822 format has been adopted, wholly or
partially, well beyond the confines of the Internet and the Internet
SMTP transport defined by RFC 821. As the format has seen wider use,
a number of limitations have proven increasingly restrictive for the
user community.
RFC 822 was intended to specify a format for text messages. As such,
non-text messages, such as multimedia messages that might include
audio or images, are simply not mentioned. Even in the case of text,
however, RFC 822 is inadequate for the needs of mail users whose
languages require the use of character sets richer than US-ASCII.
Since RFC 822 does not specify mechanisms for mail containing audio,
video, Asian language text, or even text in most European languages,
additional specifications are needed.
1 。はじめに
1982年の出版以来、 RFC 822は 、標準を定義しました
インターネット上のテキストメールメッセージの形式。 成功は
されてこのようなことをRFC 822形式が採用されている、完全に、または
部分的には、インターネットとインターネットの境界をはるかに超えている
定義されたSMTPトランスポートRFC 821 。フォーマットが普及を見ているように、
いくつかの制限がますます厳しくなってきています。
ユーザーコミュニティ。RFC 822は、テキストメッセージの形式を指定することを意図していました。 など、
非テキストメッセージ、例えば、マルチメディアメッセージ
オーディオや画像は、単に言及されていません。 テキストの場合でも、
しかし、 RFC 822は、メールユーザーのニーズには不十分です
言語はUS-ASCIIよりも豊富な文字セットを使用する必要があります。
以来RFC 822は、オーディオを含むメールのメカニズムを指定していません、
ビデオ、アジア言語のテキスト、またはほとんどのヨーロッパ言語のテキストであっても、
追加仕様が必要です。
。。。あれ？
何だか変な日本語がでてきました。
RFCは昔ながらの伝統を受け継ぐプレーンテキスト文化なので、そこらじゅうに入っている改行コードにGoogle翻訳がうまく対処できず、変なところで文章が切れてしまうようです。ということは、RFC文書の改行位置だけ付け直してGoogle翻訳に流し込めば、うまく翻訳できそうな気がします。
それを実行したのがこちらになります。
1 。はじめに
1982年の出版以来、 RFC 822は 、インターネット上のテキストのメールメッセージの標準フォーマットを定義しています。 その成功は、なるようになっているRFC 822よくによって定義され、インターネットとインターネットSMTPトランスポートの境界を越え、全体的または部分的に、フォーマットが採用されているRFC 821 。フォーマットが普及を見ているように、多くの制限がますます証明されていますユーザーコミュニティには制限があります。
RFC 822は、テキストメッセージの形式を指定することを意図していました。 したがって、オーディオまたは画像を含むマルチメディアメッセージなどの非テキストメッセージは、単に言及されていない。 でも、テキストの場合には、しかし、 RFC 822は、言語文字の使用はUS-ASCIIよりもリッチ設定する必要がメールユーザーのニーズには不十分です。 以来、RFC 822は 、オーディオ、ビデオ、アジア言語のテキスト、またはほとんどのヨーロッパ言語であってもテキストを含むメールのメカニズムを指定していない、追加の仕様が必要とされています。
ところどころ変なところはありますが、格段に良くなりました。
ちなみに、RFC2045は日本語版が日本工業規格JIS X 5810-1:2008として刊行されている稀有なRFCです。そちらの該当箇所は以下のようになっています。というわけで、これがお手本！
1.2 概要
RFC 822 は，1982 年に出版されて以来，インターネットにおけるテキストのメールメッセージの標準フォーマットを規定してきた。このフォーマットは成功を収め，インターネット及び RFC 821 で定義されるインターネット SMTP トランスポートの範囲外においても，RFC 822 のフォーマットが全部又は一部採択されるなどしている。このフォーマットは，広範に使えるように見えるが，利用者コミュニティにとって制約となる，数々の限界があることが，明らかになってきた。
RFC 822 はテキストのメッセージのためのフォーマットを規定することを想定していた。したがって，音声又は画像を含むかもしれないマルチメディアメッセージなどの，非テキストのメッセージについては言及していない。テキストの場合であっても，US-ASCII より豊富な文字集合の使用を必要とする言語を使うメール利用者の必要を満たさない。RFC 822 は，音声，映像及びアジア言語のテキストを含むメールのための機構を規定していないばかりでなく，大部分の欧州言語についても，そのテキストを含むメールのための機構を規定していないので，追加の規定が必要になる。
これはこれで意味不明な気がしなくもありませんが、ちゃんとした人間様による翻訳であり、分かりにくい英語をそのまま忠実に分かりにくい日本語に訳しましたといった風情に見受けられます。
以上！機械翻訳はあくまで機械翻訳であってリファレンスとしては使えませんが、そこはあくまで自己責任ということで、役に立つこともあるかもしれません。幸運を祈る。