angular - 为什么 Angular 使用 XLIFF 1.2 而不是 XLIFF 2？

Question

我正在开始一个新的 Angular 6 项目(我也是 Angular 的新手 ^^)，所以我对选择非常自由。在谈到Internalization时，我们在阅读后选择使用Angular原生的I18n:

ngx-translate author answer on ngx-translate vs native I18n

why XLIFF is a relevant format for I18n

在我们的阶段，可以通过一些变通方法解决无法在模板文件之外使用翻译的事实

XLIFF 学习曲线让我想到了 XLIFF 1.2 与 XLIFF 2 的问题。阅读后 the differences between XLIFF 1.2 and XLIFF 2 ，似乎 XLIFF 2 解决了很多问题，并且比现在的 XLIFF 1.2 更具前瞻性 a legacy format according to Wikipedia

因此，为什么 Angular 专注于 XLIFF 1.2 而不是 XLIFF 2？ 我注意到:

The official Angular I18n uses XLIFF 1.2

大多数网络资源(如 Medium )使用 XLIFF 1.2

很难找到一些与 XLIFF 2 兼容的免费翻译工具(在 SmartCat 上导入 XLIFF 2 文件时出错，我在使用 Rainbox/Okapi 框架时遇到了困难)

在 XLIFF 2 上也很难找到帮助(比如我如何做 ICU 的事情？)，至少对于初学者来说

至于我们的项目，我们从 XLIFF 2 开始，但我很想切换到 XLIFF 1.2

Answer 1

你的问题对很主观为什么 ，但 Angular 并不孤单。 XCode 仍然使用 XLIFF 1.2。 Symfony 最近添加了 v2 支持，但 docs still reference 1.2 .

我认为 Web 框架的采用速度很慢，因为这种格式并没有增加 Web 框架以前缺乏的功能。它为可扩展性提供了很多空间，但尽管听起来很棒，但这只是意味着人们可以以他们认为合适的任何方式使用该格式。我的意思是 <note category="file-source">file.js:93</note>很棒，除了“文件源”不是规范的一部分，所以不是很跨平台。

也许该格式在翻译行业中做得更好，但 Web 框架并不倾向于使用该格式的许多高级功能。在大多数情况下，XLIFF 文件用作索引字符串的相当笨拙的容器，v1.2 和 v2 一样。

如果一个框架刚开始使用新的 XLIFF 2 似乎很简单，但如果你已经有成千上万的人愉快地使用 1.2，我认为升级的动力不大。

我的建议是确保您随时可以在需要时切换文件格式。如果 1.2 能让你访问你喜欢的工具，一定要使用它，但如果有一天 Angular 决定弃用 1.2 并转向 v2，你需要有一个计划。有支持这两种格式的编辑器。