Mozcdict-ext用の語彙登録ページを用意した
開発::application
序
Mozcdict Extは私が管理している中で最も需要の高いリポジトリだが、コントリビュートが全くない。
正直、このプロジェクトはユーザーコントリビュートを軸に考えており、コントリビュート皆無だと進化しないのである。 もちろん、別に進化しなくても従来のMozc-UTみたいには使えるから別にいいという人も多いのだろうけれども、それでは真価を発揮できない。
そこで、コントリビュートのハードルを下げるため、公開された簡単なフォームで登録できるようにするというアイディアがかなり前からあった。
ただ、手間と、実際に使われるかどうかというあたりからやってなかっただけだ。 このあたりで停滞していたものといえばPureBuilder Simplyのサイトと同じような事情である。
語彙登録ページ
Mozcdict Ext 語彙登録ページは使い方は一目みれば分かるだろう。
ユーザーは匿名で1収録して欲しい語彙を送信することができる。
また、申請された語彙の対応状態も確認できる。
ページのフィルタ機能を使って、変換したい語が収録されていないことを確認したら、申請フォームに入力して申請するだけだ。
あとは私が定期的に確認して、受け入れたものを収録していく。 言うのは簡単だが、品詞の対応関係を調べるのが結構大変で、割と時間はかかる。
品詞については、Mozc IDを使うと登録できる人がほとんどいないと思われるため、Mozcのユーザー辞書+αくらいに抑えておいた。 また、細分化された品詞だけを候補にしてしまうと、それだけでできない人が多いと思われるため、細分化されていない品詞も設定するようにした。
私自身にMozc IDでちゃんと品詞分けできるだけの日本語力がないため、Mozc品詞2をちゃんと説明できるような日本語学力がある人に手伝って欲しいと常々思う……
なお、見た目は全く凝っていないが、こんなものの見た目に労力を注いでも仕方ないので、実用性至上主義である。
登録ソフトウェア
実はこのページを作るのは3回目である。
2回ほど作りかけで放棄したためだが、特に放棄する強い理由があったわけではなく、作りかけで放置したために自分でも状態がよくわからなくなったからだ。
今回採用したものに関しては、その技術基盤はDLSite Voice Utilsにあり、基本的に同じような作りになっている。 というか、それがあったからこそ今回さくっと作ったのであって、それがなければ面倒でまだしばらくかかっている。
相変わらずVanilla JavaScriptを使ったとてもコンパクトなもので、165行、4.9kB。 プリミティブなDOM APIを利用している。
また、通信部分はFetchwrapperを使っている。 これも割となくてはならないものになってきている。
今回のソフトウェアはクローズドなものなので、サーバー側のソフトウェアについては述べないが、もちろんクライアントソフトウェアは見ることが可能だ。
もっとも、サーバーソフトウェアはデータを検証してJSONデータを更新するだけのものである。 ちなみに、このJSONデータは間違って更新してしまう可能性がなきにしもあらずであるため、ちゃんと生成時に元データを残すようにしてある。
シンプルな作りにするため、Nginx->Lighttpd->CGIの構造。 私が作ったもので、小さなソフトウェアは割とこの構造になっている。 また、今回はRack/CGIは使わず、標準のCGIライブラリを使っている。
ステータスの更新はコマンドラインツールで行う仕様。 自分で使いやすいように工夫してある。
プロジェクトをソフトウェア自身で確認しにいくようにはなっていない。
今回も最近の流れであるクライアント完結型SPAの手法を採用しており、辞書データ全体をJSONとして取得して処理するようになっている。 本ソフトウェアも結局のところデータ全体へのアクセスが必要であり、隠蔽する必要もないし、サーバーでフィルタする意味もない。 そこで全データをJSONとして取得させればいいし、それならデータ更新時に全体データをJSONとして生成すればstaticにデータを取得できる。
ただ、従来と違いデータはJSON形式であり、JavaScript形式への変換は行っていない。 これはサーバーでの取り扱いやすさのためである。
結果的にそれがよかったかはだいぶ怪しい。 本ソフトウェアはFetchwrapperを使ってHTTP通信を2回行うが、それはどちらもJSON(辞書データと品詞データ)をロードするためである。
もし従来通りJavaScriptの変換を行えばFetchwrapperと、Fetchwrapperをインポートするためのスクリプトは不要になり、かなりスリムアップできる。 もしかしたらそういう変更をするかもしれないが、JavaScript変換はトリック感が強いのでできれば避けたいものではある。
ちょっと変わったところでは、辞書データJSONをそのまま使わずに配列に変換して使っていて、もとの辞書データはグローバル空間にエクスポートしていないのだが、辞書データのスコープのクロージャをcheckExisting()という名前でエクスポートしており、限定的なインターフェイスをもたせるようにしている。
ただ、この方法でユーザーに対して辞書データを隠蔽できるわけではないので、この方法に意味があるかというとやや微妙なところ。
他にひと工夫あるところといえば、読みのinput要素に設定されたpattern="^[\p{Script=Hiragana}ー]+$だろうか。
Unicode Scriptは各文字に1つしか当てられないため、ーのような複数の文字体系で使われる文字は含まれず、Hiraganaスクリプトとーを指定する、ちょっと正規表現慣れの必要な書き方をしている。
この機能/ページ自体へのissue
Mozcdict Extにissueを立ててほしい。