Thunderbird 3では、強力な全文検索機能が導入される予定だが、そのバックエンドを担うのがGloda（Global Database）である。Glodaは、Thunderbirdが管理するあらゆるメッセージのインデックスを作成し、柔軟で高速な検索処理を行う。
しかし、その開発は英語を念頭に置いて進められてきたため、国際化対応は遅れている。今のところ、ライバルのPostboxと同様に、Thunderbird 3はインデックスを利用した日本語全文検索には対応していない。しかも、肝心要のインデックス作成アルゴリズムが決まっていないのだ。この点に期待している方もいらっしゃるだけに、残念なことである。
この件に関しては、Mozilla Japanのdynamisさんが本家Bugzillaで問題点を詳細に指摘されているので、これを参照しながら話を進めていきたい。
dynamisさんによれば、今のGlodaは次のような問題を抱えているという（Bug 479783）。一つは、マルチバイト文字列をデータベースに格納する時点で、文字化けが発生すること。この点はエンコードの問題なので、対処は比較的容易であり、まだ解決済みではないものの、パッチが完成に近づきつつある（Bug 479214）。
真の問題は、英語のようにスペースで分節できる言語はいいとして、そうでない言語、たとえば日本語ではうまくインデックスを作成できないことだ。メッセージを解析してインデックスに落としこむプログラムをトークナイザー（tokenizer）と呼ぶが、Thunderbird 3はSQLiteの"Porter stemmer"というトークナイザーを使っているものの、これはスペースで分節する言語にしか対応していない。
これを日本語に当てはめようとすると、たとえば、「現在の Thunderbird は全文検索エンジンが使い物にならない。」という文字列は、「現在の」「Thunderbird」「は全文検索エンジンが使い物にならない。」というインデックスに変換される。「は全文検索エンジンが使い物にならない。」などというインデックスに検索文字列がヒットすることは皆無といってよく、このままではユーザーの期待とはかけ離れた低レベルの検索機能しか提供できなくなってしまう。しかも、上の例は、たまたま「Thunderbird」の前後にスペースが入っていたから三つに分解できただけで、スペースがなければお手上げだ。
そこで、別のトークナイザーが必要になるわけだが、開発者が考えていたのは、スパムフィルターで使われているトークナイザーを流用することだった（Bug 472764）。
しかし、dynamisさんの指摘では、これも使い物にならない。理由は三つあり、「全角シンボル（カッコなど）をうまく分けられない」、「『のすべてを』など、ひらがなやカタカナ（韓国語も）の一部をうまく分けられない」、「単純なユニグラムでは速度が不十分である」というものだ。これは、現行のスパムフィルターの欠点でもあり、それをGlodaに持ち込むべきではないとdynamisさんは主張する。
ここで、ユニグラムについて説明しておこう。工藤智行氏の「検索エンジンを作る」シリーズを参照すると、検索エンジンのインデックスを作成する際、形態素解析とN-gramという二通りの方法があるそうだ。ユニグラムはN-gramに含まれる一技法である。
形態素解析では、原文の自然言語を構文解析して分かち書きする。たとえば、「今日/は/良い/天気/です。」といったように。検索ノイズは少ないが、特定の言語を対象にするため、Thunderbirdのように多言語を扱うプログラムには向かない。
これに対し、N-gramは、単純に文字の並びを見出し語としてインデックスを作成する。1文字を元にインデックスを作成する技法がユニグラムで、2文字の並びを元にするときはバイグラムと呼ばれる。たとえば、バイグラムであれば、「今日は良い天気です。」という文字列を、「今日」「日は」「は良」「良い」……といった形で切り分けていく。見出し語の切り出しに文法解析を要しないので、特定の自然言語に依存しないという特徴があり、Thunderbirdが採用するならこちらの方法になる。
スパムフィルターに使われているnsISemanticUnitScannerというトークナイザーは、ひらがなとカタカナを区別するので、単純なユニグラムとは違うようだが（Bug 176528）、それでも切り出す量はバイグラムよりもはるかに多い。そうなればインデックスは肥大し、検索速度が落ちてしまう。
どう対処するかだが、dynamisさんから指摘を受けるまで主要開発者たちがこの問題に気づかなかったことからも明らかなように、言語学の知識とプログラミングの技術を兼ね備えた開発者の不在がネックになっている。また、Beta 3のリリースまでにメドを付けなければいけないが、期間は約10週しかなく、新たなアルゴリズムを開発している余裕はない。いちおう単純なバイグラムでインデックスを作成するパッチ（Bug 414102）はあるものの、精度やパフォーマンス面でかなり不安が残る。
主要開発者たちは態度を決めかねているようだ。dynamisさんが既存の有名な全文検索エンジンを挙げており（Hyper EstraierやSennaなど）、そこと交渉してライセンス問題を解決したうえで、トークナイザーを丸々取り込む話も出ている。ただ、それらはMySQLなど別のデータベースを対象にしたものであるため、SQLiteでうまく動く保証はない。
先行きは不透明だが、日本語版Thunderbird 3にとって中核的な問題であるだけに、きっちりと解決してほしいものだ。
