FUEL – MDC からリンクされている全オブジェクトのページの和訳が完了した。
以下、 FUEL 2.0 で追加された各オブジェクトについての雑感。

Window

ブラウザウィンドウの新しいタブでURIを開く。
タブを開く・閉じる・移動する・選択するイベントを監視する。
ブラウザウィンドウを開いた直後（つまり browser.xul にて window の load イベント発生時）に、イベントリスナを追加するために、 Application.activeWindow.events.addListener… などとやりたいところだが、アクティブなウィンドウ＝今開いたウィンドウとは限らない？つまり、バックグラウンドでウィンドウを開くようなケースもありうるかも？

BrowserTab

タブでURIを読み込む、タブを移動する、タブを選択する、タブの内容ドキュメントを取得する。
タブへの読み込みイベントを監視する。
Window#open と BrowserTab#load は使用頻度高そうだが、引数はどちらも nsIURI オブジェクトってのは痛い。 FUEL の目的は XPCOM を意識しない形へとコードを簡略化することじゃなかったっけ？

BookmarkFolder

Bookmark

ブックマーク・区切り・フォルダの追加、削除、各プロパティの取得と変更。機能的にはそれだけ。
BookmarkFolder#addSeparator の引数にタイトルを指定できないのはなぜ？と思ったら、 Places では区切りにタイトルを付けられなくなっているようだ。

Annotations

Places:Annotation Service 自体は拡張機能開発者的にはかなり期待できそうなシステムだけど、 FUEL の Annotations オブジェクトによってどういうメリットがもたらされるかは現時点では不明。

先のエントリでもちょこっと触れたように、BabelZilla を使うことで拡張機能のローカライズ関連のメンテナンスが楽になる。

BabelZilla へ拡張機能を登録すると、その拡張機能専用のフォーラムが作成されるので、翻訳者とのやりとりを一極化できる。また、 WTS (Web Translation System) と呼ばれるシステムによって、ローカライズファイルのアップロードやダウンロード、さらには編集までも Webベースで行うことが可能になる。

自分も2年前から少しずつ BabelZilla を使い始め、今では完全に BabelZilla へ移行した。たとえ翻訳者がEメールで直接 locale パッケージをよこしても、 BabelZilla 経由しか受け付けておりませんとお断りし、 BabelZilla へのユーザ登録を促すようにしている。

WTS を使う大きなメリットとして、「Download all locale files (missing string: replaced)」というリンクから未翻訳のエンティティ・プロパティをすべて英語に置換した形ですべての locale パッケージを圧縮してダウンロードできることが挙げられる。正式リリース版の XPI ファイルを作成する際に、この置換済み locale パッケージをダウンロードして自分の拡張機能のソースコードに含めてやればよいわけだ。

しかし、後日拡張機能のバージョンアップを実施し、新たに翻訳可能なエンティティ・プロパティを追加し、 XPI を作って BabelZilla へアップロードすると、英語に置換された部分についてはすでに翻訳済みであると認識されてしまう。これは BabelZilla の仕様であり、未翻訳なエンティティ・プロパティについてはその行自体を無い状態にして XPI を作成してアップロードしなければならない。 <!ENTITY hello ""> のように値を空欄にした場合も翻訳済みと認識される。

この問題を解決するために、自分はどうやっているかというと、翻訳が完全に済んだ locale パッケージのみを自分のソースコードへ取り込んでバージョン管理するようにし、正式リリース版 XPI を作成するときだけ一時的に locale フォルダ以下全てを BabelZilla からダウンロードした英語に置換済みのファイルへと置き換えるようにしている。

翻訳者全員の仕事が速くて、正式リリース版 XPI を作る際にすべてのロケールの翻訳が100%完了している、という前提であれば、上記のように開発版の locale フォルダと正式リリース用の locale フォルダを別にする必要は無いが、現実はそうもいかない。仕方ないけど、もう少しうまく管理できる方法はないものか、とも思っている。

ひとつ思いついたのは、 WTS が英語に置換した未翻訳なエンティティの行にコメントで目印をつけることで、次回アップロード時に WTS が未翻訳だと認識してくれるような仕組みである。
<!ENTITY hello "Hello."><!-- untranslated -->
でも、同じように properties ファイルの各プロパティの行へコメント入れるのは無理っぽいな。
HELLO=Hello # untranslated
なんてやってもコメントと認識されるわけないし、せいぜい
HELLO=Hello.
#untranslated HELLO
みたいに別の行コメントで未翻訳キーを示すしかないか。

翻訳者ではなく、拡張機能開発者としての疑問。

ある言語の翻訳者がローカライズ (xx-XX の locale パッケージ) を提供してくれたはいいが、その後、拡張機能がバージョンアップして翻訳すべき箇所が追加されても、継続的にローカライズをメンテしてくれないことが多々ある。

そういう場合、どうするか？

案１　不完全なローカライズは含めない

バージョンアップで翻訳可能な箇所を追加するたびに locale パッケージを en-US と ja-JP だけに削減してリリースし、完全なローカライズが提供され次第、それを含めて再リリースする。
ついてこれるやつだけついて来い、という感じの冷たいやり方。

確か Firefox 1.0 の頃はバージョンアップに伴い locale パッケージを減らすと変なエラーが出て、この方法は無理だったような気がする。

案２　未翻訳の部分は英語で置き換えておく

拡張機能のバージョンアップに伴い、DTDファイルに新しいエンティティを追加したとすると、その拡張機能に含まれる日本語以外の全 locale パッケージに対して英語のエンティティを追加する。

おそらくこれが一般的ではないだろうか。 Piro さんもやはりこの方式であるそうだ。
しかし、手作業でやると面倒であり、ミスも発生しやすい。英語のエンティティを追加し忘れると、ブラウザウィンドウ下部に黄色いエラーメッセージが表示されたりして被害が大きい。
BabelZilla を使っていると、この面倒くささを解消できる。ただ…

また、正式リリース前に英語で置き換えられたバージョンを翻訳者に送付し、ローカライズをお願いするというのもいいかもしれない。

案３　案１＋案２の折衷案

とりあえず未翻訳の部分は英語で置き換えてリリースし、その後あまりにも未翻訳な部分（英語で置き換えられた部分）が多くなりすぎたら、その locale パッケージを削除する。

ユーザによっては少しでも自分の国の言語に翻訳されている方がありがたいと思うかもしれないので、どの程度未翻訳な部分が増えたら locale パッケージを捨てるか、難しいところ。

7-Zip を 4.56 から 4.57 へアップデートしたら、 WinMerge の 7-Zip Plugin が使用できなくなった。
応急処置としてプラグインのDLL 「Merge7z456.dll」「Merge7z456U.dll」を「Merge7z457.dll」「Merge7z457U.dll」という名前に変更することで、今のところ問題なく動いている。

12/24追記
7-Zip 4.57 用の WinMerge 7-Zip Plugin が SourceForge から入手可能になっています。