Revision 43610 of Writing localizable code

  • リビジョンの URL スラグ: Writing_localizable_code
  • リビジョンのタイトル: Writing localizable code
  • リビジョンの ID: 43610
  • 作成日:
  • 作成者: shirayuki
  • 現行リビジョン いいえ
  • コメント 11 words added, 6 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.

ガイドライン

Thus, there are a few guidelines you should follow to make localization of your code easier:

適切なキー名を選択 
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.
プリプロセッサ マクロを使用しない 
The use of #if #else #endif or #expand is strongly discouraged. There are few exceptions to this rule, but in general, the localized file should comply with standards and should not require build tools to be transformed. If you want to add build processing to localized files, be sure to request feedback from l10n@. In most cases, you can just as well put the processing into the content code and reference different key-value pairs in l10n.
適切なソース ディレクトリ構造を使用 
Be sure to put the localizable files in the right place. 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 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 name="Guidelines">ガイドライン</h3>
<p>Thus, there are a few guidelines you should follow to make localization of your code easier:</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>The use of <code>#if #else #endif</code> or <code>#expand</code> is strongly discouraged. There are few exceptions to this rule, but in general, the localized file should comply with standards and should not require build tools to be transformed. If you want to add build processing to localized files, be sure to request feedback from <a href="/User:AxelHecht" title="User:AxelHecht">l10n@</a>. In most cases, 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>Be sure to put the localizable files in the right place. 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 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>
このリビジョンへ戻す