Ermitejo - エスペラント語日本語翻訳

#BLOGO
2008/2/16

カーソル(キャレット)位置の取得法

分類: 公開, 開発記 / タグ: , , , ,

言及が遅くなりましたが、辞書引き機能のversio 2.2.0, 2.2.1を公開しました。バージョンの上がり具合は2.2.1の方が小さいのですが、実装に掛けた労力はむしろ大きかったです。といっても前者は1行のみ、後者はGoogleで検索した結果をいくつか参考にさせていただいただけで、五十歩百歩と言えますが。

(「カーソル(キャレット)位置の取得法」の続きを読む)

2008/2/7

ワニることを避けてのマークアップ

分類: 公開, 開発記 / タグ: , , , , , ,

検索ボックスの代用表記を自動的に字上符付き文字に変換する処理など、辞書引き機能を改版しました。

上記の処理はとても簡単だったのですが、見出し語インクリメンタル検索の強調表示マークアップ誤りという障害の是正には難儀しました。JavaScriptの辛さに堪えかねて、マークアップ処理をサーバ側で実装する、即ち「ワニる」ことすら考えましたが、何とか想定通りに処理するよう書けましたので、久しぶりの処理概説を兼ねて改版内容を詳細にご紹介します。

(「ワニることを避けてのマークアップ」の続きを読む)

2007/9/30

XREAのPHPから外部プログラムを実行する

分類: WordPress, 公開, 開発記 / タグ: , , , ,

エスペラント単語のフォーチュン・クッキー機能の公開以来、随分と放置していたのですが、この度この開発日誌からも使えるようにしました。なお、ついでにリンク先の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"-->と変わりませんね。

これにより、部品はそのままで、開発日誌からもフォーチュン・クッキーを表示することが出来ました。問題は、相変わらずそうやって設置した本人が「うっ、なんだこの語は?!」とプログラムにいじめられることでしょうか……。

2007/9/10

字上符付き文字の葛藤 (単語辞書引き機能 versio 0.9.4)

分類: 公開, 開発記 / タグ: , , , , ,

音韻関係のモジュールを先の辞書引き機能の改版に合わせて新規に作成したのですが、予想通り、初物の機能はなかなか安定しませんでした。それというのも、エスペラントの規則性を過大評価したというかこれに甘えてしまい、乏しいテストケースしか用意しなかったのが敗因と言えます。結果、連日連夜の改版を行うこととなりました。大多数の場合は問題なかったとはいえ、誤った発音が表示されたり、処理が異常終了したりすることがあり、反省しています。

もう少し具体的に述べますと、エスペラントの規則性に例外があるというのではなく(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版サクラエディタの開発が進められています。

ということで、そうした発音関係の修正を中心として、ここ数日での改版点の委細を以下に転記します。

(「字上符付き文字の葛藤 (単語辞書引き機能 versio 0.9.4)」の続きを読む)

< 脇書非表示 > 脇書表示