BabelZillaの紹介文
先日の Firefox Developers Conference 2006 でBabelZillaの紹介文を書いて欲しいとの御達しを受けたのでとりあえず一部を書いた草稿をアップします（部分的にメモが残っとりますが）。こういうのでいいのかなぁ。
BabelZillaの紹介
BabelZilla Introduction
BabelZilla http://www.babelzilla.org/ はMozilla系の拡張機能のローカライズ支援サイトです。
本記事では拡張機能のローカライズを詳しく解説しています。今すぐBabelZillaを利用して拡張機能のローカライズを始めたい方は要点だけを書いたクイックスタート（BabelZillaクイックスタート：拡張機能を翻訳する、BabelZillaクイックスタート：開発した拡張機能を登録する）を読んでください。
FirefoxやThunderbirdなどのMozilla製品は拡張機能をサポートしています。Firefox本体では大多数のユーザが使う基本機能のみをサポートし、ユーザごとに異なる細やかな要求は拡張機能に任せています。そして基本機能と拡張機能が一体となって本当に使いやすいソフトウェアになっています。ですから、拡張機能を使うためのサポートも大切です。サポートには色々がありますが、まずは拡張機能のユーザインタフェースが日本語化されていることが重要です。
FirefoxやThunderbirdのローカリゼーションは各国のローカリゼーションチームが担当しています。拡張機能のローカリゼーションには、少なくとも日本の場合、そのようなチームはありません。ですから、日本語にローカライズされている拡張機能もありますし、日本語化されていない拡張機能も多くあります。
日本語化されていない拡張機能を日本語化するにはどのようにすればいいのでしょうか？方法はひとつではありませんが、典型的なよくある日本語化プロセスは次のようになります：
1. 日本語化したい拡張機能を見つける
普段よく使っている拡張機能が日本語化されていない場合はぜひぜひその拡張機能を日本語化しましょう。
2. 作者に連絡を取る
英語でメールを書きます。すぐに新しいバージョンが出そうな場合は最新の開発版ファイルを送ってもらえたり、そのほか何か注意点があれば教えてくれるでしょう。小さな拡張機能であれば、ローカライズが終わってからメールすれば十分ですのでこの時点で作者に連絡を取る必要はありません。そうですね、僕なら次のように書きます：
Subject: Japanese localization of ShootYourselfInTheFoot extension
Hi Mark,
I am going to translate your ShootYourselfInTheFoot extension into Japanese. I will send you the ja locale files when they are finished. Please let me know if there is something I should know in advance to localize it.
Thank you for creating the great extension! It actually shoots myself in the foot everyday!
Best regards,
Kenji Inoue
たまに作者のメールアドレスがどこにも書かれていない場合もあります。また、メールアドレスが変わっていて届かないこともあります。困ったものですね。たいていどうしようもありません。
3. ローカライズする
がんばりましょう。:-) 作者が国際化を意識して拡張機能を開発している場合は、locales/en-US をコピーしてその中の .properties (Javaプロパティファイル形式：JavaScriptコード中で使う) と .dtd (SGMLのDTD形式：XULファイル内で使う) を翻訳すればOKです。国際化を意識して作られていなければ... ちょっと大変です。
4. 動作確認する
jaロケールを使えるようにファイルをいくつか書き換えて、もう一度 .xpi にパックし直します（Firefox 1.5以降用に書かれたものであれば必ずしもパックする必要はないのですが）。拡張機能をインストールして、ちゃんと日本語化されていて、問題ないことを確認します。嬉しい瞬間です。分からない表現やもとの拡張機能に何か問題があればメールするといいでしょう。
5. 作者にロケールを送る
完成したjaロケールを送ります。locales/ja ディレクトリをzipで圧縮してメールに添付するといいでしょう。.xpi を送りつけても構いませんが。すでに一度作者と連絡を取っている場合はこんな感じです：
Subject: Japanese localization of ShootYourselfInTheFoot finished
Hi Mark,
The Japanese translation of ShootYourselfInTheFoot extension have finished. Check the attached file.
Best regards,
Kenji Inoue
6. 拡張機能のバージョンアップを待つ
送ったロケールがすぐに反映されてバージョンアップされる場合もありますし、次の更新と一緒にロケールが追加される場合もあります。これは作者のポリシーの問題です。待ちましょう。ただし、おそらく更新の前に「あなたの名前をcontributors listにいれたいんだけど名前は何がいい？」というメールが届くと思います。本名でもニックネームでもいいです。UTF-8対応なので漢字も使えますがあんまり見ないですね。さて、更新された拡張機能にあなたのロケールが含まれていたら、おめでとうございます。苦労が報われました。:-)
7. 拡張機能の更新をチェックする
拡張機能が更新されてローカライズが必要なリソース（文字列）が追加された場合、それに追従して日本語化を行わなければなりません。通常は作者がRC（正式公開前のファイル）を送ってくれるでしょう。もしかしたら、バージョンアップをしても全く連絡をよこさない作者もいるかもしれません。その場合、あるいは更新に追従して日本語化を行わない場合は、バージョンアップした拡張機能には日本語ロケールが全く含まれない可能性もあります（一つでも翻訳していないものがあると動作しないため）。
詳細は省きましたが、全体の流れはこのようになります。単にファイルを開いて翻訳していくだけではないのですね。
ところで、前述のプロセスは「翻訳者からみた視点」です。ローカライズされる側の拡張開発者からみたローカリゼーションプロセスについても簡単に流れを追ってみましょう：
1. 拡張機能を公開する
前提条件です。どこかに連絡先（メールアドレス）を書いておきましょう。そうしないとこれから先に書いてあることは起こりません。:-) できるだけ国際化に気をつけて拡張機能を開発しましょう。とはいっても、日本人であればen-USで作った拡張機能を自分で日本語化することになるので、まぁ大丈夫ですよね。強いて言えば、%1$S 形式を使って getFormattedString() を使えばパラメータの順番を入れ替えることができるので英語みたいなSVO以外の言語にローカライズしやすくなります。
2. 翻訳者から連絡が来る
利用者がある程度いれば、待っていればバグ報告のメールにまぎれて翻訳者からのメールが来ます。「あなたの拡張機能をローカライズしたので添付します」という内容ですね。メールをみたらすぐにメールを返信しましょう。僕はよく「Thanks! The next update of the extension is scheduled to be released in the next month so I will include your locale at that time. What do you prefer for your name in the contributors list?」という感じの返事をします。次のリリースをする際にメールをしようと思っていると、結局時間がとれなくてメールも返さないままになってしまいやすいので、とりあえず何でもいいので返事をするのが吉です（自戒も込めて）。
3. 拡張機能を更新して公開する
送ってもらったロケールを含めてバージョンアップします。いちおうその際には自分で簡単なテストはしておいた方がいいでしょう。Firefoxならabout:configのgeneral.useragent.localeをfr-FRとかにして再起動すればいいと思います。追加したロケールの翻訳者さんにはメールを送っておきましょう。その際には簡単なロケールのテストをお願いしてもよいでしょう（特にはじめの場合）。
4. 拡張機能のバージョンアップの際には連絡する
もし拡張機能をバージョンアップしてローカライズが必要な場合、公開前のファイルを翻訳者全員にメールを送ります。pagezoom-0.3.3rc1.xpi みたいなファイルですね。メールに添付しても構いませんし、人数が多ければWeb上でファイルを公開してそこへのリンクを提示してもよいでしょう。それから連絡を取り合って、更新されたロケールを受け取ります。疑問点や改善点の質問を受ければ答えましょう。もしかしたら新しい機能のバグがここで見つかるかもしれません。返事が返ってこない翻訳者も出てきますので、そういう場合はとりあえず新しい文字列は英語版のものを書いておくことになります（完全にロケールを削除するという手もありですが）。翻訳が10個を超えれば毎回この作業を行うのは面倒ですね。僕は差分を適用するツールを自前で作って持っています。
拡張機能の開発者側から見たローカリゼーションプロセスはこんな感じになります。ロケールの数が増えれば増えるほど作業の手間も増えるのですね。
2. BabelZillaの役割
以上でローカリゼーションプロセスのだいたいのところは理解していただけたかと思います。それでは本題です。BabelZillaの役割をご説明しましょう。
BabelZillaはローカリゼーションプロセスを効率化します。ローカリゼーションに必要な時間（労力）というのは、(1)ローカリゼーションそのものに必要な時間と(2)メールなどで連絡しあうコミュニケーションに必要な時間にだいたい分けられます：
ローカリゼーションプロセス＝ローカリゼーションコスト＋コミュニケーションコスト
BabelZillaは情報を一箇所に集める働きをします。情報のハブですね。それによってコミュニケーションコストが大幅に減少します。
[画像：1対多（開発者対翻訳者）→中央にBabelZilla]
これが現在のBabelZillaの第一義的機能です。ローカリゼーションコストは、残念ながら、現在のBabelZillaでは改善されません。とはいっても、Webブラウザ上でリソースを編集することもできますし、将来はローカリゼーションコストを下げる機能を取り入れる方向に向かうことになります。
2.1. BabelZillaは誰にとって得なのか？
BabelZillaに直接関わっている人々の役割は次の3種類があります：
1. 拡張機能をローカライズする人（翻訳者）
2. 拡張機能を開発する人（作者）
3. ローカリゼーションを支援する人（BabelZillaシステムの管理者・開発者・世話人）
拡張機能を実際に使う人がいませんね。エンドユーザは蚊帳の外なのでしょうか？はい、その通り。事実上、一般のMozilla製品のユーザがBabelZillaを利用するメリットは全くありません。
しかし、よく考えてみるとBabelZillaは結局エンドユーザのためにあります。翻訳者はローカライズを行います。何かを成し遂げたような気になります。でも、その翻訳物がユーザに利用されなければただの自己満足です。拡張機能の作者は翻訳が増えると何か偉くなったような気がします。でも、作者は翻訳物は使いませんね。翻訳物のコレクションなんてただの自己満足です。ローカリゼーションの支援者はわざわざ苦労して人の手助けをしてるわけですが、まぁ物好きな人たちですね。エンドユーザは普段使っている言葉でソフトウェアが使えるようになるので、大満足です。実際に役に立ちます。
結局のところ、ローカリゼーションで得をするのはエンドユーザです。そしてエンドユーザだけです。とはいっても、高確率で翻訳者自身もエンドユーザなのですが。人間には色々な役割があって大変ですね。
さてさて、雲の上の話はさておき、前章で紹介したメールベースのベーシックなローカリゼーションプロセスではなく、わざわざBabelZillaを使って実際にどれだけ得になるのかを見てみましょう。
翻訳者：実は翻訳者にとってはBabelZillaはそれほどお得感がありません。BabelZillaのご利益はコミュニケーションコストの減少にあるのですが、もともと翻訳者は拡張機能開発者と1対1の関係にあります。1対1コミュニケーションしかしなければ、間にBabelZillaをはさんでも、BabelZillaに慣れるコストも要るので特に嬉しくはありません。ただ、ひとつ、他の翻訳者の活動が見えます。他の国の翻訳者にはどのような問題があるのか。エンドユーザにとってよりよいローカリゼーションとはどのようなものなのか。どうすれば品質を保証することができるのか。みんな悩んでいます。そういう議論ができます。そこから出てくる知恵というのは一人でローカライズしているだけでは得られないものです。
作者：BabelZillaを活用して最も直接的に利益を受けられるのは拡張機能の開発者です。作者は複数の翻訳者（場合によっては10人を超えます）と連絡を取り合わなければなりませんから、BabelZillaで一元的に管理できることで必要な作業が減ります。具体的には、拡張機能をBabelZillaに登録すると自動的にフォーラム（掲示板）が一つ作成されたり、また更新した拡張機能をBabelZillaにアップロードすると自動的に翻訳者に対して更新通知が送られたりします。その結果、ローカリゼーションにかける時間が軽減されるので、本来の拡張機能の開発により多くの時間を割けるようになります。
2.2. BabelZilla上でのローカリゼーションプロセス
それではBabelZillaを利用した場合のローカリゼーションプロセスを眺めてみましょう。今度はまずは拡張機能の開発者側から：
1. BabelZillaにアカウントを作成する
BabelZillaサイトでユーザ登録を行います。
2. BabelZillaに拡張機能を登録する
開発した拡張機能をBabelZillaにアップロードします。基本的には .xpi ファイルをアップロードするだけです。その拡張機能用にフォーラムが一つ自動的に作成されます。拡張機能のWebサイトがある場合、「ローカライズをしたいただける場合はフォーラムをチェックしてみてください」というように誘導するといいでしょう。すでに機能しているメーリングリストがある場合は棲み分けが面倒かもしれませんが、フォーラムに書き込みがあった場合にメールで通知を送信するように設定することができるので見落としはないでしょう。
2'. 既存の翻訳者に通知する
すでにローカライズされているのであれば、既存の翻訳者に「BabelZillaに登録したよ」と連絡する必要があります。その際、「今までのようにメールで送ってくれてもいいよ（でもフォーラムはチェックしてね）。」と一言添えてあげるといいと思います。
3. ローカライズされるのを待つ
待っていればそのうち誰かがローカライズしてくれるでしょう（きっと）。その場合、メールで通知するように設定できます。また、たいていの場合、フォーラムに「ua-UA（Ukrainian）ロケールをローカライズしたよ。」という感じのメッセージが書き込まれます（何も連絡をくれない場合もあります）。やりとりの内容自体は前述のベーシックなローカリゼーションプロセス通りです。
4. 拡張機能を更新して公開する
ローカライズされたロケールはBabelZillaのサイトからダウンロードできるので、それをもとに拡張機能を更新します。既存の翻訳物が更新された場合、差分は取れないので自前でdiffツールなどを使いましょう（順番がめちゃくちゃだったりコメントが消えていたりするので、僕はen-USとdiffを取れるようにちゃんと整形するツールを自前で作りました）。ロケールの更新だけの場合、更新した拡張機能をアップロードする必要はないので、BabelZilla上では特に何もしません。通常のローカリゼーションプロセス通りにAddonsなどで公開して、必要があれば翻訳者に連絡するだけです。
5. 拡張機能のバージョンアップの際には
拡張機能を更新してローカライズが必要なリソースが追加された場合、翻訳者に連絡する必要があります。その場合、BabelZillaに更新した .xpi ファイルをアップロードしましょう。BabelZilla上に登録されているリソースのデータが更新されるとともに、登録している既存の翻訳者に更新通知のメールが送信されます。
更新通知が便利ですね。実は更新した拡張機能のアップロードするとき、現在のBabelZillaにはバグ（仕様？）があって注意しないといけないことがあるのですが、それはおいおい改善されるでしょう。
次に翻訳者側から：
1. 日本語化したい拡張機能を見つける
これは一緒です。
2. 作者に連絡を取る
この時点で明示的に作者に連絡を取る必要はほとんどありません。代わりにBabelZillaのサイト上でローカライズしたい拡張機能の日本語ロケールの翻訳者として登録します。また、フォーラムもチェックしておきましょう。
3. ローカライズする
BabelZillaのサイト上に最新の開発版ファイルがアップロードされている（はずな）ので、それをダウンロードして、通常通りローカライズします。ローカライズが終われば、ロケールを zip でかためてアップロードすればOKです。小さな修正であればWebブラウザでリソースを編集できますが、現状のBabelZillaでは拡張機能の更新時に差分が表示されないのと、contents.rdfの編集には対応していないので、普段のローカライズで頼ることはできません。
4. 動作確認する
通常のローカリゼーションプロセスと同様に動作確認しましょう。BabelZillaが自動的に .xpi にパックしてくれるわけではありません（してくれればいいのですが）。アップロードしたロケールはダウンロードすることができます。
5. ローカライズの完了を作者に連絡する
BabelZilla上ではローカライズの進み具合を設定することができます。進み具合にはin progress、testing/QA、Releasedの3種類の状態があります。ローカライズが完成した場合はReleasedにしましょう。そうすると自動的に作者にメールが送られます。それから、フォーラムに「更新したよ。」という旨の書き込みを行いましょう。特に問題がなければ一言「Uploaded ja (Japanese) locale in WTS.」と言うだけで大丈夫です。何も言わないとさすがにちょっと作者も悩みますので。
6. 拡張機能のバージョンアップを待つ
これは通常のローカリゼーションプロセスと同様です。ロケールの更新だけの場合、通常BabelZillaにはアップロードされません（ローカライズする必要がないのにファイルをアップロードされると逆に困りますよね、いったいどこを変更したんだー？って）。
7. 拡張機能の更新をチェックする
この作業は特に必要ありません。拡張機能が更新されてローカライズが必要になった場合、作者はBabelZillaにファイルをアップロードするので、その際に自動的に更新通知のメールを送信するように設定できます。
メールベースのやりとりがフォーラムベースのやりとりに移るだけですね。
