L10N と I18N のベストプラクティス

このブログでは、ソフトウェアのローカリゼーションとインターナショナリゼーションについて紹介します。ローカリゼーションとインターナショナリゼーションのベストプラクティスと避けるべき事柄について説明します。前回のブログをまだ読んでいない方は是非こちらをお読みください。

開発初期で行うタスク

コーディングは初めからインターナショナリゼーションを念頭に行うべきで、既存のコードをインターナショナリゼーション仕様にするのは効率的ではありません。実際の開発を始める前にインターナショナリゼーションをプランする時間を確保するようにしましょう。プロジェクト マネージャーと共にターゲットとするロケールすべての仕様についてリサーチを行うようにします。関係者の承認が必要な場合、インターナショナリゼーションによる市場拡大効果について説明すると効果的です。これは見込み客の増加、つまり売り上げの増加を意味します。あるいは、サンプル アプリケーションやプロトタイプをターゲット言語を使用して作成し、実際に使用してもらいましょう。

レイアウトの柔軟性

前回のブログでも書きましたがテキストの長さは言語によって異なります。主に 2 つのオプションがあります。

  1. ロケールごとにレイアウトを調整する。
  2. すべてのターゲット言語に十分なスペースを確保する。入力フィールドの上にラベルを配置しスペースを確保する。同じ行にする場合は入力の前に右揃えのテキストを配置する。

英語以外の入力サポート

すべての言語が A から Z のアルファベットのみを使用するわけではありません。英語以外の文字のサポートはとても重要なポイントです。例えば、文字の上のアクセント記号や複数のキーストロークによって 1 文字を入力する言語などもあります (IME 入力)。ターゲット言語のサポートを開発要件に含み、初期段階でテストを行うようにします。

ユニコード エンコーディング

文字が ??? (疑問符) や [] (ブロック) で表示されているのを見たことがありませんか?これは、エンコーディングによる問題の可能性が高いです。ファイルで Unicode (UTF-8) エンコードを使用することをお勧めします。デフォルトで ANSI、またはそれぞれの地域に基づいた他のエンコードを使用するアプリケーションがあります。

カルチャ特有の形式

数値、日付、時間、通貨、更にはカレンダーでも形式が異なることがあります。例えば、千桁の区切りにピリオド(.) を使用するカルチャがあるだけでなく、ほとんどの国や地域で異なる通貨記号を使用しています。また世界のカルチャの多くは、12 時間形式 (AM と PM) ではなく 24 時間形式を使用します。日付はさまざまなバラエティがあります。ヨーロッパでは共通の形式 (日/月/年) が使用されますが、日本では 年/月/日 形式が使用されます。また日本には和暦カレンダー、イスラエルにはヘブライ暦カレンダーがあり、どちらも公式に使用されています。

Right-to-Left (右から左) のサポート

ターゲット ロケールに Right-to-Left (右から左) レイアウトを使用するロケールがある場合、UI でもサポートする必要があります。

ネイティブのレビュー

ローカライズしたアプリケーションをネイティブ スピーカーにレビューしてもらいます。これは、インターナショナリゼーションやローカライゼーションの問題の洗い出しに役立ち、ローカライズした製品で意味が通り、利用できるレベルになります。ローカライゼーションを作業する上で懸念点がある場合は共有し、積極的に意見を交換していきましょう。

注意事項

ハードコードされたテキスト

アプリケーションを適切にインターナショナリゼーションするには、すべてのテキストと画像をプレースホルダーで置き換え (テキストは Lorem Ipsum、画像はサンプル画像を使用)、開発の早い段階でテストを行うことをお勧めします。プレースホルダーが表示されない、プレースホルダーのコンテンツによって何らかの問題が発生するなどの場合は、インターナショナリゼーションが正しく行われていません。これは文字列 (およびその他のリソース) を他のファイル (.NET の場合は .resx ) に抽出することにより簡単に処理できます。次にプレースホルダー コンテンツでファイルのコピーを作成し、必要なロケールでテストします。この方法では実際のコンテンツを変更する必要がなく、テストがパスしたら内部でローカライズまたは翻訳を外注することによってローカライズを進めます。例えば、デフォルト ロケールのみで可能なコード ビハインドで文字列の等価チェックを行います。開発関連の問題の修正は、早ければ早いほどそれにかかるリソースやコストが少なくて済みます。

不適切なコンテンツ

文化によって物事のとらえ方が異なります。たとえば色や記号の意味は文化によって異なります。また、戦争の歴史や領土問題など文化的に敏感になりやすい事柄には注意しましょう。そのため、ターゲット カルチャに合わせてコンテンツを調整することも重要です。

画像テキスト

画像にテキストは使用しないようにしましょう。これにより画像を再使用できる可能性が高まります。テキストが必要な場合は画像をオーバーレイすることにより、画像を変更する必要がなくなります。

連結した文字列

単語の順序は言語によって異なります。この違いは UX に大きな影響を与えます。例えば、favoriteColor という文字列があるとします。この文字列を使用した文、「"私の好きな色は"+ favoriteColor」の語順がすべての言語で通用するとは限りません。何色かを表す単語が英語のように文の最後にくるとは限らないからです。その他、文字列補間を使用してプレースホルダーを訳と置き換えることもできます。これによって何が付加されるのかが明確になります。これは、「"私の好きな色は" + favoriteColor + "です。"」 とプレースホルダーを使用することにより、favoriteColor を必要に応じて移動させることができます。

レイアウトでスペースの使用

テキストの表示を調整にはラベルにスペースは追加するのではなく、テキストの配置プロパティを使用します。余分にスペースを取ることが適切でない理由は、言語によってテキストの長さが異なるためです。また、各言語にそれぞれスペースがどれぐらい必要かをチェックするのは効率的ではありません。これは OS やブラウザーのデフォルト フォント設定によって異なります。

誤解を招きやすいコンテンツ

わかりやすいコンテンツを心がけましょう。翻訳を外注する場合、翻訳者にできるだけ情報を与えることによってローカライズした製品の品質を向上できます。俗語 (スラング) や略語の使用は誤解を招く可能性があるだけでなく、結果的に質の悪いローカライズ製品となります。スペースの制限によって略語を使用しなければならない場合、デザインを変更することもできますが、文字数制限を翻訳者にコメントなどを使用して明確に伝える必要があります。更に意味が分かりにくいような単語には、その単語が UI で使用される目的などを明確に翻訳者に伝えましょう。例えば、単語 「last」には、動詞の「続く」、形容詞の「最後の」、副詞の「この前に」などの意味があります。異なる意味を持つ単語のみを UI で使用する場合は、リソース ファイルにメモなどを残して翻訳者が意味を正しく取れるようにサポートしましょう。

Posted: 16 Jan 2017, 09:45

Comments

Anonymous comments are disabled