那些糟糕的技术类翻译

在计算机领域,大部分优秀的资料书籍都是英文写成的。当它们被译成中文后,翻译的质量是参差不齐。经常能看到在豆瓣书评上,大家对于某本书翻译质量的吐槽。自己在初期也读了一些中文版的,总的来说,大部分是不影响知识的理解。但是有些翻译,确实比较糟糕。遇的多了,发现这些错误也有一些规律。

语法错误

曾经读过一篇介绍正则表达式背后递归思想的文章[1],看前半部分的时候并没有觉得有什么不妥,但是看到了下面这句,整个人当时就懵了。

Rob告诉我递归不是那么清晰的设计决策,缘于其如何逼近问题的方式:考虑一个匹配模式和一段文本,写出匹配函数,该函数转而又需要一个“匹配这 里”的函数,等等。

先不说这个翻译是否流畅,单就意思来说,“递归不是那么清晰的设计决策”,这是什么情况? 要知道这是一篇介绍递归思想的文章,通篇都是在说递归好处,怎么会突然来这么一句。于是便去看了原文的表述[2]:

Rob has told me that the recursion was not so much an explicit design decision as aconsequence of how he approached the problem: given a pattern and a text, write a function that looks for a match; that in turn needs a "matchhere" function; and so on.

问题就出在对于“ not so much ...as" 这个短语的理解,这个短语的意思是“与其说是...不如说是...”,所以原文翻译后应该是“Rob告诉我,与其说是递归是一种(主观选择的)清晰的设计决策,倒不如说是他解决问题的过程自然形成了这种递归的结果.......”

用法差异

英语基础好一点的话,类似的语法错误还是比较容易避免的,最后翻译出来的内容,大致上也能还原文章的主旨。但是英语和汉语毕竟是不同的语言,在使用习惯上会有一些细微差异,这些差异在翻译时若是没处理好,也会成为阅读的障碍。比如说,在中文世界里,我们通常通过一些副词如“非常” “很”来表示强调,,而英语中虽然也有对应的副词和用法,但是在表达强调的时候,一般都是通过句式的变化。把想要的部分提前。

在《flask web开发》的中文版里,有这么一句话:

处理URL和函数之间关系的程序称为路由。

当时读到这句的时候,按照中文的意思,我便把路由认为成一个程序。在随后的阅读中,便开始了苦苦的寻觅,这段程序究竟在哪里?后来路由这个词汇又出现了几次,可是出现时的语境感觉好像跟之前理解“程序”不太一样,随后就去看了原版的内容。

The associationbetween a URL and the function that handles it is called a route.

根本就没有“程序”这个单词!在文中我们看的association这个词,它的中文意思是“关系”,而这个单词被提前,显然是要强调某种关系,如果翻译的话,应该是“ URL和处理URL的函数,这两者间的关系称为路由”。说实话,这个翻译看起来也很别扭(如果有好的翻译方式,欢迎留言),这本质是因为英文与中文表达方式差异造成的。翻译的作者可能也是为了便于读者理解,“好心”加上了“程序”这个词,这反而造成了糟糕的影响,让读者注意力都放到了程序上,而不是“关系”。

内容流失

翻译过很多技术书籍的李松峰,在一次访谈中提到有两样内容在翻译过程中容易流失[3],一是原文的形式,二是原文的风格。其中对于“原文的形式”——原文的文字组织和语句结构,他认为在把意思翻译出来后,这些形式辅助意思表达的使命就完成了。我认为他对于什么是造成流失的判断是正确的,但是原文形式不只是用来辅助意思的表达,形式本身也蕴含着意思。在《JavaScript权威指南》的原文中有这么一句话,

JavaScript allows us toscript the HTML content and CSS presentation of documents in web browsers,but it also allows us to define behavior for those documents with eventhandlers.

虽然只有一句话,但是蕴含的内容十分丰富。从字面意思去看,这句话阐述了JS有两个作用,操作文档和定义行为。转折句式的运用,表明了作者认为定义行为的作用更重要,更能体现JS的价值。 再去细看句中的用词,会发现这句话也理清了HTML CSS JS 三者的定位及关系。HTML负责内容 (content) CSS负责表现(presentation)  JS负责行为 ( behavior) , HTML和CSS属于文档(document), JS可以操作(script)文档,也可以通过 (event handlers)给这些文档定义行为。而这些词语之所以能蕴含这么多的内容,除了用词精确的原因外,原文的形式起了很大的作用。比如“script document”与 “define behavior”的对应,使JS的作用突显出来。 “…and..of…”说明了HTML与CSS的并列关系及所属范围,“HTMLcontent”名词修饰名词的方式突出了其性质content,在回过头来看看中文版的翻译,只会觉得是一句平淡的话。

可以通过JavaScript来操Web浏览器中的HTML内容和文档的CSS样式,同样,也可以通过事件处理程序(event handler) 来定义文档的行为。

以上列举的内容只是对翻译中出现的一些问题的总结,并不是说一定要去读英文原文。毕竟我们阅读中文速率还是会更高一点,而且也有很多的译著也是不错的。在阅读前,关注一下译著的出版社、译者背景、相关书评,可以让我们避免大部分的坑。不过学好英语还是很重要的,因为有时候翻译的不准确,可能是有意而为之。去找找《黑客与画家》中这段的原文,你就会发现不同之处了。

无论在物质上,还是在社会地位上,技术好像都缩小了富人与穷人之间的差距,而不是让这种差距扩大了。如果参观雅虎、英特尔、思科的办公室,会看到每个人都穿着差不多的衣服,有着同样的办公室(或者小隔间)、同样的家具,彼此直呼对方的名字,不加任何头衔或敬语。表面看大家没什么差距,但如果看到每个人银行户头上的余额差别如此之大,一定会感到震惊不已。

[1]解读 Rob Pike 编写的正则表达式程序

[2]A Regular Expression Matcher Code by Rob Pike

[3]浅谈技术翻译

你可能感兴趣的:(那些糟糕的技术类翻译)