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

開発した音声エクスペリエンスは、Alexaが利用可能な別のマーケットに向けても公開できます。グローバルマーケットに公開する場合は、言語と文化の違いに対応できるように、エクスペリエンスをデザインしてください。

マーケットに応じたローカライズ

ほかの国や言語で作られた製品のマニュアルの翻訳品質がひどいという経験は、だれにでもあるでしょう。不自然な文章や間違いだらけの文法で、その言語や文化に精通していない人が執筆したことがわかります。翻訳やローカライズが適切に行われていないコンテンツは、ユーザーエクスペリエンスと商品の信頼性に悪影響を及ぼします。質の低い翻訳をしたり、文化の違いに配慮しなかった場合は、スキルに悪影響を及ぼし、さまざまなマーケットでAlexaへの信頼が失われる結果にもつながります。
グローバルマーケットでスキルを提供する場合、提供するマーケットプレイスの言語や文化規範に合わせてコンテンツをローカライズする必要があります。同じ国であっても、さまざまな方言や文化的違いを考慮しなければならない場合もあります。それぞれのマーケットプレイスで、その国の法律が定める独自の技術要件があることにも配慮が必要です。スキルをデザインする際は、マーケットプレイスに応じた翻訳と文化的要件を満たせるように柔軟に対応する必要があります。ローカライゼーションとは単なる言葉の翻訳ではなく、Alexaがユーザーと会話する方法を文化に応じて調整するプロセスであると捉えましょう。
エクスペリエンスをデザインする際は、自分が属するマーケットプレイスの文化と言語にとらわれずに発想しましょう。スキルをデザインする際は、次の点について考えてみてください。

  • どの国と言語に向けてスキルを公開し、サポートしますか?
  • 翻訳とローカライゼーションはどの程度必要ですか? ネイティブスピーカーにローカライゼーションの作業を手伝ってもらえますか?

ローカライゼーションのベストプラクティス

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

短く簡潔な文を書く

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

口語、だじゃれ、その土地だけで通じる言い回しを避ける

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

用語の定義と使い方を統一する

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

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

ローカライゼーションを念頭に開発する

ほかのマーケットプレイス向けのスキルを開発する際は、次のベストプラクティスを検討してください。

  • テキストにはUnicode(UTF-8)を使用します。
  • 場所のデータ(地域や郵便番号など)は国別に処理できるようにしておきます。
  • 言語構造の違いを考慮し、言語別に入力処理方法を変更できるようにしておきます。

プロンプトの構造をコードに埋め込まない

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

文字列を連結しない

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

言語別の語順

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

言語 主語 動詞 目的語 コメント

英語

The big man

eats

a delicious red apple.

英語の名詞に性はありません。形容詞は格(文中の名詞の機能)に応じた語形変化を必要としません。

ドイツ語

Der große Mann(男性冠詞、主格形容詞、男性)

isst

einen roten, köstlichen Apfel.(masculine, accusative case)

主語、動詞、目的語の語順は英語と同じですが、ドイツ語では形容詞の前にコンマを置いても問題ありません。冠詞と形容詞を名詞の性と格に一致させる必要があります。

スウェーデン語

Den stora mannen

äter

ett gott rött äpple.

定冠詞が2か所で一致し、形容詞と名詞が一致しています。2番目の名詞句では音のために形容詞の順序が変わっています。

フランス語

Le gros homme(The big man)

mange(eats)

une pomme rouge et délicieuse.(an apple red and delicious)

英語と語順が異なります。

日本語

大きい男の人が(Ookii otokonohito ga)

食べています。(tabete imasu.)

おいしそうな赤いりんごを(Oishisouna akai ringo o)

主語が最初に置かれ、動詞が最後に置かれます。

ヒンディー語

बड़े बालों वाला आदमीBade wala admi

खाता है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)

英語と語順が異なります。

視覚要素のデザインを国際化する

英語のエクスペリエンスをローカライズする場合、ユーザーインターフェースなどのテキストでは、言語構造の違いからより多くのスペースが必要になるのが一般的です。たとえば英語の場合は、日本語より語句や文が短く、文字が小さくなることが多くなります(ドイツ語の場合は英語の場合よりも長くなります)。日付や数字といったデータに必要な領域もそれに応じて長さが変わります。

グラフィックにオーバーレイ、レイヤーまたはコールアウトを使用する

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

すべての画像をよく検討する

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

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>」になり、簡単、適切にローカライズできるようになります。

数字、日付、時刻を調整する

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

言語 数字 曜日 時刻

英語(米国)

-123,456,789.988

9/7/2018

Sep

Sat

2:32 pm

英語(英国)

-123.456.789,988

7 September 2018

Sep

Sat

2:32 pm

フランス語

-123.456.789,988

7 septembre 2018

sept.

sam.

2:32 pm

ドイツ語

-123.456.789,988

7.September 2018

Sep.

Sa.

2:32 pm

日本語

-123,456,789.988

2018年9月7日

9月

土曜日

2:32 pm

住所を調整する

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

ロケール別のベストプラクティス

米国

名称

  • プロンプトに人物名が含まれている場合:通常、英語では日本語の敬称である「さん」または「様」にあたる「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は外国語を「教養のあるドイツ人」あるいは現代の言葉を知る「賢い」人物のように発音します。