ローカライズ可能なコードを記述する

このページでは、ローカライズを意識した UI コードを扱う際の最善の実践とガイドラインを提供します。Mozilla と拡張機能の開発者を対象としています。

技術的な詳細は XUL_Tutorial:Localization もご覧ください。

ローカライザーについて

ローカライザーと滅多に接しない開発者に向けた、いくつかの注意点:

• ローカライザーはツールが好きで、エディタは嫌いであり、
• ローカライゼーションツールは、しばしばキー・バリュー・ペアに基づいていて、
• 少なくとも、ローカライザーは言語のスキルに才能が集中していて、プログラミングや、アプリ作成でさえも精通していない。

ガイドライン

あなたのコードをより簡単にローカライズするには、従うべきガイドラインがいくつかあります:

適切なキー名を選択する

キーに選んだ名前は (それが DTD だろうが、属性ファイルだろうが) 説明的でなければなりません。長い変数名と考えましょう。ローカライズした文字列の意味を変える場合、キーも変えます。これは適切なキー名になる可能性が高いでしょうし、変更点が単なるスペル訂正と異なることを、ツールが拾い上げ安くなるでしょう。

複合文字列では文法を前提とするのをやめる

文をいくつかのキーに分けると、うっかりと文法や文の構造を前提とすることがよくあります。こんな複合文字列はしばしば、翻訳が困難です。複合文字列が必要な時は、翻訳者に "移動する余地" を残してあげてください。適切に複合文字列を使う例は、"Firefox's setting for visited pages"です: 翻訳者は (暗示的に) ぴったりとしたテキストフィールドを配置できるでしょう。

プリプロセッサ マクロを使用しない 

#if #else #endif #expand を使用しないことを強く推奨します。このルールにはいくつか例外がありますが、一般にローカライズされたファイルは標準に従うべきで、整形にビルド ツールが不要であるべきです。ローカライズされたファイルにビルドする処理を追加したい場合は、l10n@ からフィードバックをリクエストすることを検討してください。多くの場合は、同様に処理をコンテントコードに移動して、l10n 内の別のキー・バリュー・ペアを参照できます。

適切なソース ディレクトリ構造を使用 

ローカライズできるファイルを正しい場所に置いているかを確認します。最上位階層にディレクトリを追加することは、cvsroot リポジトリ内のモジュール所有権と、ローカライゼーションの簡単さとの間の妥協点です。

適切な chrome ディレクトリ構造を使用 

あるモジュール mod 用に、ターゲットパスを jar:ab-CD.jar!/locale/ab-CD/mod/foo.dtd とすることは広くテストされていて、は chrome://mod/locale/foo.dtd としてファイルを参照するのに適切な場所です。このようなディレクトリ構造を使うことは、ソースコードのないローカライゼーション処理が簡単になり、特に拡張の作者にとって推奨します。 JAR Manifests を使うと簡単になります。

l10n impact

凍結したツリーでは、l10n-impact の変更はチェックインしないというルールがあります。これはどういう意味でしょう？ l10n-impact とは

• mozilla/@mod@/locales へのあらゆる変更点。つまりローカライザーは、他のみんながそうしているように、bonsai クエリを実行して、変更点に追いつかないといけないことを発見します。変更がないことは、クエリ結果が空となります。
• 既存のローカライズ文字列の対する、変更点や新しい利用。つまり40以上のローカライゼーションについて、QAサイクルを起動するあらゆるものが l10n-impact です。