如何翻译一本计算机书籍？

首先，恭喜你从吐槽方变成了被吐槽。

为什么你不应该翻译计算机书籍？

开始之前，我想一点泼冷水。毕竟，翻译不是一个好差事——费力不讨好，也不是一项适合每个人的 “工作”。

除却不讨好读者这一点，还在于时间投入产出的问题。翻译书是一个又长又累的活，一，我们可能一两星期才能翻译一章，二，获得的报酬与我们的时薪比有较大的差距。所以，若是为了赚钱，那么请不要考虑这种方式。一本两百页左右的书，两个人投入两三个月的时间，大抵各自只能赚上四五千块钱。

可要是，你想提升自己的能力：表达、翻译、时间管理—— 翻译是一个二次写作的过程 ，又或者是提升业内影响力，那倒是可以试试翻译。

为什么翻译一本书？

嗯，既然，翻译是一件 “吃力不讨好的事”，可为什么我们还是想翻译本书呢？

成就感。对于自己而言，相当于是 GET 了一个新的成就。年老的时候，这个成就便会变成：我年轻的时候翻译了一本书；我在你这个年纪的时候，翻译了一本书……。

影响力及沉淀相关领域。如余晟是《精通正则表达式(第3版)》（出版于 2012 年）的译者，而后他写了一本《正则指引》也是相关领域非常不错的书籍；同样的例子，还有乔梁在 2011 年翻译的《持续交付:发布可靠软件的系统方法》，随后在 2019 年也写了一本《持续交付 2.0 业务引领的 DevOps 精要》。当你翻译了一本书，在某种程度上，你也成为了这个领域的专家。再通过持续的练习和关注，也和沉淀出自己的内容。

更自信。如果你翻译了一本书，那么我想你已经有了写一本书的自信了。这也是我写了我的第一本书《自己动手写物联网》来的信心——这么简单的内容，我也会写。然后我就掉坑里了，大抵是出不来了。从某种程度上来说，对于我而言， 在有了代码和大纲之后 ，写一本书的时间和翻译一本书的时间差不多。反而，因为不需要 Google Translate 和百度翻译来帮助我，我可能写得更快——也错得更多。

既然，你已经下决心翻译一本技术书籍，那么就阅读一下我的相关经验。

翻译前：试水

在我们进入正式的翻译工作之前，我们有一堆的 “准备” 工作：

1. 选择合适的书籍
2. 试译
3. 寻找合伙人

选题：选择合适的书籍

翻译之前，自然而然地是要去寻找相关的书籍： 要么从出版社找对应的书；要么从书去找对应的出版社，再让出版社去获取版权 。两种方式相比，最简单的就是直接找出版社的编辑，通过编辑来寻找到书单，从中再去挑选合适的书籍。。

在挑选书籍的过程中，可以稍微注意这么几个点：

• 时效性。技术书籍存在一定的时效性，等你翻译完 Node.js 9 之后，Node.js 10 已经出来了……
• 好评度。看看它们在 Amazon.com 上的评论，及相关的评价。
• 厚度。厚的英文书很考验人性，如果你的性子不好，请换本书。

我的个人感受是：

首先，一定一定一定一定要找一本你感兴趣的书。一旦不喜欢，那你可能要痛苦几个月了，而且你可能没有多少收获。

其次，还要找擅长的领域或者身边有擅长的人，万一遇到几句不懂的，还可以问问。

最后，卧槽，我爱极了满篇代码，还有到处插图的书了——翻译的时候，并不是按真正的字数算报酬的，而是估算，诸如 1200字/页。时间一久，我产生了一种幻想， 有没有一本书全是代码呢？

试译

试译是一个特别重要的步骤，它决定了你 能不能翻译这本书 。相应的有一些建议，翻译完后：

• 自己读一遍，看语句是否通顺
• 找几个文字好的人过一遍，比如学中文的人（如我就是找 @花仲马）
• 多次校对几遍，以确保没有问题

在试译的过程中，请确保、确保、确保翻译的质量要 尽可能地高 。要是如果没有相关翻译经验，而直接去翻译一本书，便是一次大的挑战。我第一次直接翻译书时，就有这样的感受。当然了，要是你的英语好、中文也好的话，那么问题就不大了。那么，在你决定翻译一本书之前，可以先尝试去翻译一些文章。

试译完之后 ，你一定会怀疑人生的—— 我妈你妈，这几十年的语文都学到哪里去了 。It's very very good，你已经要走出舒适区。我翻译第一本书的时候，由于我是英文版的审阅者，也因此没有试译。不过呢，在早期尝试试译图灵的一本敏捷相关书籍时，试译失败。

试译成功后，出版社便会和你讨论出版相关的事宜，包含相关的 出版合同 。

合伙人

考虑到投入产出的问题，我建议你还是找个人合伙，一起去干这一票。在你有了信心之后，就可以继续你的翻译之旅。除此，一个可怕的事实是：广大的男 程序员 们， 普遍 表达能力没有女程序员好。所以，要是能找到个女同胞合伙，那还是对提升文字水平，大有帮助的。

至于工作量上的分配，我觉得按章数直接分配是一个不错的 idea，如：我和同学小兵，翻译第一本书的时候，是以单双章的形式分开的；我和同学小兵、朋友陈福，我翻译的是前面一两章，和后面的一两章。

最后，难免你们会讨论相关的酬劳分配、署名的问题。

• 酬劳。对于酬劳来说，按页数来分配，是一个不错的主意。毕竟，原书的页数就那么多，有的章节内容少，有的章节代码多，有的章节图少。代码和图的分配，在单双章上也倾向于一个合理的水平。
• 署名。针对于署名来说，署在前面的那个人，往往是更需要对书质量负责的人。他/她可能是翻译的发起者，也可能是翻译得最多的人……。总之，活干得最多的，放在前面也是蛮合理的。

至于公不公平，那都是相对的。

翻译时

翻译与交稿模式

从某种模式上来说，翻译也可以分为两种 “开发流程”：

• 瀑布模式：翻译完整本书的内容，再交给编辑
• 敏捷模式：翻译完每一个章节后，就交给编辑

两种模式都各自有特点。如敏捷模式更容易让书出版，只是对于编辑来说可能并没有那么友好。而瀑布模式会导致出版变长，但是各自可以集中精力。

制定翻译计划：时间管理

翻译是一个相当漫长的过程，我们需要为翻译工作腾出一定的时间。在我翻译前两本书的时候，我根据交稿时期，制定了一个非常简单的计划， 一周翻译一章 。随后，再把这部分的工作分配到每天里，一天几页，周末再校对一遍即可。无论是写书还是翻译，我都习惯在 每天的早上和中午 来翻译书籍，这样我仍然可以拥有晚上的时间，可以去做自己喜欢做的事情。

一旦，我们为翻译和写作腾出了一定的时间后，便会发现一天中的可用时间特别多——如果你和我一样不加班的话。

翻译周期：兴奋期 -> 厌倦期 -> 稳定输出期

翻译书，大抵和做项目是类似的：

兴奋期。刚来到一个新的项目，那可是相当的兴奋，恨不得一天就能翻译完这本书（PS：记住：要久，而不是快），但是我们的进度相当的慢。

厌倦期。经历了一段时间后，便觉得项目、翻译是一件无聊的事，恨不得从坑里出去。

稳定输出期。随着会发现，最后一部分翻译出来的质量，远比之前要高。坚持过了无聊期之后，我们便能保持稳定的输出状态，即能稳定地翻译，也能稳定地写代码。那么，如果你是以瀑布型交付的稿件，再回到前面的章节里，把前面的章节重新较对一票。

最后，你还是坚持下来，太棒了。

翻译后：反馈

从交稿到书的最终出版，还需要一个相当长的时间，从几个月到一年左右都有可能。也因此，这个过程可能会比翻译的时间更长。

交稿完之后，便相当于是在稿件的反馈周期里。那时，还需要与编辑保持紧密的联系。

注意事项

编辑器及版本管理

我习惯用的结合是：

• Git + GitHub 用来作版本管理
• 使用 Markdown 来编写内容
• 编辑器，使用的是 Phodit

一来，Markdown + Git 适合多个的文本管理，二来，Phodit 相当的适合于写书，哈哈哈~~

多个翻译软件

相信我，Google 不懂中国，还有中文。笑~

我的意思是，与国内的翻译软件相比，Google 的优势并不是太大。所以，若是遇到一些 Google Translate 有问题的句子，换成百度翻译、网易有道、金山词霸，你可能就会有一种豁然开朗的感觉。

音译 xx 意译

翻译的过程中，我们还到怎样翻译才会更好的问题，也就是音译好还是意译好。

音译是一种以原语言读音为依据的翻译形式，一般根据原语言内容的发音在目标语言中寻找发音相近的内容进行替代翻译。

若是直接音译，就会有一股浓浓的翻译腔，转而我们就需要采取一定的意译：

意译，是指是通过换句话，重述一个文本或段落。[wiki_yy]

并且，相信我，你可能会遇到那种作者也没有写好的书。这个时候，采用意译会比音译好多了。

英语那又长又复杂又不容易分割的语句

断句，读没有标点符号的古书时，根据文义停顿或同时在书上加上圈点。

要是你之前没有翻译相关的经验，那这个问题就值得注意一下。英语的语句一般是这样的：

Tourism doesn't care about the destination, but care about the way people and things and those wonderful memories and scenery. 

然后，金山词霸翻译成了这样：“旅游不在乎终点，而是在意途中的人和事还有那些美好的记忆和景色。”句子的后半句，还是太长了，中间可以中个逗号。改个：

“旅游不在乎终点，而是在意途中的人和事，还有那些美好的记忆和景色。”

从某种程度上来说，这样的短句更容易读懂。而英语中，还充满了各种又长又臭的倒装。

知识库（词表）

一些技术上的关键词，我们需要建立一个相关的知识库——特别是多人协作翻译的时候，可以用于统一相关的关键词。如我们在写相关文章的时候，使用英语反而更容易理解，相似的，在翻译的时候，也记得标注一下，第一次使用时，如微服务应该带上相应的 “微服务（microservices）”而不是微服务，这种阅读体验，对于读者来说，相当的痛苦。

提升文字水平

当我在写书的时候，我会阅读大量地文学书籍。以此，来添加一些相关的用词。

应对词穷

要是缺少大量文学相关的内容，大抵在翻译书的时候，会出现大量地相似语句。这些语句在我们翻译的时候，总会觉得很烦。如我们习惯的连接词：首先，其次，最后，对应的英文便是：First,... Then,... Finally。可是呢，英语可以这样写一个句子：First, Then, Then(n), Then, Finally。

对应的有不同的形式：

• 首先，其次，然后，最后
• 首先...接着...再接着...最后...
• 先......然后......再......又......接着......最后……

同样的一个词，可以有多种不同的表现形式诸如，除了、除却、除掉。而诸如本身，又可以换成好比、比方、例如、譬喻~。这也算是我们在过程中，能找到一乐趣之一。

还有 “如下代码”、“代码如下所示”，“看看这里的代码”，“代码很简单”——哈哈哈~

应对表达能力不好的作者

如果，我是说如果，你遇到作者的表达能力也不好，那么你陷入困境了。请及时与编辑联系，你可能得加入一些自己风格的翻译了。

还有技术

末了，请不要忘记，你接触的是该领域的最新知识——至少在我写这篇文章的这会儿，国内的最新技术书籍的出版时间，还是落后于国外的时间。

所以，请不要单纯以翻译为目的，练习一下其中的技术吧。

结论

你呢，还有什么温馨提示。

外传：原版 vs 译版

我仍然是一个喜欢看中文书籍的人，英文书籍于我而言，一来是贵，二来是阅读速度慢。

贵的这一点，也不需要我多说，而身为一个创作者呢，看盗版书籍也是对自己的不尊重——自己尚且如何，更何况别人呢。

对于阅读速度的问题，不同的人有不同的看法，有的人喜欢精读、细读。而我则喜欢先粗读，而后在需要的时再回来读这本书。我这脑子记不住太多的东西，一不用就忘了。于是，精读于我便是有些浪费时间的味道——除非，我非常迫切需要一本书。可很少存在这种情况，我就是一个书虫，还没用到，就已经读了——好书，都值得一读，不是吗？

而英语书经常翻译之后，价格上降了 N 倍，又能快速阅读。对于几大计算机出版社的书来说，哪怕是一本书翻译得再差，它也远远比 Google Translate 或者百度翻译更好。