“ 作为《图数据库实战》的译者之一，分享一下技术翻译的一些心得。”
前段时间，和叶伟民Billy、高俊宁Raymond、周一行一起聊了一下技术翻译那些事儿。这里把我对技术翻译的一些心得和大家分享一下。
我和叶伟民Billy去年合作翻译了《图数据库实战》，现在也在合作翻译另一本关于AI方面的书。也算是踏入了技术翻译圈。
01
—
翻译是一次二次创作
虽然技术翻译不同于文学翻译，必须把原文的意思完整、准确、清晰地表达出来。
但有些时候，原文作者会引用一些谚语，这些谚语对于原语言和文化有意义，对于中文读者就没有意思了。
所以需要充分理解语境和语义，作一些本地化的发挥。
当然，对于技术类书籍，这样的情况不多，但也是有的。
在英语中，有些语句很长，特别是很喜欢通过which和that构成长句，这样的句子直译起来很别扭，我会根据理解用中文重新表达出来。
另外，有些很小的细节也特别困扰人。比如在《图数据库实战》中，会有question和problem这两个词，它们都能被直译成“问题”，但此问题非彼问题。
这些看起来非常简单的词语，却很难在中文找到与原文一致的确切表达，我们在question到底应该被翻译成“问题”还是“疑问”，很难拿捏。有些时候，要通过结合上下文进行定夺，不能一概而论。
所以充分理解原文很重要。当然，翻译也是一次很好的学习过程，等于把被翻译的书完全吃透了一遍。
02
—
翻译与写书
我写过两本书，翻译过一本书，两种体验是挺不一样的。
写书是完全的自我创作过程，需要大量自己的灵感。
虽然在立项的过程中，书的大纲已经基本上有了，但这个骨架很多时候还是需要丰富的。
写书最怕的是虎头蛇尾，开始的时候思如涌泉，到了后面不知道怎么收尾，甚至需要凑字数，这也是为什么有些作者写了好几年都无法交稿。
据说最惨痛的教训是，一个作者精耕了几年，交稿时，他所写的那个技术已经下架了，没有出版意义了。
所以写书是一种对出版社的有风险的承诺，在立项那一刻，能否完成是未知数。但一般出版社给的时间比较宽裕，主动权反而更多在作者身上。
翻译不会有内容焦虑。但是交稿时间有严格要求，而且不宽裕。对于做业余翻译的来说，时间上会有一些挑战。
技术书籍的翻译，不光是要翻译意思，自己要对内容，通常是一种新的技术，要有充分的理解，这也是一个有挑战的学习过程。当然，好处是顺手把这项新技术给学了。
总体上，翻译和写书不同的是，它是一定能完成的任务，只是不同的水平和投入会产生质量的差别。
03
—
敏捷翻译？
我们只花了三个月完成了《图数据库实战》近17万字的初稿，应该算是很快的。我们用了一点敏捷的原则。
首先，要确定每个周末都要投入时间进去；
其次，通过头两周“测速”，看看一个周末能完成多少进度，进而可以推算要多少个周末能完成；
最后，这样就可以做出一个计划，按照推算，可以在交稿前四周完成，后面就有可以继续完善的空间了。
有了这样的计划，就可以继续套用“先完成再完美”的原则：
前半段的目标是完成，尽快地完成，一直闷头翻，对于一些难翻的部分先标记跳过，达到可以交稿的最低要求；
后半段的目标是完善，重新阅读和调整，啃掉前面标记难翻的部分。
04
—
技术翻译的收益
作为非职业的选手，写书的机会可遇不可求，灵感也不是时时有。
但翻译的机会则多的是，几乎所有英语不错的技术人都能参与。
我和我的外籍老板聊天时，他不是很明白为什么会有技术翻译这个行当。我解释了两点：
大部分中国的技术人员不会啃英文原版书，不是每个人都有英语阅读能力，就算有，也没那个兴趣和精力；
英文原版书非常贵，中文翻译版是英文原版价格的1/3到1/2，对中国读者更友好。
对于中国这么一个大市场，技术翻译的机会还是非常多的。
所以，对IT从业人员来说，有这样的机会，愿意投入的，都应该参与，这是在工作以外，提升自己在整个业内知名度的一个途径，也是为自己带来更多机会的一种背书。
一起卷起来吧！
觉得文章不错，顺手点个“点赞”、“在看”或转发给朋友们吧。
相关阅读：
关于作者
刘华（Kenneth）
著有书籍《猎豹行动：硝烟中的敏捷转型之旅》《软件交付那些事儿》
《图数据库实战》中文译者之一。
世界500强银行DevOps与云平台中国区总监
敏捷、精益、DevOps专家
公众号“敏于思 捷于行”博主
精通极限编程、Scrum、看板方法、测试驱动开发、持续集成、行为驱动开发、DevOps工具栈、Docker、Kubernetes
曾在QCon、GDevOps、DevOpsDays Meetup、中国软件技术大会、ArchSummit、Top 100等论坛发表主题演讲
阿里云、谷歌云认证架构师
关注公众号看其他原创作品
敏于思 捷于行
坚持原创高质量软件交付相关文章
觉得好看，点个“点赞”、“在看”或转发给朋友们，欢迎你留言。
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
