#1 Viro legas libron.
#2 Libron legas viro.
#3 Viro libron legas.
#4 Libron viro legas.
#5 Legas viro libron.
#6 Legas libron viro.
Free Esperanto Course の Lesson 1 で解説されている通り、上記の文は英文の "A man reads a book." に対応するものです。#3と#4は日本語に似た語順(#3は「男が本を読む」で、#4は「本を男が読む」)で、#5はフィリピンのタガログ語に似た語順になっています。
フリーソフトの Esperantilo で英訳してみると#1〜#6の文はどれも"A man reads a book."と翻訳されます。
文中の位置で主語、目的語の判定が行われる英語。主語、目的語の判定は文中の位置とは無関係なエスペラント。
ここで私が選択しなければならないのは、#1のようなパターンのエスペラント文が翻訳できればよしとするか、#1〜#6のすべてのパターンを翻訳できなければならないとするか、です。さあ、どっち?


1. 構文解析:原語(エスペラント)の語順でSVOと想定する各位置に項が存在しない場合、それを「空所」(Gap)として扱い、想定以外の位置に出現している項に長距離依存していると解釈する。
2. 意味解析:概念依存構造(CDS)に落とし込む。
3. 意味変換&構文生成:CDSをピボットとして対象言語(英語や日本語)の構文を生成する。以降、形態素生成などはここでは略。
まだ1.の途中辺りまでしか実装出来ていませんが、それだけでも数千行の処理となってしまいます。私はHPSGという文法理論に基づいて構文解析・意味解析を行っていますが(以下URL:ただし昔の記事なので今の実装とはかなり違います)、既に1年半も悩んでいます。
ご参考 http://blogo.ermitejo.com/2007/09/20/efektivigo_de_hpsg_en_libera_vortordo/
一方、英語と同準と固定さえしてしまえば、単語変換と形態素生成だけでかなりの文章が翻訳出来てしまいますので、とても楽ちんです。「運用でカバー」というのはどこでも良く聞く言葉ですが、利用者に対しても(制限付きであっても)「まず利用出来る」という土台を提供出来ることも利点です。
必要な情報を完備した大量の登録データを辞書としてあらかじめ用意するというのは非常に難儀なことなので、学習し成長し続けるシステムというアイデアには魅力を感じます。
一昔前なら断念せざるを得なかった「富豪的プログラミング」によって、出来ることが広がっていくのは痛快ですね。
Wikipediaのようにユーザ参加型の方式もありますが、そもそもWeb上にある膨大な量のテキストは宝の山です。
例えば共起を見つけるのにGoogle Web APIを使うことで、個人でもGoogleさんが蓄えた膨大なテキストデータを(間接的に)触ることが出来ます。集合知は今世紀ならではの資料だと思います。
この分野は「ワードサラダ」などといって広告スパムブログの人たちも頑張ってしまっているようですが、物は使いようということで。
まだ「Google 翻訳」は期待に応えるような成果はあげてないようですが、集合知を反映するシステムというのは夢のある企てなので、何とか成功してほしいものだと考えます。「Google 翻訳」では翻訳した結果を利用者がチェックして、適不適をフィードバックするようになってますよね。それを翻訳メモリーみたいなことに利用するだけならあまり魅力を感じないけれど、システムが自身の動作をそれによって変えていくようにプログラムされていれば面白いなあと思います。