マイクロソフトリサーチがTechFestイベントで出展した、リアルタイム翻訳電話システムのデモ動画です。
残念ながら英語-ドイツ語の翻訳ですけど。一方がしゃべり終えたら相手側に合成された翻訳音声が流れています。
実際の翻訳は1:20秒あたりから。ブースの隣同士で英語・ドイツ語でマイクに話していますが、技術としては電話を通してどこにでもかけられるわけです。
翻訳精度や話し終えてから相手側言語で合成するまでの時間の短縮、そして実際の普及が期待されますね。
Tag Archives: 英語
遠く離れた恋人に熱い抱擁をプレゼントできるHugegram(ハグイーグラム)
大切な人に花束を届けるのはもう古い? ハグイーグラムは、宅配便で送れるハグ(抱擁)です。
この「史上もっとも心温まる、シェアできるパーソナルギフト」。なんと$29.95(3000円弱)で買えるのだとか。あなたのメッセージを吹き込むことができるので、あなたの大切な人は常にあなたにハグされているように感じることができるのです。
そしてテレビコマーシャル。いろんな意味ですごい。
これ、どうもジョーク製品というわけじゃなくて真剣に売ってるようです。えっ?
処女/童貞証明書サービスCertifiedVirgin.com
CertifiedVirgine.com (証明された処女/童貞.com)では、たったの1ドルであなたの、あるいはあなたが認定した友達の処女証明書、童貞証明書を発行してくれるというウェブサイトです。
さわやかです
そ、そうですか。
…
実際に申し込もうとすると、フォームには小さく「私はこれがユーモアだと理解してます」というのに同意させられます。また、収益の一部はエイズに関する研究に寄付されるそうです。
それで、この証明書、何に使うんですかねえ?
via Geekologie
多聴多読マガジン2月号で読んだ4!の英語版I’vReadをご紹介いただきました
発売中の多聴多読マガジン2月号にて、読んだ4!の英語版I’vReadをご紹介いただきました。
読んだ4!は日本のAmazonで扱っている(主に)日本語の本を記録しますが、I’vReadでは英語の本、アメリカのAmazon.comで売っている本を記録できます。
![多聴多読マガジン 2010年 02月号 [雑誌]](http://images.amazon.com/images/P/B0030C5ERY.01._PC_SCMZZZZZZZ_.jpg)
「Twitterでつぶやき英作文」という特集で、ツイッターを使って海外の有名人をフォローしたり、ツイッターで英語をつぶやくときの英語の書き方例などを紹介されていますが、その中のコラムで、ツイッターを活用する関連サービスとしてI’vReadを紹介していただきました。
赤ちゃんの扱い方イラスト集
新成田エクスプレスは余分なオチンチンを…何?
成田エクスプレスの新しい車両には、鍵のついた荷物置き場があるようですね。
で、その説明書きに英文がついているらしいのですが、その英文が「変」なんだそうです。
日本語の説明文がこれ。
指定された暗証番号をお忘れの場合は、列車終着駅でお荷物の引渡しとなります。
その横についている英語の説明がこれ。
When the set combination is forgotten, it becomes a delivery of the spare prick in the train terminal station.
これを日本語に再翻訳すると、”prick”は「突く」とか俗語で「おちんちん」の意味なので、
セットの組み合わせが忘れられたら、この列車のターミナル駅で余分なおちんちんの配達になるでしょう。
前半もちょっと変ですが、問題は後半。「この列車のターミナル駅」は「この列車の最後の停車駅」の言い間違いですが、その後になぜか「余分な突き」「予備の刺し傷」、あるいは「余分なおちんちん」が登場します。
ブログAltJapanでの推理によると、エキサイト翻訳がこれに近い結果を出すのだそうです。エキサイト翻訳に「お荷物」を入力すると、
たしかに「お荷物」=”spare prick”=「余分なちんちん」となります。
なぜこんな訳語が入ったのかということですが、AltJapanの人によると、(彼がこれまで聞いたこともないという)イギリス英語のフレーズ”like a spare pricks at a wedding”(結婚式のお邪魔もの、お荷物)という表現があるそうで、ここから、「お荷物」=”spare prick”という間違った対応が生まれているようです。このフレーズの場合の「お荷物」は、あきらかにネガティブな意味の方の「お荷物」ですね。お客様向けの丁寧さを表す「お」ではなく。
ある文脈でそれが「お荷物」を表すからといって、機械的に置き換えるのは危険ですよ、というのがわかります。
翻訳した英文をもう一度エキサイト翻訳で逆変換すると、ちゃんと「お荷物」になってしまいますので、簡易なチェックである「元の言語にもう一回機械翻訳しなおす」というだけでは、この失敗は防げない。この失敗を防ぐには、別の翻訳サイトで逆翻訳をすべきだったかもしれません。
まあ、JR東日本みたいな大きな会社だったら、英語ネイティブの社員だっているでしょうし、ネイティブにチェックしてもらうのが結果的に一番安上がりだと思いますが。
なお、英語圏の人に日本語⇒英語の誤訳について反撃したい場合は、アジアジンでも紹介した「偶然だぞ」を見せてあげるといいでしょう。
# なお、この記事、タイトルで僕も単語の選択を間違っております…
また、究極の失敗としては、以前紹介した中国の「翻訳サーバーエラー食堂」も、よい教訓になるかと。
via Gen Kanai
外国語ならなおさら、できる限りのことをしないと伝わらない
PHPの文字エンコーディングの入力チェックを改善する方法について日本語のブログで議論があり、そのパッチを本家に提案したが、却下された、という話が盛り上がっているようです。
バグレポートされた岩本さん自身や、コメント欄やはてなブックマークでは、
- PHPの開発陣がダメだ
- マルチバイトに理解がない外国人がダメだ
- 残念だ
みたいな意見があまりに大勢をしめているので、そのバグレポートを見てみた上で、思ったことを述べたいと思います。
岩本さんのバグレポートを訳すと、こんな感じです
要約:
------------
セキュリティ的な要件により、htmlspecialchars()はバイト列をもっと
厳密にチェックすべきです。XSSするコードが見つかりました。
http://d.hatena.ne.jp/t_komura/20091004/1254665511 [日]
原始的なパッチを書きました。
http://iwamot.com/misc/html.c.patch.20091006
使えるかどうか知りませんが(笑)
再現コード:
---------------
// 越長 UTF-8 列
echo htmlspecialchars("A\xC0\xAF&", ENT_QUOTES, 'UTF-8');
// 不正な Shift_JIS 列
echo htmlspecialchars("B\x80&", ENT_QUOTES, 'Shift_JIS');
echo htmlspecialchars("C\x81\x7f&", ENT_QUOTES, 'Shift_JIS');
// 不正な EUC-JP 列
echo htmlspecialchars("D\x80&", ENT_QUOTES, 'EUC-JP');
echo htmlspecialchars("E\xA1\xFF&", ENT_QUOTES, 'EUC-JP');
echo htmlspecialchars("F\x8E\xFF&", ENT_QUOTES, 'EUC-JP');
echo htmlspecialchars("G\x8F\xA1\xFF&", ENT_QUOTES, 'EUC-JP');
予期する結果:
----------------
何も出てこないこと
実際の結果:
--------------
A_&B_&C&D_&E__&F__&G___&
("_"は不正なバイトを意味します)
もしあなたが日本語でオープンソースのプロジェクトをやってて、他にも毎日バグレポートを受けているような状態で、こんな感じのバグレポートが来て、「問題の詳細はこのURL、アラビア語ですけど」みたいに書かれていたとして、この問題について調査を始めたり、優先してこの問題に取り掛かったりするでしょうか? 僕ならしないと思います。
ましてや、”I don’t know whether it is useful though 
” 「使えるかどうか知りませんが(笑)」ですよ? こういうのは日本的な謙譲の美徳として日本のコミュニティでは通じても(どこでも通じるかはわかりませんが)、およそ真剣に「この問題について知ってほしい、興味を持ってほしい」という態度とは受け取られないと思います。
それまで、複数のブログでいろいろな人がしっかりした問題点の検証や議論を、かなりの長文の日本語でされていて、日本語でそれらを読んでいる人にとっては問題は自明なのかもしれません。
しかし、PHPの開発は英語でコミュニケーションされてますし、彼らが英語で上のバグレポートに出てくる断片からウェブを検索したとしても、日本語での議論のようなまとまった情報は見つからないかもしれません。
日本語で議論されている皆さんの努力にはとても敬意を払っていますが、最終的な問題がPHP本体を直すことにあるのであれば、英語に持っていって相手を説得するときに尻すぼみになっているのは残念です。
僕も英語でバグレポートするのは大変ですし、岩本さんのレポートも、パッチもあるし問題の背景が共有されているなら十分だとは思いますが、何が問題で、直さないとどういう問題が起こるか、起こったとして被害の大きさはどれぐらいか、修正がこれまでの他アプリにどんな副作用を起こしうるか(あるいは起こさないか)、といったことを書かないと、むしろ取り合わないのが普通じゃないかと思います。
はてなブックマークのコメントで書いたところ、岩本さんからこう追記をいただきました。
id:AKIMOTOさんに限らず、私のレポートの仕方が悪かったせいだと思われる方、ぜひ本件を引き継いでいただけないでしょうか。私の望みは htmlspecialchars の文字エンコーディング妥当性チェックが改善されることであって、どなたかが達成されるのであれば、それで万々歳です。採用されるレポートの書き方もそれで分かるでしょうし。
他人の英語について何かコメントしたら、こういう返しをされるだろうな、というのはわかっていました。
しかし、それぞれの人はそれぞれの優先順位があります。この問題が無視できる問題だ、とは僕は思いませんが、僕自身がこの先解こうとしている他の問題に比べれば、自分で引き継ぐほど差し迫った不利益を受けていませんし、また、議論されているみなさんほど、この問題について精通してもいません。英語が書けるというだけで、誰もが替われるような話ではないでしょう。少なくとも僕にはこの件の翻訳ボランティアになる動機がありません。
ただ、それが「自分に取って優先順位の高い問題で、どうしても通したい」ときにどうしてるか、は紹介できるかと思います。
ちょうど昨日、僕も一本のバグレポートを書きました。主な興味の対象のレイヤーが違うのですが、PHPのメールライブラリSwift Mailerのバージョン4に関するもので、日本独自仕様の提案に関係するものです。
具体的には、NTT Docomoなどが過去に間違って導入した、RFC違反の形式でピリオドを持つメールアドレスを受け付ける特別なモードを導入してほしい、というものです。
PHPとSwift Mailerではレイヤーも規模も、何もかも違いますが、
- 何が問題なのか
- その問題に他のアプリケーションはどう対処しているのか
– mail addressの場合、iPhoneやGmailが日本市場向けに何をしているか書きました
– 文字エンコーディングの入力チェックの場合、他の言語や処理系でどう扱っているか、というような話になるかと思います
- その変更を採用することで、既存のユーザーに影響するか
– 今回は影響するもの、影響しないものを合わせて複数の取りうる修正案を併記しました
といったことをまとめ、何が問題で、どうしてこんなばかばかしいRFC違反のメールを受け付けられることが日本の一部のユーザーにとって(ひいてはSwift Mailerの日本での普及にとって)大事か、というのを伝えようとしたつもりです。なんといっても、こんな修正日本以外のユーザーには何のメリットもないですからね。
# ちなみにこのレポート書くのに何日もかかってます。英語でブログ書いてるからといって、複雑な内容を一瞬で書けるわけではもちろんないです。
このメールの件は、いわば「悪い仕様を追認する」汚い修正なので、念入りにiPhoneなど他社の対応状況も添えましたが、PHPのエスケープで起こる問題が本当に筋のいいものであれば、これまでの日本語での議論をきっちりまとめて伝えることで、それよりは受け入れやすいのではないかと思います。
英語でバグレポート書くのも大変でしょうし、却下されれば凹みもするでしょうけれど、それを日本語に持ち帰ってきて「残念だ、残念だ」と騒いでも、それは決して相手に伝わらないですよ。
はてブコメントで「残念」と書いている人の中に、そのバグレポートを開いて見てみた人がどれぐらいいるんでしょうか。
「いつもの同じ問題」じゃないとわからせるには、わからせるだけの証拠を積み上げて見せないといけないし、バグレポートで届かないなら、(英語の)ブログを書いたりサイトを立ち上げたり、メーリングリストで問題提起したり、却下した本人にメールしたり、いろいろとあるのではと思います。
この問題で議論されているみなさんの努力、バグレポートまで書かれてチャレンジされた岩本さんの努力には(一PHPユーザーとして)たいへん感謝していますが、努力することが重要なのじゃなくて、どうやって自分(達)の意を通すかが大事ではと思います。それが「PHPのせい」「コアチームのせい」「英語のせい」「外国人のせい」で終わってしまうとしたら、僕はそれが残念です。
# あと、↑途中書いた僕自身のスタンスをよく読まずに「じゃあお前やれば」とコメントしないでくださいね。僕の次のバグレポートは、Swift Mailerでのiso-2022-jpサブジェクト行のエンコード&行分割に関するものになる予定です
[追記 2009.10.09]
徳丸浩さんが、PHPが今すぐ直らないとしても実施できる、このセキュリティホールが起こりうる条件と、その回避法についての解説をまとめられています。
[追記 2009.10.09]
moriyoshiさんが最初のバグレポートをcomitしてくださいました。ありがとうございます。
将来のマイナーアップデートリリースでこの問題は解消されるでしょう。実際に今このセキュリティホールが有効になる条件下のアプリケーションを運用されている方は、個別にパッチをあてたPHPをビルドして差し替えるか、上の徳丸さんの対策を行なう必要はあります。