グローバルマーケット向けデザイン
国際化またはローカライゼーションとは、対象となるさまざまなマーケットのさまざまな言語、地域、技術要件に合わせて機能やスキルをデザインすることです。国際化を念頭において開発すると、新しい市場に向けて製品をローカライズするために必要なリソースが少なくて済みます。ローカライゼーションは単なる言語の翻訳ではなく、Alexaがユーザーと会話する方法をさまざまな文化に適応させる作業です。
エクスペリエンスを開発するときには、開発者の生まれ育った文化や母語にとらわれずに考える必要があります。機能やスキルをデザインするときには、どの市場に製品を出荷するか、 どの言語をサポートするか、 どの程度の翻訳やローカライゼーションが必要かを検討します。 ほかの国や言語で作られた製品のマニュアルの翻訳品質がひどいという経験は、誰にでもあるでしょう。翻訳がよくないと、その製品がユーザーの言語や文化から生まれたものではないことがわかってしまい、その製品に対する信頼やエクスペリエンスが失われます。文化の違いや翻訳を適切に扱わないと、スキルに悪影響が及ぶだけでなく、さまざまなマーケットでAlexaへの信頼が失われていきます。
ベストプラクティスとしては、Unicode（UTF-8）の使用、文字列リソースの外部化、さまざまな言語へのデザインとコントロールの適応、ユーザーのロケールに基づくデータ処理、さまざまな言語での入力処理などが挙げられます。
音声デザイン
短く簡潔な文を書く
長く複雑な文は翻訳するのも理解するのも大変です。複雑な修飾語・被修飾語に気を付けたり、長い文でも短い文と同じようにわかりやすくするよう工夫しましょう。長さやわかりやすさは、文を声に出して読むと理解しやすくなります。
コンテンツに不要な俗語、だじゃれ、方言は使わないようにする
これはローカライゼーションでは特に重要です。ほかの言語や、その言語が使われている特定の地域、特定の世代に同等の言葉がなかったり、誤解されたりする可能性があるからです。
俗語、だじゃれ、方言がスキルに不可欠である場合は、翻訳者と協力して、特定のロケールで同じ意味を持つ言葉を探すことをお勧めします。たとえば、「お疲れ様です」という言葉は翻訳しにくい表現です。「9時5時」も同様です。ほかの国や地域では働く時間帯が異なるからです。
用語の定義と使用を統一する
翻訳前のテキストで特定の用語の使われ方に統一性がなかったり、用語定義を翻訳者に適切に示さなかったりすると、翻訳の品質は高くなりません。用語集を提供し、用語データベースをあらかじめ用意するためには、開発者が製品の重要な用語を定義し、それらの用語を翻訳前のテキストで矛盾なく使用する必要があります。
すべてのコンテンツで、地政学上の不適切な表現や扱いに注意を要する事柄についてよく検討する
地政学の見地から適切に配慮するということは、スキルで提供するコンテンツがユーザーの気分を害さないようにするということです。たとえば、画像やグラフィックが別の文化ではまったく異なる意味を持ち、極めて不快とみなされる可能性もあります。適切な配慮を怠ったことが原因で、法律や規制のリスクにさらされる原因となったり、メディアに批判されたりボイコットやデモが起こったりする原因になるかもしれません。
テキスト、およびテキスト以外のコンテンツについても、地政学上の問題や、特定の宗教を冒涜するような言葉、人権を侵害するような表現がないようよく検討します。この場合のテキストとは、UI文字列、ドキュメント、ヘルプ、マーケティングコンテンツなどを指します。テキスト以外とは、動画、音声、ゲーム、画像などのことです。
特に画像にはリスクが潜んでいます。画像は感情的な反応をかき立てたり、考え方に影響したり、記憶を呼び覚ましたりすることがあり、全世界で受け入れられるとは限らないからです。確認が必要なほかの情報としては、色、数字、名称、その他の時事コンテンツがあります。
確認が必要な画像の種類は以下のとおりです。
- 旗（旗は国によって受け取られ方が変わります）
- 地図（国境の認識が国によって異なります）
- 人（身ぶり、容姿、人種など）
- 象徴や像（国家、政治、宗教、スピリチュアル）
- 成人向け画像やわいせつな画像
画像をそのロケールで使用するかどうかを判断するときには、 ほかのロケールでもこの画像は同じ意味を持つか、ほかのロケールでこの画像は不快と受け取られないか、 文化的見地からそれらのロケールに適した象徴を見つける必要があるかを考慮します。
開発のベストプラクティス
プロンプトの構造をコードに埋め込まない
言語によって語順が異なります。名詞句は、名詞と場合によっては形容詞や形容動詞で構成されます。語順は各言語の文法によって決まります。動的コンテキスト（変数）を含む名詞句を連結しないでください。
語順が言語によって異なる次の例を見れば、コードで語順を決めずに、スキルの翻訳者がロケールに適した語順を決めるべき理由が理解できると思います。
言語別の語順例
| 言語 | 主語 | 動詞 | 目的語 | コメント |
|---|---|---|---|---|
| 英語 | The big man | eats | a red delicious apple. | 英語では、主語の次に動詞が置かれます。また名詞の文法的性がありません。主格や目的格に応じて形容詞を変化させる必要もありません。 |
| 日本語 | 大きい男の人が（Ookii otokonohito ga） | 食べています。（tabete imasu.） | 赤くておいしいりんご（レッドデリシャス）を（Akakute oisii ringo (red delicious) o） | 主語が最初に置かれ、動詞が最後に置かれます。「red delicious」が特定の品種「レッドデリシャス」のりんごを指しているのか、りんご全般に対する「赤くておいしい」という形容なのかはっきりしません。 |
| ドイツ語 | Der große Mann（男性冠詞、主格形容詞、男性） | isst | einen roten, köstlichen Apfel.（男性、対格） | 主語、動詞、目的語の語順は英語と同じですが、ドイツ語では形容詞の前にコンマを置いても問題ありません。冠詞と形容詞を名詞の性と格に一致させる必要があります。 |
| スウェーデン語 | Den stora mannen | äter | ett gott rött äpple. | 定冠詞が2か所で一致し、形容詞と名詞が一致しています。2番目の名詞句では音のために形容詞の順序が変わっています。 |
| フランス語 | Le gros homme（The big man） | mange（eats） | une délicieuse pomme rouge.（a delicious apple red） | 語順が変わっています。 |
| ヒンディー語 | बडा आदमी Bada aadmi | खाता हैkhata hai | एक लाल स्वादिष्ट सेबek lal swadisht seb | 日本語と同じように、ヒンディー語の語順も英語と異なり、動詞が最後になります。ヒンディー語には冠詞（the、a、an）がありません。 |
| スペイン語 | El hombre grande（The man big） | come（eats） | una manzana roja y deliciosa（an apple red and delicious） | 語順が変わっています。 |
ここからわかるのは、主語も目的語も連結してはならないということです（コードによる語順決定）。名詞または形容詞が変数である場合は、コードを1つの文字列にして、翻訳者がコード内の変数の位置を変えられるようにします。
文字列を連結しない
文字列の連結は国際化とローカライゼーションの両方に影響します。複数の文字列を連結して1つの文を構成することは、開発者がよくやってしまう不適切なコーディング手法です。連結した文字列を組み合わせると日本語では理解できる文になるかもしれませんが、多くの言語の文法ではそうではありません。翻訳者は文の語順を変更する必要があるかもしれないのに、1つの文が複数の文字列に分割されていれば、語順の変更ができなくなるかもしれません。
視覚要素のデザイン
ローカライゼーションでは、ユーザーインターフェースとその他のテキストの長さが原文の日本語と大きく違ってくる場合がよくあります。たとえば英語の場合、おおむね日本語より語句や文が短く、文字が小さくなります（ドイツ語の場合は英語の場合よりも長くなります）。日付や数字といったデータに必要な領域もそれに応じて長さが変わってきます。
画像
グラフィックにオーバーレイ、レイヤーまたはコールアウトを使用する
UI文字列の翻訳と同じように、グラフィックのテキストも翻訳する必要があります。テキストがグラフィックに埋め込まれていると、翻訳されたテキストを含むグラフィックの更新が難しくなり、負荷もかかります。グラフィックのローカライゼーションについては、グラフィックの使用を控えるか、グラフィック内のテキストを削除するのがよいでしょう。
すべての画像をよく検討する
対象の国やマーケットのユーザーにとってわかりやすい、適切な汎用画像を使用します。特定の文化に固有な画像は世界では理解されない可能性があります。単なる画像でもおかしなものだと受け取られることがあります。たとえば、日本と米国では郵便ポストやトラックの外見がかなり違います。世界中のユーザー向けに使える汎用的な画像を適用すれば、外国の市場や世界に向けて製品を発売するときに、画像を差し替える必要がなくなります。
画像が各文化や国で適切かどうかを確認するだけでなく、各ロケールで画像が正しく表示されているかどうかや、正しい画像が表示されているかどうかを確認する必要もあります。たとえば、翻訳されて画像上に載せ替えられたテキストが画像内で正しく表示されているかなどがこれに該当します。
テキスト
UIに必要な領域
UIコンポーネントの場合、多言語にも対応できるよう、UIの領域に余裕を持たせます。たとえば、日本語からドイツ語にUIを翻訳すると、さらに多くのスペースを必要とすることがあります。
ガイドラインをいくつか示します。
- 疑似ローカライゼーション機能（翻訳対象言語ではあるが、内容的には意味のないダミーの文章を入力する機能）を使用して、コンテンツの文字列をできるだけ早い段階でテストします。たとえば、Google翻訳で訳文を生成します。
- あふれてしまったコンテンツは、コントロールを追加するようにします。ただし、ユーザーエクスペリエンスを損ねる場合は追加しません。
- 完全に表示されていない箇所を特定します。
- 翻訳で長くなった場合を考慮して、少なくとも30%は拡張できるようにしておきます。
行の折り返しと切り詰め
Textコンポーネントを使うすべてのレイアウトに行の折り返しと切り詰めを定義し、テキストが、必ずすべて折り返して表示されるようにします。TextコンポーネントでmaxLinesプロパティを使って、行数を1行、2行などに制限するTextコンポーネントをコールアウトします。
ただし、ナビゲーションに使用するテキストは切り詰めないでください。こうしたテキストのコンポーネントには、使える行の数が視覚デザインによって限られていても、文字列の拡張に対応できるだけの広いスペースが必要です（前述のガイドラインを参照）。 翻訳が収まらないためにデザインを変更するのは大変な作業です。そのため、こうした変更が必要な場合でも対応できるよう、事前に対策を取っておく方がよいでしょう。
ボタンとコントロールのテキストラベル
ボタンのラベルは簡潔にします。最初に作成した日本語のラベルはデザイン内に収まっていても、多言語に翻訳したら収まらなくなったり、ラベルの改行のせいでボタンが伸びてしまったりするなど、指定のスペースにボタンやその他のコントロールが収まらないことはよくあります。UIフォントを見やすくするために拡大するユーザーにも同様の問題がよく起こります。ラベルに多くの単語を詰め込むのではなく、メッセージを別の本文としてボタンの上に分けて、ラベルには「OK」や「Agree」といった簡潔なアクションだけを表示します。1行に複数のボタンを配置しないでください。
強調や区別のためのフォントのスタイルと大文字
英数字の場合、太字、下線、取り消し線、大文字（ラベルをすべて大文字にする）といったフォントのスタイルは、強調したり、目に付きやすいようにするために使用しますが、このようなスタイルを使わない言語もあります。日本語もそうですが、中国語、アラビア語、ヒンディー語、韓国語などもこれに該当します。こうした言語では、代わりに別の形式を使用します。たとえば、前景と背景の色を変える、引用符を使う、コントロールの枠線と塗りつぶしを適用するなどです。
縦方向の隙間（行の高さと空間）は余裕をもって設定します。発音区別符号を多用する言語に翻訳された場合に、強弱符号の付いた大文字を収めるためにより広い空間が必要になるからです。
文字間のスペース
文字と文字の間にスペースを空けない言語は、日本語以外にもあります。このような言語では、GUI表示において改行処理が難しく、文字列の最終行に1文字しか含まれないということも発生します。テストを何度も繰り返して、バランスよく表示されるよう調節してください。
複数行の句
視覚レイアウトで1つの句を複数行に故意に分けないでください。代わりに、行の自然な折り返しを使います。または、句を文法上独立した複数の部分に分けます。1つの句を複数行に分けると、実装する方法は次の2つしかなくなり、そのどちらでも文法に従って正しく翻訳できません。
- 1つの句を複数の文字列リソースにする方法。翻訳者は各リソースを個別に翻訳するため、それらのリソースを組み合わせて表示すると、全体の文脈が意味をなさなくなったり、文法が正しくなくなったりする場合があります。これを防ぐには、テキスト1行につき文字列リソースは1つにします。
- 1つの文字列リソースに改行（'\n'）文字を組み合わせて強制的に改行しまう方法。翻訳者は改行した後の文章をどうやって扱っていいのかわかりません。新規行の内容を削除してしまうこともあります。翻訳したとしても、それが不適切な箇所に配置されていると、意図した意味にならないこともあります。翻訳者は翻訳中に翻訳したテキストの画面配置を確認できないからです。
複数行にわたる句に動的に代入される引数が含まれている場合は、翻訳された文字列が全体としては意味をなさなくなる可能性が高くなります。引数が配置される位置が固定されているためです。こうした句でも文法的に正しく翻訳するためには、句の中にある引数の位置を調整できることが必要です。次の例を考えてみましょう。
「n日」という引数は他言語では句の別の位置に配置される可能性があります。翻訳者は各行を個別に翻訳します。2行以上の句は他言語では文法上正しくない不自然な句になります。
行を故意に改行しないでください。「n日」だけを1行に表示するには、1つの句を独立した複数の部分に分けます。たとえば、「主語：動詞目的語」という形式を使用します。
句の動的テキスト要素
メッセージをデザインするときには、別のテキストを動的に置換する引数を使わないでください。「この世帯から＜personal name＞のプロフィールを削除」というメッセージを考えてみましょう。言語によっては、これを文法に従って翻訳するために、置換されるテキストの文法を把握している必要があります。使うと想定される文法ごとに個別のメッセージテンプレートが必要になります。メッセージを書き換えることで引数が不要になるのであれば、そちらを選んでください。書き換えられない場合は、メッセージを「主語：動詞目的語」の形式に書き換えてみてください。この例では、「この家庭から削除するプロフィール：＜personal name＞」となります。
次に「<title|author|recent>で並べ替え」というメッセージを考えてみましょう。ユーザーに並べ替えオプションを選ばせるテキストラベル付きコントロールとして、よく使われているものです。言語によっては、助詞「で」と動詞「並べ替え」の順序をその言語に必要な品詞や文法に応じて変える必要がでてきます。これを「主語：動詞目的語」の形式に書き換えると「並び替えの順序：<title|author|recent>」になり、簡単、適切にローカライズできるようになります。
数字、日付、時刻
日付、時刻、電話番号、ファイルサイズ、その他の汎用的な数字は、各国で慣習的に使われている形式で記述します。
日付と時刻の例
| 言語 | 数値 | 日付 | 月 | 日 | 時刻 |
|---|---|---|---|---|---|
| 日本語 | -123,456,789.988 | 2018年9月7日 | 9月 | 土曜日 | 午後2:32 |
| 英語（米国） | -123,456,789.988 | September 7, 2018 | Sep | Sat | 2:32:55 PM |
| 英語（英国） | -123.456.789,988 | 7 September 2018 | Sep | Sat | 14:32:55 |
| フランス語 | -123.456.789,988 | 7 septembre 2018 | sept. | sam. | 14:32:55 |
| ドイツ語 | -123.456.789,988 | 7.September 2018 | Sep. | Sa. | 14:32:55 |
住所
住所のフィールドラベルとフィールド順序は国によって異なることも考慮してください。たとえば、欧米の住所は地域の最小単位から最大単位（住地番、市区町村、都道府県、国）の順に並び、最後に郵便番号が記載され、日本とは順番が逆になります。
ロケール別のベストプラクティス
米国
名称
- プロンプトに人物名が含まれている場合：通常、英語では日本語の敬称である「さん」または「様」にあたる「Mr./Ms.」を付けることはなく、下の名前のみになります。つまり「
さんからのメッセージ」は「Message from 」というプロンプトにします。</li> - プロンプトや発話に氏名が含まれる場合：日本での言い方をもとに依存関係を作らないでください。たとえば、日本語ではたいてい「こんにちは、
＋さん」という形式になりますが、英語では単に「Hi 」というプロンプトになります。知り合いや同僚には下の名前で呼びかけることがほとんどです。</li> </ul> 注意事項
- 日本語と英語での名前の順序の違い：1）英語では名が先で、姓が後なので、日本語とは逆です。2）英語では人の名前の前に敬称を付けます。最もよく使われる敬称は「Mr./Ms.」です。 連絡先リストやデータベースの名前とこの敬称の自動連結は、多くの場合うまく行きますが、そうでない場合もあります。
- 日本と米国での住所の順序の違い：「ワシントンDC」は州と同レベルのようにみなされることがありますが、正確には「ワシントン」が市名で「DC」の部分が州と同等です。結果、「ワシントンの天気は？」という質問への応答は、日本人が「神戸の天気は？」とたずねたときの応答と同様になります。
- 発話のバリアント：ローカライゼーションの観点からすると、発話を日本語から英語に直訳するだけでは、対応するプロンプトが有効に機能するためには不十分な可能性があります。たとえば、日本語で「答えを教えて」という発話の場合は、英語では「What is the answer」と「Tell me the answer」の両方が必要です。
- 発話のあいまいさ：よくある発話が、一見似ていても日本語と英語で異なる可能性があります。たとえば、日本語の「本を読んだ」と「赤い本を持っている」は異なる表現ですが、英語では、それぞれ「I have read books」、「I have red books」と同じ発音になってしまいます。
- 「Yes」か「No」の答えを引き出すプロンプト：日本語で「……ですね？」といった確認プロンプトの場合は、英語ユーザーの応答が「Yes」か「No」となるように（たとえば「xxx, (is that) right?」など）英語プロンプトを書く必要があります。
- 複数の選択肢：ユーザーに複数の選択肢を提示する場合は、オプションを読み上げている途中でユーザーが応答することがないようにしてください。
- エラープロンプト：英語の場合、エラープロンプトは簡潔であることが好まれます。分かりやすく、直接的な表現を用いてください。日本語の場合のように「すみません」「申し訳ありません」という言葉を必ずしも入れる必要はありません。エラープロンプトがトリガーされる場面はたくさんあるので、エラーメッセージは特に難しい問題ですが、どんな場面でも適切なエラーメッセージとなるようにする必要があります。
住所
音声出力または視覚要素で住所を入力できる場合、米国の住所は番地から始まり、最小単位から最大単位、最後に郵便番号の順に並ぶことに注意してください。ワシントンDCは厳密には「州」に相当します。したがって、日本の市と都道府県の情報を使用するプロンプトが、英語では意図しない結果につながることがあります。たとえば、ワシントンの天気について質問すると、より具体的な情報を求めるエラープロンプトがトリガーされます。これは兵庫の天気をたずねたときと同様です。
単位と時間
- 米国では長さ、距離の単位にインチ／フィート／ヤード／マイルが使用されています。
- 米国では場合に応じて12時間表記と24時間表記の両方が使用されていますが、12時間表記が一般的です。たとえば、鉄道は通常24時間表記ですが、口語では「Let us meet at 3pm」という表現がよく使われます。
- 英語では月と日は月を表す名詞と、日を表す接尾辞で表現されます。たとえば、月はJanuary、February、Marchなど、日は1st、2nd、3rdになり、3月3日は「March 3rd」になります。
ドイツ
Alexaはユーザーのことを「Du」と呼びます。Alexaは高地ドイツ語を話し、方言の表現を使わないようにしています。オーストリアでもドイツと同様です。
Alexaは外国語を「教養のあるドイツ人」あるいは現代の言葉を知る「賢い」人物のように発音します。
Alexaの発音はこうです。
- Amazon（ドイツ語の発音）
- Echo（ドイツ語の発音）