コンパイラー型i18nの賛否

もし10年以上ウェブアプリケーションを開発してきたなら、国際化（i18n）が常に摩擦点であったことをご存知でしょう。文字列の抽出、JSONファイルの管理、複数形ルールの扱いなど、誰もやりたがらない作業であることが多いのです。

最近、「コンパイラー型」i18nツールの新しい波が登場し、この苦痛を解消すると約束しています。魅力的な提案はこうです：コンポーネント内にテキストを書くだけで、ビルドツールが残りを処理してくれる。 キーもインポートも不要、ただのマジックです。

しかし、ソフトウェア工学におけるすべての抽象化と同様に、マジックには代償が伴います。

このブログ記事では、宣言型ライブラリからコンパイラー型アプローチへの移行、彼らがもたらす隠れたアーキテクチャ的負債、そしてなぜ「退屈な」方法がプロフェッショナルなアプリケーションにとって依然として最良の方法であるかを探ります。

翻訳の簡単な歴史

今の状況を理解するためには、出発点を振り返る必要があります。

2011年から2012年頃、JavaScriptの状況は大きく異なっていました。現在私たちが知っているようなバンドラー（WebpackやVite）は存在しなかったか、まだ初期段階にありました。ブラウザ上でスクリプトをつなぎ合わせていた時代です。この時代に、i18nextのようなライブラリが誕生しました。

彼らは当時可能な唯一の方法で問題を解決しました：ランタイム辞書です。巨大なJSONオブジェクトをメモリに読み込み、関数がその場でキーを検索する仕組みでした。これは信頼性が高く、明示的で、どこでも動作しました。

そして現在に至ります。私たちはミリ秒単位で抽象構文木（AST）を解析できる強力なコンパイラ（SWCやRustベースのバンドラー）を持っています。この力が新しいアイデアを生み出しました：なぜ私たちは手動でキーを管理しているのか？なぜコンパイラが「Hello World」というテキストを見て、それを置き換えてくれないのか？

こうして、コンパイラベースのi18nが誕生しました。

コンパイラの魅力（「マジック」アプローチ）

この新しいアプローチがトレンドになっている理由があります。開発者にとって、その体験は驚くべきものです。

1. スピードと「フロー」

集中しているときに、変数名（home_hero_title_v2）を考えるために立ち止まると、フローが途切れてしまいます。コンパイラアプローチでは、<p>Welcome back</p> とタイプしてそのまま進めます。摩擦はゼロです。

2. レガシー救出ミッション

5,000のコンポーネントがある巨大なコードベースを引き継ぎ、翻訳が一切ないと想像してください。手動のキー管理システムでこれを後付けするのは数ヶ月に及ぶ悪夢です。コンパイラベースのツールは救出戦略として機能し、手動でファイルに触れることなく数千の文字列を瞬時に抽出します。

3. AI時代

これは見逃せない現代的な利点です。AIコーディングアシスタント（CopilotやChatGPTのようなもの）は、標準的なJSX/HTMLを自然に生成します。彼らはあなたの特定の翻訳キーのスキーマを知りません。

• 宣言的（Declarative）: AIの出力をテキストからキーに置き換えるために書き直す必要があります。
• コンパイラ（Compiler）: AIのコードをコピー＆ペーストするだけで、そのまま動作します。

現実の確認：なぜ「マジック」は危険なのか

「マジック」は魅力的ですが、その抽象化は漏れが生じます。ビルドツールに人間の意図を理解させることに依存すると、アーキテクチャの脆弱性が生まれます。

1. ヒューリスティックの脆弱性（推測ゲーム）

コンパイラは何がコンテンツで何がコードかを推測しなければなりません。

• className="active" は翻訳されますか？これは文字列です。
• status="pending" は翻訳されますか？
• <MyComponent errorMessage="An error occurred" /> は翻訳されますか？
• "AX-99" のような製品IDは翻訳されますか？

最終的には、コンパイラと「戦う」ことになり、アプリケーションのロジックを壊さないように特定のコメント（例：// ignore-translation）を追加することになります。

2. 動的データのハードリミット

コンパイラの抽出は静的解析に依存しています。安定したIDを生成するためには、コード内にリテラル文字列が存在している必要があります。
もしAPIが server_error のようなエラーコード文字列を返す場合、コンパイラはビルド時にその文字列の存在を認識できないため、翻訳できません。動的データ用に「ランタイム専用」の二次的なシステムを構築せざるを得ません。

3. 「チャンク爆発」とネットワークウォーターフォール

ツリーシェイキングを可能にするために、コンパイラツールはしばしばコンポーネントごとに翻訳を分割します。

• 結果: 50個の小さなコンポーネントがある単一のページビューで、50回の別々のHTTPリクエストが小さな翻訳断片に対して発生する可能性があります。HTTP/2を使用していても、これはネットワークのウォーターフォールを生み出し、単一の最適化された言語バンドルを読み込む場合と比べて、アプリケーションの動作が遅く感じられます。

4. ランタイムのパフォーマンスオーバーヘッド

翻訳をリアクティブに（言語を切り替えたときに即座に更新されるように）するために、コンパイラはしばしばすべてのコンポーネントに状態管理フックを注入します。

• コスト: もし5,000件のアイテムのリストをレンダリングすると、テキストのためだけに5,000個の useState と useEffect フックを初期化することになります。これは、宣言的ライブラリ（通常は単一のContextプロバイダーを使用）が節約するメモリとCPUサイクルを消費します。

トラップ：ベンダーロックイン

これはおそらく、コンパイラベースのi18nで最も危険な側面です。

宣言的ライブラリでは、ソースコードに明確な意図が含まれています。キーはあなたが所有しています。ライブラリを切り替える場合は、インポートを変更するだけです。

コンパイラベースのアプローチでは、ソースコードは単なる英語のテキストです。 「翻訳ロジック」はビルドプラグインの設定内にのみ存在します。 もしそのライブラリのメンテナンスが停止したり、ライブラリの機能を超えてしまった場合、あなたは行き詰まります。ソースコードに翻訳キーが一切存在しないため、「イジェクト」することは簡単ではありません。移行するには、アプリケーション全体を手動で書き直す必要があります。

もう一方の側面：宣言的アプローチのリスク

公平を期すために言うと、従来の宣言的な方法も完璧ではありません。独自の「落とし穴」が存在します。

1. ネームスペース地獄: どのJSONファイルを読み込むか（common.json、dashboard.json、footer.jsonなど）を手動で管理する必要がよくあります。もし一つでも忘れると、ユーザーは生のキーを目にすることになります。
2. 過剰フェッチ: 注意深く設定しないと、初回ロード時にすべてのページのすべての翻訳キーを誤って読み込んでしまい、バンドルサイズが膨れ上がることが非常に簡単に起こります。
3. 同期のズレ（Sync Drift）： コンポーネントが削除された後も、そのコンポーネントで使われていたキーがJSONファイルに残り続けることがよくあります。翻訳ファイルは無限に増え続け、「ゾンビキー」で溢れてしまいます。

Intlayerの中間的アプローチ

ここで、Intlayerのようなツールが革新を試みています。Intlayerは、コンパイラが強力である一方で、暗黙のマジックは危険であることを理解しています。

Intlayerは独自のtransformコマンドを提供します。隠れたビルドステップで単にマジックを行うのではなく、実際にコンポーネントのコードを書き換えることができます。テキストをスキャンし、コードベース内で明示的なコンテンツ宣言に置き換えます。

これにより、両方の利点を得られます：

1. 粒度（Granularity）： 翻訳をコンポーネントの近くに保持できるため（モジュール性とツリーシェイキングが向上します）。
2. 安全性: 翻訳は隠れたビルド時のマジックではなく、明示的なコードになります。
3. ロックインなし: コードがリポジトリ内で標準的な宣言的構造に変換されるため、webpackプラグイン内にロジックを隠すことはありません。

結論

では、どちらを選ぶべきでしょうか？

もしあなたがジュニア開発者、ソロ創業者、またはMVPを構築している場合：
コンパイラベースのアプローチは有効な選択肢です。非常に速く開発を進めることができます。ファイル構造やキーについて心配する必要はありません。ただビルドすれば良いのです。技術的負債は「未来のあなた」の問題です。

もしあなたがプロフェッショナルなエンタープライズグレードのアプリケーションを構築している場合：
マジックは一般的に悪い考えです。コントロールが必要です。

• バックエンドからの動的データを扱う必要があります。
• 低スペックデバイスでのパフォーマンスを確保する必要があります（フックの爆発を避けるため）。
• 特定のビルドツールに永遠にロックインされないようにする必要があります。

プロフェッショナルなアプリケーションの場合、宣言的コンテンツ管理（Intlayerや確立されたライブラリのようなもの）が依然としてゴールドスタンダードです。これにより関心事が分離され、アーキテクチャがクリーンに保たれ、アプリケーションが複数言語を扱う能力が「ブラックボックス」コンパイラの推測に依存しないことが保証されます。