• 感谢赞赏!给好友秀一下吧

    内容棒,扫码分享给好友

  • 评论
  • 收藏
  • 点赞
    点赞

我的科技翻译经验总结

我的科技翻译经验总结

本文来自公众号: 余晟以为(ID:yurii-says),作者:余晟,头图来自:视觉中国


按:以前我写过一本电子书《翻译漫谈》,主要是总结自己的翻译经验。没想到这么多年过去了,早已经免费开放阅读,仍然有朋友找我讨要、讨论这本书。我去豆瓣阅读看了下,大家的评价还挺让人欣慰,而且不断有新的反馈。所以我修订扩充了原书的一些篇章,发在这里。



传统上,翻译与文学的关系很近。说起翻译,许多人首先想到的是“文笔要好”。近年来随着信息交流的发展,实用型文本尤其是科技文献的翻译越来越显得重要,许多科技领域的从业人员也有兴趣或有动力翻译科技文献,并取得了大量成果,突出表现之一就是IT类书籍的翻译质量有了很大的提升,这背后的功臣很多都是IT界的“翻译票友”。


科技翻译是大大繁荣了,科技翻译自身的学问却没有相应的进展,各种翻译教程和经验总结仍然侧重于一般的翻译或文学翻译。然而深入了解翻译的人都知道,不同文体、不同领域的翻译是各有特点的,而不能不顾原文,一味追求“信、雅、达”。比如新闻翻译追求简洁、准确、吸引眼球,文学翻译更强调完整、流畅、意境贴切。这种差异贯彻到翻译实践当中,产生了很多讲究,所以新闻才能译得像新闻,小说才能译得像小说。同样的道理,科技翻译也不能完全照搬普通翻译的做法,要想做好它,还必须了解其自身的特点。根据我的总结,科技翻译大致有以下几个特点。


第一,科技文献通常是用来讲道理的,所以译者必须准确理解文字表达的道理。


这里说的“讲道理”不是狭义的“说理”,而包括讲解原理、研究论证、实验分析等等,换句话说,科技文献的内容是可以用理性分析的客观现实,所以读者的理解也应该可以客观衡量。文艺作品没有这个特点,经常是“言有尽而意无穷”,可以“一千个读者就有一千个汉姆雷特”,科技文章则要求“有九分把握不说十分话”,必须“一千个读者只能有一个汉姆雷特”。所以,科技文献的译者不但要懂得原文,还必须准确理解原文。以前有几家出版公司的IT类翻译图书之所以被大家痛骂,很大程度上并不是因为译者的文字水平不够好,而是因为译者根本不懂也不愿意弄懂作者在说什么,这样的译文会被读者痛骂。


科学技术本身有客观标准可循,所以科技文献的意思理解起来反而比文学作品更容易,因为译者不必拘泥于原文。假设原文先讲了甲乙两个算法,然后下了比较的结论,但只是说“一个算法比另一个好几倍”。单纯从文字来看,很难知道到底是哪个好,哪个不好,但这个问题难不住科技翻译的译者,因为他可以亲自动手编程实践。要知道,逻辑和程序是绝不会因人而异的。推而广之,译者完全可以独立验证自己的理解是否准确,而理解准确恰恰是译文合格的前提条件。


类似的例子还有:


乔布斯是很有能力的工程师,和沃兹尼亚克不可相提并论。


“不可相提并论”当然是说两者大不相同,但这里到底要表达的是什么意思呢,谁的水平更高?在我看来,如果一定要读者熟悉苹果早期的创业故事,才能读懂这个句子,那么译者是不合格的。译者完全可以也应当根据自己对背景知识的了解,澄清这一点,改译为:


乔布斯也是很有能力的工程师,但远比沃兹尼亚克逊色。


这个例子我只是看了译文觉得有点别扭,翻了原文才知道“不可相提并论”的原文是not in the same league,本身就有“远远不如”的意思。严格说起来,译文在这里是有瑕疵的,起码原文的转折意思没保留。


我建议,科技文献的译者在翻译完成之后,应当抛开原文来读读,想想是否能明白作者要讲解的知识、原理、规律。如果做不到,那么译文多半不合格。


第二,科技翻译的译者完全可以适当改动原文。


上文已经说过,科技文献的一大特点是其论述内容有客观标准可循,所以译者可以借助“文字之外”的信息来验证自己的理解。这可以算科技翻译的独门优势,而且这点优势相当有价值。因为科技文献的作者往往不是专门的文字工作者,不能奢求他们有很高的写作水平,某些片段可能讲解晦涩,难以理解,或者原作者并没有为译文读者考虑(实际上这种情况相当普遍),使用了一些专属于某些文化的典故、俚语。


如果是文学翻译,遇到这样的问题会非常麻烦,摸不准原作者到底是什么意思。科技翻译则没有这种问题,译者一旦确认自己理解了原文的内容和逻辑,就可以大胆改动译文读者难以理解的片段,避免译文读者在同样的问题上浪费精力。


我曾在技术文章中见到作者评价某种做法的难度“和拯救麻风病人一样”。根据上下文猜测,这里大概是说难度不小,不过非要理解为难度很小似乎也说得通,因为现在麻风病似乎很少见了,也很少听说治疗很麻烦,所以我不敢确认。译者尚且如此,见不到原文的读者估计就更难以确认了。


于是我专门去查了资料,原来这里作者指的是在斯里兰卡的非政府组织、慈善机构、公共关系公司、卫生部门为拯救麻风病人的进行了长期的艰苦努力,那么意思当然是难度大了。所以最终翻译为“和拯救麻风病人一样非常艰难”,这样就确保读者不会误解。


再举一个例子,有篇译文讲的是如何用正则表达式匹配独立的单词,原文有:


so, if inline appeared in the sentence, the regular expression will match not in but inline.


这样处理,如果句子中出现了inline,表达式匹配的是inline,而不是in。


这个翻译是不恰当的。英文本身就是以词为单位的,所以阅读原文时当然知道其中的inline、in都是指的“单词”inline、in,而不是“字符串”inline、in。但中文的词汇之间并没有形式分隔,所以读者有可能把“这句话包含inline”理解为“这句话包含字符串inline”。如果译者大胆将“单词”两个字增补进去,译为下面这样就避免了误解:


这样处理,如果句子中出现了单词inline,表达式会匹配inline,而不会匹配其中的in。


以上两处改动都出自译者之手,目的都是为了保证读者的正确理解,保证“一千个读者只有一个汉姆雷特”,且译者这么做有足够的底气这么做。当然,如果译者觉得应当尽量避免改动原文,也可以保留原文,辅以注释说明,这个道理相当简单——发布有缺陷需要用户自己打补丁的软件,与发布官方已经打好补丁的软件,显然大家都喜欢后者。


第三,在“顺”与“信”发生冲突时,科技翻译选择信而不顺。


“顺”和“信”的取舍,是老一辈翻译家非常关注的问题。所谓顺,指的是文字通顺、流畅,所谓信,指的是准确、忠于原文的形式。因为语言习惯不同,所处的文化不同等原因,翻译时难以“形神兼备”的情况是时常出现的。要译文流畅,可能就要对原文做较大改动;要尽量不改动原文,文章又无法流畅。对这个问题,不同的文体有不同的处理。


在“信”与“顺”之间,文学翻译更偏向“顺”,如:


the night breeze came with pleasant guitar


原意是“晚风和好听的吉他是一起来的”,但这样表达很别扭,故可以改为“晚风送来美妙的吉他”,这是取“顺”而弃“信”。但如果科技文章中出现the data come with noise,翻译为“数据送来了噪音”就是严重的错误,只能译为“数据是和噪音混在一起来的”,这是取“信”而弃“顺”。尽管看起来比较直白简陋,但很多技术文献本身就是直白简陋的,翻译时一味追求译文的“顺”,不但丧失了科技文章看重的准确信,即便从翻译本身来说,也有涂脂抹粉、文过饰非的嫌疑。


要补充的是,“信”和“顺”舍弃一定要在“信和顺无法调和”的前提下进行,“信而不顺”绝不是不动脑筋硬译的借口。即便是坚持信而不顺的鲁迅先生也说过:信而不顺,绝不是舍弃“跪下”而保留“用膝盖站立”,不是舍弃“银河”而保留“牛奶路”,不是舍弃“创刊”而保留“发行了第一期”,也不是舍弃“火箭筒”而保留“火箭推进榴弹发射器”。实际上,大量科技文章都是非常浅显直白的,译文对译文读者的要求不应当高过原文对原文读者的要求,尤其是不应当人为抬高对读者文字理解能力的要求。


第四,科技翻译时,译者应当对译文专业领域有所了解。


这方面最明显的例子就是关于武器的。众所周知,英文里的“枪”和“炮”都可以用gun,比如机枪是machine gun,加农炮是cannon gun。简单说,在英文里gun有许多种,“枪”和“炮”都是之一。然而在中文里,“枪”和“炮”的定义是截然分明的:口径在20mm以下的是“枪”,口径在20mm以上的叫“炮”。所以正常来说,你看到的应该是 7.62mm步枪,12.7mm机枪,20mm机关炮,75mm榴弹炮等等。


大概是不少译者不具备这种背景知识,所以翻译时经常搞错。英美国家一般使用英制单位而不是公制单位,所以口径描述一般用.30或者.50。其中.30对应“0.30英寸”也就是7.62mm,.50对应“0.50英寸”也就是12.7mm。但是查阅相关译文,经常出现“30mm步枪”和“50毫米机枪”的说法。


如果不熟悉.30或者.50的单位,把英寸和毫米搞混尚且情有可原,但“30mm步枪”和“50mm机枪”的说法就充分显示了译者对专业领域缺乏认知。即便不知道超过20mm口径应当叫“炮”,按常识推断,枪弹一般是食指粗细,30mm口径有两三指粗,成年人单手通常只能握一发,步枪能不能发射这种弹药?弹匣会多大?普通士兵能携带多少发这样的弹药?依靠常识不难发现其中的问题。


寻常弹药的直径和成人手指类似,“30mm“是它的三四倍粗,根本放不进弹匣。 来源:pixabay


不要以为军事领域的单词很偏门,一般不会遇到。实际上如果你留意身边的译文乃至报道,就会发现这样的错误比比皆是。


在前几天的新西兰枪手事件爆发后,许多报道都提到“枪手腿上绑了很多杂志”。枪手要去行凶,杂志不能防弹,只能让行动更笨拙,为何会这样?原来是译者缺乏军事知识,只知道magazine是“杂志”,却不知道它也表示“弹匣”。


第五,科技翻译也需要了解基本文化知识。


我们经常说,好的专业文章也可以写得“深入浅出”。要做到这一点,免不了借用一些日常生活中的经验和例子。但是,不同文化的生活经验可能是相差迥异的,如果译者缺乏基本的了解,就很可能犯错。


比如一篇以网络通讯为主题的文章,借用了无线电通讯的场景来讲解。在美国,也许私人电台、无线电步话机很普遍,所以这种讲解是很生动的。但是中国的情况与此不同,读者和译者可能并没有太多的切身经验,这时候就要加倍小心。遗憾的是,译文里就出现了:


罗杰,准备发送下一批数据。


好玩的是,之前和之后都没有出现过“罗杰”这个人名。这个其实不用看原文就知道,“罗杰”的英文是roger,因为在句子开头,所以首字母大写,被译者误以为是人名。但是,如果留意过无线电通话就会知道,roger并不是人名,它的意思就是“收到”,是无线电通话中很常用的说法,所以正确的译文应当是:


收到,准备发送下一批数据。


再比如,一篇协商系统的文章里有这么个场景:主持节点询问所有参与节点,是否有反对意见。如果没有反对意见,那么主持节点就会说:


通过……通过……完成了。


读者看到这里明显会觉得奇怪,既然通过是确定的,为何要一再说“通过”,最后明明没开始,为何说“完成了”?查阅原文,主持节点的信息是going…going…gone,这其实是借用了拍卖官在一锤定音之前喊的“第一次……第二次……第三次,成交!”,所以对应的译文应当是


第一次……第二次……定了!


另外一个常见的翻译错误是人名。英文里经常有一些人名是代引号的,译者大概不知道这是什么意思,就直接照原样翻译过来了。类似下面这样:


the commander is Virgil Ivan "Gus" Grissom


指令长是维吉尔·伊万·“格斯”·格里索姆


the captain is Bernard “Bud” Kauderer


艇长是伯纳德·“巴德”·科德罗


这都是不妥的,读者会看得莫名其妙。因为正常人的名字不会打引号,父母给小孩取名时也不会弄一个带引号的名字。


那么这里的引号是什么意思呢?其实它就是“昵称”、“诨名”、“爱称”,通常是非正式但流行的称呼,就等于我们熟悉的“大刘”、“老张”、“建平”之类。Virgil Ivan "Gus" Grissom是美国首批七位宇航员之一,如果你留意过相关的纪录片或者电影,会发现大家都叫他Gus,虽然他正式的名字是Virgil Ivan Grissom。


the commander is Virgil Ivan "Gus" Grissom


指令长是“格斯”——维吉尔·伊万·格里索姆


the captain is Bernard “Bud” Kauderer


艇长是伯纳德·科德罗,大家都管他叫“巴德”


另一个常见的例子是Colonel,虽然首字母大写,但它不是人名而是军衔,也就是“上校“。可是据网友考证,新华社的报道在前后十六年间,都把它翻译为“科洛内尔”,所以世界各国都有“科洛内尔”占据重要位置:


菲律宾军方发言人科洛内尔·布埃纳文图拉·帕斯夸尔说……(2005年报道)


军方发言人科洛内尔·乔纳森·旁斯说……(2009年报道)


科洛内尔·艾哈迈德·阿卜杜勒拉扎克主管也门哈德拉毛省军事情报(2013年报道)


均来自新华社报道


译者如果平时没有留意过这些文化细节,单纯比照原文的文字,就容易犯下这类错误。不过它们也不难避免,如果译者足够留心,会发现“罗杰”也好,“通过……通过……完成了”也好,单纯从文章来说也不通,和描述的场景冲突。如果能发现这点,对着原文多查资料,也可以避免这类问题。


第六,科技翻译时,译者应当对加倍小心应对专有名词(术语)


专有名词是科技文章中大量用到的词汇,专用来指涉一些约定俗称的概念。因为科技行业的发展水平不同,现代科技专有名词的大部分都来自西方国家,所以必须翻译出来。物理、生物等领域的专有名词许多都是组合而成,翻译相对容易,如magnetic field翻译为“磁场”,haemoglobin翻译为“血红蛋白”(希腊文的haima“血”和拉丁文的globin“球”)


不幸的是,IT行业的情况特殊,这个行业许多人心态很年轻,思维很开放,很多术语是从生活中借鉴而来,翻译起来反而麻烦。比如buffer和cache两个词,本来buffer指的是“逃生气垫”,cache指的是“隐匿的存放处”,引申出计算机里的“缓冲”和“缓存”是非常形象自然的。中文的“缓存”和“缓冲”属于针对具体领域专门创造的术语,虽然已经约定俗成,毕竟割断了原来的形象感,导致初学者见到“缓存”和“缓冲”以为是全新发明的东西,甚至很多人会混淆这两个名字相近的概念,不得不需要花很多时间去记忆“缓存是透明的”,却不知道cache本来就有“隐匿存放”的意思。


可见,术语的翻译一定要加倍小心。这方面好坏例子都很明显。好的例子如表示空气污染级别的beyond index翻译为“爆表”(应该是我最早这么翻译的,有据可查),即便不认识beyond index的人,一看“爆表”也知道意思。坏的典型比如case-sensitive翻译为“大小写敏感”——据我观察,几乎没有初学者第一眼能看懂“大小写敏感”是什么意思,不少人还以为IT行业的术语就是这个怪调调。


真正的原因其实是这个译名错了。查阅词典可知,sensitive除去表示“感觉上的敏锐”,还有一个意思是“有能力区别和分辨”,所以case-sensitive的真正意思应当是“能区分大小写”(“敏感”和“有能力识别”有一定联系,但区别很大:“不识好歹”不等于“好歹不敏感”,“是非分明”也不能说成“是非敏感”)。好在如今越来越多的资料已经开始采用“区分大小写”的说法,免去了很多初学者的疑惑。


译者不够谨慎造错一个术语,会影响到无数后来者的学习。所以这样说来,我觉得cookie不翻译反而是好事,有人非要翻译为“小甜饼”反而画蛇添足,因为中文世界里大多数人都不知道“小甜饼”是什么,有什么作用,也不知道HTTP Cookie其实来自magic cookie,所以直接说cookie反而更好。


即便一些专有名词已经有了译名,译者也应当记得,这些译名一般只适用于狭窄的领域内,不是放之四海而皆准的译法。比如plug and play,大家都知道这是“即插即用”,如果在讲解程序的文章里出现,比如


Having these code snippets, are you ready to plug and play? 


翻译为“即插即用”就不合适了,因为这里作者是调侃性地借鉴硬件的“即插即用”,谈的并不是硬件标准,而是“把代码直接拿过来用”的做法。所以不妨翻译为“即抄即用”,这样保留了愿意,读音也接近“即插即用”,便于读者理解,甚至原文的一点点幽默感也保留下来。如果译者想不到“即抄即用”,至少也应当在“即插即用”外面打个引号。


类似的例子还有正则表达式中的character class,许多译者一看到class,就立刻想到“类”,所以character class就翻译为“字符类”。但是“类”这个词在IT知识体系里有专门的意思,它表示某种类型的对象定义变量和方法的原型,是对现实中一类有共同特征的事物的抽象。character class翻译为“字符类”,就会让读者联想到“对象”等等一系列概念,在有的语言中甚至真的有类名叫Character,这就更容易混淆了。其实character class里的class只表示“组合/集合”,类似表示“班级”的class,所以应当翻译为“字符组”更合适。


总的来说,我认为科技翻译的特点就是如此。它不会要求译者有极高的文学造诣,但并不意味着放低了对译者的要求。无论是从逻辑的严密、歧义的避免上,还是背景知识的理解和术语的准确性上,科技翻译都有更高的要求,而且许多时候有成文、成型的习俗和规范,不像文学翻译有那么多自由发挥的空间。不过我相信,这些要求对负责任的译者来说不是问题——须知道,科技行业工作,本身也离不开严谨、细致的工作习惯。


本文来自公众号: 余晟以为(ID:yurii-says),作者:余晟

*文章为作者独立观点,不代表虎嗅网立场
本文由 余晟以为© 授权 虎嗅网 发表,并经虎嗅网编辑。转载此文章须经作者同意,并请附上出处(虎嗅网)及本页链接。原文链接:https://www.huxiu.com/article/290333.html
未来面前,你我还都是孩子,还不去下载 虎嗅App 猛嗅创新!
+1
16
说点什么