第25章: ローカライゼーション

私たちはサーバーをユーザーの近くに配置してレイテンシーを削減します。しかしレイテンシーはミリ秒だけで測られるものではありません——理解のレイテンシーでもあります。読者がすべての文を外国語から頭の中で翻訳しなければならない場合、理解の「ラウンドトリップタイム」は爆発的に増加します。ローカライゼーションとは、システムを特定の言語、地域、文化的慣習に適応させる実践です。データをユーザーの近くにレプリケートするのと同じように（第24章: Geoレプリケーションを参照）、コンテンツをユーザーの母国語でレプリケートして理解を近づけます。

ロケール検出

ローカライズされたシステムが最初に答えなければならない質問は：このユーザーはどの言語を望んでいるか？です。私たちは優先順位で複数のシグナルをチェックする検出チェーンを使用します：

fn detect_lang(path: &str, headers: &str) -> (Lang, &str) {
    // 1. URL prefix: /ja/chapter/systems → Lang::Ja
    if path.starts_with("/ja/") {
        return (Lang::Ja, &path[3..]);
    }
    if path == "/ja" {
        return (Lang::Ja, "/");
    }

    // 2. For the landing page only: cookie, then Accept-Language
    if path == "/" {
        if let Some(lang) = parse_cookie(headers, "lang") {
            if lang == "ja" {
                return (Lang::Ja, path);
            }
        }
        let lang = parse_accept_language(headers);
        return (lang, path);
    }

    // 3. All other paths: no /ja/ prefix means English
    (Lang::En, path)
}

チェーンは原則に従います：URLが真実の情報源である。/ja/プレフィックスは明示的な選択です——ユーザーが特定の言語のリンクをクリックしました。/chapter/systemsのようなプレフィックスのないパスでは、クッキーやブラウザ設定に関係なく、言語は常に英語です。これにより言語スイッチャーが確実に動作します：日本語ページで「English」をクリックすると、必ず英語ページが表示されます。

唯一の例外はランディングページ（/）で、コンテンツパスによる区別ができません。ここではlangクッキー（以前の明示的な言語選択により設定）を確認し、ブラウザのAccept-Languageヘッダーにフォールバックします。

コンテンツモジュール構造

各言語には英語のオリジナルをミラーリングする独自のコンテンツモジュールがあります。英語コンテンツはcontent.rsに、日本語翻訳はcontent_ja.rsにあります。両方のモジュールは同一の関数シグネチャを公開します。ディスパッチ関数が検出された言語に基づいて正しいモジュールにルーティングします。

翻訳はインフラストラクチャ

よくある間違いは翻訳を後付けとして扱うことです——システム全体を1つの言語で構築し、後から翻訳を付け足そうとすること。より良いアプローチは、ローカライゼーションパイプラインを先に構築することです：

1. Lang列挙型と検出チェーンを設計する。

2. コンテンツディスパッチ関数と並列モジュール構造を構築する。

3. 言語スイッチャーとhreflangタグを追加する。

4. その後で翻訳を生産する。

こうすることで、翻訳が始まる前にインフラストラクチャがテストされ動作しています。翻訳が到着すると、既存のモジュールにスロットインし、追加のコード変更なしで即座に機能します。