多言語サイトの文字数設計 - 翻訳で文章が膨らむ問題への対処法

約 8 分で読めます

Web サイトを多言語展開する際、最も見落とされがちな問題が「テキストの膨張」です。日本語で完璧にデザインした UI が、英語に翻訳した途端にレイアウトが崩壊する。ドイツ語版ではボタンのテキストがはみ出し、アラビア語版では右から左への表示で余白が破綻する。本記事では、翻訳による文字数の変動を定量的に分析し、多言語サイトの UI 設計で採用すべき具体的な対処法を解説します。

言語間のテキスト膨張率 - 日本語を基準とした比較

同じ意味の文章でも、言語によって必要な文字数は大きく異なります。日本語は漢字の表意性により情報密度が高く、他の多くの言語に翻訳すると文字数が増加します。

翻訳先言語膨張率 (日本語比)例: 日本語 10 文字の場合主な要因
英語1.5〜2.0 倍15〜20 文字スペース区切り、冠詞の追加
ドイツ語1.8〜2.5 倍18〜25 文字複合語の長さ、格変化
フランス語1.6〜2.2 倍16〜22 文字冠詞、前置詞の多用
スペイン語1.5〜2.0 倍15〜20 文字動詞活用の長さ
韓国語1.1〜1.5 倍11〜15 文字助詞の明示、スペース区切り
中国語 (簡体字)0.8〜1.1 倍8〜11 文字漢字の共通性
タイ語1.3〜1.8 倍13〜18 文字スペースなし連続表記
アラビア語1.2〜1.7 倍12〜17 文字右から左の表記、接続形

特に注意が必要なのはドイツ語です。ドイツ語は複合名詞を 1 単語として表記する特性があり、"Geschwindigkeitsbegrenzung" (速度制限、25 文字) のような長大な単語が頻出します。ボタンやナビゲーションのラベルでこの膨張を想定していないと、レイアウトが確実に破綻します。

UI 要素別の文字数設計戦略

多言語対応の文字数設計は、UI 要素の種類によってアプローチが異なります。

ボタン・CTA

ボタンのテキストは最も膨張の影響を受けやすい要素です。日本語の「送信」(2 文字) は英語で "Submit" (6 文字)、ドイツ語で "Absenden" (8 文字) になります。

ナビゲーション・メニュー

ヘッダーナビゲーションは水平方向のスペースが限られるため、膨張の影響が顕著です。

フォームラベル・プレースホルダー

フォームのラベルとプレースホルダーは、入力フィールドの幅との関係で文字数制約が生じます。

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 ファイルで管理するのが一般的です。文字数の膨張を管理するために、以下のプラクティスを推奨します。

ピクセル幅ベースの文字数制限

文字数による制限は、フォントやレンダリングエンジンによって実際の表示幅が異なるため、厳密な制御には不向きです。より正確な制御が必要な場合は、ピクセル幅ベースの制限を採用します。

同じ 10 文字でも、言語とフォントによって表示幅は大きく異なります。

テキスト文字数表示幅 (16px, sans-serif)
文字数カウント (日本語)7 文字約 112px
Character Count (英語)15 文字約 130px
Zeichenzählung (ドイツ語)14 文字約 125px
Подсчёт символов (ロシア語)16 文字約 145px

日本語は 1 文字あたりの幅が広い (全角文字) ため、文字数が少なくても表示幅は大きくなります。逆に英語は文字数が多くても、各文字の幅が狭いため表示幅の増加は緩やかです。SEO における文字数でも、Google の検索結果表示はピクセル幅ベースで切り詰められるため、同様の考慮が必要です。

RTL (右から左) 言語への対応

アラビア語やヘブライ語などの RTL (Right-to-Left) 言語に対応する場合、文字数の問題に加えてレイアウトの反転が必要になります。

RTL 対応は文字数設計と密接に関連します。アラビア語は接続形 (文字が前後の文字と繋がって形が変わる) を持つため、同じ文字数でも表示幅が文脈によって変動します。固定幅のレイアウトは RTL 言語で特に破綻しやすいため、フレキシブルなレイアウト設計が不可欠です。

メタデータの多言語文字数管理

UI テキストだけでなく、メタディスクリプションや OGP タグなどのメタデータも多言語対応が必要です。

メタデータ日本語の推奨文字数英語の推奨文字数備考
title タグ30〜35 文字50〜60 文字ピクセル幅ベースで約 600px
meta description80〜120 文字150〜160 文字モバイルでは短く表示される
og:title30〜40 文字40〜60 文字SNS プラットフォームにより異なる
og:description60〜80 文字100〜120 文字Facebook は約 300 文字まで表示

重要なのは、各言語版のメタデータを機械的に翻訳するのではなく、言語ごとの文字数制限に合わせて最適化することです。日本語の title が 35 文字で完璧に収まっていても、英語に直訳すると 70 文字になり、検索結果で途中切れになる可能性があります。翻訳ではなく「各言語での再作成」という意識が必要です。

テスト戦略 - 擬似ロケール (Pseudo-Locale) の活用

すべての言語の翻訳が完了する前に、テキスト膨張によるレイアウト崩れを検出する方法として「擬似ロケール」があります。

擬似ロケールとは、原文のテキストを人工的に膨張させたテスト用の言語データです。たとえば、"Submit" を "[Šüƀɱîţ !!!]" のように変換し、文字数を 1.5〜2 倍に膨張させます。これにより、翻訳を待たずにレイアウトの耐性をテストできます。

擬似ロケールの生成ルール:

主要な i18n ライブラリ (react-intl、vue-i18n、next-intl など) は擬似ロケールの生成機能を備えているか、プラグインで対応できます。CI/CD パイプラインに擬似ロケールでのビジュアルリグレッションテストを組み込むと、翻訳追加時のレイアウト崩れを自動検出できます。

文字数の膨張を抑える翻訳テクニック

翻訳者と協力して、テキストの膨張を最小限に抑えるテクニックを紹介します。

まとめ

多言語サイトの文字数設計は、翻訳後のテキスト膨張を前提としたフレキシブルな UI 設計が鍵です。日本語を基準にすると、英語で 1.5〜2 倍、ドイツ語で 1.8〜2.5 倍の膨張を見込む必要があります。CSS の論理プロパティ、Flexbox による柔軟なレイアウト、擬似ロケールによる事前テスト、i18n ファイルへの文字数制約の明記を組み合わせることで、どの言語でも美しく機能する UI を実現できます。翻訳テキストの文字数確認には文字数カウントスをご活用ください。

API レスポンスの文字数設計ガイド

REST API のレスポンスサイズやフィールド長の設計指針を解説。ペイロードの最適化、エラーメッセージの文字数設計、主要フィールドの推奨文字数一覧など、API 設計に役立つ実践的な情報をまとめました。