最終更新:
多言語サイトの文字数設計 - 翻訳で文章が膨らむ問題への対処法
Web サイトを多言語展開する際、最も見落とされがちな問題が「テキストの膨張」です。日本語で完璧にデザインした UI が、英語に翻訳した途端にレイアウトが崩壊する。ドイツ語版ではボタンのテキストがはみ出し、アラビア語版では右から左への表示で余白が破綻する。本記事では、翻訳による文字数の変動を定量的に分析し、多言語サイトの UI 設計で採用すべき具体的な対処法を解説します。
言語間のテキスト膨張率 - 短い文字列ほど大きく膨らむ
同じ意味の文章でも、言語によって必要な文字数は大きく異なります。日本語は漢字の表意性により情報密度が高い「コンパクトな言語」で、英語やドイツ語などへ翻訳すると文字数が増えるのが一般的です。ここで重要なのは、膨張率が翻訳先の言語だけでなく元の文字列の長さに強く依存する点です。W3C の国際化ガイド「Text size in translation」は、元のテキストが短いほど翻訳後の膨張率は高くなりやすいと指摘しています。ボタンやラベルのような短い文字列こそ、最も大きく膨らむと考えて設計する必要があります。
W3C が引く IBM の設計ガイドラインでは、英語から欧州言語へ翻訳した場合の平均的な膨張率を、元の文字列の長さごとに次のように示しています。
| 元の文字列の長さ (英語) | 平均的な膨張率 |
|---|---|
| 10 文字以下 | 200〜300 % |
| 11〜20 文字 | 180〜200 % |
| 21〜30 文字 | 160〜180 % |
| 31〜50 文字 | 140〜160 % |
| 51〜70 文字 | 151〜170 % |
| 70 文字超 | 約 130 % |
言語別の傾向は、W3C が紹介する実際の UI (Flickr) の集計が参考になります。英語を 1 とすると、フランス語やポルトガル語で約 2.6 倍、ドイツ語で約 2.8 倍、イタリア語で約 3.0 倍に達する一方、韓国語は約 0.8 倍、中国語は約 1.2 倍にとどまる例が報告されています (いずれも短い UI 文字列での比較)。日本語も中国語と同じくコンパクトな言語のため、欧州言語への膨張は起点が英語の場合よりさらに大きくなりやすいと考えておくと安全です。
特に注意が必要なのはドイツ語です。ドイツ語は複合名詞を 1 単語として表記する特性があり、"Geschwindigkeitsbegrenzung" (速度制限、26 文字) のような長大な単語が頻出します。ボタンやナビゲーションのラベルでこの膨張を想定していないと、レイアウトが確実に破綻します。
UI 要素別の文字数設計戦略
ボタン・CTA
ボタンのテキストは最も膨張の影響を受けやすい要素です。日本語の「送信」(2 文字) は英語で "Submit" (6 文字)、ドイツ語で "Absenden" (8 文字) になります。
- 固定幅ではなく
min-width+paddingで設計する - 日本語の最短テキストの 2.5 倍の幅を確保する
- テキストが 1 行に収まらない場合の折り返し処理を CSS で定義する
white-space: nowrapは多言語サイトでは原則使用しない
ナビゲーション・メニュー
ヘッダーナビゲーションは水平方向のスペースが限られるため、膨張の影響が顕著です。
- ナビゲーション項目は日本語で 4〜6 文字、英語で 8〜15 文字を想定する
- Flexbox の
flex-wrap: wrapで自動折り返しを許容する - モバイルではハンバーガーメニューに切り替えるブレークポイントを、言語ごとに調整する
- ドイツ語やフィンランド語など膨張率の高い言語では、省略形の使用を翻訳者と事前に合意する
フォームラベル・プレースホルダー
フォームのラベルとプレースホルダーは、入力フィールドの幅との関係で文字数制約が生じます。
- ラベルはフィールドの上に配置する (左配置だと膨張時に入力欄が狭くなる)
- プレースホルダーは翻訳後に入力欄からはみ出す可能性を考慮し、
text-overflow: ellipsisを設定する - バリデーションメッセージは翻訳で 2〜3 倍に膨張することを想定し、表示領域を確保する
CSS による多言語テキスト膨張への対策
CSS レベルで実装できる膨張対策を紹介します。
/* 基本: テキストの折り返しと溢れ防止 */
.multilingual-text {
overflow-wrap: break-word;
word-break: break-word;
hyphens: auto;
}
/* ボタン: 最小幅を確保しつつ伸縮可能に */
.btn-multilingual {
min-width: 120px;
padding: 0.75em 1.5em;
white-space: normal;
text-align: center;
}
/* ナビゲーション: 膨張時の折り返し対応 */
.nav-multilingual {
display: flex;
flex-wrap: wrap;
gap: 0.5rem;
}
/* テーブルセル: 最小幅と折り返し */
.table-multilingual td {
min-width: 80px;
word-break: break-word;
}
/* 言語別の font-size 調整 (ドイツ語は小さめに) */
:lang(de) .compact-text {
font-size: 0.9em;
}
/* CJK 言語の行間調整 */
:lang(ja), :lang(zh), :lang(ko) {
line-height: 1.8;
}hyphens: auto は英語やドイツ語で特に効果的です。長い単語を適切な位置でハイフネーションし、行末の大きな空白を防ぎます。ただし、日本語や中国語ではハイフネーションの概念がないため、:lang() セレクタで言語ごとに適用を制御する必要があります。
i18n ファイルの文字数管理
多言語サイトの翻訳テキストは、JSON や YAML 形式の i18n ファイルで管理するのが一般的です。文字数の膨張を管理するために、以下のプラクティスを推奨します。
- 各キーにコメントで最大文字数を明記する:
"submitButton": "送信" // max: 15 chars - 翻訳キーの命名に UI 要素の種類を含める:
nav.home、btn.submit、label.emailのように接頭辞で分類すると、翻訳者が文字数制約を意識しやすい - CI/CD パイプラインに文字数チェックを組み込む: 翻訳テキストが指定の最大文字数を超えた場合にビルドを失敗させる
- 翻訳メモリ (TM) に文字数制約を登録する: 翻訳支援ツール (CAT ツール) の翻訳メモリに最大文字数を設定し、翻訳者がリアルタイムで制約を確認できるようにする
ピクセル幅ベースの文字数制限
文字数による制限は、フォントやレンダリングエンジンによって実際の表示幅が異なるため、厳密な制御には不向きです。より正確な制御が必要な場合は、ピクセル幅ベースの制限を採用します。
同じ 10 文字でも、言語とフォントによって表示幅は大きく異なります。
| テキスト | 文字数 | 表示幅 (16px, sans-serif) |
|---|---|---|
| 文字数カウント (日本語) | 7 文字 | 約 112px |
| Character Count (英語) | 15 文字 | 約 130px |
| Zeichenzählung (ドイツ語) | 14 文字 | 約 125px |
| Подсчёт символов (ロシア語) | 16 文字 | 約 145px |
日本語は 1 文字あたりの幅が広い (全角文字) ため、文字数が少なくても表示幅は大きくなります。逆に英語は文字数が多くても、各文字の幅が狭いため表示幅の増加は緩やかです。SEO における文字数でも、Google の検索結果表示はピクセル幅ベースで切り詰められるため、同様の考慮が必要です。
RTL (右から左) 言語への対応
アラビア語やヘブライ語などの RTL (Right-to-Left) 言語に対応する場合、文字数の問題に加えてレイアウトの反転が必要になります。
- CSS の
direction: rtlとunicode-bidiプロパティを適切に設定する - Flexbox の
flex-directionはdirectionプロパティに自動追従するため、明示的な反転は不要 - マージンやパディングの左右を論理プロパティ (
margin-inline-start、padding-inline-end) で指定する - アイコンの向き (矢印、進む/戻るなど) も反転が必要。ただし、ロゴや数字は反転しない
- RTL 言語と LTR 言語が混在するテキスト (双方向テキスト) では、
<bdi>タグで方向を分離する
RTL 対応は文字数設計と密接に関連します。アラビア語は接続形 (文字が前後の文字と繋がって形が変わる) を持つため、同じ文字数でも表示幅が文脈によって変動します。固定幅のレイアウトは RTL 言語で特に破綻しやすいため、フレキシブルなレイアウト設計が不可欠です。
メタデータの多言語文字数管理
UI テキストだけでなく、メタディスクリプションや OGP タグなどのメタデータも多言語対応が必要です。
| メタデータ | 日本語の推奨文字数 | 英語の推奨文字数 | 備考 |
|---|---|---|---|
| title タグ | 30〜35 文字 | 50〜60 文字 | ピクセル幅ベースで約 580px |
| meta description | 80〜120 文字 | 150〜160 文字 | モバイルでは短く表示される |
| og:title | 30〜40 文字 | 40〜60 文字 | SNS プラットフォームにより異なる |
| og:description | 60〜80 文字 | 100〜120 文字 | リンクプレビューで表示される長さはプラットフォームにより異なる |
重要なのは、各言語版のメタデータを機械的に翻訳するのではなく、言語ごとの文字数制限に合わせて最適化することです。日本語の title が 35 文字で完璧に収まっていても、英語に直訳すると 70 文字になり、検索結果で途中切れになる可能性があります。翻訳ではなく「各言語での再作成」という意識が必要です。
テスト戦略 - 擬似ロケール (Pseudo-Locale) の活用
すべての言語の翻訳が完了する前に、テキスト膨張によるレイアウト崩れを検出する方法として「擬似ロケール」があります。
擬似ロケールとは、原文のテキストを人工的に膨張させたテスト用の言語データです。たとえば、"Submit" を "[Šüƀɱîţ !!!]" のように変換し、文字数を 1.5〜2 倍に膨張させます。これにより、翻訳を待たずにレイアウトの耐性をテストできます。
擬似ロケールの生成ルール:
- 各文字をアクセント付き文字に置換する (a → ä、e → ë など)
- テキストの前後に括弧やマーカーを追加する ([...] など)
- テキスト長を 1.5〜2.0 倍に膨張させるパディング文字を追加する
- 原文が判読可能な状態を維持する (デバッグ時にどのキーか特定できるように)
主要な i18n ライブラリ (react-intl、vue-i18n、next-intl など) は擬似ロケールの生成機能を備えているか、プラグインで対応できます。CI/CD パイプラインに擬似ロケールでのビジュアルリグレッションテストを組み込むと、翻訳追加時のレイアウト崩れを自動検出できます。
文字数の膨張を抑える翻訳テクニック
翻訳者と協力して、テキストの膨張を最小限に抑えるテクニックを紹介します。
- 省略形の積極的活用: "information" → "info"、"configuration" → "config" のように、UI テキストでは省略形を許容する
- 動詞の命令形を使う: "Click here to submit the form" → "Submit" のように、ボタンテキストは動詞 1 語に凝縮する
- 冠詞の省略: UI テキストでは "the"、"a"、"an" を省略しても自然な場合が多い
- 文化的適応 (ローカライゼーション): 直訳ではなく、ターゲット言語で自然かつ簡潔な表現に意訳する
- アイコンとの併用: テキストの一部をアイコンに置き換えることで、文字数を削減しつつ意味を伝える
まとめ
多言語サイトの文字数設計は、翻訳後のテキスト膨張を前提としたフレキシブルな UI 設計が鍵です。日本語のようにコンパクトな言語を起点にすると欧州言語では大きな膨張を見込む必要があり、W3C や IBM のガイドラインでも短い文字列ほど膨張率が高くなると示されています。CSS の論理プロパティ、Flexbox による柔軟なレイアウト、擬似ロケールによる事前テスト、i18n ファイルへの文字数制約の明記を組み合わせることで、どの言語でも美しく機能する UI を実現できます。翻訳テキストの文字数確認には文字数カウントスをご活用ください。