CSDN博客

img DrCMM

浅谈计算机图书的翻译——“增值翻译”的几个参考例子

发表于2002/7/11 9:13:00  2298人阅读

我的一篇文章,请大家提提意见( w-gao@263.net ),笔者的小小心愿是将“增值翻译”发展成一门可操作性极强的理论,:-)


----------------------------------

浅谈计算机图书的翻译——“增值翻译”的几个参考例子

作者:高巍(网名DrCMM),地址w-gao@263.net。本文欢迎转载,欢迎大家来信交流讨论。转载时请保留本声明,谢谢。


今年5月,我就个人对科技翻译的一些粗浅认识向技术作家侯捷先生请教。在给侯捷先生的电子邮件中我提出了“增值翻译”的想法,强调应该改变传统翻译中以原文和原作者为中心的做法,而要“以读者为中心”,给译者以自由。侯捷先生随后以《“增值翻译”与“译者的自由”》一文回复,鼓励后学。

“增值翻译”的概念实际上很简单,就是在保证原文技术实质的前提下,尽量有助于读者对技术内容的理解。在我接触的国外技术图书中,除了少数几个如C++之父Stroustrup,原作者的文笔一般并无过人之处。而且,我想,读者阅读一本技术图书的目的并不是了解原作者的写作笔法和叙述风格,相应地,译者在翻译时的重点也不应该是尽量符合原书的文字。今天,大量译作中随处可见的洋腔洋调、别扭句式就是传统翻译理论带来的直接后果,影响了读者的阅读体验。

有关翻译我是一个门外汉,自己的工作也与翻译完全无关,应该说只是“外行看热闹”,对于该领域没有置喙评论的资格。我对翻译的一点浅陋认识主要来自以下几个方面:

(一)个人读书经历
做程序员的,难免要读到一些翻译过来的技术图书。读得多了,特别是当好不容易弄懂了一个问题再回过头来看时,常常不免发出这样的感慨,“挺好懂的一件事情,干吗要说得这么晦涩别扭,如果换一种说法,完全不必要让读者费那么大劲才能弄明白。”
久病成良医。良医不敢当,但是再读到别人的译著时,起码敢说一句,“没吃过猪肉,还没见过猪跑吗?”

(二)作家王小波
如果能够勉强攀关系,我与王小波先生还是校友兼系友。我非常赞同王小波先生关于阅读体验应该“有趣”的提法,对于内容本来就难的技术书籍,译者更应该体谅读者,不要在文字上为难读者,而要尽量降低读者在文字方面的困难,可以将主要精力用于理解和吸收技术知识。

王小波先生在《我的师承》一文中,这么写道:
“假如中国现代文学尚有可取之处,它的根源就在那些已故的翻译家身上。我们年轻时都知道,想要读好文字就要去读译著,因为最好的作者在搞翻译。这是我们的不传之秘。”
“到了将近四十岁时,我读到了王道乾先生译的《情人》,又知道了小说可以达到什么样的文字境界。道乾先生曾是诗人,后来做了翻译家,文字功夫炉火纯青。他一生坎坷,晚年的译笔沉痛之级。”

因此,因了王小波先生的介绍,我得以接近傅雷、王道乾和宗白华等先生的译文。

(三)《性心理学》
科技著作方面的翻译,潘光旦先生(曾任清华大学校长)译、英国蔼理士原著的《性心理学》是我认为最佳的译本,三联书店版。潘光旦先生的译本,原文和潘先生的译注篇幅接近一半对一半的比例,潘先生从中国古代的史籍、方志、笔记丛刊中整理了大量佐证材料,使得读者阅读兴味盎然。
在过去那个精神极度空虚和苦闷的年代,一个青年想了解性知识,同时又要拒绝那些下三滥的东西以及避开政治上的风险,他很自然地会发现这本书是一个安全的选择(毕竟,有三联的牌子和清华校长的身份)。当然,现在的青年就很“幸福”了。

(四)《21世纪经济报道》和《经济观察报》
大学的时候随喜众人,去考TOEFL和GRE,听说阅读Economist(《经济学人》)、New Republic(《新共和》)、Foreign Affairs(《外交季刊》)能长英文的功力,所以不管读不读得懂还是硬着头皮去读。虽然,后来GRE终于没有去考,但是阅读的习惯却留了下来。

国内的新媒体对国外媒体的抄袭和剽窃是一个公开的秘密,但有翻译的好、抄的巧妙的,也有翻译的差,抄都不会抄的。相对来说,《21世纪经济报道》和《经济观察报》是抄袭和剽窃得比较成功的,起码翻译的质量比较高。从这两份流行报纸上,我常常毫不惊讶地发现Economist、Wall Street Journal上熟悉的文字,当然也学到了一些比较高明的翻译技巧,特别是一些比较好的欧化句式。这些欧化句式,对于英语中的一些长句、难句,特别是那些句子成分较复杂,又多倒装、插入语、同为语和从句的句式,往往有独到的功效。

 

“增值翻译”是一门实践的艺术,空谈理论无益,如果不自己动手做一做,很可能是眼高手低的尴尬情形。我对“增值翻译”的观点是,

“原文仅仅是一个blueprint,译者可以根据读者对象的水平范围、阅读兴趣,大胆的增删调整(尽量少删,而以“注”和“评”为主),使得译本更适合特定目标读者对象群体。”

这个观点究竟读者是否接受,多大程度上接受,对于一个标榜“以读者为中心,而不是以原文为中心”的翻译理论而言,是非常关键的。特别是,如何把握增删调整的度,更是一个敏感的问题,侯捷先生就对“删”持很谨慎的态度。因此,我尝试着对一些经典技术著作的名家译本中的若干段落给出自己的译文,主要选自潘爱民先生译的《The C++ Primer》,裘宗燕先生译的《The Design and Evolution of C++》,以及侯捷先生译的《Refactoring》、。希望大家能够比较一下,多提意见,使我能够继续不断使得“增值翻译”更具可操作性。(个人一点私心和一点宏愿,请大家体谅。)

自己决没有与这些尊敬的译者比较的意思,只是希望愿意与对技术翻译感兴趣的朋友们交流,获得一些启发和提示,使作为读者的我能够有幸读到一本又一本优秀的译著,更加有利于技术的普及。CSDN的孟岩(myan)先生曾经作愤激之语:读者能够读到优秀的译著是一种幸运。我更希望,读到优秀的译著是读者对于译者最起码的期待和要求。

侯捷先生非常重视读者的意见。希望本文能够成为来自一个普通读者对国内技术翻译界的一点有益反馈。


例子1:《C++ Primer》的前言关于Primer名称由来的一段
此段在CSDN论坛的技术书籍版曾经引起过争议。为什么一本Advanced级别的书要取Primer做名?我认为把这段译好,从商业角度而言非常重要。即使这本书正文是张丽译,但前言至少应该是潘先生所译。试想,如果这本书不是侯捷先生极力推荐,有多少读者会因为Primer而顾名思义,错过一本好书!
(1)原文:
C++ Primer provides a comprehensive introduction to the International Standard on C++. It is a primer in the sense that it provides a consciously tutorial approach to describing the C++ language. (It is not a primer in the sense of providing a simplistic or "gentle" description of the language.) Programming aspects of the language, such as exception handling, the container types, object-oriented programming, and so on, are presented in the context of solving a particular problem or programming task. Language rules, such as the resolution of an overloaded function call or the type conversions supported under object oriented programming, are given extensive treatment that may initially seem out of place in a primer. We believe that the coverage is necessary to a practical understanding of the language, and we view the material as something one goes back to rather than digests at one sitting. If you find it initially overwhelming or simply too dry, put this material aside until later — we identify such sections with the following convention:

(2)潘爱民先生译文:
C++ Primer 为C++国际标准提供了一个全面的介绍。在这种意义上,它是一个初级读本(primer),它提供了一种指导性质的方法来描述C++语言。(但是,它也为C++语言提供了一种简单而温和的描述,从这个角度来看,它不是一本初级读物。)C++语言的程序设计要素,比如异常处理、容器类型、面向对象的程序设计等等,都在解决特定问题或程序设计任务的上下文环境中展示出来。C++语言的规则,比如重载函数调用的解析过程以及在面向对象程序设计下支持的类型转换,也都有广泛的论述,这看起来就超出了一本初级读本的范畴。我们相信,为了加强读者对于C++语言的理解,覆盖这些内容是必要的。对于这些材料,读者应该不时地回头翻阅,而不是一次消化了事。如果开始的时候你发现这些内容比较难以接受或者过于枯燥,请把它们放到一边,以后再回头来看。我们把这样的章节加上特殊的记号:※。

(3)高巍译文:
C++ Primer全面地介绍了ISO标准C++。正因为涵盖的内容如此广泛,为了方便读者掌握C++,本书特意按照学习教程的形式来组织和安排全书的结构。在这个意义上,它是一个“基本教程”。(但是,本书针对的是C++的初学者而不是程序设计的初学者,因此对C++语言的讲解不同于一般C++教程的冗长繁琐,在阐述形式上追求简洁和雅致,所以有别于通常意义上的基础读本。)对于C++语言中和编程实践有关的部分,如异常处理、容器类型、面向对象的程序设计等等,本书赞同“在战争中学习战争”的态度。鉴于C++初学者一般缺乏大型软件项目开发的经验,因此,本书是通过分析实际编程中一个个具体的问题和任务来导入这些语言特性。基于同样的原因,一般基础读本中通常并不涉及的内容,诸如重载函数调用的决议以及面向对象编程中所支持的类型转换等C++语言规则,本书也给予了充分的关注。作者相信,涵盖上述主题有助于读者从编程实践的角度深入理解C++语言。当然,对于这些较深的技术主题,读者应该不时回头翻阅,而不是过一遍了事。如果开始的时候你发现这些内容难于接受或者过于枯燥,可以暂时跳过这些章节,留待日后再读。我们为这些章节都标注了特殊的记号:※。

(4)多说几句:
primer:有关该词英文释义的关键是elementary,译成“基本教程”比“初级读本”更适宜。

tutorial:有关该词英文释义的关键是instruction,译成“指导”不适宜。联想到Intel CPU的指令称为Instruction,因此tutorial有cookbook,“手把手教”的意思,这里译为“学习教程”。

gentle:理解成“温和”文意不通,而且与Simplistic不能对应。做过GRE填空题的人,肯定不会这么译!

前言的第二段有“The book is intended as a first book on C++; it is not intended as a first book on programming!”,正好用来在本段加入“本书针对的是C++的初学者而不是程序设计的初学者”。


例子2:《The Design and Evolution of C++》第1章第3节
这一节非常重要,正如裘宗燕先生在《译者序》中所言,“提出了他在从事科学技术工作中的人文思考”。我就此专门给Stroustrup先生发电子邮件请教,Stroustrup先生回邮如下:
“At the time where I wrote that, I did give a thought to Russian programmers.”
如果明白Stroustrup为什么在《The C++ Programming Language》中讲到C++名称的由来时提到了乔治.奥威尔的《1984》,而且明白《1984》在反对极权主义历史上的重要意义,我们会对C++更增加一种语言之外的感情。
强烈建议读到这篇文章的朋友,看看《1984》!用google搜一下,很多地方提供电子版下载。

(1)原文:
My preferences in literature have reinforced this unwillingness to make a decision based on theory and logic alone.In this sense,C++ owes as much to novelists and essayists such as Martin A.Hansen,Albert Camus,and George Orwell,who never saw a computer,as it does to computer scientists such as David Gries,Don Kunth,and Roger Needham.Often,when I was tempted to outlaw a feature I personally disliked,I refrained from doing so because I did not think I had the right to force my views on others.I konw that much can achieved in a relatively short time by the energitc pursuit of logic and by ruthless condemnation of "bad,outdated and confused habits of thought."However,the human cost is often high.A high degree of tolerance and acceptance that different people do think in different ways and strongly prefer to do things differently is to me far preferable.

(2)裘宗燕先生译文:
对文学的热爱更增强了我的认识:仅根据理论和逻辑做决策是没有希望的。在这个意义上说,C++由小说家和散文家那里得到的东西也很多,例如马丁.汉森、阿尔伯特.加缪以及乔治.奥威尔等。他们根本没有见过计算机,但对于C++的贡献却与计算机科学家如David Gries,Don Kunth,Roger Needham一样大。经常地,如果我试图取缔一个我个人不喜欢的语言特征时,我总抑制住自己这样做的欲望,因为我不认为自己有权把个人观点强加给别人。我知道通过强力地推行逻辑,毫无同情心地谴责“思想中坏的、过时的、混乱的习惯”,是可能在相对短的时间里有更多的建树。但是,人的代价总是最高的。不同的人们确实会按不同的方式思考,喜欢按不同的方式做事情,对于这些情况的高度容忍和接受是我最愿意的事情。

Martin A.Hansen,1909-1955,丹麦小说家和散文作家。——译者注。

Albert Camus,1913-1960,法国小说家、散文家和剧作家,1957年获诺贝尔文学奖。——译者注。

George Orwell,1903-1950,英国作家和社会批评家。——译者注。


(3)高巍译文:
我在文学方面更偏爱马丁.汉森、阿尔伯特.加缪以及乔治.奥威尔等的作品,这种文学风格方面的阅读偏好使得我更不情愿仅仅根据理论和逻辑作出决定。从此意义上说,这些散文家和作家,虽然从未见过计算机是什么,但是他们对于C++的贡献可以说和计算机科学家如David Gries,Don Kunth,Roger Needham一样大。很多时候,当我试图取消一个我个人不喜欢的语言特性时,我总是尽量控制住自己不要这样做,因为我不认为自己有权把个人观点强加给别人。我也清楚,如果全力追求逻辑上的完美,毫不留情地谴责那些“坏的、过时的、混乱的思维定势”,C++可能在相对更短的时间内取得更大的成就。但是,这样做会造成很高的人力代价。C++语言应该有着高度的包容性,允许不同的人们按照各自喜欢的不同方式思考和行事,这是我更倾向于的看法。

Martin A.Hansen,1909-1955,丹麦小说家和散文作家。在丹麦被德国占领期间,他为丹麦抵抗运动组织大量著文,呼吁丹麦人民奋起反抗侵略者。他的文章大量使用意向符号,与鲁迅的散文诗集《野草》风格类似。Stroustrup也是丹麦人,Martin A.Hansen对其的意义正如鲁迅对我们的意义。——译者注。

Albert Camus,1913-1960,法国小说家、散文家和剧作家,1957年获诺贝尔文学奖。作品有:《反面和正面》,《婚礼集》,《局外人》,《米诺托或奥兰的逗留》,《鼠疫》,《戒严》,《正直的人们》,戏剧:《误会》、《加利居拉》等。——译者注。

George Orwell,1903-1950,英国作家和社会批评家。他最重要的两部作品是政治寓言《1984》和《动物庄园》,对极权主义和乌托邦思想进行了深刻的讽刺。——译者注。

(4)多说几句:
preference是指作者在文学方面的好恶取舍,不是简单热爱文学,而是热爱文学的某些风格流派(genre)。

马丁.汉森、阿尔伯特.加缪以及乔治.奥威尔,我认为裘宗燕先生在译注中应给以更多介绍。否则,读者很难理解为什么他们甚至连电脑都没摸过,为什么对C++的贡献却与计算机科学家们一样大。这是理解本段内容的关键!

“我知道通过强力地推行逻辑,毫无同情心地谴责“思想中坏的、过时的、混乱的习惯”,是可能在相对短的时间里有更多的建树。”这段话,裘宗燕先生的译文太晦涩。而且,“强力地”在原文中找不到依据,energetic pursuit并没有“强力”的意思。

整个第1章第3节,因为涉及人文方面内容较多,裘宗燕先生译的都不令人满意。建国后理工科培养出来的教授学者人文素养之差,令人惊叹!在北大物理系读书时,教我们课的老教授深情地回忆解放前清华大学物理系要求学生必须修读朱自清先生的中国文学课,真是令人感伤而神往!


例子3:《Refactoring》前言第一段
(1)原文:
"Refactoring" was conceived in Smalltalk circles, but it wasn't long before it found its way into
other programming language camps. Because refactoring is integral to framework development,
the term comes up quickly when "frameworkers" talk about their craft. It comes up when they
refine their class hierarchies and when they rave about how many lines of code they were able to
delete. Frameworkers know that a framework won't be right the first time around—it must evolve
as they gain experience. They also know that the code will be read and modified more frequently
than it will be written. The key to keeping code readable and modifiable is refactoring—for
frameworks, in particular, but also for software in general.
(2)侯捷先生译文:
重构(refactoring)这个概念来自Smalltalk圈子,没多久就进入了其他语言阵营。由于重构是框架(framework)的开发中不可缺少的一部分,所以当框架开发人员讨论自己的工作时,这个术语就诞生了。当他们精炼自己的类别层次体系时,当他们叫喊自己可以删除多少多少行代码时,重构的概念慢慢浮出了水面。框架设计者知道,框架不可能一开始就完全正确——它会随着设计者的经验成长而进化;他们也知道,代码被阅读和被修改的次数,远远多于它被编写的次数。保持代码易读、易修改的关键就是重构(refactoring)——对框架而言如此,对一般软体也如此。
(3)高巍译文:
重构的概念源自Smalltalk社群,最初是在应用程序框架(Application Framework)的开发过程中形成,后来逐渐在其他程序设计语言中也得到了采用。一般而言,应用程序框架是一个完整的程序“模板”,其具备标准应用软件所需的基本功能,如文件存取、打印预览、数据动态交换等,还包括了支持这些功能的图形用户界面元素。应用程序框架由一组内聚力相当强的类库组成,类之间的静态层次结构关系和隐含的逻辑联系对于应用程序框架至关重要,而这些静态关系和隐含的逻辑联系往往相当复杂,程序设计者不可能采取传统的“自顶向下”设计(Up-Front Design),而只能采取所谓的演化式设计(Evolutionary Design),逐渐调整和精化纷繁复杂的类之间的层次结构关系。在演化式设计中,一个应用程序是在设计人员多次反复,“认识-设计-再认识-再设计”这样的循环过程中通过“无情地重构”逐渐完成的。从软件生命周期的角度来看,代码编写仅占整个软件生命周期的很小部分,大多数时间进行的工作是测试和维护,因此代码的易读性与可理解性也就尤为重要。重构,就是在保持代码的外在行为的前提下,改善代码的质量(特别是代码易读性与可理解性)的一个有效方法。因而,重构不仅有助于应用程序框架的开发者,对于一般软件的开发者而言也是有益的。

 

例子4:《Refactoring》前言第二段
(1)原文:
So, what's the problem? Simply this: Refactoring is risky. It requires changes to working code that can introduce subtle bugs. Refactoring, if not done properly, can set you back days, even weeks.
And refactoring becomes riskier when practiced informally or ad hoc. You start digging in the
code. Soon you discover new opportunities for change, and you dig deeper. The more you dig,
the more stuff you turn up…and the more changes you make. Eventually you dig yourself into a
hole you can't get out of. To avoid digging your own grave, refactoring must be done
systematically. When my coauthors and I wrote Design Patterns, we mentioned that design
patterns provide targets for refactorings. However, identifying the target is only one part of the problem; transforming your code so that you get there is another challenge.

(2)侯捷先生译文:
好极了,还有什么问题吗?很明显:重构具有风险。它必须修改运作中的程式,这可能引入一些幽微的错误。如果重构方式不恰当,可能毁掉你数天甚至数星期的成果。如果重构时不做好准备,不遵守规则,风险就更大。你挖掘自己的代码,很快发现一些值得修改的地方,然后你挖得更深。挖得愈深,找到的重构机会就越多……于是你的修改也越多。最后你给自己挖了个大坑,却爬不出去了。为了避免自掘坟墓,重构必须系统化地进行。我和另外三位(协同)作者在《Design Patterns》书中曾经提过:design patterns(设计样式)为refactoring(重构)提供了目标。然而,“确定目标”只是问题的一部分而已,改造程式以达目标,是另一个难题。

(3)高巍译文:
但是,重构也存在风险。风险之一就是对代码的改动导致程序无法正常工作,如果同时又缺乏完善的版本控制和配置管理机制,常常导致几个工作日甚至数周的努力付诸东流。风险之二就是开发人员往往过度“沉溺”于重构之中,采取的是一种随意无序的工作方式。这里改动一段代码,那里改动一段代码,而且不时发现有更多地方需要改动,最后开发人员越陷越深,不可自拔。重构并不是过去那种“修修补补式”(Code-Fix)无序开发方式的一个好听的代名词。实际上,重构有着它的原则和最佳实践,是一个有纪律(Disciplined)的改善现存代码质量的软件工程方法。例如,优秀的设计模式就为重构提供了一个代码改进的方向和目标。当然,有了方向是一回事,如何通过重构接近这个方向就是另外一回事。

 

0 0

相关博文

我的热门文章

img
取 消
img