嗨咿，我是 illumi！最近新開了一個專案想要有中英兩種以上語言切換，但要選擇哪個工具呢？一起來研究不同工具的差別吧～
首先！我先說！盡量在專案一開始就做，不然之後會改得很痛苦！所以現在臨時想加入語言切換的先停下深思一下......
下表是我針對幾個常用工具做比較：next-intl、next-i18next、還有一個比較新的 Intlayer，以及一般 React 世界裡常見的 react-i18next / react-intl / LinguiJS。
（比較維度：API 易用性、Next.js 支援、TypeScript 安全性、載入策略 / lazy loading、SEO / URL 路由、社群與生態、缺點）
| 工具 / 框架 | API / 用法直觀性 | Next.js 支援 / 適用性 | TypeScript / 安全性 | 載入 / 懶加載 / 分割 | URL 路由 / SEO 友好 | 生態 / 社群 / 插件 | 主要缺點 / 注意點 |
|---|---|---|---|---|---|---|---|
| next-intl.dev | 中等偏簡單。使用 useTranslations、t()，支援 ICU 語法等。 |
官方設計支援 Next.js（App Router / Pages Router 都能用） | 支援 TypeScript，但 keys 不會強制全局型別（需手動管理型別安全） | 可透過命名空間、動態載入 JSON 檔做分割 | 支援本地化路由（localized routing）對 SEO 有幫助 | 社群活躍度中上；文件清楚；正在被越來越多人採用 | 中大型專案時可能要你自己維護 key 管理、缺鍵處理、翻譯流程 |
| next-i18next | 用法偏「i18next 生態」風格。比較多配置，但熟悉 i18next 的人會容易上手 | 適合 Next.js 的 Pages Router。若用 Next 13 的 App Router，兼容性會比較麻煩 | 有基本 typings，但對大型專案要強型別仍需額外努力 | i18next 生態中有很多 plugin 支援 lazy loading、命名空間拆分等 | 支援本地化路由（Next.js 本身 i18n routing + next-i18next 配合） | 插件豐富（i18next 生態強） | 配置容易變複雜，文件碎片較多；和 App Router 的整合不會像 next-intl 那麼順 |
| Intlayer | 比較新的方案，其 API 設計偏向 component 級內容與 co-located 翻譯檔案 | 適合 Next.js 13+ App Router，主打與 RSC／Server Components 共存 | 強類型支援：自動生成嚴格型別與 build 時缺鍵檢查 | Tree-shaking + 按需載入，很適合控制 bundle 大小 | 路由支持、URL helper、middleware 支援都設計得比較齊備 | 比較新、社群還在成長中 | 新方案總有比較少經驗積累的風險；某些特殊需求或翻譯平台整合需觀察成熟度 |
| react.i18next.com | React 生態成熟、API 多樣（hook、Trans、HOCs 等） | 在 Next.js 中可用（尤其在客戶端），但 SSR / Next 特有功能需搭配額外橋接 | TypeScript 支援不錯，搭配 i18next plugins 型別可加強 | 支援懶加載、命名空間、延遲載入翻譯檔案 | 本身不管 URL 路由，那要靠 Next.js 的 i18n 路由機制搭配 | 生態強大，是 i18next 的核心組件之一 | 在 Next.js 的 SSR / routing 整合時，可能要額外做同步 / 預載 / 初始 state 處理 |
| react-intl (FormatJS) | API 比較宣告式，用 <FormattedMessage>、ICU 語法，直觀，適合格式化（日期、數字）場景強 |
可在 Next / SSR 中使用，但要手動包裝 provider /橋接 | 有內建型別定義，對格式化支持好 | 雖然本身不專門針對懶加載翻譯檔案，但可搭配外部庫或自寫方案 | 和 Next.js i18n 路由需搭配使用 | 在格式化與國際化邏輯上是業界標準之一 | 對大量文字與多語言切換需求時，可讀性有時不如 hook 為主的方案 |
| LinguiJS | 較小眾但設計清爽：支援 message extraction、自動提取翻譯 key 等特性 | 可以與 Next.js 合用（需要做部分整合） | 同樣支援 TypeScript，並允許較乾淨的 message 型別抽取 | 支援動態載入、lazy loading 等 | URL 路由需靠 Next.js 機制整合 | 文件與生態不像前面幾個那麼大，但在中小型專案中足夠用 | 若專案規模很大或有非常複雜翻譯流程，可能要自行擴展 |
專案規模 / 翻譯量
如果只是簡單幾頁、語系不多（比方說中文 / 英文 / 日文），你用比較輕量的方案（next-intl 或 react-intl）就夠了。
若未來會有很多語言、很多段落要翻譯、更新頻繁，那 plugin 強、可拆解、懶載入能力強的方案比較耐用。
Next.js 的版本 / 架構
如果你在 Next 13+ 用 App Router／RSC，那支援這種架構良好的方案會省你很多整合痛苦。這點 next-intl 和 Intlayer 在設計上比較貼合。
如果你還在用老的 Pages Router 或混搭，next-i18next 有成熟文檔支持。
TypeScript / 型別安全的要求
在專案裡要抓錯誤要越早越好。方案若支援 build-time 檢查缺鍵、嚴格型別，就能在開發期就捕到錯。這樣跑到產品上出錯的風險低很多。
Intlayer 在這塊承諾比較多（自動生成型別、缺鍵檢查）(Intlayer)。但代價是你要接受它相對新的狀態。
譯文維護 / 編輯流程
如果你有外部翻譯團隊、或語言更新頻繁，語系平台整合 (Translation Management System, TMS) 很重要。某些方案較容易搭配 TMS（例如 i18next 生態本身就有許多連接器）。
你要先問：翻譯誰做？更新頻率？是否要讓非工程師上界面編輯？
SEO / 路由 / 使用者體驗
多語系網站最常的挑錯點是 SEO 被忽略（hreflang、localize 路由、默認語系處理等）。方案若有內建幫你處理 URL + SEO 標籤，那你少寫很多 boilerplate。
next-intl 有本地化路由與支持。(next-intl.dev)
小專案優先考慮：next-intl
它在 Next.js 新架構環境裡整合較順；API 規劃不會太重；你可以快速上手又不會卡得太死。
若以後專案變複雜，你可以再補額外工具（例如 TMS、key 校驗腳本等）。
如果願意承擔風險 / 嘗試新東西：Intlayer
在長期維護、型別安全、build 檢查這些方面有潛力很高。但現在還沒被業界完全驗證很多年。你可以做試驗性專案，用它在某些模組裡。
當你要做「超複雜、語言很多、外部翻譯團隊參與」的案子時：考慮 next-i18next / react-i18next 解決方案
它生態成熟、插件多，如果你需要切換很多語系、線上更新翻譯都能處理。
在做多語系網站時，最常遇到的就是字數長短不一。特別是 英文通常比中文長，一個按鈕「登入」翻成英文就變成 "Sign in"，甚至某些說明句會直接膨脹一倍。如果排版沒有彈性，切換語系時就會出現斷行、跑版、甚至文字被截斷的尷尬狀況。解法上可以從幾個方向著手：
flex、grid 等 CSS 排版方式，讓元素能夠隨文字長度自動換行或調整。text-overflow 或自適應字級避免排版被破壞。好的了解差不多了！那我們明天就挑 next-intl 來實作吧！
iThome鐵人賽
看影片追技術