Al-*_*-un 5 internationalization xliff angular
我正在开始一个新的 Angular 6 项目（我也是 Angular 的新手 ^^），所以我对选择非常自由。在谈到Internalization时，我们在阅读后选择使用Angular原生的I18n：
在我们的阶段，可以通过一些变通方法解决无法在模板文件之外使用翻译的事实
XLIFF 学习曲线给我带来了 XLIFF 1.2 与 XLIFF 2 的问题。在阅读了 XLIFF 1.2 和 XLIFF 2 之间的差异后，似乎 XLIFF 2 解决了很多问题，并且比 XLIFF 1.2 更具前瞻性，后者现在已成为传统根据维基百科的格式
因此，为什么 Angular 专注于 XLIFF 1.2 而不是 XLIFF 2？我注意到：
至于我们的项目，我们从 XLIFF 2 开始，但我很想切换到 XLIFF 1.2
关于原因，您的问题非常主观，但 Angular 并不孤单。XCode 仍然使用 XLIFF 1.2。Symfony 最近添加了 v2 支持，但文档仍然引用 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，你需要有一个计划。有支持这两种格式的编辑器。