アプリケーションの国際化（i18n）における大きな問題の一つは、それが「後回し」にされがちな点にあります。
まずアプリを開発し、ニーズを検証し、数ヶ月あるいは数年経ってからようやく「そろそろグローバル展開しよう」と考えるのが一般的です。
しかし、i18nソリューションは構造的であり、開発チームに大きな負荷を与えます。本来であれば、最初から仕様書に盛り込んでおくのが理想的です。
では、具体的にどうすればいいのでしょうか？ 開発を1週間ストップして、すべてのコンポーネントを書き換えるべきでしょうか？
最近、コンパイラベースのアプローチを採用したソリューションをいくつか見かけるようになりました。「数行のコードを追加するだけで、アプリが多言語化される」というシンプルな約束を掲げています。
しかし、そこには代償もあります：
開発スピードの著しい低下
- コンパイラによる処理が追加されるため、特に開発モード（ホットリロードなど）でのパフォーマンスに影響が出ます。
完璧ではない
- 98%のケースで正しく動作しているように見えても、残りの2%が厄介です。コンポーネント外にある
getDescriptionのような関数をどう翻訳するか？ 複数形、変数埋め込み、日付形式などをどう管理するか？
バンドルサイズ
- 読み込まれるコンテンツ量が二の次にされがちです。その結果、ユーザーが1ページ閲覧するだけで、全ページの全言語データがロードされてしまうこともあります。
ベンダーロックイン
- 一部のソリューションではプラットフォームに依存してしまい、翻訳生成に高額な費用を払い続けることになります。
Next.js Server Components
- サーバーサイドでレンダリングされるコンテンツをどう多言語化するかという課題があります。
こうした課題に対し、Intlayer はミックスアプローチ（混合型アプローチ）を提案しています。
Intlayerは、コンポーネントを処理するコンパイラを提供します。React Compilerが useMemo や useCallback でラップするのと同様に、Intlayerはコンポーネントからコンテンツを抽出し、getIntlayer / useIntlayer 関数を自動的に挿入して多言語化します。
<T> ブロックや t 関数を記述する必要はなく、Intlayerがコンポーネントをそのまま変換します。
また、Intlayerは本質的に**宣言的な国際化（Declarative i18n）**ソリューションです。そのため、ページのメタデータに使用したり、手動で管理されたコンテンツとコンパイラによる処理を共存させたりすることも可能です。
その他の特徴：
- 完全無料: キーごとの課金はありません。利用しているAIプロバイダーのコストのみで翻訳可能です。
- 高い互換性: Vite / Next.js (Webpack / Turbopack) / React / Svelte / Vue / クライアントおよびサーバーサイドに対応。
- 柔軟な設定: 開発（dev）および/または本番（prod）ビルドでの有効化を選択可能。
- 最適化: バンドルサイズを考慮した設計。
Next.js ドキュメント: https://intlayer.org/doc/environment/nextjs/compiler
Vite ドキュメント: https://intlayer.org/doc/environment/vite-and-react/compiler
Github: https://github.com/aymericzip/intlayer
これについて、皆さんのフィードバックをお聞かせください。