主要问题是：我应该如何构建XLIFF的结构以使其可用？
我所拥有的：
一个XLIFF项目，我想将可翻译内容导出为MessageCatalogue。我的意思不是捆绑翻译，而是数据库中的动态内容。
到目前为止，我已经编写了一个捆绑包，该捆绑包使用XliffFileDumper来收集内容，并使用XLIFF来编写XLIFF文件。
这给了我一个平实的XLIFF，其中包含要翻译的内容。我猜这不是很有用。
示例：页面具有内容。目前，我只是将所有内容收集在一个平面MessageCatalogue => XliffFileDumper中。将文件交给翻译者，他/她将不知道哪个内容属于哪个页面。不好，对吧？
此刻我使用的<file id="content.fr">方法似乎有点受此限制。我可以添加元数据（注释），但是不能使用组。似乎不可能在一个单元中添加多个段。
我可以设置的是一个“域”，例如，它会产生(domain=content)标签XLIFF。
以这种方式构建有用的XLIFF真是太好了，但是请告诉我是否可以。比我需要写一个定制的symfony自卸车。
想法： 我可以在每个页面上使用一个域，从而导致文件很多？好的做法？ 我可以在元数据/注释中添加有关父页面的信息。翻译者甚至可以利用它吗？
文件结构的最佳做法是什么？ 如果有人知道{{1}}捆绑包会有所帮助，请告诉我。
答案 0 :(得分：1)
鉴于您当前提到的自卸车限制，您无法构建基于最佳实践的有用XLIFF。
如果您要优化自卸车，我建议先阅读此内容 https://galaglobal.github.io/TAPICC/T1/WG3/rs01/XLIFF-EM-BP-V1.0-rs01.xhtml
基于上述，使新的转储程序参数输出为XLIFF 1.2，XLIFF 2.1或XLIFF 2.0。 XLIFF 2.1 http://docs.oasis-open.org/xliff/xliff-core/v2.1/os/xliff-core-v2.1-os.html是向后兼容XLIFF 2.0的最新版本，但不向下兼容XLIFF 1.2。 CAT（计算机辅助翻译）工具对XLIFF 1.2的支持仍然大于XLIFF 2，但是OASIS技术委员会不再维护XLIFF 1.2。
您的新转储工具应支持对具有源资产元数据的提取文件/组/单元进行递归分组和修饰，有关操作方法，请参见上面的最佳实践文档。如果这样做，CAT工具将能够将其显示给翻译者，他们会发现它非常有用。 基本上，每个结构元素都有一个专用属性来存储所提取资源的ID，即文件上的@original，组和单元上的@name。您还可以在@type中存储私有nmtoken：前缀字符串。如果这还不够的话，您可以在框架或资源数据模块中存储更多的往返数据。两者都可以是内部或外部的。
还建议从XLIFF 2核心开始，仅在成功完成核心往返之后添加模块数据。
fs模块是一个非常有用且易于实现的模块，它可以更轻松地为翻译人员生成HTML预览。
注释<note>不应仅用于翻译人员易读的指令/警告/注释来用于元数据往返。
您猜到了，转储程序应该能够创建分层结构。您无需费心分割单元。但是可以创建具有更多细分的单位。再次查看最佳实践文档，以了解何时有意义。.您应该始终能够在任何单位内收到不同数量的细分。但是内容不能跨单元边界迁移。
一个单元内的分段编码是XLIFF 1.2和XLIFF 2之间的主要区别。您需要详细了解规格。