文章目录
  1. 1. 将译稿纳入版本管理
  2. 2. 创建一个词条文档
  3. 3. 权衡信、达、雅
  4. 4. 第一遍粗译,第二遍细译,第三遍校审
  5. 5. 每天坚持翻译,日积月累
  6. 6. 翻译技术类书籍,自身实力要过硬

2013年到现在,已经翻译了3本书了,其它杂七杂八的文章也不少。其中有一些经验和教训,势必要总结一下。

将译稿纳入版本管理

没有版本管理的代码修改起来是战战兢兢地,而译稿也类似。我习惯在GitHub上创建一个私有的仓库(我是GitHub的会员),把与该书相关的内容都放置上去,每翻译一点就迁入一次,保证任何修改都可以追踪。

创建一个词条文档

在翻译书的过程中,难免会遇到很多专业词汇,有些专业词汇有统一的翻译,而有些则没有,需要自己权衡后给出一个翻译结果。最好把这些词汇都放置到一个独立文档中,这尤其对多人合作翻译的情形相当有用。可以保证整本书对专业词汇翻译的一致性,也便于以后修正某个词条的翻译。

权衡信、达、雅

信、达、雅是青末启蒙思想家严复提出的概念。”“信”指意义不背原文,即是译文要准确,不歪曲,不遗漏,也不要随意增减意思;“达”指不拘泥于原文形式,译文通顺明白;“雅”则指译文时选用的词语要得体,追求文章本身的古雅,简明优雅。我所翻译的都是一些技术性书籍,信肯定是占首位。而英文被动句较多,长短句结合,要通过“达”的方式来变换句式,符合中国人阅读习惯。“雅”则注重用词的准确性,是个比较难达到的标准。

第一遍粗译,第二遍细译,第三遍校审

一般在翻译时我是按段落为单位的。先看一个段落,看懂了以后再把整个段落翻译出来。其中遇到不是很懂的句子先空下来,等到整章或整节翻译完成以后再回头看。这是因为我发现翻译时也有2/8原则。全文有80%的内容很好翻译,而20%的内容则比较难翻译。如果在翻译的过程中碰到20%难翻译的地方就努力攻克的话,会把翻译的时间的打散,进度会很慢。而第一遍粗译,跳过难以翻译的地方,第二遍时再补译的好处是,由于你已经翻译了整章,建立了良好的上下文关系,对付1,2句话那还不是小意思。此外还有心理因素,整章只有几句话没翻译,心里比较轻松,也更容易激发灵感。第二遍全部翻译完毕后,第三遍就是仔细校审了,这时候主要注意力就是句式的结构调整、词汇调整了。

每天坚持翻译,日积月累

一般翻译一本书编辑会给出时间限制的。而我翻译只能利用业余时间,可以说时间非常有限。如果三天打鱼、两天晒网,很容易堆积到最后,由于赶工而影响质量。所以养成良好的翻译习惯是非常必要的。可以每天至少翻译两页,周末多翻译一些,这样积少成多,水滴石穿,遇到节假日再突击一下,这样利用时间才是最合理的。自己也不会感觉有压力。

翻译技术类书籍,自身实力要过硬

我翻译的三本书,一本是关于JavaScript的,一本是关于HTML5和CSS3的,另一本是关于C# 多线程编程的。虽然这方面我之前都有所涉猎,但是为了保证翻译的质量和技术术语词汇的准确性,我会通读很多与之相关的书籍。以《Effective JavaScript》这本书为例,在翻译这本书之前我已经读过好几本与之有关的书了,但是为了保证翻译的质量,这毕竟是我翻译的第一本书,我不仅阅读了Effective系列的其他书籍(比如《Effective Java》),也阅读了大量与JavaScript有关的书(比如《JavaScript高级程序设计》,《JavaScript语言精粹》,《JavaScript权威指南》等)。通过大量的阅读与练习,我对原文的理解更加轻松,对词汇的翻译也更加准确。


翻译技术类书籍其实不难,有志于此的程序员们可以先将英语练好,多读几本英文技术类书籍,然后找一些自己喜欢的文章练练手,说不定有一天哪本译作上就有你的大名。

文章目录
  1. 1. 将译稿纳入版本管理
  2. 2. 创建一个词条文档
  3. 3. 权衡信、达、雅
  4. 4. 第一遍粗译,第二遍细译,第三遍校审
  5. 5. 每天坚持翻译,日积月累
  6. 6. 翻译技术类书籍,自身实力要过硬