〜現場で何度もモヤモヤしてきた話を、全部さらけ出します〜
Webサイトの多言語対応というテーマ、パッと聞くと「まあ翻訳すればいいんでしょ？」くらいに思われがちです。
でも実際に現場に入ってみると、翻訳の精度うんぬんより先に、もっと根本的なところで議論が止まります。
「言語を切り替える方式にするか」
それとも
「日本語と英語、同じ画面に両方載せちゃうか」
このUI設計、地味に見えて、めちゃくちゃ重要です。ここの選択をミスると、ユーザー体験・SEO・保守性・開発コスト・コンテンツ運用の負荷、ほぼ全部に響いてきます。
私はこれまで複数の多言語サイト開発に関わってきましたが、この話題になるたび、毎回同じ結論に着地します。
「どっちにもメリットがある」
……はい、エンジニアが一番聞きたくない答えです。会議室の空気が一瞬止まるやつです。でも今日は逃げずに、実体験ベースでちゃんと整理していこうと思います。
⭐️まずは2つの方式をおさらい
パターン1：言語切替型
いちばんメジャーな方式です。画面の右上あたりに、
- Japanese
- English
- Français
- Deutsch
みたいなメニューがあって、そこでポチッと切り替えるやつ。今、世の中の多言語サイトの大半はこの形です。皆さんも意識せず何百回と使っているはずです。
技術的には、
- i18n(アイ・エイティーン・エヌ)……「internationalization(国際化)」の略で、iとnの間に18文字あるから i18n。ソフトウェアを多言語対応できる「構造」にすること。
- l10n(エル・テン・エヌ)……「localization(地域化)」の略。i18nで作った土台に、実際の翻訳や文化的な調整を流し込む作業のこと。
- locale routing……URLやアクセス元の情報から「この人には日本語版を出そう」と振り分ける仕組み。
- hreflang(エイチレフラング)……「このページの英語版はこっちですよ」とGoogleに教えるためのタグ。国際SEOの必須アイテムです。
みたいな仕組みと組み合わせて実装します。URL設計も、
/ja//en/
のようにきれいに分かれていることが多いですね。
パターン2：二言語同時表示型
1つの画面の中に、日本語と英語を仲良く並べて載せちゃう方式です。イメージはこんな感じ。
サービス概要 / Service Overview
当社はクラウドソリューションを提供しています。
We provide cloud solutions.
大学の案内ページとか、公共機関のサイトで見かけたことがある人も多いんじゃないでしょうか。実装自体はかなりシンプルです。翻訳データを同じテンプレートの中にそのまま並べるだけなので、技術的なハードルは正直そんなに高くありません。
……ただし。技術的には楽なぶん、別のところで問題が山ほど噴出します。ここから先が本題です。
言語切替型のメリット
① UIが圧倒的にスッキリする
これが最大のメリットです。ユーザーは自分の言語だけを見れば済みます。
たとえば1000文字の記事があったとして、日本語ユーザーは1000文字読めばいい。英語ユーザーも1000文字読めばいい。シンプルイズベストです。
これがもし二言語同時表示だったら、体感的には2000文字。ユーザーからしたら、
「記事を読んでいるのか、それともスクロール耐久レースにエントリーしてしまったのか」
わからなくなってきます。デザインの世界には「Less is more(少ないほど豊かである)」というミース・ファン・デル・ローエの有名な言葉がありますが、多言語UIにもまさにこれが当てはまるなと感じます。
② SEOにめちゃくちゃ強い
Googleは基本的に「言語ごとにページを分けてね」というスタンスです。先ほど紹介したhreflangをきちんと設定してあげれば、
- 日本語で検索した人には日本語ページ
- 英語で検索した人には英語ページ
がちゃんと出し分けられます。国際SEOの観点では非常に効果的で、グローバル展開を狙う企業サイトなら、もはや必須と言っていいレベルです。
③ CMSの運用が整理しやすい
WordPressやHeadless CMS(コンテンツの中身とデザインの見た目を切り離して管理できる仕組み)を使う場合、言語ごとにコンテンツを綺麗に整理できます。
最近だと、
- WordPress
- Contentful
- Strapi
- Sanity
- Hygraph
あたりも多言語管理の機能がかなり充実してきました。翻訳のワークフローも組みやすいので、企業サイトとの相性は抜群です。
言語切替型のデメリット
もちろん良いことばかりではありません。
① 内容を見比べにくい
たとえば英語学習中の人だと、「日本語版と英語版、両方見比べたいな」というケースがあります。そうなると、
日本語ページを開く → 英語ページに移動 → 日本語に戻る → やっぱり英語も見る……
まるで負荷テストツールがブラウザを勝手に操作しているみたいな挙動になります。ユーザー体験としては、正直あまり美しくありません。
② 翻訳漏れに気づきにくい
これ、現場で本当によく起きます。
- 日本語版だけ更新されている
- 英語版だけ情報が古い
- フランス語版がそもそも存在しない
- 開発チームは誰も気づいていない
- でも利用者はしっかり気づいている
私自身、公開後に「英語版だけ情報が3年前のままですよ」と指摘されて、思わず冷や汗をかいた経験があります。本番環境というのは、いつでも正直者です。誰も見ていないところでもバレるときはバレます。
二言語同時表示型のメリット
① 情報を比較しやすい、これに尽きる
これは本当に大きな強みです。たとえば、
- 契約書
- 利用規約
- 学術資料
- 技術文書
こういうものは、原文と翻訳文を並べて確認したいケースが多いです。その場合、日本語と英語が同じ画面に並んでいるほうが圧倒的に便利。実際、国際プロジェクトの現場では、日本語の仕様書と英語の仕様書を並べて突き合わせる作業が頻繁に発生します。この方式なら、エンジニア同士の「あれ、そっちの仕様と認識違ってない？」という食い違いを減らす効果も期待できます。
② 翻訳の品質チェックがしやすい
翻訳者やレビュー担当者にとっては、これはかなりありがたい形です。原文と訳文を同時に見比べられるので、
- 誤訳
- 抜け・脱字
- ニュアンスの欠落
に気づきやすくなります。翻訳管理システム(TMS)の世界でも、この「原文と訳文を並べる」という考え方は広く採用されています。
③ 実装がシンプル
高度な言語切替のロジックを組まなくても運用できます。場合によってはCMSすら要らず、静的なサイトでも十分対応可能です。
二言語同時表示型のデメリット
① とにかく長い
もう一度言います。長いです。本当に長いです。想像している以上に長いです。
ユーザーは読み進めるうちに、「私は今、情報を読んでいるのだろうか。それともマラソンを完走しようとしているのだろうか」という、ちょっとした哲学的な問いにたどり着きます。特にスマートフォンでは深刻で、1ページが異様な縦長構造になりがちです。
② SEO的にちょっと扱いづらい
1つのページの中に複数の言語が混在してしまうため、検索エンジンが「このページは結局どの言語がメインなの？」と判断しづらくなるケースがあります。国際SEOの観点では、一般的にはあまり有利とは言えません。グローバルな集客を重視するサイトには、正直あまり向いていない方式です。
③ デザインが崩れやすい
- 英語は短い
- ドイツ語は長い(複合語が長すぎることで有名です)
- 日本語は文字の密度が高い
- 中国語はまた別の特徴がある
つまり多言語対応というのは、実質「レイアウト破壊耐性テスト」でもあるわけです。デザイナーとフロントエンドエンジニアが揃って頭を抱える理由の1つです。「言うは易く行うは難し」を、ボタン1個のデザインで体感できます。
⭐️結局、どっちを選べばいいのか
私の経験上、ざっくりこう考えるのが一番しっくりきます。
言語切替型が向いているサイト
- 企業のコーポレートサイト
- SaaSサービス
- ECサイト
- Webメディア
- ブログ
- マーケティングサイト
- グローバル向けサービス
これらはSEOとユーザー体験の良さが命です。基本的には言語切替型が最適で、今の業界標準もこちらです。
二言語同時表示型が向いているサイト
- 契約関連の書類
- 技術仕様書
- 学術論文
- 大学関連のサイト
- 国際機関向けの資料
- 教育系コンテンツ
- 原文と訳文を比べて読ませたいコンテンツ
ユーザーが「内容を見比べながら読む」ことを前提にしているなら、この方式のほうが圧倒的に強いです。
⭐️まとめ
多言語対応に、万能の正解というものは存在しません。
言語切替型は「読みやすさ」と「SEO」に強い。
二言語同時表示型は「比較のしやすさ」と「翻訳確認のしやすさ」に強い。
私自身、これまでの開発経験の中で両方の方式を採用してきましたが、企業のWebサイトやサービスサイトであれば、基本的には言語切替型を選びます。一方で、仕様書や技術文書のように原文との比較が重要になるケースでは、二言語同時表示型の価値は非常に高いと感じています。
要するに大事なのは、「ユーザーは何をしにこのページへ来るのか」という、UX設計のいちばん最初の問いに立ち返ることです。
技術選定においても同じことが言えますが、最適解は必ずしも最新技術の中にあるとは限りません。「急がば回れ」ということわざがありますが、多言語対応もまさにそれで、遠回りに見える基本設計の議論こそが、あとあと一番の近道になったりします。
実際、設計会議で1時間も真剣に議論した結果、「とりあえずユーザーに聞いてみたら一瞬で解決した」なんてこともよくある話です。エンジニアリングというのは、時に高度な分散システムを組むことよりも、人間を理解することのほうがよっぽど難しい仕事なのかもしれません。