Writing localizable code

  • リビジョンの URL スラッグ: Writing_localizable_code
  • リビジョンのタイトル: Writing localizable code
  • リビジョンの ID: 43611
  • 作成日:
  • 作成者: shirayuki
  • 現行リビジョン はい
  • コメント 21 words added, 89 words removed

このリビジョンの内容

{{ Draft() }}

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

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

ローカライザーについて

A few notes about localizers for developers who rarely deal with them:

  • localizers like tools, and they don't like editors,
  • localization tools are often based on key-value pairs,
  • at least some localizers have their talents focused on language skills and are not savvy in programming, or even building applications.

ガイドライン

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

適切なキー名を選択 
The names chosen for your keys (regardless of whether that's a DTD or a properties file) should be descriptive. Think of them as long variable names. If you change the semantics of a localized string, change the key. This will more likely be a good key name, and it will help tools to pick up that the change you do is different from just a spell fix.
Try not to assume grammar in composite strings
Splitting sentences into several keys often inadvertently presumes a grammar, a sentence structure, and such composite strings are often very difficult to translate. When a composite string is needed, try to give the translators "room to move". An example of a well used composite string is Firefox's setting for visited pages: the translator can (implicitly) position the text field as he sees fit.
プリプロセッサ マクロを使用しない 
#if #else #endif #expand を使用しないことを強く推奨します。このルールにはいくつか例外がありますが、一般にローカライズされたファイルは標準に従うべきで、整形にビルド ツールが不要であるべきです。ローカライズされたファイルにビルドする処理を追加したい場合は、l10n@ からフィードバックをリクエストすることを検討してください。多くの場合は、you can just as well put the processing into the content code and reference different key-value pairs in l10n.
適切なソース ディレクトリ構造を使用 
ローカライズできるファイルを正しい場所に置いたか確認します。The addition of new top-level directories is a compromise between module ownership in the cvsroot repository and the ease of localization.
適切な chrome ディレクトリ構造を使用 
For a particular module mod, a target path jar:ab-CD.jar!/locale/ab-CD/mod/foo.dtd has been widely tested and is a good place for your files referenced as chrome://mod/locale/foo.dtd. Using a directory structure like this eases the localization process without the source code and is especcially recommended to extension authors. JAR Manifests can make this easy.

l10n impact

On frozen trees, there is the rule to not check in l10n-impact changes. So what does that mean? l10n-impact is

  • any change to mozilla/@mod@/locales; Localizers find out if they have to catch up on changes by doing bonsai queries, just as everybody else does. No change means that this query result is empty.
  • any changed or new use of existing localized strings; Anything that triggers a QA cycle on our 40+ localizations is l10n-impact.

{{ languages( { "de": "de/Lokalisierbaren_Code_schreiben", "en": "en/Writing_localizable_code", "es": "es/Escribir_c\u00f3digo_localizable", "fr": "fr/\u00c9criture_de_code_localisable" } ) }}

このリビジョンのソースコード

<p>{{ Draft() }}</p>
<p>このページでは、ローカライズを意識した UI コードを扱う際の最善の実践とガイドラインを提供します。Mozilla と拡張機能の開発者を対象としています。</p>
<p>技術的な詳細は <a href="/en/XUL_Tutorial/Localization" title="en/XUL_Tutorial/Localization">XUL_Tutorial:Localization</a> もご覧ください。</p>
<h3 id="About_Localizers" name="About_Localizers">ローカライザーについて</h3>
<p>A few notes about localizers for developers who rarely deal with them:</p>
<ul> <li>localizers like tools, and they don't like editors,</li> <li>localization tools are often based on key-value pairs,</li> <li>at least some localizers have their talents focused on language skills and are not savvy in programming, or even building applications.</li>
</ul>
<h3 id="Guidelines" name="Guidelines">ガイドライン</h3>
<p>あなたのコードをより簡単にローカライズするには、従うべきガイドラインがいくつかあります:</p>
<dl> <dt>適切なキー名を選択 </dt> <dd>The names chosen for your keys (regardless of whether that's a DTD or a properties file) should be descriptive. Think of them as long variable names. If you change the semantics of a localized string, change the key. This will more likely be a good key name, and it will help tools to pick up that the change you do is different from just a spell fix.</dd> <dt>Try not to assume grammar in composite strings</dt> <dd>Splitting sentences into several keys often inadvertently presumes a grammar, a sentence structure, and such composite strings are often very difficult to translate. When a composite string is needed, try to give the translators "room to move". An example of a well used composite string is Firefox's setting for visited pages: the translator can (implicitly) position the text field as he sees fit.</dd> <dt>プリプロセッサ マクロを使用しない </dt> <dd><code>#if #else #endif</code> <code>#expand</code> を使用しないことを強く推奨します。このルールにはいくつか例外がありますが、一般にローカライズされたファイルは標準に従うべきで、整形にビルド ツールが不要であるべきです。ローカライズされたファイルにビルドする処理を追加したい場合は、<a href="/User:AxelHecht" title="User:AxelHecht">l10n@</a> からフィードバックをリクエストすることを検討してください。多くの場合は、you can just as well put the processing into the content code and reference different key-value pairs in <code>l10n</code>.</dd> <dt>適切なソース ディレクトリ構造を使用 </dt> <dd>ローカライズできるファイルを正しい場所に置いたか確認します。The addition of new top-level directories is a compromise between module ownership in the <code>cvsroot</code> repository and the ease of localization.</dd> <dt>適切な chrome ディレクトリ構造を使用 </dt> <dd>For a particular module <code>mod</code>, a target path <code>jar:ab-CD.jar!/locale/ab-CD/mod/foo.dtd</code> has been widely tested and is a good place for your files referenced as <code><a class=" external" href="chrome://mod/locale/foo.dtd" rel="freelink">chrome://mod/locale/foo.dtd</a></code>. Using a directory structure like this eases the localization process without the source code and is especcially recommended to extension authors. <a href="/en/JAR_Manifests" title="en/JAR_Manifests">JAR Manifests</a> can make this easy.</dd>
</dl>
<h3 id="l10n_impact" name="l10n_impact">l10n impact</h3>
<p>On frozen trees, there is the rule to not check in <em>l10n-impact</em> changes. So what does that mean? <em>l10n-impact</em> is</p>
<ul> <li>any change to <code>mozilla/@mod@/locales</code>; Localizers find out if they have to catch up on changes by doing bonsai queries, just as everybody else does. No change means that this query result is empty.</li> <li>any changed or new use of existing localized strings; Anything that triggers a QA cycle on our 40+ localizations is <em>l10n-impact</em>.</li>
</ul>
<p>{{ languages( { "de": "de/Lokalisierbaren_Code_schreiben", "en": "en/Writing_localizable_code", "es": "es/Escribir_c\u00f3digo_localizable", "fr": "fr/\u00c9criture_de_code_localisable" } ) }}</p>
Revert to this revision