如何在不进行 XLIFF 转换的情况下翻译 DITA 文件

您是否正在寻找一种无需手动进行 XLIFF 转换即可翻译 DITA 文件的方法？ 如果真是这样，那你来对地方了。 DITA（达尔文信息类型化架构）已经是效率和内容重用的黄金标准，但许多技术内容团队仍然发现自己陷入了一个令人沮丧的循环：XLIFF 转换循环。

如果您目前的翻译工作流程涉及将 DITA 文件导出为 XLIFF 格式，将这些文件发送给翻译机构，然后再手动将它们重新导入到您的系统中，那么您损失的可能不仅仅是时间。 你可能会危及你辛辛苦苦建立起来的文档的完整性。

在本文中，我们将讨论手动转换的技术陷阱、管理增量的隐性成本，以及为什么原生 DITA 支持对现代文档团队来说是一项变革性的举措。 读完本文后，您将能够开始优化您的 DITA 翻译工作流程，并朝着更快、更可靠、更具成本效益的流程迈进。 让我们直接开始吧！

XLIFF 技术文档税

XLIFF（XML 本地化交换文件格式）对于很多方面来说都是一个优秀的标准，但对于 DITA 用户来说，它常常充当中间人，使事情变得比简化事情更复杂。 我们通常称之为 XLIFF 税：为了使这种格式得以运作，需要付出时间、金钱和人力劳动，而这实际上是隐形的代价。 这就是为什么这种手动转换过程可能会给你的团队造成比你意识到的更大的损失。

1. 内容重用分解：引用和键引用

DITA 的真正精髓在于它能够跨多个主题引用内容。 将 DITA 文件转换为 XLIFF 时，这些复杂的关联关系通常会被简化或完全破坏。 在标准的 XLIFF 文件中，内容引用 (conref) 可能只是以静态文本字符串的形式出现。

这会造成严重的财务问题：由于转换工具未能将同一个警告说明或安全程序识别为单个可重复使用的实体，您最终可能需要多次付费翻译该内容。 更糟糕的是，当您重新导入该文本时，您可能会发现全局内容引用已被硬编码文本覆盖，这实际上破坏了您的模块化架构，并使未来的更新成为一场噩梦。

2. 标签损坏和验证错误

DITA 文件受严格的 DTD（文档类型定义）或 XML 模式约束。 每次您的内容从 .dita 格式转换为 .xliff 格式，然后再转换回来时，您都有可能创建我们所说的标签混乱。

只需要一名不熟悉 DITA 结构的译员，就可能意外删除必需的属性或放错结束标记。 在 DITA-OT 构建过程中，一个缺失的括号或一个放置错误的属性都可能导致整个构建失败。 我们都经历过这种情况：周五下午，你正准备发布新版本，但你的支持工程师却在成千上万行代码中寻找一个验证错误。

3. 达美航空管理噩梦

手动 XLIFF 工作流程常常迫使作者不再是创作者，而是文件管理者。 为了节省翻译成本，作者通常会尝试手动识别差异（仅识别自上次更新以来已更改的文件）。 这个过程出了名的困难，原因有三：

• 它容易出错：仅仅漏掉一个更新的主题就可能导致文档不同步，从而让客户感到困惑。
• 技术上来说，这很费力：你的团队最终会花费数小时比较版本，而不是编写新的、有用的内容。
• 它缺乏上下文：如果一个主题的微小变化影响到相关主题的含义，手动增量选择很可能会错过它。

超越标签：属性保护的重要性

DITA 到 XLIFF 转换过程中最容易被忽视的方面之一是 XML 属性的管理。 DITA 非常依赖属性进行分析和筛选，例如产品、平台和受众。 这些工具允许您从同一来源发布不同版本的手册。

使用原生 DITA 工作流时，这些属性默认受到保护。 在 MotaWord，我们的系统能够识别出产品属性是元数据，永远不应该被翻译。 在标准的 XLIFF 转换中，这些属性通常要么被剥离（这会破坏您的条件发布），要么暴露给翻译人员。 如果翻译人员看到 pro_version 并将其翻译成西班牙语 version_profesional，则您的条件处理逻辑将不再起作用。

为什么“翻译=否”是救命稻草

translate="no" 属性对于需要保持代码片段、命令行指令或特定品牌名称在所有语言中保持一致的技术写作者来说至关重要。 原生 DITA 解析器会在引擎级别遵循此属性。 在手动 XLIFF 转换中，用于创建 XLIFF 文件的过滤器经常忽略这些指令，这会导致代价高昂且令人烦恼的后期编辑周期，以修复过度翻译的内容。

语境鸿沟：为什么译者难以驾驭 XLIFF 格式

翻译不仅仅是替换词语，更重要的是理解语境。 当 DITA 主题转换为扁平的 XLIFF 文件时，转换器通常会看到一系列孤立的字符串。 他们会丢失地图视图，而地图视图是项目结构的基础。 他们无法看出某个特定的标题属于某个更大任务中的特定部分。

通过使用原生 DITA 翻译，翻译人员可以在一个真正理解 DITA 层次结构的系统中工作。 这能为您的文档质量带来以下几个好处：

• 它提供了更清晰的表达：译者知道一个词是步骤、结果还是前提条件。
• 它确保术语的一致性：该系统确保简短描述中使用的术语与主题正文中的相同术语相匹配。
• 它保持了视觉完整性：信息的逻辑流程保持完整，这在制作复杂的硬件或软件技术手册时尤为重要。

更佳方案：使用 MotaWord 进行原生 DITA 翻译

我们认为技术写作人员应该专注于内容创作，而不是与文件格式作斗争。 这就是为什么我们致力于通过原生方式消除 XLIFF 中间环节的原因。

工作流程比较

手动 XLIFF 工作流程

• 需要花费数小时导出和筛选文件。
• 存在内容引用扁平化的高风险。
• 通常会导致元数据损坏或意外翻译。
• 文件导入后需要进行大量的人工质量保证。
• 人工操作和重复排版产生了隐性成本。

使用 MotaWord 实现原生 DITA 工作流程

• 只需几分钟，即可通过直接上传文件完成操作。
• 100% 保障您的内容完整性。
• 自动锁定或忽略元数据，以确保安全。
• 下载后即可立即提供可直接用于构建的文件。
• 使用翻译记忆库，确保您只为新内容付费。

上传您的原始 .dita 和 .ditamap 文件

您无需进行复杂的导出操作，只需上传原始 DITA 文件或整个 Ditamap 项目即可。 我们的平台旨在原生解析 DITA 结构。 它能够区分标题、正文和简短描述，从而确保您的元数据保持不变，并且您的结构保持健全。

自动化代替手动差异化

由于 MotaWord 使用了集成翻译记忆库，您不再需要花费时间去弄清楚哪些文件发生了变化。 您可以上传整个项目，让系统完成繁重的计算工作：

• 我们的系统会将您的整个 Ditamap 与您之前的翻译进行比较。
• 它能在几秒钟内识别出新增或修改过的字符串。
• 您只需为新词付费，即可享受增量带来的成本优势，而无需承担任何手动操作的麻烦。

构建就绪文档的经济学

XLIFF 转换的真正隐性成本体现在最终的出版周期中。 在人工工作流程中，收到翻译文件仅仅是流程的一半。 您仍然需要将所有内容重新导入到您的 CCMS（组件内容管理系统）中，使用 DITA Open Toolkit 运行测试构建，并调试不可避免的 XML 错误。

本地化质量保证阶段可能需要撰稿人花费数天甚至数周的时间。 原生 DITA 支持确保您下载的文件可以直接使用。 由于该结构从未被拆解以装入 XLIFF 集装箱，因此无需重建。 只需点击几下，即可将翻译完成后的文件发布为 PDF 或 HTML 网站。

常见问题解答

1. 如何在不破坏引用关系的情况下翻译DITA文件？

像 MotaWord 这样的原生 DITA 翻译平台会按照原始 XML 结构处理文件。 通过避免转换为 XLIFF，系统可以保留指向内容引用 (conrefs) 和键引用 (keyrefs) 的指针。 这样可以确保正确处理可重用对象，而不会将其硬编码到翻译后的文本中。

2. 对于小型团队来说，最佳的 DITA 翻译工作流程是什么？

对于小型团队来说，最高效的工作流程是直接使用 DITA 格式。 与其投资昂贵的中间件或花费数小时手动导出 XLIFF 文件，小型团队不如使用可以直接接受 .dita 和 .ditamap 文件的平台。 这降低了技术成本，也省去了聘请专门的本地化工程师的需要。

3. MotaWord 是否支持专用的 DITA DTD？

可以。 由于 DITA 允许特殊化（创建自定义元素类型），我们的原生解析器旨在遵循底层 XML 模式。 您的自定义标签和属性受到保护，除非它们包含可翻译的内容，否则不计入字数统计。

4. DITA 与 XLIFF 在翻译方面哪个更好？

虽然 XLIFF 是通用软件字符串的优秀交换格式，但 DITA 在结构化文档方面更胜一筹，因为它包含更多关于内容重用的上下文信息。 几乎总是最好直接翻译 DITA 文件，因为它能避免在两种不同文件格式之间转换时常见的往返错误。

5. 我能否将原生 DITA 翻译与我现有的 CCMS 系统配合使用？

绝对可以。 大多数组件内容管理系统，如 IXIASOFT、Heretto 或 Oxygen Content Fusion，都允许您导出原始 DITA 包。 您可以直接将这些包上传到 MotaWord，然后将翻译结果重新上传到您的 CCMS，无需任何中间转换步骤。

6. 如何利用翻译记忆库降低DITA翻译成本？

通过将整个 Ditamap 上传到原生平台，系统会使用翻译记忆库 (TM) 从您之前的项目中识别出完全匹配的内容。 您只需为新增或修改的文本付费，这大大降低了长期技术文档项目的成本。

7. 如何处理DITA图像本地化和href链接？

当您以原生方式上传 DITA 项目时，系统会识别图像和链接标签。 您可以指定是否要将这些图像的路径更新为本地化文件夹（例如，将路径从 /images/en/ 更改为 /images/es/），或者保持其原样。 这样可以确保你的链接在翻译版本中永远不会失效。

停止转换并开始使用 MotaWord 进行同步

如果您当前的翻译工作流程感觉像是一个阻碍您前进的手动障碍，那么很可能是时候放弃 XLIFF 转换，转向原生 DITA 工作流程了。 通过消除这些手动步骤，您可以降低文档错误的风险，并显著加快全球发布周期。

你应该把精力放在创作优质内容上，而不是管理文件导出上。 准备好看看您在下一个项目中可以节省多少时间和精力了吗？ 您今天即可通过 MotaWord 上传 .dita 文件获取即时报价。

OYTUN TEZ - MotaWord首席技术官 (CTO)

翻译研究学者，论文研究方向为机器翻译——总体而言是一位技术专家，痴迷于智能、无缝的翻译流程。