この度、辞書引き機能を正式版として改めて公開する運びとなりましたので、謹んでご連絡申し上げます。形態素解析機能に関連した副産物として2007/05/20に公開し、半年間に及ぶ試験稼働を終えることが出来ました。構文解析の研究・設計を行っていたり、或いは翻訳システム自体の開発に飛び石的に携わざるをえなかったりと、辞書引き機能に常に目を向けられていた訳ではありませんが、30回に及ぶ改版を経て、半年間の間に十分に揉んでいただいた辞書引き機能は着実に歩みを重ねて来られたと考えています。
本サイトの本来の使命は翻訳システムの開発ですが、その副産物としての辞書引き機能がこれほどまでにご利用いただけているとは、開発者自身予想だにしておりませんでした。しかしこうして栄えあるversio 1を刻めたことは、ひとえに、まだまだ発展途上であるこの辞書引き機能をご利用いただいた皆様あっての帰結であろうと感謝しております。改めてご利用者の方々にお礼を申し上げます。
現在は形態素解析処理の結果を素に辞書中の日本語訳語をそのまま用いているだけであり、日本語の訳語としては甚だ不十分な状態であることは認識しております。これは日本語の文字列生成処理を加えていない所為でありますが、次版に向けては勿論、新たに発見された不具合(バグ)の修正や、上記以外の機能追加についても積極的に取り組んで参る所存です。ご意見・ご感想・ご要望等も楽しみにお待ちしております。
次版は半年後とは言わず、ご案内出来る日が遠からずまたやって来ようかと見通しておりますので、今後ともどうぞよろしくお願い申し上げます。
なお、最近の修正点は以下の通りです。
(「単語辞書引き機能の正式版公開 (versio 1.0.0)」の続きを読む)
エスペラント単語のフォーチュン・クッキー機能の公開以来、随分と放置していたのですが、この度この開発日誌からも使えるようにしました。なお、ついでにリンク先のURIの字上符付き文字も正書法にしました。GUIなユーザエージェント(つまりはIE等)では左肩に表示される「Ĉu vi scias?」というものがその成果です。
最初からやっておけば良かったのですが、XREAに於いてWordPressから外部プログラム(この場合、フォーチュン・クッキーのスクリプト)を呼び出す方法が当初不明だったため、今まで放置していたという次第です。
WordPressはPHPで書かれており、かつ、XREAに於いてPHPはSafe Mode(セーフモード)で稼働しているので、単純に適当なテーマファイル、例えばslidebar.phpあたりにecho `~`;やらexec('~');やらecho popen '~';やらと書いただけでは、外部プログラムを稼働することは出来ません。かといって、わざわざsidebar.phpの中でロジックを最初から組むのはぞっとしません。何せ、ランダム表示の元ネタである見出し語一覧は、Perlのデータ構造としてStorable::nstoreしたものを解凍しているだけなので、PHPから単純にこのバイナリデータを読むこと能わず、PHP用の見出し語一覧をまたこしらえる必要があります。これはいかにもいただけません。
とはいえPerlは知っていてもPHPは知らなかったため難儀していたのですが、結局やることは単純で、virtual('~');をするだけでした。この場合、呼ぶ先は'/virtual/USER/public_html/DIR/SCR.pl'と絶対パスで記述するのではなく、'DIR/SCR.pl'と記述する必要があります。この辺は、通常のHTML文書にSSIを埋め込む際の記述<!--#include virtual="DIR/SCR.pl"-->と変わりませんね。
これにより、部品はそのままで、開発日誌からもフォーチュン・クッキーを表示することが出来ました。問題は、相変わらずそうやって設置した本人が「うっ、なんだこの語は?!」とプログラムにいじめられることでしょうか……。
文章内単語訳機能を公開しました。これまでの単語辞書引き機能と違い、エスペラント語の「文章」を与え、それぞれの単語の辞書引き結果を連続的に表示する機能です。
「翻訳」「逐語訳」ではなく「単語訳」ですので、構文解析の成果は一切、これっぽっちも反映されていません。また、エスペラント単語に該当する日本語も、訳し分け(複数の訳語がある場合の取捨選択)や形態素生成(格・数・時制等々を考慮して訳語を一部変換する処理)も、少なくとも初版の現在は全く対応していません。
ですが、これまでちまちまと単語訳を繰り返していたことと比べ、例えばエスペラント文を他のウェブページからコピペして一斉に辞書引きすることが出来るため、散文的な文章、特に技術的な文書や、エスペラント版ウィキペディアのような文書では、訳された単語を並べてみるだけでもそれなりに理解が出来ようかと思います。「荒訳」という程のものではありませんが、造語解析の成果によって、未知語が殆ど存在しないことに驚かれるかも知れません。これこそまさにエスペラントの真髄です。
なお、これにあわせ、辞書引き機能のトップページを新たに設けました。これまではサブドメインを直接指定しても、単語辞書引き機能のページへリダイレクトしていましたが、単語辞書引き・文章内単語訳の両方のフロントエンドとするべくページを新設したものです。その他、ドキュメント類(ヘルプ等)はこれから整理して参ります。
この新味に乏しいけれども効果は少なからぬ機能が、エスペラントを介した相互理解やエスペラント学習の一助となれば幸いです。
とはいえ、まだまだα版という趣が強く、エラー処理や特殊処理等は殆ど手つかずであり、往々にしてエラーを吐くこともあろうかと存じます。これについては、今後の改版を見守っていただければと考えています。
ようやくversio 0.9.0で実装を始めた音韻関連の機能が整いつつあります。直近で更新した内容は、韻文中での発音に関する二点です。
前者では、アクセントを変更しないという点が曲者です。エスペラントの規則性ゆえに、実装も極めて論理的かつ簡素なものとなっていたのですが、こういう特例の存在により、優雅さとは程遠い泥臭い実装を行う羽目になります。前者ではl’を「ル」と読めるようになるのですが、l’armoをルアーモと読んでしまうために、ここでも特例を設けてラーモと読めるように処理を書き加えました。
良い機会なので、発音をカタカナやIPAで転記する処理の概要をご紹介します。あまり変なことを考えず、人間の頭の中で行っている処理を素直にコード化することが一番と言えます。
('sam', 'ide', 'an', 'o', 'j', 'n')は('sam', 'ideanojn')になります。これはまだ文法上の区切りですが、続け読みが出来るように配慮された配列になっています。'sam'は('sa', 'm')に、'ideanojn'は('i', 'de', 'a', 'no', 'j', 'n')に分解されます。これで、それぞれの要素が一つの音に対応するような配列になりました。('sa', 'm', 'i', 'de', 'a', 'n', 'o', 'j', 'n')というリストを得て、配列に突っ込みます。trすれば事足ります。アクセント位置には長母音の記号を与えて完成です。samとideanojとの間は空白を入れておきます。'sa'は$japana->{'s'}{'a'}で「サ」が求まりますし、母音のみや子音のみの場合にはダミーのキーを与えて$japana->{'m'}{'_'}で「ム」、$japana->{'_'}{'i}で「イ」が求まるという次第です。長母音で「ー」を与えて完成です。このように可能な限り手を抜いて楽をして発音させている無邪気な実装なので、世知辛いesper’などという文字列を与えたら、まず「’」なんてハッシュキーがないのでこけますし、これを無視したら母音が一つ足りないわけでエスペル(エがアクセント)と読もうとするしで大変です。
そこで、以下のように機能追加することによって、こうした言語現象にも対応出来るようにしました。
(「エスペラント発音解析の実装方法 (単語辞書引き機能 versio 0.9.5)」の続きを読む)
音韻関係のモジュールを先の辞書引き機能の改版に合わせて新規に作成したのですが、予想通り、初物の機能はなかなか安定しませんでした。それというのも、エスペラントの規則性を過大評価したというかこれに甘えてしまい、乏しいテストケースしか用意しなかったのが敗因と言えます。結果、連日連夜の改版を行うこととなりました。大多数の場合は問題なかったとはいえ、誤った発音が表示されたり、処理が異常終了したりすることがあり、反省しています。
もう少し具体的に述べますと、エスペラントの規則性に例外があるというのではなく(sam/ide/an/oやらといった場合は除きますが)、Perlで字上符付き文字を実装する際に手抜きをしており、これが後々尾を引いているといったところでしょうか。
実は、エスペラント語日本語翻訳システム「Ermitejo」は、21世紀、このUnicodeの時代に、字上符付き文字の内部処理を前時代的なx後置式の代用表記で行っています。関数名やら変数名やらをエスペラント式に名付けているだけなら特に問題がないのですが、取り扱うデータを代用表記すると、色々不都合が起きます。
普通に処理している場合には、外部から正書法ないし代用表記で突っ込まれたデータのアルファベートを変換して内部で使い、外部に表示する際には逆変換して正書法で返しているので問題はありませんでした。しかし、エスペラントの誇る1文字1音という原則が崩れ、「ĉ」の音「ʧ」を「cx」と2文字で表現することになりますので、音韻関係の機能の実装で舞台裏が拙さが露見したという次第です。
責任転嫁するつもりは毛頭ありませんが、コーディングに使っているエディタのサクラエディタがUTF-8への対応が甘く、なかなかこうした悪癖を改められないという思いもあります。サクラエディタは内部コードがUTF-8等ではなくShift-JISなので、UTF-8のファイルの読み書き自体は出来ますが、エスペラントの字上符付き文字等やIPA等は保存出来ないので、痛いところです。今更秀丸にも戻れませんが、さりとてサクラエディタの抜本的な書き直しを行える技量も時間も私には無いので、開発者の方々に声援を送ることしか出来ません。
【追記】kobake氏のウェブサイト「digital hole」にて、UNICODE版サクラエディタの開発が進められています。
ということで、そうした発音関係の修正を中心として、ここ数日での改版点の委細を以下に転記します。
| 月 | 火 | 水 | 木 | 金 | 土 | 日 |
|---|---|---|---|---|---|---|
| « 5 月 | ||||||
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 | 31 | |||