Share via

ローカライズの準備をする方法 (HTML)

  • [アーティクル]

[ この記事は、Windows ランタイム アプリを作成する Windows 8.x および Windows Phone 8.x 開発者を対象としています。Windows 10 向けの開発を行っている場合は、「最新のドキュメント」をご覧ください]

ローカライズに向けてアプリを準備する場合は、ここで説明している手順とベスト プラクティスに従ってください。始める前に、「グローバル化のためのチェック リスト」に目を通し、他の市場、地域、または言語に向けてアプリの準備が終わっているかどうかを確認してください。

手順

リソース ファイルと修飾子を使う

必ず、リソース ファイルに文字列リソースを指定してください。詳しくは、「クイック スタート: UI リソースの翻訳」をご覧ください。

画像または他のファイル リソースは、それらのファイルまたはフォルダーで、適切な言語タグを使って指定してください。画像、オーディオ、ビデオのローカライズには大量のシステム リソースが使われるため、可能な限り依存性がないメディア アセットを使うことが望まれます。詳しくは、「修飾子を使ってリソースに名前を付ける方法」をご覧ください。

コンテキスト依存のコメントを追加する

アプリのリソース ファイルに、ローカライズ コメントを追加します。このコメントはローカライズ担当者に表示されるため、ローカライズ担当者が正確にリソースを翻訳するのに役立つコンテキスト情報を提供する必要があります。また、翻訳によってソフトウェアが壊れることを防ぐため、コメントには十分な制約情報も含める必要があります。 必要に応じ、Makepri.exe ツールを使ってコメントをログに記録することもできます。

ResJSON では、下線から始まるフィールドにコメントなどのメタデータを指定できます。次に例を示します。

{
    "String"  : "Hello World",
    "_String1.comment" : "This is a comment to the localizer"
}

語句ではなく文をローカライズする

次の文字列、"{0} を同期できませんでした" について考えてみましょう。

{0} は予定、タスク、ドキュメントなどのさまざまな単語で置き換えることができます。この例は日本語では機能しますが、ドイツ語の対応する文ではどのようなケースでも機能しません。次に示すドイツ語の文では、テンプレート文字列内の一部の語句 ("Der"、"Die"、"Das") はパラメーター化された語句と一致する必要があります。

日本語 ドイツ語
予定を同期できませんでした。 Der Termin konnte nicht synchronisiert werden.
タスクを同期できませんでした。 Die Aufgabe konnte nicht synchronisiert werden.
ドキュメントを同期できませんでした。 Das Dokument konnte nicht synchronisiert werden.

 

別の例として、"{0} 分後に通知する" という文を考えてみましょう。"分" は日本語では使うことができますが、他の言語では別の語句を使っている可能性があります。たとえば、ポーランド語では、状況に応じて "minuta"、"minuty"、または "minut" を使います。

この問題を解決するには、1 つの単語ではなく、文全体をローカライズしてください。このやり方は手間がかかり、洗練されていないように見えるかもしれませんが、次の理由から最善の方法と言えます。

  • どの言語でも、明瞭なエラー メッセージが表示される。
  • ローカライズ担当者は、文字列が何に置き換えられるかをたずねる必要がない。
  • アプリが完了した後でこのような問題が浮かび上がったときに、犠牲の大きいコード修正を行う必要がない。

パラメーターの順番を正しくする

どの言語も同じ順番でパラメーターを使うと想定しないでください。 例として、"毎年 %s %s" という文字列を考えてみましょう。最初の %s は月の名称に置き換えられ、2 つ目の %s は月の日付に置き換えられます。この例は日本語では機能しますが、日付と月が逆順に表示されるドイツ語にこのアプリがローカライズされると、エラーになります。

この問題を解決するには、言語に応じて順序を入れ替えることができるように、文字列を "毎年 %1 %2" に変更します。

過度にローカライズしない

特定の文字列をローカライズし、タグは除外します。次に例を示します。

ローカライズ対象が多すぎる文字列 ローカライズ対象が適切な文字列
<link>使用条件</link> 使用条件
<link>プライバシー ポリシー</link> プライバシー ポリシー

 

前の <link> タグをリソースに含めると、そのタグもローカライズされます。これにより、タグが無効になります。文字列自体のみをローカライズしてください。一般に、タグは「ローカライズ可能なコンテンツから分離しておく必要があるコード」と考える必要があります。 ただし、コンテキストを保持して順序を正しい状態にするために、一部の長い文字列にはマークアップを含める必要があります。

異なるコンテキスト (文脈) に同じ文字列を使うことは避けてください。

文字列の再使用は最善の方法のように思われるかもしれませんが、同じ語句またはフレーズに異なる意味やコンテキストが含まれる場合にはローカライズ問題を引き起こすことがあります。

2 つのコンテキストが同じである場合には文字列を再使用できます。たとえば、"ボリューム" という文字列は、サウンド効果のボリュームと音楽のボリュームの両方に使うことができます。どちらもサウンドの強さを意味するためです。ハード ディスクのボリュームの場合、コンテキストと意味が異なり、この語句が他の言葉に翻訳される可能性があります。このため、ハード ディスクを指す場合には、同じ文字列を再使用してはなりません。

別の例として、文字列 "オン" と "オフ" の使用を考えてみましょう。日本語では、"オン" と "オフ" は、フライト モード、Bluetooth、デバイスの切り替えに使うことができます。しかし、イタリア語では、何がオンで何がオフかというコンテキスト (状況) に応じて翻訳が変化します。コンテキストごとに 2 つの文字列の組み合わせを作らなければなりません。

また、"text" や "fax" などの文字列は英語では動詞としても名詞としても使うことができますが、翻訳プロセスを混乱させる可能性があります。この場合、別の方法として動詞形と名詞形の両方に個別の文字列を作ります。 コンテキストが同じかどうか確信できない場合は、(間違えるとしても) 重大な間違いは避け、明確な文字列を使ってください。

一意の属性を使ってリソースを特定する

リソース識別子は大文字と小文字が区別されません。リソース識別子は、リソース ファイルごとに一意でなければなりません。 リソースにアクセスする場合は、リソースの実際の値ではなく、リソースの識別子を使ってください。リソース識別子は変化しませんが、リソースの実際の値は言語に応じて変化します。

翻訳に付加的なコンテキストを提供するために、必ず意味のあるリソース識別子を使ってください。

文字列リソースが翻訳に回された後は、リソース識別子を変更しないでください。ローカライズ チームは、リソース識別子を使ってリソース内の追加、削除、更新を追跡します。リソース識別子の変更 ("リソース識別子のシフト" とも呼ばれる) を行うと、文字列が削除されて他の文字列が追加されたような表示状態になります。このため、リソース識別子を変更した場合は、文字列を翻訳し直す必要があります。

適切な翻訳方法を選ぶ

文字列がリソース ファイルとして分けられた後、それらを翻訳できます。文字列を翻訳するのに適したタイミングは、プロジェクト内の文字列が最終的に確定した後です。この最終処理は、通常、プロジェクトの終わりごろです。 翻訳プロセスには、さまざまな方法で取り組むことができます。どの方法を選ぶかは、翻訳する文字列の量、翻訳する言語の数、翻訳の方法 (社内で行うか外部ベンダーを雇うか) などに応じて決まります。

次に選択肢を示します。

  • **リソース ファイルは、プロジェクト内で直接開いて翻訳できます。**この方法は、文字列の量が少ないプロジェクトや、2 ～ 3 言語に翻訳する必要があるプロジェクトに合っています。たとえば、開発者が複数の言語に通じており、翻訳プロセスを自分で処理することをいとわない場合などに適します。この方法は迅速さがメリットであり、ツールを必要とせず、誤訳のリスクが最小限に抑えられますが、拡張性はありません。たとえば、複数の言語にわたるリソースの同期があっけなく失われ、ユーザー操作に問題が生じ、メンテナンスが困難になる可能性があります。
  • **文字列リソース ファイルは XML または ResJSON テキスト形式で作られるため、どのテキスト エディターを使った翻訳にも回すことができます。翻訳されたファイルは、プロジェクトに書き戻します。**この方法には翻訳者が誤って XML タグを編集するリスクがありますが、Microsoft Visual Studio プロジェクトの外で翻訳作業を進めることができます。この方法は、少数の言語に翻訳する必要があるプロジェクトに適します。XLIFF 形式はローカライズ向けとして特別に設計された XML 形式であり、いくつかのローカライズ ベンダーやローカライゼーション ツールでうまくサポートされています。他のリソース ファイル (.resw や .resjson など) から XLIFF ファイルを生成する場合は、多言語アプリ ツールキットを使うことができます。

ローカライズ担当者へのハンドオフは、他のファイル (画像やオーディオ ファイルなど) でも必要となることがあります。文化性の強いファイルは、ローカライズが難しい場合があります。このようなファイルの作成はお勧めできません。

次の提案も検討してください。

  • **ローカライズ ツールを使う。**リソース ファイルを解析し、翻訳可能な文字列だけを翻訳者が編集できるようにするローカライズ ツールは多数あります。この方法では翻訳者が誤って XML タグを編集するリスクは減ります。ただし、ローカライズ プロセスに新しいツールとプロセスの導入が必要になるという欠点があります。ローカライズ ツールは、扱う文字列は大量であるが言語は少ないというプロジェクトに適します。詳しくは、「多言語アプリ ツールキット」をご覧ください。
  • **ローカライズ ベンダーを利用する。**プロジェクトに大量の文字列が含まれ、多数の言語に翻訳する必要がある場合は、ローカライズ ベンダーの利用を検討します。ローカライズ ベンダーは、リソース ファイルの翻訳だけでなく、ツールとプロセスについてのアドバイスを得るためにも利用できます。これは非常によい解決策ですが、最もコストがかかる選択肢でもあり、翻訳済みコンテンツの作業期間が延びる可能性があります。
  • **ローカライズ担当者に必要情報を与える。**文字列のローカライズ担当者に、名詞または動詞と見なされる可能性がある文字列を知らせます。用語ツールを使って、ローカライズ担当者に、作った単語について説明します。混乱を避けるため、文字列は文法的に正しく、明瞭で、できる限り専門的でないように維持します。

アクセス キーとラベル

アクセシビリティで使われるアクセス キーとローカライズされたアクセス キーは、2 つの個別のセクションに分類されます。このため、この 2 つの文字列リソースの表示の "同期" は難問です。必ず次に示す実装に従い、ラベル文字列に適切にコメントを付けることによって、そのラベル文字列をアクセス キー定義にリンクすることが重要です。

<label id="theLabel" data-win-res="{accessKey: 'theLabelAccessKey'}" for="xPrinterRedirection" accessKey="L">The <u>L</u>abel</label>
<input type="checkbox" value="OFF" id="xPrinterRedirection" name="xPrinterRedirection" />

Make sure that <u>L</u> is synchronized with the access key "theLabelAccessKey" のようなコメントを必ず入れてください。

並べ替えることができる日本語文字列のふりがなのサポート

日本語の漢字には、語句と使用状況に応じて変化する複数の発音があるという、ユニークな特性があります。 このため、日本語の名称が付いたオブジェクト (アプリケーション名、ファイル、曲など) を並べ替えるときに問題が発生します。 日本語の漢字は、以前は一般に、XJIS と呼ばれる、コンピューターが理解できる順序で並べられていました。 残念ながら、この並べ替え順序は発音に即したものではなく、人間にとってはそれほど便利ではありません。

ふりがなを使うと、ユーザーや作成者は自分が使う文字の表音要素を指定でき、この問題が解決されます。 以下の手順でふりがなをアプリ名に追加すると、アプリ一覧の正しい場所にその名前が並びます。 アプリ名を漢字で付け、ふりがなは含めなかった場合、ユーザーの UI 言語または並べ替え順序が日本語に設定されていると、Windows は適切な発音を生成しようと最善の努力を尽くします。 しかし、珍しい読み方やユニークな読み方をするアプリ名の場合、比較的一般的な読みで並べ替えられる可能性があります。このため、日本語アプリケーション (特に名前に漢字が含まれるアプリケーション) で最も望ましい方法は、日本語ローカライズ プロセスの一環として、ふりがなバージョンのアプリ名を提供することです。

  1. [パッケージ表示名] と [アプリケーション表示名] として "ms-resource: Appname" を追加します。

  2. 次に示すように、strings フォルダーの下に ja-JP フォルダーを作り、2 つのリソース ファイルを追加します。

    strings\
    en-us\
    ja-jp\
        Resources.altform-msft-phonetic.resw
        Resources.resw

  3. 通常の ja-JP 用の Resources.resw: アプリ名 ""希蒼"" の文字列リソースを追加します。

  4. 日本語ふりがなリソース用の Resources.altform-msft-phonetic.resw: アプリ名 ""のあ"" のふりがな値を追加します。

ユーザーは、ふりがな値 "のあ" と発音値 (入力方式エディター (IME) の GetPhonetic 関数を使う) "まれあお" の両方を使ってアプリ名 "希蒼" を検索できます。

並べ替えは、次に示す [Regional Control Panel] (地域コントロール パネル) フォーマットに従って行われます。

  • 日本語ユーザー ロケールでは次のように並びます。
    • ふりがなが有効になっている場合、"の" の下に "希蒼" が並びます。
    • ふりがなが含まれていない場合、"ま" の下に "希蒼" が並びます。
  • 日本語以外のユーザー ロケールでは次のように並びます。
    • ふりがなが有効になっている場合、"の" の下に "希蒼" が並びます。
    • ふりがなが含まれていない場合、"漢字" の下に "希蒼" が並びます。