最近在实验室内进行一本与开源相关的书籍的英译中翻译工作,而且是多人协同的翻译,不得不感慨翻译确实是门专业性很高的工作,高质量的译本需要投入大量的人力和精力。
翻译技巧
提到翻译标准,大家会立即想到严复先生提出的“译事三难:信、达、雅。”即要在忠实原文的基础上,做到文辞通顺、简明优雅。
有大量翻译类的课程会介绍相关的翻译技巧,在这里就不再系统的赘述,就简单说一下个人的一点体会。
背景知识
翻译专业性书籍一定要有相对坚实的相关背景知识。由于专业性较强的书籍中存在大量与领域知识相关的词汇或表达,如果缺乏专业知识,很容易导致词不达意,或至少显得专业性不足。
就开源领域而言,除了与技术研发相关的一些概念外,对协作流程与工具等也需要有相当的了解,如代码仓库(repository)、拉取请求(pull request)、制品(artifact)、分发(distribution)等概念,如果不了解这些概念,很难做到准确翻译。
更准确的表达
准确的表达是最基本的要求之一,事实上对背景知识的要求也是为了表达的准确性。但另一方面,从较宽泛的英译中场景而言,其实容易出现的问题是对于一些多义词的处理。
在英语中,很多动词都有多重含义,在搭配到不同的短语中时,需要选取相应的中文动词搭配才能做到准确表达,否则就会出现搭配不协调甚至传达错误的含义。
更自然的表达
对于具有专业背景的译者而言,做到准确的传达原文的含义并不算是困难的事情。但由于中英文写作以及不同的作者表达习惯的不同,能够在英译中时在准确传达原文意思的同时做到符合中文的表达习惯并不容易,从这次的翻译经历来看,最重要的可能是以下几点:
从句翻译
个人感觉这是中英文表达形式上最大的不同之处,英文中存在大量的从句形式。包括定语从句、状语从句等很多时候都是以短语从句的形式出现在文中,如果此时按照原文来翻译,会导致中文的句子支离破碎,不仅阅读起来拗口,理解上也会出现困难。
如果对于各类从句的翻译不能很好的处理,会导致整篇文章翻译后有明显的翻译痕迹,阅读体验较差。
所以我也查阅了一些相关的文章,有一个原则很不错,即 8 个以内单词的从句直接前置到原句中,而 8 个单词以上的从句单独翻译。也就是对于较短的修饰性从句,没有必要再单独成句,否则就会导致主句被打散。而单独翻译的从句则应该注意添加合适的连接词,因为英文中的修饰性从句通常直接跟在修饰对象之后,如果直接翻译而没有连接词,会显得翻译非常生涩。
语义精炼
语义精炼也是翻译时比较难以把握的一点,但却非常重要。语义精炼需要在直译和理解原文含义后按照中文习惯重写整句,对于一些复杂的句式即使处理了词语搭配和从句,如果不重写依然会显得冗长和生硬。
事实上有人对不同语言的信息熵做过分析,以中英文圣经为例,其存储空间的比例大约为 1:1.6 左右,但使用 Huffman 编码的情况下占用的空间比例则是几乎一样的,这意味着在传达相同信息量的情况下,中文会比英文简练很多。从信息熵的角度而言,中文的信息熵更大,即中文单词包含的信息可能性更多,同时理解难度也更大。
从个人体验而言,如果能处理好上述几个问题,其实就已经可以处理好书籍翻译中 80% 的内容了,但如果想真的做好一本书的翻译,则需要在一些关键词句上下足功夫才行。
翻译流程
上述只是简要的一个翻译中个人觉得比较重要的一些体会,然而不仅在运用到具体工作中有困难,事实上在多人协作翻译时引入的协作成本带来的挑战同样很大,下面梳理一下这次翻译的整体流程:
上述为拆分章节后每一章有一个翻译成员和一个 Review 成员的情况下的协作流程,基本步骤为:
- 翻译成员首先对该章节通过机器翻译配合人工校对得到初版译稿后提到 chapter1 的分支上
- Review 成员拉取这个分支后进行 review 和修改,并提交到相应的 review1 分支中
- Review 成员从自己的 review1 分支向 chapter1 分支提交一个 PR,该 PR 包含了所有的修改意见
- Review 成员在上述 PR 中对每一处修改意见说明修改原因
- 翻译成员对于每一处修改意见进行评审,认为没有问题就可以 resolve,有问题直接在该意见处的 thread 中进行讨论,并由 review 成员反复修改
- 全部 review 意见 resolve 后即可将 review1 分支合并到 chapter1 分支中,此时双人协作的翻译完成
- 从 chapter1 分支向 main 分支提交 PR,此处没有修改内容,为完整翻译内容的一次性提交
- 团队中其他章节的成员对该 PR 进行共同 review 讨论,并最终合入 main 分支,完成该章节翻译
上述的翻译流程为某一章节的双人协作翻译流程,最终包含了一个团队成员的集体 review,其他章节的翻译流程也类似,其中有些注意的点是:
- 如果一章的内容过多,review 成员提交时可以拆分成多个 PR,这样每个 PR 的 review 讨论可以更加聚焦
- 另外,其实单章的 review 是可以不用 review 分支的,也可以直接提交 PR 并进行讨论。但这样的划分会使工作界面变得模糊,双人协作和集体协作在同一个 PR 中,那么无论是工作空间和时间上的划分都不够明确,从而可能产生更多的沟通成本。
自动化协同工具的产品设计
// TODO