2013年到现在，已经翻译了3本书了，其它杂七杂八的文章也不少。其中有一些经验和教训，势必要总结一下。
将译稿纳入版本管理
没有版本管理的代码修改起来是战战兢兢地，而译稿也类似。我习惯在GitHub上创建一个私有的仓库（我是GitHub的会员），把与该书相关的内容都放置上去，每翻译一点就迁入一次，保证任何修改都可以追踪。
创建一个词条文档
在翻译书的过程中，难免会遇到很多专业词汇，有些专业词汇有统一的翻译，而有些则没有，需要自己权衡后给出一个翻译结果。最好把这些词汇都放置到一个独立文档中，这尤其对多人合作翻译的情形相当有用。可以保证整本书对专业词汇翻译的一致性，也便于以后修正某个词条的翻译。
权衡信、达、雅
信、达、雅是青末启蒙思想家严复提出的概念。”“信”指意义不背原文，即是译文要准确，不歪曲，不遗漏，也不要随意增减意思；“达”指不拘泥于原文形式，译文通顺明白；“雅”则指译文时选用的词语要得体，追求文章本身的古雅，简明优雅。我所翻译的都是一些技术性书籍，信肯定是占首位。而英文被动句较多，长短句结合，要通过“达”的方式来变换句式，符合中国人阅读习惯。“雅”则注重用词的准确性，是个比较难达到的标准。
第一遍粗译，第二遍细译，第三遍校审
一般在翻译时我是按段落为单位的。先看一个段落，看懂了以后再把整个段落翻译出来。其中遇到不是很懂的句子先空下来，等到整章或整节翻译完成以后再回头看。这是因为我发现翻译时也有2/8原则。全文有80%的内容很好翻译，而20%的内容则比较难翻译。如果在翻译的过程中碰到20%难翻译的地方就努力攻克的话，会把翻译的时间的打散，进度会很慢。而第一遍粗译，跳过难以翻译的地方，第二遍时再补译的好处是，由于你已经翻译了整章，建立了良好的上下文关系，对付1，2句话那还不是小意思。此外还有心理因素，整章只有几句话没翻译，心里比较轻松，也更容易激发灵感。第二遍全部翻译完毕后，第三遍就是仔细校审了，这时候主要注意力就是句式的结构调整、词汇调整了。
每天坚持翻译，日积月累
一般翻译一本书编辑会给出时间限制的。而我翻译只能利用业余时间，可以说时间非常有限。如果三天打鱼、两天晒网，很容易堆积到最后，由于赶工而影响质量。所以养成良好的翻译习惯是非常必要的。可以每天至少翻译两页，周末多翻译一些，这样积少成多，水滴石穿，遇到节假日再突击一下，这样利用时间才是最合理的。自己也不会感觉有压力。
翻译技术类书籍，自身实力要过硬
我翻译的三本书，一本是关于JavaScript的，一本是关于HTML5和CSS3的，另一本是关于C# 多线程编程的。虽然这方面我之前都有所涉猎，但是为了保证翻译的质量和技术术语词汇的准确性，我会通读很多与之相关的书籍。以《Effective JavaScript》这本书为例，在翻译这本书之前我已经读过好几本与之有关的书了，但是为了保证翻译的质量，这毕竟是我翻译的第一本书，我不仅阅读了Effective系列的其他书籍（比如《Effective Java》），也阅读了大量与JavaScript有关的书（比如《JavaScript高级程序设计》,《JavaScript语言精粹》,《JavaScript权威指南》等）。通过大量的阅读与练习，我对原文的理解更加轻松，对词汇的翻译也更加准确。
翻译技术类书籍其实不难，有志于此的程序员们可以先将英语练好，多读几本英文技术类书籍，然后找一些自己喜欢的文章练练手，说不定有一天哪本译作上就有你的大名。
