10件のよくある i18n のミスと回避方法

開発者がJSX内にボタンのラベルを直接書きます: <button>Submit Order</button>.

アプリは英語で提供され、問題なく動作します。6か月後、企業はドイツへ拡張します。

ローカライゼーションチームは2,000件以上のハードコードされた文字列を発見します。後付けの作業には3週間かかり、47個のバグを引き起こします。

最初のコンポーネントを記述する前に i18n フレームワークを設定します（例: next-intl、react-i18next、vue-i18n）。

リソースファイル構造を作成（例: messages/de.json）し、t('checkout.submitButton') のような翻訳キーを通じてすべての文字列を参照します。

UI コンポーネント内の生の文字列を検出するリンティング規則やプリコミットフックを追加します。

翻訳ファイルには企業名『CloudForge Inc.』と技術用語『OAuth 2.0 Token』が通常の翻訳可能な文字列として含まれています。

スペイン語の翻訳者は「CloudForge」を「ForjaNube」に、「OAuth 2.0 Token」を「ficha OAuth 2.0」に翻訳してしまう。

結果: ユーザーは企業を実名で見つけられず、スペイン語のドキュメンテーションを読む開発者は、未知の翻訳済み用語に混乱します。

変更せずそのままにしておくべきすべてのブランド名、製品名、法人名、専門用語を列挙した「翻訳不可」用語集を作成してください。

翻訳不可の内容には、別のネームスペースや特別なキーを使用してください。多くの i18n ツールは、翻訳者が編集できない「ロックされた」セグメントをサポートしています。

翻訳ファイルに文脈を説明する翻訳者向けのコメント/説明を追加してください: 「これはブランド名です — 翻訳しないでください」または「専門用語 — 英語のままにする」。

開発者は書く: 'You have ' + count + ' items in your ' + cartType + ' cart' — 英語では完璧に機能します。

ドイツ語の翻訳者は3つの別々の断片を受け取り、語順を変える必要があるため、文法的に正しい文を作成できません。

結果: ドイツのユーザーは 'Sie haben 5 Artikel in Ihrem Warenkorb Standard' を見てしまい、ぎこちなく専門的でない。

連結を避け、プレースホルダー付きの単一メッセージキーに置き換え： 'cart.summary': 'あなたの'{cartType}'カートには{count}アイテムがあります。'

変数を翻訳関数のパラメータとして渡す: t('cart.summary', { count: 5, cartType: 'Premium' }).

翻訳者は自由に並べ替え可能： 'あなたの'{cartType}'カートには{count}アイテムがあります' — 正しいドイツ語。

開発者は書く: count + (count === 1 ? 'Datei' : 'Dateien') — ドイツ語を正しく扱います。

ポーランド語の翻訳者は4つの形を必要とします: 1 plik, 2-4 pliki, 5-21 plików, 22-24 pliki. 単純な三項演算子では表現できません。

結果: ポーランド語のユーザーは '5 pliki'（誤った形）を見て、正しくは '5 plików' となる。アプリは壊れているように見える。

ICU構文でメッセージを定義します: 'fileCount': '{count, plural, one {# Datei} other {# Dateien}}'.

翻訳者は各言語に必要な複数形をすべて提供します。ポーランド語: '{count, plural, one {# plik} few {# pliki} many {# plików} other {# pliku}}'.

アクティブなロケールの CLDR ルールに基づいて、実行時に自動的に正しい形を選択します。

デザイナーは5つのボタンからなるナビゲーションバーを作成し、それぞれ幅を正確に100pxに設定します。英語版では見栄えが良いです。

ドイツ語の翻訳: 'Settings' は 'Einstellungen' (13 対 8 文字)、'Submit' は 'Absenden' (8 対 6) となる。ナビバーがはみ出します。

結果: モバイルデバイスではボタンが互いに重ね合わせられるか、テキストが切れてしまい、ドイツ語話者にとってのナビゲーションが使い物にならなくなります。

固定幅を min-width、max-width、Flex レイアウトに置き換えます。CSS Grid または Flexbox を使ってスペースを動的に分配してください。

テキストコンテナを改 行可能に設定します: overflow-wrap: break-word を使用し、翻訳可能なコンテンツには white-space: nowrap を避けてください。

すべての文字列を40%長くする疑似ローカリゼーションでUIをテストし、Worst Caseをシミュレートします — 翻訳者に文字列を送る前に。

開発者は日付を MM/DD/YYYY、価格を $1,234.50 の形式でフォーマットします — 米国のユーザーにとって正しいです。

ドイツのユーザーは日付を 03/04/2025 と見て、3月4日として解釈します（DD/MM/YYYY の慣例）。価格 $1,234.50 は 1.234,50 と表示されるべきです。

結果: ユーザーは誤った日付のフライトを予約し、料金表示の形式を疑問視します。ドイツ市場ではサポートチケットが15%増加します。

データの日付には Intl.DateTimeFormat(locale) を、価格には Intl.NumberFormat(locale, { style: 'currency', currency }) を使用して、手動のフォーマットを置換してください。

内部的には ISO 8601 形式 (YYYY-MM-DD) でデータを保存し、表示時にのみユーザーのロケールでフォーマットしてください。

重要な日付/数値表示を、少なくとも5つの異なるロケール（en-US、de-DE、ja-JP、ar-SA、zh-CN）でテストし、最も重要な形式のバリエーションをカバーします。

開発者はアプリ全体で margin-left: 16px および text-align: left を使用しています — 標準的な LTR の実践です。

アプリはサウジアラビアで起動します。戻るボタンは前方を指し、サイドバーは間違った側に表示され、数値データは整列していません。

結果: アラビア語ユーザーはアプリを30秒で離脱します。問題を解決するために、チームは4週間の緊急CSSリファクタリングを必要とします。

すべての物理的な CSS プロパティを論理的な同等物に置き換えます: margin-left → margin-inline-start, padding-right → padding-inline-end, text-align: left → text-align: start.

アクティブなロケールに基づいて HTML ルート要素に dir 属性を設定します。RTL 固有のオーバーライドには CSS の :dir(rtl) 擬似クラスを使用してください。

方向性を示すすべてのアイコンを確認します。方向依存のアイコンを鏡像版に置き換えるか、RTL コンテキストには CSS transform: scaleX(-1) を使用してください。

デザイナーが 'Start Your Free Trial' のテキストを画像自体に直接埋め込んだプロモーション用バナーを作成します。

ローカライズチームはすべてのUI文字列を翻訳しますが、ドイツ語のページのバナーにはまだ英語のテキストが表示されています。

結果: ドイツ語のランディングページには混乱を招く英語のバナーがあります。15言語分のローカライズされたバナーを作成するには3日間のデザイン作業が必要で、ローンチを遅らせます。

翻訳可能なテキストを背景画像の上に置くためにCSSを使用します：テキストレイヤーを画像コンテナの上に絶対配置します。

インフォグラフィックやダイアグラムには、翻訳キーを参照する <text> 要素を持つ SVG を使用し、未加工の文字列を埋め込まないでください。

マーケティング資料のアプリスクリーンショットには、Fastlane（モバイル）やPlaywright（Web）などのツールを使って各ロケールのスクリーンショットを取得するように自動化します。

開発者は 'Premium Features' の新しいセクションを 15 個の新しい翻訳キーとともに追加します。英語版がすぐに提供されます。

フランス語の翻訳はまだ完成していません。フランス語のページには未加工のキーが表示されます： 'premium.feature1.title'、 'premium.feature1.description'。

結果: フランス語の利用者は開発者側のキー名が並ぶ壊れたページを見ています。サポートチームには数十件のバグ報告が寄せられます。

i18n 設定にフォールバック言語チェーンを設定します。欠落しているフランス語（fr）キーは自動的に英語（en）にフォールバックします。

未翻訳のキーを監視システム（例：Sentry、Datadog）にログする Missing-Key ハンドラを追加し、ユーザー体験を崩さずに対応します。

ローカルごとの翻訳カバレッジを追跡し、カバレッジが閾値（例: 95%）を下回った場合にリリースをブロックする翻訳カバレッジダッシュボードを作成します。

開発者は、従来の標準である latin1 コレーションを使用した MySQL データベースを設定します。アプリのソースコードは UTF-8 を使用します。

日本のユーザーは本名で登録します。データベースは '田中太郎' を損傷したバイトとして保存します。

結果: ユーザーのプロフィールには壊れたテキストが表示されます。さらに悪いことに、すべてのCJK名の検索とソートが壊れて、数千人のユーザーに影響します。

すべてのソースファイルをUTF-8に設定します（エディタと .editorconfigを設定）。HTMLに <meta charset='UTF-8'> を追加し、APIの応答には 'Content-Type: application/json; charset=utf-8' を含めます。

データベースを utf8mb4 に設定します（MySQL で utf8 は 3 バイトのサブセットです）。接続の照合順序を utf8mb4_unicode_ci に設定します。

ターゲット文字体系をカバーするフォントを選択します：ラテン文字、キリル文字、CJK、アラビア語、デーヴァナーガリー。最適な読み込みのためにシステムフォントスタックまたは言語サブセットを備えた Google Fonts を使用します。