为什么角使用XLIFF 1.2而不是XLIFF 2？

Question

我开始了一个新的角6项目(我对角也是新的^^)，所以我对选择相当自由。在进行内部化时，我们在阅读后选择使用本机I18n：

• ngx-翻译作者在ngx上的答案-翻译vs本机I18n
• 为什么XLIFF是I18n的相关格式

翻译不能从模板文件中使用这一事实可以在我们这个阶段通过一些变通方法来解决。

在阅读了XLIFF 1.2和XLIFF 2的差异之后，XLIFF 2似乎解决了很多问题，并且比现在的XLIFF 2更有前途。

因此，为什么关注XLIFF 1.2而不是XLIFF 2?注意到：

• 官方角度I18n使用XLIFF 1.2
• 大多数web资源(如在5~6成熟上)使用XLIFF 1.2
• 很难找到一些与XLIFF 2兼容的免费翻译工具(我在SmartCat上导入XLIFF 2文件时出错，并且与Rainbox/Okapi框架做了斗争)
• 在XLIFF 2上也很难找到帮助(比如我如何完成ICU的工作)，至少对于初学者来说是这样的。

至于我们的项目，我们开始使用XLIFF 2，但我强烈希望切换到XLIFF 1.2。

Answer 1

关于为什么是，你的问题是相当主观的，但是角质并不是唯一的问题。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，但是如果有一天角决定放弃1.2并迁移到v2，那么您需要有一个计划。有一些编辑器支持这两种格式。

Answer 2

我想指出官方规格变更 for 2.0中的这一行：

针对注释002，规范现在明确表示，不需要向后兼容XLIFF 1.2。

您还可以从相同的changelog中读取：

针对评论038，模块和扩展被禁止在和更低的结构级别上。

因此，文件可能无法验证这两种格式。

Answer 3

角现在正在接受XLIFF 2文件(参见这里)