3.5 国际化与本地化

3.5 国际化与本地化

i18n（国际化，让应用能适配多语言）与 l10n（本地化，具体语言的落地）在 Angular 有两条主路线：构建期翻译（模板标记 + 提取 + 按语言出包）与运行期替换（翻译字典 + 管道/指令查表）。主线上这一节的看点：文案是模板绑定的一部分，翻译方案直接决定文案绑定在检查期怎么求值——构建期方案零运行时成本，运行期方案多一层查表。

上一节留下的钩子

3.4 谈的是把攻击挡在门外，本节掉转方向——把同一扇门向多种语言的用户敞开，且不给检查添负担：

1. 在模板中标记可翻译内容并处理插值、复数、选择三种场景。
2. 说明构建期 i18n 的提取-翻译-合并流程与多语言产物的构建方式。
3. 用运行期字典方案（translate 管道或信号字典）实现语言即时切换。
4. 处理本地化数字、日期、货币的显示差异。

一、构建期方案：标记与提取

<!-- 模板中标记静态文案 -->
<h1 i18n>订单管理</h1>

<!-- 带插值：用占位符表达式描述上下文，帮助译者理解 -->
<p i18n>共 { total, plural, =0 {没有订单} =1 {一笔订单} other {共 {{total}} 笔订单} } </p>

<!-- 选择类：按枚举值换文案 -->
<span i18n>状态：{ status, select, paid {已支付} shipped {已发货} other {进行中} }</span>

<!-- 属性也要标记 -->
<input placeholder="搜索订单" i18n-placeholder>
​

提取与构建流程：CLI 命令提取模板里的标记生成翻译源文件（XML 格式），译者填目标语言后，构建时按语言参数把翻译直接织入产物——每个语言一个构建产物，运行时没有查表开销。这也是它在检查管线上的优势：翻译后的文案在编译期就固化，检查期与普通静态文本无异。

# 提取可翻译文案到源文件
ng extract-i18n --output-path src/locale
# 按语言构建（配置好 locale 后）
ng build --configuration=zh
ng build --configuration=en
​

二、运行期方案：字典与切换

构建期方案的代价是"语言即产物"——不能在运行中切换。需要即时切换的场景用运行期字典：

import { Injectable, signal, computed } from '@angular/core';

const DICT = {
  zh: { title: '订单管理', empty: '没有订单', searchPh: '搜索订单' },
  en: { title: 'Orders', empty: 'No orders yet', searchPh: 'Search orders' }
} as const;

@Injectable({ providedIn: 'root' })
export class I18nService {
  private lang = signal<'zh' | 'en'>('zh');

  // 信号字典：语言一换，读过 t 的组件全部精准更新（3.1 节路线二）
  readonly t = computed(() => DICT[this.lang()]);

  switch(next: 'zh' | 'en') { this.lang.set(next); }
}

// 模板：<h1>{{ i18n.t().title }}</h1>
// <input [placeholder]="i18n.t().searchPh">
​

信号字典把语言切换变成普通数据变更，界面更新走精准检查路线，切换瞬间完成且只刷新文案相关组件。对比旧的订阅式翻译管道（不纯管道 + 每绑定查表），运行成本与 2.5 节的纯度分析完全对得上——能缓存的重算尽量缓存，不能缓存的控制在少量绑定。

⚠️ 坑：复数与选择逻辑在运行期方案里要自己写规则（中文无复数变形，英文有），别只翻名词漏了语法结构；日期数字的本地化交给框架的本地化数据包注册，别手工拼。

三、本地化显示

// 注册本地化数据（应用配置中，以中文为例）
import { registerLocaleData } from '@angular/common';
import localeZh from '@angular/common/locales/zh';
registerLocaleData(localeZh);

// 模板中配合 LOCALE_ID 使用内置管道
// <p>{{ now | date:'medium' }}</p>          中文环境输出：2026年1月6日 下午3:42:00
// <p>{{ amount | currency:'CNY':'symbol' }}</p>  输出：¥199.00
// <p>{{ ratio | percent:'1.1-2' }}</p>      输出：12.3%
​

图：两条 i18n 路线的决策树

四、案例：双语后台的完整落地

背景：内部后台需要中英双语，用户在页头下拉切换，且接口返回的枚举文案也要跟随语言。
操作：选择运行期方案（必须即时切换）；枚举文案并入字典（DICT.zh.statusPaid = '已支付'）；日期货币统一走内置管道并注册两份本地化数据；语言偏好写入本地存储，启动时读取初始化信号。
结果：切换下拉后全站文案、日期格式、货币符号一次刷新；刷新页面后语言保持。
解读：语言是全局状态的一种，方案选择与 2.9 节状态分类同构——"会话状态归根服务"，语言偏好正归此类。枚举文案并入字典避免了"框架管模板、业务管枚举"两套体系并存的割裂。
变式：若之后要上线多租户公共站点（面向搜索引擎、每种语言独立 URL），迁移到构建期方案并按语言出独立产物，SEO 收益显著——这也是它与 SSR（下一节）的交汇点。

本节要点回顾

• 构建期方案：标记-提取-织入流程，每语言一个产物，运行时零查表，检查期与静态文本等价。
• 运行期方案：信号字典让语言切换成为普通数据变更，走精准检查路线。
• ICU 语法：复数与选择在模板标记里原生支持，运行期方案需自补规则。
• 本地化显示：注册本地化数据后，内置管道按环境输出日期货币百分比的正确形态。
• 主线上的一环：文案即绑定，翻译方案决定这批绑定在检查期的求值成本。

下一节回到工具链主线：Angular CLI 高级应用。