KDE 4のSonnetによる高度な言語処理機能
KDE 4では、これまでより一歩進んだスペルチェック機能も採用する可能性がある。Rideout氏は「スペルチェックの機能をKDEのすべてのテキスト編集ボックスで有効化することについて、現在メーリングリストで議論を進めている」と話す。またSonnetには、単語のカウント数や読みやすさのスコアなど、テキストの統計情報を表示する機能も用意される。最終的にはテキストの自動補完機能も実現したい、とRideout氏は考えている。
SonnetがすべてのKDEアプリケーションで容易に利用可能なライブラリであることから、Rideout氏はテキストエディタ以外のアプリケーションにも目を向けている。とりわけSonnetの言語検出機能には、思いも寄らない使い方が期待できる。Sonnetは、20文字程度のテキストデータを与えるだけでその言語を判断することができるのだ。この言語検出機能はすでに数十種類の言語で動作している。Rideout氏によると、デスクトップ検索ツールStrigiの開発者らは同ツールの検索機能に言語検出の機能を統合することを検討しているという。おそらく、そのうちにユーザは「先週、スペイン語で書かれた文書」といった条件で検索を実行できるようになるだろう。
最近、言語学の学士号を取得したRideout氏は、多言語サポートの改良はKDE 3で「変更要求が一番多かった項目」であり、言語検出にとって最も大きな可能性を秘めた領域でもある、と話す。「ユーザは文書の正しさをきめ細かくチェックできるようになるだろう。文書を構成するどんな単位（デフォルトは段落）でも、そこで使われている言語で利用可能なツールにより、その言語に応じたチェックが行われる。便宜上それぞれの部分に対して自動的に言語の検出が行われることになっているが、ユーザがこの機能を無効にしたり結果を訂正したりすることもできる」
Sonnetの言語検出機能がないと、イギリス人の同僚と頻繁にやりとりするフランス人ユーザは、言語を切り換えるたびにスペルチェッカで使用する言語ライブラリを手動で変更しなければならない。KDE 4であれば、別の言語で入力を始めたことをSonnetが自動的に検知し、その言語に応じたスペルチェックをしてくれる。もっと複雑な状況として、フランス語で書いている電子メールの途中に英語で書かれた段落を引用することもある。この場合KDE 3であれば、KSpell 2が英語の段落の部分をひどいスペルミスのあるフランス語と解釈してしまい、赤い下線が長々と引かれることになるだろう。一方KDE 4のSonnetなら、英語の部分に対しては自動的に英語としてのスペルチェックが行われ、フランス語の本文と同様に正しく処理されることになる。
この言語検出機能について、Rideout氏は次のように説明する。「もともとSonnetの言語検出機能は、Maciej Ceglowski氏の開発したLanguidというPerlスクリプトをベースにしたものだった。私はこのPerlスクリプトをC++に移植したうえで何度も修正をくわえてきたので、アルゴリズム的には同じアプローチをとってはいるが、もはや直接的な移植版にはなっていない。最初はLanguidを「ベースにしたもの」だったが、同じコードがSonnetのどこにも使われたことはなく、今では色々なところで大きな違いがある。Languidの作者は、寛大にもKDEに対してLGPLを用いたライセンスを認めてくれた。我々による派生コードをKDEのライブラリの一部としてメンテナンスと配布ができるようにとの配慮だった」
Languidは、基本的に『N-Gram-Based Text Categorization』（Nグラムに基づくテキスト分類、William Cavnar、John Trenkle著）に記された手法に基づいている。グラムとは、N文字からなるテキストのセグメントのことで、Sonnetでは3文字からなるトライグラム（trigram）を使用している あるテキストに含まれるすべてのトライグラムの尤度を分析することによって、そのテキストの言語について仮説を立てることができる。Rideout氏は次のような例で説明する。「我々の言語モデルでは、英語なら‘_th’、スペイン語なら‘_de’が最上位のトライグラムになっている。したがって、テキストに‘_th’で始まる単語が多く、‘_de’で始まるものがない場合、スペイン語ではなく英語のテキストである可能性が高い。また、お互いに類似した表記体系を持つ言語どうしでのチェックのみを行ういくつかの最適化手法や、近くに書かれているテキストの言語をヒントとして利用する経験則も用意している」
Sonnetはテキストの各段落に対して個別に言語のチェックを行うが、Rideout氏によれば文単位でチェックすることも可能だという。段落ごとにチェックを行うのは、テキストの分量が多いほど正確な結果が得られるのと、大きな文書ですべての文をチェックすると負荷が不必要に大きくなってしまうためである。
Sonnetでは、言語検出の機能を使わずにメインおよびバックアップの言語辞書を選択することもできる、とRideout氏は話す。この場合、メイン言語の辞書によってスペルミスと判断された単語は、バックアップ言語の単語であると想定され、その辞書によるスペルチェックがかけられる。この方法は、たとえば、医学用の辞書にしか載っていない用語を多用する医師のような人々にとって役立つだろう。Sonnetの言語検出には、レイアウト・ヒントに関するもっと革新的な機能も含まれている。たとえば、ヘブライ語（右から左へと読む言語）で書かれた段落であれば、自動的に右揃えでページ上に表示されるのだ。
こうしたコンピュータによる言語処理のすべてをユーザインタフェースの動作の妨害や遅延を起こすことなくバックグラウンドで実行するために、SonnetではKDEのThreadweaverというテクノロジを利用している。Threadweaverを介して複数の実行ジョブを別々のスレッドに的確に割り当てることで、Sonnetはユーザの入力を妨げることなく、文書に対して言語検出およびスペルチェックの機能を実行することができる。Rideout氏は、Threadweaverを早くから採用した人々の1人である。Threadweaverについて彼は次のように語る。「シングルプロセッサ・システムの場合、理論上は従来のKSpellのコードよりも処理速度が低下することもあり得るが、ユーザが認識できるほどの速度低下ではない。マルチプロセッサ・システムの場合は、かなり処理速度が向上する。ただし、開発の容易さという点では、従来のアプローチに比べてかなり劣る」
革新的な言語検出の機能であるにもかかわらず、Rideout氏は二度手間を避けて既存コードを再利用するように注意している。スペルチェックに関しては、その大部分をAbiwordのEnchantライブラリに基づいたプラグイン・システムをSonnetは利用している。さらにEnchantは、スペルチェックの機能をAspellをはじめとする各種の標準スペルチェック・ライブラリに頼っている。Enchantの機能を補うためにRideout氏が開発を進めているのが、Elixirと名付けられた文法チェック・ライブラリである。Elixirは、An GramadóirやLanguageToolなど、いくつかの既存の文法チェック用フリーソフトウェアを対象とした共通のインタフェースとして動作する。彼は、Elixirが完成したらAbiwordに採用されることを期待しており、EnchantとElixirの双方で利用されるこのプラグイン・システムの標準化をFreeDesktop.orgに求めている。また、EnchantとElixirがKDEおよびGNOMEの主要なテキストエディタで直接使用され、OpenOffice.orgやその他のエディタでも標準規格に準拠したこれらのプラグインが採用されることもRideout氏は期待している。
Sonnet誕生のきっかけ
Sonnetプロジェクトは、Zack Rusin氏が書いたあるブログ記事から始まった。Rusin氏はTrolltechの開発者でKDEに関しては約5年の経験を持ち、Sonnetの前に用いられていたKSpellのメイン開発者でもある。2006年5月にRusin氏が自らのブログで提案したのが、KDE用の「完全な言語処理フレームワーク」である。彼はそこで、デスクトップ環境の言語処理に関する標準機能の1つ、スペルチェック機能を文法、辞書、シソーラス、翻訳の各ツールを利用して強化することについて述べていた。
Rusin氏が取り組んでいるのは、KDEのもとになっているQtツールキットである。そのため、彼の注力分野は言語処理ではなく、主としてコンピュータグラフィックに関するさまざまな側面である。「言語処理は確かに魅力的な分野だが、少なくともデスクトップでの利用に関する限り、言語処理に取り組みたいという人はなぜかあまり多くない」と彼は言う。
Rusin氏がSonnetを提案したとき、Jacob Rideout氏はKDE開発についてわずかな経験しかなく、何件かのバグレポートとパッチで貢献していたに過ぎなかった。しかし、Rideout氏は言語学の専門知識を活かし、KDEプラットフォームを利用するライターのために考案された「無駄な機能を排したテキストエディタ」、Phrasisの開発を進めていた。
Rideout氏が開発したライター向けのテキストエディタには、文法チェックの機能が求められていたようだ。「GPLに従う文法チェッカでPhrasisに組み込めるものに適したQt/KDEラッパーを探していた。KDEには適当なものがなかったが、AbiWord用のプラグインが見つかった。そこで私はAbiWord用のラッパーをQtに採用したうえで、もしかするとそれを使いたいという人がいるかもしれないのでKDE開発者たちにそのことを知らせた。何人かのKDE開発者は、特にKOfficeを手がけていた開発者はそれを聞いて興奮していたが、当時はこの作業をしてくれる人が1人もいなかった。そこで、いくらか調査をしてZack（Rusin氏）をはじめ何人かと話をした後、自分でハッキングを始めたんだ」。現在、Rideout氏はKDEプロジェクトのSVN（Subversion）アカウントを取得し、PhrasisそっちのけでSonnetの開発を続けている。Rusin氏もアドバイザ的な役割で引き続きSonnetプロジェクトに関与している。
「機能の点ではすべてが75％完了した段階にある」とRideout氏は語る。これまで、Rideout氏にとって最大の障害はマルチスレッド環境に置けるプログラミングを学ぶことだった。彼は次のように話す。「以前から私の開発のやり方は、準備なしにコーディングを始めるというもので、おそらく必要とされるコードの1～2割はこうして作られる。次に、一歩引いて目標を再確認し、適切なソリューションの設計を行う。そしてコードを再構成し、アーキテクチャを実装する、といった具合だ。基本的に、コードに対する私のアプローチは文章に対するものと同じで、多くの草案を書き、それを自分で容赦なく編集する、というものだ」。このプログラミング・スタイルはこれまでのRideout氏には合っていたが、マルチスレッド環境では「とんでもない状況を生み出す可能性がある」とRideout氏は嘆く。「現在、作業の大半は終わっていてKDEのSubversionリポジトリで公開されているが、ベテランのKDE開発者たちによるレビューはまだ済んでいない」
Rideout氏によると、Sonnetにおける翻訳機能の優先度は低く、KDE 4のリリースには間に合わないかもしれないが、将来的には実現したいのでこの開発に他の人々が協力してくれることを望んでいるという。また、辞書またはシソーラス関連のツールも「KDE 4.0リリースに合わせて用意されるコア・コンポーネント」のリストには記されていない。
KDE 4の多くのコンポーネントと同様、Sonnetはデスクトップ・オペレーティングシステムで一般的になっている機能に大きな変化をもたらすと期待されている。なかでも多言語ユーザはSonnetの自動言語検出のおかげで大きな進歩を実感することになるだろうが、その他のユーザでも文法のチェックやテキスト統計情報の取得のほか、翻訳、辞書、シソーラスといった今後搭載予定の機能をきっと活用できるはずだ。
