訪日客向けの多言語ホームページは、日本語ページをそのまま置き換えるだけでは作れません。閲覧者が滞在前や滞在中に確認する情報を選び、各言語で同じ判断ができるように設計します。
対応言語を増やす前に、社内で正確に案内できる範囲と更新担当を決めます。翻訳の作成、内容確認、画面への反映を別の工程として管理します。
対象者と利用場面を決める
最初に、誰がいつサイトを見るのかを整理します。訪問前にサービスを比べる人、移動中に場所を確認する人など、実際に想定できる場面を書き出します。
国籍や言語だけで読者を一括りにせず、必要な行動からページを考えます。所在地、利用方法、問い合わせなど、案内できる項目を選びます。
対象外の地域やサービスがある場合は、受け付けられる範囲を社内で確定します。未確認の対応を可能だと推測して掲載しません。
対応言語の優先順位を決める
対応言語は、現在の利用者、社内で確認できる人材、問い合わせ対応の可否を基に選びます。言語数の多さだけを完成条件にしません。
候補ごとに、翻訳するページ、確認担当者、問い合わせ後の対応方法を一覧にします。更新できない言語は、公開範囲を限定する判断も必要です。
自動翻訳など外部サービスを使う場合は、機能、費用、データの扱いを提供元の公式資料で確認します。未検証の精度を保証しません。
日本語の正本を先に整える
翻訳前に、日本語で掲載する会社情報、サービス内容、利用条件、連絡先を確定します。資料ごとに内容が違う場合は、責任者へ確認します。
正本には、対象ページ、承認者、変更日を記録します。翻訳者が意味を推測しなくてよいよう、専門用語や固有名詞の説明を添えます。
料金、期間、制度など変わる情報は、根拠資料と確認日を残します。公式情報を確認できない項目は翻訳へ進めません。
翻訳と内容確認を分ける
翻訳文は、言葉として自然かだけでなく、日本語の正本と意味が一致するかを確認します。翻訳者と事業内容の確認者を分けます。
地名、日時、単位、入力例などは、対象言語でどう示すかを社内で決めます。外部サービスの仕様に関わる表記は、公式資料を参照します。
修正時は、元の日本語、翻訳文、変更理由、確認者を一つの記録へまとめます。どの版が承認済みかを区別します。
問い合わせ導線を言語別に確かめる
各言語のページから、問い合わせや予約など実際に受け付ける方法へ進めるかを確認します。対応できる言語と受付範囲を明記します。
入力項目、送信後の案内、返答担当を言語ごとに確認します。受信後に内容を理解できる担当者がいない状態で窓口だけを増やしません。
外部の予約・決済サービスへ移る場合は、対応言語と利用条件を提供元の公式資料で確認します。サイト側の案内と異なる条件を載せないようにします。
公開後の更新表を作る
多言語サイトでは、日本語だけを変更して他の言語を残さないよう、対象ページを対応表で管理します。変更の必要がない言語も確認結果を記録します。
- 対象者、利用場面、対応範囲を決めた
- 言語ごとのページと担当者を確認した
- 日本語の正本と根拠資料をそろえた
- 翻訳と事業内容を別々に確認した
- 問い合わせ後の対応体制を決めた
- 言語別の公開後確認を記録した
公開後は、言語切り替え、主要ページ、問い合わせまでを各端末でたどります。表示できることだけでなく、内容が正本と一致するかを確かめます。
