
“您对多语言源文件格式有多少了解?”
去年年初,在我的团队要改进 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 下载……何不去自己看看?
有关我们新的多语言应用的更多信息,请访问: