Angular i18n 中缺失的部分
Source: Dev.to
实际出错的地方
在生产环境的应用中，翻译文件不是一次性构建产物。
它们是由人类和外部工具编辑的长期文档。
一个典型的语言文件包含的内容远不止翻译文本：
- 翻译者备注
- 上下文分组
- 审批标记
- 供应商特定的元数据
…为每个字符串提供意义和历史的信息。
然而，每当 messages.xlf 变化时，团队就被迫进入风险工作流：
- 手动编辑 XML
- 复制‑粘贴合并
- 重新生成语言文件
- 假设 XLIFF 只是键‑值数据的脆弱脚本
结果几乎总是相同：静默的数据丢失。
- 备注消失。
- 已批准的翻译被重置。
- 上下文丢失。
没有人会注意到，直到翻译者抱怨或构建失败。
Angular 并未解决此问题。大多数第三方工具也没有。
什么是 xlf-sync 的设计目标
xlf-sync 存在的目的非常明确：
将
messages..xlf文件 结构上 与messages.xlf保持同步，且不破坏已有的内容。
它 不 生成翻译、不 “清理” XML，也不假设可以安全地重新创建本地化文件。
相反，它把这些文件视为 需要保留的宝贵状态。
- 源文件仍然是 键的存在 的权威。
- 本地化文件仍然是 其他所有内容 的权威。
元数据才是真正的区分因素
大多数同步工具会从头重建翻译单元，这不可避免地会剥离工具不理解的信息。
xlf-sync 采用相反的做法：
- 现有的翻译单元绝不被重新构建。
- 它们以字节为单位读取并保留，仅在源文件引入新内容时才进行扩展。
如果译者两年前添加了备注，它会保留下来。
如果 CAT 工具添加了元数据，它也会存活。
如果某条目被标记为已批准，它仍然保持已批准状态。
这不是一个便利功能——它是该工具的核心保证。
处理更改而不删除历史
应用程序不断变化：字符串会被添加、删除和重新组织。
xlf-sync 做了一个重要假设：删除不等同于移除。
当一个键从源文件中消失时，你可以决定如何处理它。你可以：
- 将其标记为废弃。
- 将其移动到专用的墓地文件。
- 明确删除——如果这真的是你想要的。
没有任何隐式操作。没有任何东西会意外消失。
这使得重构更安全，并且即使功能暂时被移除，也能保留翻译工作。
为真实的 Angular 代码库而设计
许多 Angular 仓库并不是干净的全新项目。它们包含遗留模块、迁移以及混合的格式。
xlf-sync同时支持 XLIFF 1.2 和 2.0，并能按文件检测版本。- 即使同一项目中同时存在两种格式，它也能正常工作。
这使得它不仅适用于新应用，也适用于有历史的成熟系统。
可见性和自动化很重要
Angular 的 CLI 并未提供翻译健康状况的清晰视图。
xlf-sync 填补了这一空白，提供：
- 快速的控制台报告。
- 一个独立的 HTML 仪表盘，可视化各语言环境的翻译覆盖率。
该仪表盘在工程团队之外尤其有用——它让翻译进度一目了然，无需打开 XML 文件。
对于自动化，check 命令将 i18n 变成真正的 CI 关注点。当翻译出现以下情况时，你可以让构建失败：
- 缺失
- 不同步
- 与源文件出现漂移
这将 i18n 从事后考虑转变为质量门槛。
Angular 从未发布的缺失功能：翻译仪表盘
Angular 的 i18n 工具会生成文件，但它 完全没有可视化。你无法了解：
- 哪些语言环境落后。
- 已翻译了多少。
- 实际缺口在哪里。
xlf-sync 通过一个独立的 HTML 仪表盘 解决了这个问题。
npx xlf-sync dashboard运行该命令会生成一个自包含的报告，直观展示所有语言环境的翻译覆盖率。它会显示：
- 键的总数量。
- 已翻译的数量。
- 缺失的键。
全部无需打开 XLIFF 文件。
由于仪表盘是静态 HTML，它可以自然地嵌入 CI 流程。团队常把它作为构建产物附加，使翻译进度与其他质量指标一起可见。
测试报告和覆盖率指标
这不仅仅是视觉上的美化。
它是为了让 i18n 可度量。
与其他工具的区别
大多数工具把 locale 文件视为派生产出。
xlf‑sync 把它们视为资产。
正是这一点决定了它的行为：
- 不会进行破坏性的同步
- 不会丢失元数据
- 不会静默重写
它把安全性置于巧妙性之上——这正是长期多语言项目所需要的。
了解更多
- GitHub 仓库：
- 官方文档与着陆页：
- npm 包：
结束语
Angular i18n 能很好地完成提取工作。
其余的全部交由开发者处理。
xlf‑sync 并不取代 Angular 的工具链——而是对其进行补充。
如果你的应用拥有真实的翻译、真实的译者以及真实的变更，这个问题迟早会显现。
xlf‑sync 只需从那一刻起将风险消除即可。