国際化(i18n)とは、製品を再設計することなく、あらゆる言語や地域に適応できるようにコードで行う作業です。W3Cでは、これを“文化、地域、言語が異なる対象ユーザーにとって簡単なローカリゼーションを可能にする製品、アプリケーション、またはドキュメントコンテンツの設計と開発”と定義していますW3C)。実際には、これはどこでも Unicode を意味し、ハードコードされたユーザー向けの文字列、日付、数字、複数形のロケールを考慮した書式設定、長いテキストや右から左へのスクリプトに耐えるレイアウトはありません。
主なポイント
- i18n はエンジニアリングです。ローカリゼーション(l10n)は、i18n によって可能になる 1 つの市場への適応です。“18” と “10” は、各単語の最初と最後の文字の間の文字を数えます。
- ほとんどの i18n バグを防ぐ 5 つの習慣: UTF-8 エンドツーエンド、外部化された文字列、ICU スタイルの複数形および変数処理、プラットフォームのロケール フォーマット API、および柔軟なレイアウト。
- フラグメントを連結して文を構築しないでください。言語によって語順や複数形のルールが大きく異なります。
- 翻訳者が文字列を確認する前に、疑似ローカリゼーションを使用してテストします。
- すでに稼働しており、i18n 用に構築されていない Web サイトでも、コードベースをリファクタリングすることなく、レンダリング層で多言語化できます。
i18n、l10n、g11n: 違い
| 期間 | の略 | 意味するもの |
|---|---|---|
| i18n | 国際化 | 製品を構築して できる 任意のロケールをサポートします |
| l10n | ローカリゼーション | 適応させるため 一つの ロケール: 翻訳、形式、画像、法的テキスト |
| g11n | グローバリゼーション | 両方を組み合わせて新しい市場に参入するビジネス プロセス |
W3Cには、国際化に通常含まれるものがリストされています:ローカリゼーションの障壁の除去(Unicodeと文字エンコード)、双方向テキストなどの機能のサポート、日付、カレンダー、数字、名前のローカル規約のサポート、および“ローカリゼーション可能な要素をソースコードから分離”各ユーザーに適したバージョンが読み込まれるようにするW3C).
I18n 作業が完了したかどうかの簡単なテストは次のとおりです。新しい言語を追加するには、翻訳者と何らかの構成が必要です。開発者が必要なら、何かを見逃した。
1。Unicode(UTF-8) を端から端まで使用します
UTF-8はWebのデフォルトであり、文字エンコードが既知のWebサイトの99。1%で使用されています(W3Techs、2026年9月28日)。最近では、HTML に間違いがほとんどありません。それらは周囲の層で発生します:
- 完全な UTF-8 に設定されていないデータベースの列と接続。MySQLでは、
utf8は3 バイトのサブセット; 使用するutf8mb4または絵文字と一部の CJK 文字が失われます。 - 文字列の文字数ではなくバイト数を数えるため、「Zürich」や「東京」が文字の途中で切り捨てられることがあります。
- スプレッドシート ソフトウェアで間違ったエンコードで開かれた CSV エクスポート。
- ロケール照合の代わりにバイト順序で並べ替えます。これにより、“Zebra” の後に “Äpfel” が置かれます。
エンコーディングを一度宣言する(<meta charset="utf-8">)、すべての接続に設定し、次のようなロケール認識の比較を使用します Intl.Collator JavaScript で。
2。ユーザー向けの文字列をすべて外部化する
ユーザーが参照する文字列は、識別子でキー付けされたリソース ファイルに属します。テンプレートやコードからそれらを遠ざけてください:
{
"cart.title": "Your cart",
"cart.empty": "Your cart is empty",
"cart.checkout": "Go to checkout"
}各ロケールは独自のファイルを取得し、コードは要求します cart.title。フレームワークは同じパターンに従います。Vue では、vue-i18n ライブラリが公開します $t for “ロケールメッセージの翻訳” および $i18n ロケールやメッセージを管理するグローバルインスタンスの場合(vue-i18n ドキュメント)。React(react-intl, i18next), Angular (@angular/localize)、Django、Rails、Laravel はすべて同等のものを出荷します。
後で痛みを救ういくつかのルール:
- 翻訳者にコンテキストを与えます。“Open” は動詞(ファイルを開く)または形容詞(ストアが開いている)になります。各キーに説明を追加します。
- 英語のテキストが一致するという理由だけでキーを再利用しないでください。“ボタンの保存”とバナーの保存 “20%” は、ほとんどの言語で異なるメッセージです。
- 翻訳者が HTML を壊さないように、マークアップを可能な文字列から遠ざけたり、プレースホルダーを使用したりしてください。
3。文を連結しないでください; プレースホルダーと複数のルールを使用します
これは無害に見えます:
'You have ' + count + ' new messages';2 つの方法で壊れます。言語間の語順の変更や複数形のルールは “1 対その他すべて” ではありません。Unicode CLDRの複数形ルールでは、英語に2つの基本カテゴリ(1、その他)、日本語に1、ロシア語とポーランド語に4つ(1、少数、多数、その他)、アラビア語に6つ(0、1、2、少数、多数、その他)が与えられます(ユニコード CLDR).
ICU MessageFormat など、それらのルールを知っているメッセージ形式を使用します
{count, plural,
=0 {You have no new messages}
one {You have # new message}
other {You have # new messages}}その後、ロシア語の翻訳者が を追加できます few そして many コードを変更せずにフォームを作成します。性別、序数 (“1、2”)、リスト (“A、B、C”) にも同じことが当てはまります。
4。プラットフォームに日付、数字、通貨をフォーマットさせます
03/04/2026 米国では3月4日、ヨーロッパのほとんどの地域では4月3日です。 1,234.5 英語で書かれています 1.234,5 ドイツ語と 1 234,5 フランス語で。独自の書式設定を書かないでください。最新のプラットフォームにはすべてロケール データが組み込まれており、JavaScript にはロケール データが組み込まれています Intl API (MDN):
new Intl.NumberFormat('de-DE', { style: 'currency', currency: 'EUR' }).format(1234.5);
// "1.234,50 €"
new Intl.DateTimeFormat('fr-FR', { dateStyle: 'long' }).format(new Date('2026-09-27'));
// "27 septembre 2026"関連するいくつかの決定は早期に下す価値があります:
- UTC に時間を保存し、ユーザーのタイムゾーンに変換して表示します。
- 通貨をロケールから分離しておきます。カナダを訪れるフランス語を話す訪問者は、ユーロではなくカナダドルで支払います。数値を通貨としてフォーマットすることは i18n です。価格を決定することはビジネス上の決定です。
- 名前や住所がどのように形成されるかを想定しないでください。多くの人は西洋的な意味での “名” と “姓” を持たず、郵便番号は必ずしも数字であるとは限りません。
5。伸縮性のあるデザインレイアウト
翻訳されたテキストは英語よりも長いことが多く、短い文字列が最も成長します。W3CはIBMのガイドラインの数字を要約しています。ヨーロッパの言語では最大10文字の文字列が200%から300%増加する可能性がありますが、70文字を超えるテキストは約130%に増加します(W3C、翻訳時のテキストサイズ)。彼らの例は、イタリア語で “views” を “visualizzazioni” に変換することです。
UI作業の場合、それは次のことを意味します:
- 英語のラベルに適したサイズの固定幅のボタンやタブはありません。
- 画像にテキストが焼き付けられていません。画像を描き直さなければ翻訳できません。
- 右から左への文字(アラビア語、ヘブライ語、ペルシア語、ウルドゥー語)をサポートします
dir="rtl"オン ザ<html>要素とCSSの論理プロパティ(margin-inline-startの代わりにmargin-left)なので、レイアウトはそれ自体をミラーリングします。 - サポートする予定のスクリプトをカバーするフォントを選択するか、フォールバックを定義します。
6。ロケール検出とURLを意図的に処理する
ユーザーのロケールの選択方法と記憶方法を決定します
- 明示的な選択(言語スイッチャー)が常に勝ちます。
- それ以外の場合は、ブラウザを使用します
Accept-Languageヘッダーは強制的なリダイレクトではなく、提案として提供されます。 - URLにロケールを入力します(
/de/,de.example.com) は任意の公開ページ用であるため、各言語バージョンを検索エンジンで共有、キャッシュ、インデックス化できます。Cookie だけでも、翻訳されたページは Google に表示されません。
製品に公開ページがある場合、それらの言語URLにはhreflang注釈も必要です フレフランガイド.
7。擬似ローカリゼーションでテストします
疑似ローカリゼーションは、実際の翻訳が存在する前に、ソース文字列を変更されたバージョンに置き換えます [Ýöûŕ çåŕţ îš éɱþţý !!!!]。アクセントはエンコーディングの問題をキャッチし、パディングは長いテキストの下で途切れるレイアウトをキャッチし、括弧は切り捨てと変更されなかったハードコードされた文字列を明らかにします。多くの i18n ライブラリとビルド ツールは疑似ロケールを生成できます。リリースごとに UI テスト スイートをそれに対して実行します。
これらもチェックリストに追加してください:
- RTL ロケールに切り替えて、ナビゲーション、方向(矢印、プログレス バー)を含むアイコン、およびフォームの位置合わせを確認します。
- アクセント付き文字を使用して並べ替えと検索をテストします。
- 忘れられがちなメール、PDF、エラーメッセージ、プッシュ通知を確認してください。
新規プロジェクトのためのi18nチェックリスト
- UTF-8 (
utf8mb4MySQL)のファイル、データベース、接続、API - リソース ファイル内のすべてのユーザー向け文字列。翻訳者向けのコンテキストが含まれます
- 複数形、性別、変数の ICU メッセージフォーマット(または同等)
Intlまたは、日付、数字、通貨、リスト、並べ替えのためのプラットフォームのロケール API- UTC ストレージとユーザーごとのタイムゾーン表示
- 柔軟なレイアウト、CSS論理プロパティ、
dir属性サポート - 公開ページの URL、検索エンジンの場合は hreflang のロケール
- CI における擬似局在化
ウェブサイトが既に存在する場合
上記のすべては、構築しているアプリケーションに適用されます。すでに稼働しているマーケティング サイト、ストア、または CMS の場合、これは大規模なリファクタリングを意味し、コンテンツを所有するチームは通常、コードを所有するチームではありません。
その場合、翻訳はレンダリング層で行うことができます。ConveyThis サイトがすでに出力しているテキストを読み取り、210言語のいずれかに翻訳し、各言語を独自のURL(ビジネスプラン以上のサブフォルダまたはサブドメイン、または ?lang hreflang が自動的に追加されたパラメータ)。右から左への言語ではテキストの方向が切り替わり、言語ごとに画像を置き換えることができます 用語集と翻訳メモリ 製品名と用語の一貫性を保ちます。としてインストールされます WordPressプラグイン、 Shopify アプリまたは他のスタック上の単一のスクリプトなので、コードベース内の i18n 作業を独自のスケジュールで継続できます。コンテンツを各市場に適応させるビジネス面については、ガイドをお読みください コンテンツのローカリゼーションには何が含まれますか.
よくある質問
国際化はなぜ i18n と略されるのでしょうか? “国際化”の最初の “i” と最後の “n” の間には 18 文字があります。ローカリゼーション(l10n)も同じパターンに従います。
I18nは翻訳と同じですか? いいえ。翻訳はローカリゼーションの一部です。i18n は、コードを変更せずに翻訳やその他のローカル適応を可能にするエンジニアリングです。
プロジェクトはいつ開始すればよいですか i18n? スタート時。文字列を外部化してロケール API を使用すると、初日はほとんどコストがかからず、成熟したコードベースに後付けすると多くのコストがかかります。
何だ $i18n Vueで? Vue-i18nでは、 $i18n ロケールやメッセージを管理するグローバルインスタンスであり、 $t キー(の翻訳されたメッセージを返す関数ですvue-i18n).
次のステップ
コードベースが完全に国際化されるまでに複数の言語でライブ Web サイトが必要な場合は、 ConveyThis アカウントを作成します そして、あなたの最初の言語を公開してから比較してください 計画 さらに追加すると。