“您对多语言源文件格式有多少了解？”
去年年初，在我的团队要改进 Trados Studio 对多语言源文件的支持时，有人问了我这个问题。当时我对这个主题知之甚少，只知道它们包含多种语言的可翻译内容，布局不遵循标准格式，这给我们造成了极大的难题，导致我们很难提供通用支持。
我对这个问题的回答是，我们何必要优先考虑对多语言格式的支持？Trados Studio 已经可以处理双语文档了，不是吗？ 也就是说，创建源文件的多个副本，然后为每个目标语言创建双语文档，如魔法般粘贴现有翻译，翻译其余没有译文的内容，在完成后再挥挥魔法棒，将所有翻译粘贴到多语言原生文件中，这样做不是更简单吗！
是的，前提是您是可以在夏尔御风而行的甘道夫，而且这种魔法并不容易掌握。 项目经理往往要使用两个命令（Ctrl + C 和 Ctrl + V）来完成繁琐的任务，在准备期间首先将现有译文复制粘贴到双语文档中，在翻译完成后再将译文复制粘贴回多语言源文件中；不用太久，他们就会得上鼠标手的毛病……
是什么原因让多语言格式在翻译环境中如此难以管理？为什么我们不管理多语言文档，而要使用标准的双语文档呢？计算机辅助翻译 (CAT) 工具包含许多特性和功能，旨在支持语言服务专家更快地交付项目，同时确保质量和一致性。它们可从各种源文件格式中提取可翻译内容，并为每种目标语言生成双语格式的文件 (SDLXLIFF)。
为了更好地理解相关挑战，我们来解释一下为什么不在翻译环境中引入多语言文档。让我们考虑一种典型的情况，例如我们需要将内容翻译成多种目标语言，我们希望将翻译工作分配给擅长这些语言的不同语言服务专家。 这个流程适用于管理双语文档，因为通常情况下，一种目标语言会由一名译员处理。使用 CAT 工具，您可以分别分发各个双语文档。
现在我们再来考虑一下，一种语言的分段可能与另一种语言的分段截然不同。 这可以在双语文档中准确无误地表示出来，因为源内容和目标内容之间是 1:1 的关系，所以您可以进一步拆分和/或合并多个翻译单元 (TU)，同时保持原始段落的完整性。在多语言文档中，这需要像甘道夫一样高超的魔法技能才能做到，因为每种目标语言都可能需要对源内容进行不同的分段，因此您也就无法在单个翻译单元中对齐多条翻译。
您是不是开始意识到，真正的问题不是“为什么我们不在 Trados Studio 中管理多语言文档”，而是如何让以双语为主的环境管理多语言格式。
最初，您会认为 Trados Studio 能很轻松地完成这项任务，因为它已经具有很多核心功能，你能够创建任务，从源文件提取可翻译内容，基于源文件创建双语文档，然后分析、预翻译等…… 那么，为了从多语言源文件中为每种目标语言创建双语文档，自动化执行这些流程有多困难？事实证明，这一点也不困难！Trados Studio 提供的 API 使开发人员能够根据需要创建自己的文件类型和批处理任务。
因此，为了解决在 Trados Studio 中支持多语言源文件的问题，我们发现最实用的方法是开发一种可以利用 Trados Studio 已有核心功能的文件类型，然后引入两个新的自动化任务。第一个任务“导入多语言翻译”，用于导入目标语言以及帮助译员理解内容的任何其他上下文信息。 这个任务在使用常规 Trados Studio 断句规则对源文件进行分段后执行。 我们需要考虑的是，我们没法始终让原文句子准确映射到目标句子，因为段落中的句子可能会更多或更少，在翻译时没办法准确地实现一一对应，因此，如果段落包含多个句子，则目标译文仅对应于第一个原文句子。 第二个任务“生成多语言翻译”，它将在项目完成后重新生成多语言源文件。这样，不用再复制、粘贴或创建脚本，即可将翻译导回到原始多语言源文件中。
首先，我们开发了对多语言 Excel 和多语言 XML 文件格式的支持，因为这是翻译中最常用的两种多语言格式。多语言 Excel 文件是游戏行业提供字符串进行本地化的标准格式，通常用于存储术语。
随 Trados Studio 分发的 API 是我们生态系统的重要组成部分，它们使开发人员能够在其翻译环境中添加独特的功能，从而满足其业务需求。 Trados AppStore 团队开发的多语言文件类型就是其中的几个示例，正如我们创建的大多数软件一样，GitHub\RWS 社区也提供了它们的开源代码，可供用户下载。我们鼓励所有开发人员参与这些项目的开发，这样我们就能相互学习，继续提供创新的解决方案，携手解决共同面临的问题。还有许多第三方开发人员开发的应用的成功案例，这些应用均可从 RWS AppStore 下载……何不去自己看看？
有关我们新的多语言应用的更多信息，请访问：
