多言語対応は、日本語では情報を得にくい人に、製品やサービスを理解してもらうための取り組みです。新しい顧客への案内、既存顧客の利用支援、採用や公共の情報提供など、何を改善したいかを決めてから、対象言語とページを選びます。
読み手が判断や操作に困る場所を確かめる
製品の仕様が読めない、料金や利用条件がわからない、問い合わせを送れないといった問題がある場合は、必要な情報を別の言語で用意する理由になります。新規の集客だけでなく、既存顧客から繰り返し質問される内容も確認します。
翻訳を増やしただけで、売上や満足度が上がるとは限りません。説明の正確さ、商品の需要、価格、問い合わせ後の対応なども影響します。目的に合う指標を決め、対応前後の変化を確認する必要があります。
ブラウザー翻訳と、運営側が用意する訳文を分けて考える
利用者がブラウザーなどの翻訳機能で読む場合は、運営側がその訳文を直接確認・管理できるとは限りません。自社で訳文を提供する場合は、正式名称、条件、文体を確認し、必要な修正を運用へ組み込めます。
ただし、外国語を利用するすべての人がブラウザー翻訳を使っているとは判断できません。ブラウザーの言語設定やアクセス元の国だけでは、実際の閲覧方法まではわかりません。
また、ブラウザー上の翻訳と、検索から到達できる言語別ページを公開することは別です。外国語ページを用意していない場合でも、外国語の検索からの流入が必ずゼロになるわけではありません。検索向けの内容と設定は、別に確認します。
検索で届けたい情報と、利用者の操作をそろえる
対象言語で使われる製品名や検索語を調べ、その問いに答える内容を用意します。言語別URL、検索エンジンが取得できる本文、ページタイトル、内部リンクを確認します。同じ内容の言語版がある場合は、hreflangで対応関係を示す方法があります。
hreflangは順位や検索への登録を保証する設定ではありません。本文が翻訳されているページを、言語が違うという理由だけで重複として扱うわけでもありません。詳しくはGoogleの言語版の説明を参照してください。
流入後は、資料、問い合わせ、予約、購入まで対象言語で進められるかを確認します。紹介ページだけを翻訳して、重要な操作で日本語に戻ってしまう構成を残さないようにします。
品質と更新に、どの作業が必要か見積もる
翻訳の方法は、自動翻訳、翻訳者への依頼、その組み合わせなどから選びます。いずれの場合も、意味、名称、数値、条件、否定を確認します。専門的な内容や重要な条件は、内容を把握している担当者に確認を依頼します。
用語集には正式な名称を、ガイドラインには文体や表記をまとめます。画像や資料、住所や日付の形式などは、文章とは別に対応が必要になる場合があります。過去の訳文を再利用する仕組みでは、修正の保存先と適用範囲を確認してください。
原文の変更をいつ反映するか、誰が公開後の画面を確認するかも決めます。費用にはサービスの利用料や翻訳費に加え、確認、実装、保守、問い合わせ対応の時間を含めます。
導入事例は、自社と条件が近いかを見る
他社の事例では、対象言語、ページ数、更新頻度、目的、担当体制を確認します。売上や問い合わせの変化が示されている場合は、期間や集客施策などの比較条件も確認します。言語を増やしたことだけを成果の原因と決めつけないようにします。
自社に近い条件を探す際は、導入事例を参考にしてください。実績が確認できない匿名の成功談や、出典のない数値を投資判断の根拠にはしないようにします。
限られた範囲で始め、結果をもとに見直す
最初に、対象の読み手、言語、必要なページ、確認する期間、担当者を決めます。現在の閲覧や問い合わせを記録し、公開後は有効な問い合わせや利用につながっているかと、更新の作業量を確認します。
離脱率の差だけで、読めずに離脱したと断定することはできません。流入経路、ページの目的、端末、実際の操作を合わせて調べます。結果をもとに、情報を補う、操作を見直す、対象を広げるといった次の対応を選びます。