i18nextによる日本語・ベトナム語二言語サイトの設計

ライブラリはi18next + react-i18nextを採用しています。構成上の要点は、言語判定をどこで行うかです。選択肢は、URLパス、サブドメイン、クッキー・ローカルストレージ、ブラウザのAccept-Languageの4つです。

私たちはログイン後のLMS領域ではDBに保存されたユーザー設定を正とし、公開ページではブラウザ設定からの初期推定＋手動切り替えとしています。URLパスに言語を含める方式はSEOには有利ですが、認証必須領域では意味がなく、URLの複雑さが増すだけです。

翻訳リソースはJSONファイルで管理し、名前空間を「画面単位」ではなく「機能単位」で切ります。画面単位で切ると、同じ文言が複数ファイルに重複し、修正漏れの温床になります。

多言語対応の技術的な難しさの8割は、実装ではなく翻訳リソースの運用にあります。

キーの命名は、文言そのものではなく意味で付けます。文言ベースのキーは、同じ文言が文脈によって別の訳になる場合に破綻します。日本語の「確認」は、文脈によってベトナム語では「Xác nhận」にも「Kiểm tra」にもなります。

未翻訳の検出は、CIで機械的に行います。日本語JSONとベトナム語JSONのキー差分を検出するスクリプトを用意し、差分があればCIを落とします。i18nextのフォールバック機能に頼ると未翻訳が静かに蓄積します。「フォールバックは事故対策、CIが正規の検出手段」と役割を分けます。

翻訳の質については、機械翻訳をそのまま使わないことに尽きます。AIによる下訳＋ベトナム語ネイティブによるレビューの体制です。技能実習・特定技能の制度用語には定訳が存在するため、用語集を先に整備し、下訳の段階からAIに参照させることで、レビューの負荷を大幅に下げられます。

ベトナム語はラテン文字ベースですが、声調記号付きの文字を多用します。ここに2つの落とし穴があります。

第一に、フォントのグリフ不足です。日本語向けに選んだフォントはベトナム語の合成文字を完全にはカバーしていない場合があり、1つの単語の中で文字の太さや高さが混ざる「まだら表示」が起きます。対策はフォントスタックの明示です。html要素のlang属性を言語切り替えと連動させ、CSSの:lang()セレクタで言語ごとにfont-familyを切り替えます。

第二に、行の高さです。ベトナム語の声調記号は文字の上下に付くため、日本語向けに詰めたline-heightでは記号が前の行と接触することがあります。日本語で1.5、ベトナム語では1.6〜1.7を目安に、言語別に調整しています。

日本語の「保存」はベトナム語で「Lưu lại」、「受講履歴」は「Lịch sử học tập」。経験則として、ベトナム語は日本語の1.5〜2.5倍の幅を要求します。日本語だけで画面を設計すると必ずレイアウト崩れを起こします。

対策は設計段階のルール化です。ボタンやタブのラベル領域は固定幅にせず、min-widthとpaddingで組む。ナビゲーションの項目数はベトナム語での幅を基準に決める。そしてPlaywrightのスクリーンショットテストを両言語で撮り、視覚的な崩れをCIで検出する。人間は自分が読めない言語の画面を注意深く見ないため、ベトナム語画面の崩れは機械に見張らせるのが確実です。

日越二言語対応の主要な確認項目をまとめます。画面の多言語化だけ進めて、メールが日本語のまま、は頻出の漏れです。

翻訳を外部委託する場合は、JSONではなくキー・日本語・文脈説明・用語集の4点セットをスプレッドシートで渡し、納品後にスクリプトでJSONへ変換する方が安全です。

第三言語の追加を見据えるなら、語順に依存した文字列連結を避け、i18nextの補間とプレースホルダを使い切ることです。「日本語とベトナム語でたまたま動く」実装は、SVO言語の追加で壊れます。運用の仕組みを最初に作った者だけが、破綻せずに言語を増やしていけます。