作者:韩磊整理者：韦小琪

作者简介

韩磊是AR 技术公司亮风台的产研副总裁。在此之前，他曾在大学、技术媒体和财经媒体工作，有多年的企业经营管理、社区与媒体运营经验。他与人合著有《网络媒体教程》，合译有《Beginning C# Objects 中文版：概念到代码》，译有《梦断代码》《C#编程风格》《代码整洁之道》《UNIX 传奇：历史与回忆》《匠艺整洁之道：程序员的职业修养》等图书。其译作技术精准、语言流畅、文字凝练、修辞考究，备受读者好评，也是出版社非常信赖的技术译者。

本文是基于韩磊先生在2020年10月异步社区五周年大会上的演讲和2021年4月《UNIX 传奇：历史与回忆》新书发布会上的演讲转录整理而成，为了行文通顺和便于理解，整理过程中做了一些必要的修改。

感谢韩磊老师授权发布此文，他和我们一样，希望本文对有志于从事IT技术图书翻译的朋友有所帮助。

个人技术翻译的经历

大家好，我是韩磊。先介绍一下我个人从事技术图书翻译的经历。

2006年，翻译《Beginning C# Objects 中文版：概念到代码》，2008年翻译了《梦断代码》《C#编程风格》；2010年翻译《代码整洁之道》。

2010年以后的10年，我离开技术图书翻译工作，直到2022年又重新捡起来，翻译《Unix传奇：历史与回忆》。主要是因为做书这件事的价值观出了一点问题。翻译和写作这些图书带来的稿酬和版税，还不如我自己的一个月的收入。当然，另外还有一个原因是这几年一直在忙着创业。

为什么2020年又重拾翻译工作呢？因为我想明白了做书的几方面的价值所在。

第一个价值是，求知。做书带给我知识的价值。在翻译一本书的时候，我会把这本书当做按图索骥的一个索引，通过一本书查阅大量的文献资料，获得大量其他的知识。虽然获取知识的过程是很痛苦的，但结果是很快乐的。

第二个价值在于，探索的过程非常有趣。尤其翻译过程中，当你看到一个词、表达、一个术语、一个句子，不明白什么意思，你需要去求解，大量查阅资料，去和周围的朋友讨论，去向专家求教。当你得到答案的时候，那种欣喜若狂是无法比拟的。探索求解，这个过程也是很快乐的。

第三个是，分享。我之前在CSDN工作了6年，一直致力于技术知识的传播。社区、论坛、专业的出版机构，他们做的事情就是把好的东西挖掘出来，进行高质量的重新创作后，再分享给社区。我一直相信，知识来自于社区，由社区的一份子或多个份子，一块去重新创造它，让它变得更好之后再反馈给社区，让整个社区获益。

当我想明白这三个问题之后呢，恰好又有了一些时间来做这些事，所以就重新捡起技术图书的翻译工作。接下来，我谈一下我对IT图书翻译的一些思考和认识。

翻译IT图书的几个条件

先来谈谈我对翻译IT图书这个事儿的理解。翻译IT图书可能会比翻译文学作品难度更高，因为翻译文学作品需要译者有一定的文学素养，而翻译IT图书则需要译者具备IT专业素养。

首先，译者必须要具备技术背景，否则往往会对原文的理解会出现错误。

其次，必须对图书的原文的语法、文化以及对象国的语言和思维有很好的理解。

第三，是具备资料的查证能力。IT类的图书往往会涉及要引用外部的资料，这时候需要对这份资料进行查证以求不要出现大的错漏。甚至有时候会遇到作者写作的内容出错的情况，这对译者是一个很大的考验。你必须发现这些错误并纠正。当然我们通常不会直接做修正，而是在原文的基础上添加译者注。

最后，要有很好的中文表达能力。如果中文功底不过关，即便对原文的理解已经很透彻，但是你用中文表达不清楚，读者就可能不知道你要表达什么。甚至你可能传递了一个错误的观点。

在传统的翻译上我们讲究信，达，雅。信就是忠实于原文，达就是能够清楚地表达原文的意思，雅的即为译文的流畅度和优美程度。我们会发现信和雅是两个不可能同时达成的任务。译者在翻译的过程中要兼顾表达原文的中心意思和让读者能够完全的理解到原文想表达的意思，这其实是非常困难的一件事情。

我们来举个简单的例子吧！大家看下面这句话。

这句话是说当时有一种IBM出品的很老的计算机，这个计算机有16k的core。我以前看到一篇翻译的文章，把这句话翻译成了“有一台带16k内核的计算机”，但是其实这是对计算机历史和专业了解程度不够所导致的一个错误。这里的core指的是早期计算机的存储设备是用的磁芯，也就是一个有磁性的铁环，中间穿上线它就具备了存储数据的能力。这里的core指的是磁芯，而不是内核。所以正确的翻译应该是：这个公司有一台16k内存的IBM机器。这是一个简单的例子，说明我们对任何原文要理解透彻，知道它后面的技术的背景、历史的背景或者文化的背景。

IT图书译者的自律自觉

译者应该具备什么样的自律或者自觉呢？

1.译者要练就扎实的基本功，少留麻烦给编辑。我是一个很怕麻烦别人的人，所以我在翻译的过程中也尽可能不把一些问题留到后面的编辑流程。当然有一些作者写作的时候不太注意，比如“的”“地”“得”其实是很重要的。因为在出版规范里，这样的错误在平时写作或者翻译的时候是一定不能出现的，否则会给后面的编辑过程带来大麻烦。

再给大家推荐一本书，如果你有志于写作文和翻译的话，应该读读这本书。张志公先生的《修辞概要》是一本几十年前出的老书。这本书引用了大量的文学的例子来介绍修辞的各种用法，我相信读完这本书对大家在写作上会有很大的提升。

2. 做好时间的管理。不管是想要写作还是翻译一本IT图书，你会发现这是一个大工程，想一鼓作气完成是很难的。那么最好的做法是什么呢？就是把这个大工程分成10个部分或者20个部分，每天花半个小时要比你用一个周末来做一个10个小时的工作，所取得的成就更大。因为人的思维如果连续7天不在一个频道上，就会被打断，要重新回到这个频道是一件困难的事情。那么把这几百页的书切分成章节或者一个个的小里程碑，那么当你完成每一个里程碑的时候，就会获得一个成就感。成就感累积起来，翻译或者写作的动力就会不断的加强。不至于越到后面越痛苦。

3. 处理好专有名词。为什么专门提到这点，是因为我过去在翻译好几本书的过程当中和编辑有大量的沟通，发现很多沟通都是针对专有名词该怎么翻译上。那么这里有两个技巧。首先，是专有名词其实它是有人名词典、地名词典，也有咱们常用的工具，比如术语在线，还有图书的名录。所有我们的译名一定要遵循这些规范。只要遵循这些规范，后面的沟通交流就会舒服很多。其次是一定要有一个专有名词对照表。一个词在文章当中或图书当中会出现很多次，如果你有一个对照表可以按图索骥，就可以让所有的专业名词达到统一。我觉得译者一定要有把问题前置的自觉。

最后，对于专有名词的人名部分，因为计算机领域的人名范围比较特殊，一些IT名人的名字有约定俗成的翻译，我在翻译图书的过程中，将其搜集整理为一个线上词典，方便大家查阅参考（http://namedict.hanlei.name）。

善用机器翻译

那么我还想再谈一个话题，这个话题其实在翻译圈子里面有很多相关讨论，就是机器翻译。很多人会先入为主地说机器翻译一定是错误的，就像前一段时间特斯拉出现了好几次因为驾驶员开了自动驾驶没有去管这个车而导致事故的情况。做个类比的话，机器翻译导致的翻译质量不佳是不是有点像特斯拉因为驾驶员开了自动驾驶导致的车祸呢，其实有点像。但问题是，这些车祸真的是自动驾驶的错吗？

我认为这种说法是有点偏颇的。在特斯拉或者其他的电动车公司的操作指引里，明确要求驾驶员需要时刻把手放在方向盘上，及时纠正和接管自动驾驶的错误信号，之所以出现车祸就是因为驾驶员没有做这样的准备。同样，我个人认为机器用来做翻译的时候你也不能把它当做一个可以完全自动化处理所有问题的工具——它只是一个辅助翻译的手段。

我在翻译图书时候，其实是使用了大量AI翻译的方法来帮助我进行初译。结果如何呢？我相信并不能先入为主的认为机器翻译就一定差。因为机器翻译只是帮助我做了前面的最初的翻译工作，也就是代替我做了大量文字输入的工作，那么在后面其实仍然有很多工作需要我解决。

在整个翻译过程中，我的经验是像DeepL这样的翻译工具只能帮你做初译，你仍然需要大量时间来阅读、查证和润色，利用各种方法找到机器翻译存在的问题并修改，最后才能定稿。我们常常会批评某本书机翻会很严重，那种做法就是没有做好后面的工作，完全是不负责任的，就像驾驶员将一切交给自动驾驶。完全排斥机器翻译也是一种错误的想法，译者要善用工具。

另外，在我翻译这本书的过程中还得到了一个感悟，许多先贤和前辈发明了许多高科技手段，就是为了提高工作的效率，我们不应该一味地排斥这些科技。那么下面我们就举一组例子来说明机器翻译有时候甚至比人类还要靠谱，例如下面这个长句：

如果你的母语不是英语，你会发现这个句子有些难以理解。这时候，我使用了DeepL来翻译这句话。虽然看起来表达了这句话的含义，但是有些问题还是很明显的。比如，翻译的文字一逗到底没有任何分隔，这不符合中文的表达方式。于是我对这个句子进行了润色，就得到了一个更好的版本：

最后，我再回过头来检查自己的翻译，发现我对句子结构的理解是错误的，有时还比不上翻译工具对句子的理解。大家可以看到我在原文上标注了一些颜色，这代表的是从句的指代关系。这个例子里我的错误是，把晶体管当做了制造通讯设备的必要条件，但“真空管是制造通讯设备的必要条件”才是这句话的原意。所以我们不能轻信机翻，但也不能瞧不起机翻。

下面这个例子同样有不符合中文使用习惯的问题，译文里面出现了太多的“的”导致译文出现太冗长的问题。所以我把它拆成了两个部分，第一部分是“文件系统是操作系统的一部分”，第二部分是“负责管理……”这部分，这样更加符合中国人的语言习惯。这里我们要说的是，人类和机器翻译如何互相协助让译文更加通顺。

翻译中的“坏味道”

最后，想和大家分享一下我在从事翻译工作时一个小小的体验。大家都知道《重构》这本经典的图书，书中作者提到了一个概念——“坏味道（Bad Smell）”。其实我们熟练的技术人员，看到一段代码的时候会有一种感觉，这里面可能出现了问题，也就是“坏味道”。翻译工作也是一样的，当熟练地译者看到这些“坏味道”，应该去思考如何改变这个bug，让译文变得更加流畅。

我们再来看几个例子。刚才说道，英美文化中喜欢用长句表达且很看重逻辑词，这和他们的语言结构有关。但长句中会不可避免地出现很多从句，若将这些从句直译成中文将会出现很多诸如“的”这样的连接词。比如本书中的这个例子：