寫這篇文章是想推薦我做的i18n套件，藉由比較 Angular 最多人用的兩款套件，
解釋為什麼做這款工具的原由。

做後台系統（admin / dashboard）時，多語系的需求通常跟官網完全不同。
官網常見的目標是 SEO 與初始畫面快速；
後台更需要的則是「使用者操作中直接切換語系」，而且要做到不打斷工作流程。

這篇文章先整理後台系統最典型的 i18n 需求，接著用
Angular 內建 i18n、
ngx-translate、
ngx-atomic-i18n 三種方案做對照。

後台系統最常見的 i18n 需求

後台的易用性通常包含幾點：

• runtime 動態換語系（不依靠 reload）
  : 使用者在右上角切語言，畫面立刻更新，不需要重新整理頁面、不需要重新進站。

• 翻譯資源模組化（namespace / feature scope）
  : 後台功能很多，翻譯如果全塞一包會變得難維護、難協作。理想是依 feature 拆 namespace。

• 翻譯資源可 lazy load（按需載入）
  : 不希望初次載入就把所有的都翻譯載進來；而是進到某頁才載該頁需要的翻譯，提升效能。

• SSR/SSG 相容有善性
  : 後台本體多半是 CSR，但 demo / 文件站可能想用 SSG；有些專案也會需要 SSR。希望 i18n 架構不要讓這件事變困難。

• 切語言的體驗穩定，切換語系或剛進入頁面時不閃 key、避免不一致
  : 後台切換頁面的頻率高，任何「切換瞬間顯示不完整」的體驗都會被放大。

三種方案結論與自適用情境

Angular 內建 i18n
優: 很適合「建置期決定語言」的網站（官網/SEO/內容頁）。
但它不支援真正的 runtime 動態切語言；你能做的是「多建置語言版本 + 導向另一個語系入口」，本質上等同換站/重載，不是同一個 app 裡即時切換。
缺: 它重整網頁切語言的特性，會讓網站當下狀態丟失。
後台使用者如果正在填表、編輯資料、開多個 tab、或正在比對列表與明細。
換語系重新載入整個應用程式，就需要額外處理：

• 表單狀態保存/還原
• 搜尋條件、分頁、排序狀態保存
• 多頁簽/多視窗一致性
• 路由參數與語系路徑的同步（/en/...、/zh/...）
  這些都會變成後台體驗的負擔。
  另一個缺點就是版本管理的負擔，每個語系一個網站來維護，維運的複雜度上升。

ngx-translate
優: 成熟的 runtime i18n 方案，社群大、功能完整、彈性高。
缺: 在大型後台常見的痛點是：翻譯資源用同一包，最後造成初始下載肥大。lazy load 與快取策略需要自己製作custom loader，有技術門檻，每個人做的規則可能有點不一樣，需要團隊規範。

ngx-atomic-i18n
優: 能一安裝就無腦 lazy-load + 按需下載資源，
針對後台需求設計，主打 namespace（以元件/功能為單位）+ 預設 lazy load + 快取 + SSR/SSG 友善。
缺: 新套件，社群成熟度低，只支援 Angular 16+。

ngx-atomic-i18n

github: https://github.com/viacharles/ngx-atomic-i18n
Demo & Tutorial: https://i18n-demo.viacharles.net/