为 Angular Admin/Dashboard 应用选择 i18n 策略

Source: Dev.to

管理后台/仪表盘应用的常见 i18n 需求

1. 运行时语言切换（无需刷新） – 用户选择语言（通常在右上角菜单），界面立即更新，无需页面刷新。
2. 模块化翻译资源（命名空间 / 功能作用域） – 管理后台包含众多功能；将所有翻译打包到单个文件会导致维护困难。
3. 懒加载翻译资源（按需加载） – 避免在首次加载时就打包所有语言。
4. SSR/SSG 友好 – 大多数后台应用是 CSR，但可能需要为文档/演示页使用 SSG，或为某些项目使用 SSR。i18n 架构不应使这些渲染模式变得更难。
5. 稳定的切换体验（无键名闪烁 / 无不一致 UI） – 管理用户频繁导航，任何翻译键的闪烁或文本不匹配都会非常显眼且令人烦恼。

对比的实现方式

Angular 内置 i18n

优点

• 适用于在构建时就确定语言的站点（例如营销站点、SEO 为主的页面）。
• 编译时方案，可生成多语言版本。

缺点

• 同一运行中的应用无法实现真正的运行时语言切换；常见的变通办法是构建不同语言的版本并进行重定向，这会导致页面重新加载。
• 维护成本增加，因为实际上需要管理多个站点构建。
• 在表单状态、搜索过滤、分页、多标签页一致性以及将路由参数与语言路径（如 /en/...、/zh/...）同步时会出现问题。

最适合
SEO 为首要目标、能够接受“构建时决定语言”的网站。

ngx‑translate

优点

• 成熟的运行时 i18n 方案，社区庞大。
• 功能灵活，集成选项众多。

缺点

• 在大型后台应用中，容易形成一个庞大的翻译包，导致初始下载体积膨胀。

最适合
需要最大灵活性且已有规范的加载器/命名空间管理的团队。

ngx‑atomic‑i18n

优点

• 专为后台应用需求设计：按功能/组件划分命名空间、默认懒加载、缓存以及对 SSR/SSG 友好。
• 目标是 “原子化、可懒加载的 Angular i18n”。

缺点

• 包较新 → 社区规模小，生态成熟度较低。
• 需要现代 Angular（v16+）。

最适合
希望获得 “即装即用” 方案、按功能作用域懒加载且不把 i18n 当作副任务的后台应用。

30 秒快速上手（概念示例，可直接复制）

npm i ngx-atomic-i18n

项目结构

src/assets/i18n/
  en/
    common.json
    users.json
  zh-Hant/
    common.json
    users.json

在项目中一次性注册 i18n（例如 main.ts 或 app.config.ts）

import { provideAtomicI18n } from 'ngx-atomic-i18n';
import { bootstrapApplication } from '@angular/platform-browser';
import { AppComponent } from './app/app.component';

bootstrapApplication(AppComponent, {
  providers: [
    provideAtomicI18n({
      supportedLangs: ['en', 'zh-Hant'],
      fallbackLang: 'en',
      assetsPath: 'assets/i18n',
      // default: lazy‑load namespaces on demand + cache
    }),
  ],
});

在模板中使用翻译（示例管道名：t）

{{ 'common.title' | t }}

{{ 'users.create' | t }}

运行时切换语言（无需刷新）

import { i18n } from 'ngx-atomic-i18n';

i18n.setLang('zh-Hant');

可选：在渲染前确保当前页面的命名空间已加载

await i18n.loadNamespace('users');

这就是全部思路：按功能划分的命名空间 + 按需加载 + 运行时切换且无 UI 闪烁。