グローバルマーケット向けのデザイン

グローバルマーケット向けの音声エクスペリエンスをデザインする際は、次のベストプラクティスを念頭に置いてください。

長く複雑な文は、翻訳するのも理解するのも大変です。複雑な修飾語・被修飾語に気を付けるだけでなく、文の長短に関わらず、わかりやすい文になるよう工夫しましょう。ある句を長いと感じた場合、ドイツ語やトルコ語など特定の文法構造を持つ言語では、その3～4倍の長さになる可能性があります。

文化特有の言い回しは、ほかの言語や地域、特定の文化圏には相当する表現がなかったり、あるいは悪い意味に取られたりする可能性があります。スキルのコンテンツにとってどうしても必要な場合は、その地域出身の翻訳者と協力して、相当する用語を見つけてください。たとえば、「お疲れ様です」は翻訳しにくい表現です。「9時5時」も同様です。ほかの国や地域では働く時間帯が異なるからです。

スキルで使用する名前、用語、アクションは使い方を統一します。使用する用語の定義を提示して、翻訳者が適切な訳語をつけやすいようにする必要があるかもしれません。
すべてのコンテンツで、地政学上の不適切な表現や扱いに注意を要する事柄についてよく検討します。スキルのコンテンツに、文化的にデリケートな話題や不快感を与える語などが含まれていないことを確認します。たとえば、ある画像が別の文化では異なる意味を持ったり、不快とみなされたりする可能性があります。別のマーケットのユーザーが不快に感じないように、音声と視覚の両方のコンテンツを確認してください。
画像には特にリスクがあるので、注意が必要です。

• 旗（旗は国によって受け取られ方が変わります）
• 地図（国境の認識は一部の国で異なります）
• 人（身ぶり、容姿、人種など）
• 象徴や像（国家、政治、宗教、スピリチュアル）
• 成人向け画像やわいせつな画像
• 色、数字、名前、イベントの文化的な意味

言語によって語順は異なります。名詞句は、名詞と場合によっては形容詞（形容動詞）や冠詞で構成されます。語順は各言語の文法によって決まります。動的コンテンツ（変数）を含む名詞句は連結しないでください。

文字列の連結は国際化とローカライゼーションの両方に影響します。複数の文字列を連結して1つの文を構成することは、開発者がよくやってしまう不適切なコーディング手法です。連結した文字列を組み合わせると日本語では理解できる文になるかもしれませんが、多くの言語の文法ではそうではありません。翻訳者が文の語順を変更しなければならない場合に、1つの文が複数の文字列に分割されていると、語順の変更ができないことがあります。

主語と目的語のいずれも連結しないでください（コードで語順が決まってしまいます）。名詞または形容詞（形容動詞）が変数である場合は、コードを1つの文字列にして、翻訳者がコード内の変数の位置を変えられるようにします。一部の言語では、形容詞や冠詞の性と格を名詞とその文中での機能（主語、直接目的語、間接目的語）と一致させる必要があります。
以下の表では、言語別に語順の違いを例示しています。

UI文字列の翻訳と同じように、グラフィックのテキストも翻訳する必要があります。テキストがグラフィックに埋め込まれていると、翻訳されたテキストを含むグラフィックの更新が難しくなり、コストもかかります。グラフィックのローカライゼーションについては、グラフィックの使用を控えるか、グラフィック内のテキストを削除するのがよいでしょう。

対象の国やマーケットのユーザーにとってわかりやすい、汎用的で適切な画像を使用します。特定の文化に固有な画像は世界では理解されない可能性があります。単なる画像でもおかしなものだと受け取られることがあります。たとえば、日本と米国では郵便ポストやトラックの外見が異なります。世界中のユーザー向けに使える汎用的な画像を適用すれば、外国の市場や世界に向けて製品を発売するときに、画像を差し替える必要がなくなります。
画像が各文化や国で適切かどうかを確認するだけでなく、意図した画像が各ロケールで正しく表示されているかどうかを確認する必要もあります。たとえば、翻訳されて画像上に載せ替えられたテキストが画像内で正しく表示されているかなどがこれに該当します。

UIコンポーネントの場合、多言語にも対応できるよう、UIの領域に余裕を持たせます。たとえば、日本語からドイツ語にUIを翻訳すると、さらに多くのスペースが必要になることがあります。できるだけ早いタイミングでコンテンツの文字列をテストし、十分なスペースがあることを確認してください。翻訳文がスペースに入りきらない場合は、慎重にUIをデザインし直してください。

訳文の行数が多くなった場合でも、デザインを崩さずに文字がしっかり読めるようにデザインします。これは、ナビゲーション要素などの必須項目で特に重要です。テキストを読む際にスクロールか切り詰めが不可欠な場合は、切り詰めるのに適切な箇所を翻訳者に指定してもらいます。Textコンポーネントを使うすべてのレイアウトで、行の折り返しと切り詰めを定義してください。TextコンポーネントでmaxLinesプロパティを使い、行数を1行、2行などに制限するTextコンポーネントをコールアウトします。

ボタンのラベルは短く簡潔にして、翻訳しても同じレイアウトに収まるようにします。テキストが長すぎると、翻訳文でボタンが横長になり、ほかのUI要素を画面から押し出してしまいます。見やすくするためにUIフォントを拡大するユーザーにも同様の問題が起こります。ボタンの情報は最小限に抑え、ボタンの上の本文に詳細を記します。またアクションに関するテキストは短くします（「OK」や「キャンセル」など）。 可能であれば、1行に複数のボタンを配置することは避けてください。

英数字の場合、太字、下線、取り消し線、大文字（ラベルをすべて大文字にする）といったフォントのスタイルは、強調したり、目に付きやすいようにするために使用しますが、このようなスタイルを使わない言語もあります。縦方向の隙間（行の高さと空間）は余裕をもって設定します。発音区別符号を多用する言語に翻訳された場合に、強弱符号の付いた大文字を収めるためにより広い空間が必要になるからです。太字、斜体、大文字／小文字を使用しない言語（中国語、日本語、アラビア語、ヒンディー語など）では、フォントのスタイルによる効果を出せないため、代わりに、前景や背景の色、引用符、枠線などの形式を使用してテキストを強調します。

文字と文字の間にスペースを空けない言語は、日本語以外にもあります。このような言語では、GUI表示において改行処理が難しく、文字列の最終行に1文字しか含まれないということも発生します。テストを何度も繰り返して、バランスよく表示されるよう調節してください。

全体を表示する代わりに行を自然に折り返すか、句を文法上独立した複数の部分に分けるようにします。1つの句が複数の行に分かれる場合、誤訳になってしまう可能性があります。翻訳者は各リソースを個別に翻訳するため、それらのリソースを組み合わせて表示すると、全体の文脈が意味をなさなくなったり、誤った文法になったりする場合があります。これを防ぐには、テキスト1行につき文字列リソースは1つにします。この問題は、文字列に改行（'\n'）が埋め込まれている場合にも起こります。翻訳者が改行の扱いを知らず、翻訳を行わないことで発生します。多くの翻訳会社では、テキストが最終的にどのように画面表示されるかを翻訳作業中に確認しないため、こうした問題が起こります。

複数行にわたる句に動的な引数が含まれている場合は、翻訳された文字列全体が意味をなさない可能性が高くなります。これは、句の中で引数が配置される位置が固定されているためです。こうした句でも文法的に正しく翻訳できるように、句内の引数の位置を調整する必要があります。変数を含むテキストを文法的に正しく翻訳するためには、置換されるテキストの文法を把握している必要があります。この翻訳には、想定される文法上の性や格に応じて異なるメッセージテンプレートも必要です。または、引数や変数要素がなくなるようにメッセージを編集し直してください。書き換えられない場合は、メッセージを「主語：動詞目的語」の形式に書き換えてみてください。たとえば、「<title|author|recent>で並べ替え」というメッセージは、ボタンなどのUI操作として表示されることがよくあります。言語によっては、助詞「で」と動詞「並べ替え」の順序をその言語に必要な品詞や文法に応じて変える必要が出てきます。これを「主語：動詞目的語」の形式に書き換えると「並べ替えの条件：<title|author|recent>」になり、簡単、適切にローカライズできるようになります。

日付、時刻、電話番号、ファイルサイズ、その他の汎用的な数字は、各国で慣習的に使われている形式で記述します。
次の表に、さまざまなロケールでの日付と時刻の例を示します。

住所のフィールドラベルとフィールド順序は国によって異なります。たとえば、欧米の住所は地域の最小単位から最大単位（住地番、市区町村、都道府県、国）の順に並び、最後に郵便番号が記載されます。日本とは順番が逆になります。

• プロンプトに人物名が含まれている場合：通常、英語では日本語の敬称である「さん」または「様」にあたる「Mr./Ms.」を付けることはなく、下の名前のみになります。つまり「さんからのメッセージ」は「Message from 」というプロンプトにします。
• プロンプトや発話に氏名が含まれる場合：日本での言い方をもとに依存関係を作らないでください。たとえば、日本語ではたいてい「こんにちは、＋さん」という形式になりますが、英語では単に「Hi 」というプロンプトになります。知り合いや同僚には下の名前で呼びかけることがほとんどです。

• 日本語と英語での名前の順序の違い：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は外国語を「教養のあるドイツ人」あるいは現代の言葉を知る「賢い」人物のように発音します。