海外向けのWebサイトやアプリは、日本語を別の言語に置き換えれば完成するわけではありません。説明は理解できても、日付の読み方が分からない、住所を入力できない、案内された方法で問い合わせができない、といった問題が残ることがあります。利用する地域と場面に合わせ、内容と操作の両方を整える作業がローカライズです。
この記事では、2026年10月31日に確認した公開資料を基に、翻訳との関係、対象に含めるもの、公開前の確認手順を整理します。国や言語だけで利用者の好みを決めつけず、実際の読者と利用条件を確かめることから始めましょう。
ローカライズと翻訳、国際化の関係
W3Cの解説では、ローカライズは製品や文書などを対象地域の言語・文化その他の要件に合わせることとされています。翻訳に加え、日付、通貨、住所、画像なども検討の対象です。localization を l10n と略すのは、最初と最後の文字の間に10文字あるためです。
翻訳も、もともと文脈や読者を考慮して意味を伝える仕事です。「翻訳は単語の置換、ローカライズは自然な表現」という分け方では、その役割を十分に説明できません。ローカライズでは、訳文だけでなく、商品やサービスを現地の条件で使える状態まで対象が広がる、と捉えると実務上の範囲が明確になります。
国際化は、複数の言語・地域に対応しやすい設計を先に用意することです。たとえば、画面の文章をプログラムから分離する、文字が増えてもボタンを表示できるようにする、地域別の形式を扱えるようにする、といった準備です。翻訳開始後に設計上の制約が見つかると、文章だけでは解決できない場合があります。
最初に対象地域と利用者を具体化する
「英語版」「中国語版」という指定だけでは、表記や用語を一つに決められないことがあります。対象地域、利用者の年齢や専門知識、購入者か既存顧客か、閲覧端末、読む目的を整理します。同じ言語でも、企業の購買担当者向けの仕様書と、初めて使う人向けの画面では必要な説明が異なります。
最初の依頼書には、「誰が、何を判断し、どの操作を終えればよいか」を一文で書くと役立ちます。たとえば「海外販売店の担当者が、対応機種を確認して見積依頼を送れるようにする」であれば、商品説明だけでなく、型番一覧と問い合わせフォームまでが確認対象になります。
地域の事情は、社内の販売担当者や現地で利用する人の具体的な情報から確認します。「この国ではこの色が必ず好まれる」といった一律の説明は避け、意味の誤解、見やすさ、ブランドとの整合性を個別に検討しましょう。必要なら複数案を試し、判断理由を残します。
文章以外に見落としやすい対象
| 対象 | 確認する例 |
|---|---|
| 画面・文書 | 見出し、ボタン、エラー文、図中文字、説明資料、通知メール |
| 数値と形式 | 日付、時刻と時差、通貨、単位、小数点、電話番号 |
| 取引と窓口 | 販売地域、配送先、支払方法、問い合わせ言語、受付時間 |
| 実装と表示 | 入力欄、検索、改行、文字欠け、画像の代替テキスト |
通貨記号を変えるだけで販売価格を変更したり、日本での保証条件をそのまま海外へ適用したりしてはいけません。文章の表現調整と、事業上の条件変更は分けて扱います。価格、返品、保証、個人情報の取扱いなどは、担当部門が対象地域の条件を確認し、承認した内容を訳文へ反映します。
日付も、数字を並べるだけでは月と日を取り違える可能性があります。原稿で意味を確定したうえで、対象地域の形式や月名を使う方法を選びます。イベントの開始時刻には、どの地域の時刻か、利用者の表示環境で自動変換するのかまで決めておきましょう。
Webサイトやアプリでは利用の入口までそろえる
Webサイトでは、翻訳したページにたどり着けることも大切です。Googleの公式案内は、言語版ごとに異なるURLを用意し、必要に応じて hreflang で対応する版を示す方法を説明しています。これは検索エンジンが言語・地域の別を理解するための設定で、検索順位の上昇を保証するものではありません。
言語切替後にトップページへ戻される、申込ボタンの先だけ日本語になる、検索結果に未翻訳ページが混じる、といった導線も点検します。アクセス数だけを見ず、読者が必要な情報へ進めたか、問い合わせの途中で困っていないかを確認してください。
アプリでは、本体の画面と配布ページを一緒に管理します。Appleの開発者向け案内でも、アプリ内の内容に加えて画像やApp Storeの情報が対象に含まれます。紹介文の機能名とアプリ内のボタン名が違うと、利用者は同じ機能だと気づけない場合があります。
制作中は文脈と判断記録を共有する
翻訳者には、文字列の一覧だけでなく、画面の画像、前後の操作、文字数の制約、正式な製品名を渡します。「保存」が設定の保存なのか、ファイルのダウンロードなのかで表現は変わります。短い文ほど前後の情報が必要になることを、制作日程にも織り込んでください。
共通の用語集には、採用語だけでなく、使わない表現とその理由も残します。訳語を変える場合は、画面、マニュアル、FAQ、通知メールのどこへ影響するかを確認します。過去の訳文を再利用するときも、機能や条件が更新されていないかを見直しましょう。
原稿を確定する担当者、訳文を確認する担当者、画面に実装する担当者を決め、照会事項の回答先を一本化します。原稿を途中で変更した場合は、変更した箇所と版を共有し、古い訳文が再び入らないようにします。
公開前に確かめたい四つの観点
確認は、意味、地域条件、表示、操作の四つに分けると進めやすくなります。意味の確認では原文と訳文の抜けや条件を照合し、地域条件の確認では対象地域で提供できる内容かを担当者が判断します。表示確認は実際の端末で行い、操作確認では申込みやエラー時の流れも試します。
たとえば登録画面なら、氏名の入力、住所の書式、必須項目の説明、確認メール、登録後の案内までを一続きで確認します。正しい訳文が入っていても、入力欄が必要な文字を受け付けなければ利用できません。担当者ごとに確認した環境と結果を記録しておきます。
公開後も、原文の更新と各言語版の更新を連動させます。料金や利用条件の改定では、更新日、変更箇所、承認者、公開先を一覧にし、古い画面画像やPDFも対象に含めてください。ローカライズの成果は、最初の公開時だけでなく、更新を続けられる運用まで含めて評価することが大切です。
