Mozilla をローカライズする方法

ニュースグループでの議論 / メーリングリスト
Mozilla 地域化プロジェクトスタッフ

MLP [地域化プロジェクトホーム] | [地域化資料] | [貢献する方法]

序文

この文書で Mozilla をあなた自身の言語に地域化したバージョンを作り、 mozilla.org コミュニティでそれが利用できるようにするために基本的で必要なステップを解説します。

  1. MLP 貢献者として登録する。
  2. ビルドをダウンロードする。
  3. ファイル上の作業をする。
  4. ローカライゼーション/効率化ツールを使う
  5. パッケージングする。
  6. あなたの作業物をQA(品質保証)する。
  7. 地域化したものを mozilla.org へフィードバックする

Mozilla を手に入れる

ここで環境に応じたリリースビルドをダウンロードすることが出来ます。
Mozilla Application スィート
Mozilla Firefox ブラウザ
Mozilla Camino Mac ブラウザ
Mozilla Thunderbird メールクライアント
Mozilla Sunbird カレンダ
Mozilla 地域化プロジェクトの基礎となっている それぞれの地域化リリースに、実行可能バイナリがあります。

    http://www.mozilla.org/releases/
これらは、Mozilla 地域化プロジェクトが localization releases で基準とするものとして作業可能なものです。

もし、Mozilla のリリースとすばやく同期したければ、リリース後にはナイトリービルドをダウンロードすることも出来ます。

    ftp://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/
次のリリースでサポートされるであろう部分の地域化を始められます。 そうすれば、ひとたび実際にリリースされたときに必要な作業を減らせるでしょう。 |注意| してください。これらのものは実験的なビルドです。 これらは動くかもしれませんし、ときには動きませんし、PC のデータに損害を与えることすらあります。 あなたに警告しています。

ローカライズに必要なこと

 
Mozilla のローカライズ可能なリソースは編集可能なファイルに外部化され、そのファイルはいくつかのグループに分けられます。
  • chrome ファイル: アプリケーションのユーザインタフェースの実際に見える部分です。 これらのファイルはアプリケーションが配置とアクセス可能な順に登録される必要があります。
    リソースがひとたびアドレスのパス(URI)を通して登録されると、ある Web サーバのハードディスクドライブに含まれている Web ページが URL アドレスを通してアクセス可能なのと同様な方法で "fake"な(仮の)アドレスのパスを通して到達可能となります。
    一度 chrome リソースがいくつかの言語に登録されると、アプリケーションにとって "fake"(仮の)アドレスから実際の言語リソースの一つの配置されている場所への変換は容易です。このため、UI 言語は透過的に切り替え可能となります。

    Mozilla の英語の mozilla.org ディストリビューションでは、これらのファイルは chrome/ フォルダの中にある zip 圧縮ファイルの中に格納されています:
    • "en-US.jar": UI 言語リソースの大部分を含む。すべてのプラットフォームで使われる。
    • "en-win.jar" ("en-unix.jar", "en-mac.jar"): ユーザインタフェースを通して利用されるすべての外部参照(URL/URI)を含む。 これは地域コンテンツリンクも含むことができる。

    • "US.jar": ユーザインタフェースで使われるすべての外部参照(URL/URI)を含む。ここには、地域特有のコンテンツリンクも含まれる。

  • デフォルトのプロファイル (任意): 新しいプロファイルが作られるときに使われるテンプレートの地域化されたユーザプロファイルです。 これらは defaults/profile/[country-code]/ バイナリフォルダの中にあります。

  • 追加内容物(任意追加するもの): このカテゴリは定型の操作ではアプリケーションにとって厳密に言えば必要ではないすべてのファイルが入ります。 たとえば。 などです。

地域化/効率化ツールを使う

生産性をあげるために、地域化/効率化ツールを使ってください。 それぞれのビルドをゼロから地域化しなければならないとしたら、時間の無駄ですし、間違いが起こりやすくなってしまいます。 MozillaTranslator を使えば、どの文字列が新しくなっていて、地域化が必要なのかがわかります。

また、MozillaTranslator のようなプログラムを使えば、ファイルを直接あつかったり、元の地域化可能リソースを圧縮ファイルから解凍したりする負担から地域化作業者を解放し、一度地域化すると、配布可能な形式にパッケージングし戻せます。

翻訳 語彙リスト & リファレンス

ここにほんとに少しだけですがオープンソースコミュニティの貢献による翻訳語彙リストとその他のリファレンス資料があります。 これらは翻訳においてよい出典資料です。

パッケージングとインストール

作業の成果を一般に利用可能とする方法は基本的には二つあります。

  1. インストール可能な言語パック(*.xpi)とすること。 地域化されたリソースとインストーラー・スクリプトだけを含んだ一つの小さく圧縮された圧縮物です。 Mozilla をインストールしたユーザはクリック一つでその言語で利用可能になります。
  2. 目的のプラットフォーム/OSのためのすべての実行バイナリをも含む、地域化されたフル・ビルドとすること。
詳細はこちら

XPI
もちろん、インストール可能な XPI パッケージをもつことは、最初の選択肢です。 どの Mozilla ユーザも都合に応じて好みの利用可能な言語を加えることができるからです。 複数ユーザ環境や、すでにインストールされたプログラムのコピー、そして雑誌のCDにあったまだ地域化されていないバージョンなどに加えることができます。
インストール作業はナビゲータでファイルを開いたり、Web のリンクを追うのと同じくらい簡単です。 ひとたびインストールを終えれば(ときには高速起動を無効化してアプリケーション再起動後)、 その言語はpreferences(設定)のLanguage/Contents(言語/コンテンツ)欄で選択可能です。 (Edit | Preferences | Appearance | Language/Contents)(訳注:日本語パック適用後は、(編集 | 設定 | 表示 | 言語/コンテンツ)です)

フル地域化ビルド
もし、自分の言語で Mozilla の完全なディストリビューションを作る必要があるなら、この方法となります。
Mozilla は完全なオープンソース・アプリケーションですが、— これが可能な選択であれば —mozilla.org によってコンパイルされたもの以外のものの再配布をやめるように勧めます。 その理由は mozilla.org がこのソフトウェアを一般にリリースする目的にあります。 それは機能(や機能不足)についてフィードバック日本語ではこちらを集めるためで、まったく同じな実行バイナリを再配布することはこの行為を軽減し、可能なら開発者に自分の責任のバグにだけ集中させることができるからです(-.^)

配布ビルドの再配布方法は主に以下のように分類されます

  • バイナリの単なる圧縮(tar.gzやzipのように)
  • 完全なインストーラービルド。アプリケーションが収められた従来型の圧縮ファイルの中に同梱されたインストーラもしくは、(標準的な MS-Windows のインストーラファイルのような)本体にすべてのバイナリを結合した単一の実行可能ファイルのいずれかが含まれます。
  • ネット・インストーラ・ビルド。これは完全なビルドで、モジュール化されたいくつかの XPI アーカイブファイルに小さなスタンドアロン(単独実行可能)なインストーラを加えたものです。 このインストーラは、ひとたびダウンロードして実行すれば、設定を収集して選ばれた部品だけをダウンロード開始することができます。
  • Unix パッケージはメンテナンスシステムに(*.rpmや*.debのように)バンドルされています。 これらはたいていビルドしたいシステムによって管理される自己インストーラ・パッケージを基盤としてスクリプトで構成されています。

ローカリゼーションの結果の QA(品質保証)

もちろん、あなたの作業にも改訂があります。 品質保証は Mozilla のような大きなプロジェクトを整然とさせ、有用でバグのないものにするためには不可欠なものです。

地域化の品質全体を改善するために繰り返し行うことのできるテストにはいくつかの段階があります:

  • ひとたび利用したい言語が Mozilla で利用可能となれば、XUL というブラウザのユーザ・インタフェースファイルを読み込むことによって、Mozilla インタフェースを構成する多くのダイアログウィンドウ探索することができます。
    Mozilla のインタフェースのたくさんのダイアログウィンドウを調査することが出来ます。 chrome/ フォルダの中の .jar 圧縮ファイルの中を(PKZip 互換のユーティリティを使って)見て、 *.xul ファイルを見ます。 これらはコンポーネントごとにまとめられて content/ フォルダの下に含まれています。
    ナビゲータで、対応する "chrome://" URL をアドレスバーに打ち込んでこれらのファイルを開きます。

    /content/messenger/addressbook/ の下の messenger.jar の中の abSelectAddressesDialog.xul を開くとすると、 ナビゲータのアドレス欄に chrome://messenger/content/addressbook/abSelectAddressesDialog.xul入力する必要があります。

    ときおり、DTD ファイルの中の地域化された文字列が、似たような名前の .xul ファイル上のインタフェースの結果として表示されます (例:abSelectAddressesDialog.xulabSelectAddressesDialog.dtd の中に置かれた文字列を使います)。

  • プログラムを使う!そう、これはもちろん最善の方法です。 日に日に使うに従って、すべての利用可能な機能を、メニュー項目というメニュー項目を、ボタンというボタンを、系統的に網羅する計画を試してください。


  • ユーザのフィードバックを推奨してください。だれかのミスを見つけるのは第三者の方がたいてい簡単だからです

投稿

 
作業を一度終えたら、

MLP スタッフと連絡をとってください。 私たちがそれらを Mozilla FTP サイトからダウンロードできるようにします。

しかし、そこで止まらないでください。世界にあなたの作業を知らせましょう! あなたの言語のニュースサイトに連絡を取り、その言語を話すプログラムの存在を人々に知らせましょう。 この作業は、英語の mozilla.org のリリースに同期させて、作業の成果を公表しないことよりももっと重要かもしれません。

あなたのアナウンスに対して、十分な CC が見つかるかもしれません。 別途、オンラインフォームを通してアナウンスを投稿可能なサイトのアカウントを作りたくなるかもしれません。。

このほうが、あなたの作業の成果を多くの人がダウンロードしてテストすることの効果を得る可能性が高いのです。 テストしてくれた人が、あなたのチェックから漏れてしまった何かを見つけたら、フィードバックを受けてください。 前述したとおり、品質はアプリケーションは使うことによって改善することができるものです。