在过去的 2 个月里面，我把我个人的大部分时间都投到了翻译《HTTPの教科書》一书的事情上。而直至2个月之后的现在，我已经完成了该书初稿的翻译工作，并在今年的 4 月 25 日，后改名为《图解HTTP》并由人民邮电出版社负责出版发行。
缘起
某一天下午，我碰巧浏览到图灵社区的某个页面，在招募一本日文书的翻译，猜测内容主要是讲 HTTP 协议（因为仅有一张封面及内容简述）。在更早一段时间内我对 Web 应用开发产生兴趣（因为我有个明确的需求要去实现），所以有关 HTTP 知识也涉猎一并学习了。如今面对这样一本书，从语言及技术 2 方面来说，壁垒已经不存在，而且我比较确信的是如果我愿意接手这个项目，自然能手到擒来。
翻译完这一本书的价值远大于翻译这一本书的预期。
- 帮助我解开困扰我相当久的一个问题。
- 通过逐字逐句的翻译，对HTTP的理解更深刻。
- 翻译方法及流程的掌握。
- 规划项目并确保进度不失控。
- 对国内图书出版流程的了解。
曾经有一段时间，我始终被一个问题困扰
我应该如何去理解别人？是否存在试图理解这回事？人与人之间的交往是否建立在相互理解的基础之上？如何才能做到真正地理解对方？
在相当长的一段时间内，我是在寻求这样的答案。因为无法 100% 地站在对方的立场，不管怎么说我理解，“我能理解你”这句话都相当地缺乏说服力。如果能做得更好一些，就是实际去做和对方相似度很高的事情。比如，我有好几个当文学翻译的朋友，经常会听到对方对于翻译如何苦逼的抱怨，我也是安慰几句，一笑了之。我自己也做过一些类似笔译方面的工作，但和翻译一本书相比，工作量和时间跨度上相差了好几个数量级。所以现在，对方若要是再向我诉苦，我就可以说：恩，我能理解：）就是这样程度的一种理解。于是在这里，稍稍插入一个断言。即， 如果想要理解一个人就尽量去做和对方相似度高的事情，去站在对方的立场，去体验。然后在自己心中默念：不要期望有人会理解你，永远假设没人懂你，但即使如此也没有关系。
翻译方法及流程的掌握
作为一名技术类图书翻译的新人，在次对翻译方法和流程试做一次回忆和总结。
阅读原文
当时拿到的是 PDF 电子档（如果还有下次的话会选择让对方给我快递一本实体书或复印本）。浏览目录，明确整本书大致的讲授内容。然后认真地通读一遍原文。在阅读的过程中，肯定会遇到个别生词术语（如果有实体书的话就能够直接在上面做好标记）；如果遇到读下来模凌两可的语句也需要着重标记。通读完全文之后，对整个书的翻译难度自然会有一个全局性的把握，而之前标记出来的词句自然成为了路标，这时才正式下笔开始翻译。
精译
整本书的翻译工作都是在 Sublime Text + Makedown 插件下完成的。之前说语言和技术方面的壁垒已经破了，这只是大方向上的；而翻译是一字一句落实到细节的活儿。难免会遭遇各种各样的问题。
术语的统一 在翻译的过程中，我管理的一张中日英术语统一表贯穿始终。如果说在翻译英语技术书籍时需要从英语中映射到中文对应的说法，那翻译日语时则多了这样一个步骤。日语→英语→中文。原因是，曾经都是看老美的书，几乎没有看过日本IT方面的书，如果直接从日到中，在表述上肯定会存在问题的，而先往英语上靠一下再回过头来找对应的中文译名就方便许多，但同时也麻烦些。
语言表述问题 出版社方面的要求是：翻译要求忠实原文，翻译准确，语言通顺，不得有漏译现象。尽量不对原书进行改动的行为。而我对自己的要求是： 要说人话 。再具体一些即是：尽量把长句切短，补足主语或宾语，不擅加个人理解上的改动或注释，忠实原文的同时无翻译腔，无语气词。为此我还特意买了几本最近才出版的日语技术类书籍，学习下别人是怎么做的。按我的理解，翻译并非是一项创造性质的工作，它完全是建立在原文基础上的改造，考验的是译者的改造技巧，如果能够以相当高明的技术改造并应付过去就是名合格的译者。如果译者具备相应的技术背景，那么在一些场景的翻译过程中就能够理解作者背后想传达的思想，如果仅仅直白地忠于原文也许会叫读者看得云里雾里。另一方面如果译者过于犀利，表达了超出作者范畴的理解也是不行的。所以对语言表述的难点在于，经译者的理解及处理后，能够让译文完整地传达作者的思想，还能够看起来相当地忠于原文。
技术的严谨 在解决上述2个非技术问题之后，核心问题是传达的技术是否正确及严谨。比如有一个章节讲到了 Header ，然后我就直接找了 RFC 2616 阅读了一遍。在翻译此书之前也看过几遍 《HTTP权威指南》 。我必须保证看了此书的读者不会因为我的翻译被误导而学习了错误的概念，这样还不如不读，我的翻译也失去了价值，同时白底黑字的也势必会成为烙印及口实。
校审
在完成初稿后我首先自己阅读了一遍，因为从翻译者 → 阅读者身份的转变同时会带动关注视角的改变。因为在翻译时，绝大程度上的注意力是在词，句，段落是否与原文原意贴切，会不停地在原文与译文之间切换着看。在变为阅读者之后，就完全抛弃了原文，一口气读一章节的译文的过程中，就会发现……对，软软的流畅度。如果自己在阅读过程中有卡顿，或被迫停下理解之处，大部分都是翻译细节没有处理到位的情况。于是，就在每一个细节的地方对用词、或表述结构进行微调，直至满意为止。最后，我还请了我的几位好友（暂略）来帮忙校对及润稿，全程在 bitbucket 上 用 git 完成，他们在 Web 方面的经验远在我之上，我试图这样通过诸多手段才能保证翻译上不存在问题。在我把初稿交予负责编辑之后又和她以 word批注 + mail等方式经行了长达 4 个版本的修改，逐字逐句，细节到每个标点的正确使用。
规划项目并确保进度不失控
全书约 307 页。如果以简单粗暴地按每天翻译3P来计算，就是102天约3个半月。老实说这个时间不算长，因为出版社会给与1-5个月的翻译周期。但是我无法接受，我手头上还有一些重要的 Project 等待我去完成（翻译只是一个意外的插曲）。于是，就变得再暴力一些，按每天 6P 的量来计算，51 天约 2 个月（最终我是花了 2 个月多 2 天的时间，比预计进度慢了 2 天整）。
翻译是一件比想象中更为吃力的事情。如果以我阅读此书的速度来看，1P 用个 30 秒就差不多了，但实际落到阅读-理解-查阅-咨询-输入-纠错，最终从日语假名转换成中文汉字，每 1P 都需要花费我 30 分钟甚至更长的时间。同时意味着我每天需要额外花费3 个小时的时间在这个项目中。现在重回这段的开头，规划已有，如何保证项目进度不失控？只要每天按照计划，按部就班地完成每日定量的作业即可保证。可最大的问题实际上在于无法 100% 保证每天能够完成这样的计划（这里并不是说计划本身的问题，而在于每天可能会出现的突发事件导致无法完成工作量的情况）。
针对可预见性的事态，我相应地调整了生活状态。比如：谢绝一切聚会，不出席邀约，砍掉了一次旅游计划，下班后直接回家，并保证周末最大限度宅在家中。晚上 21-23 点入睡，早上 4 点多起床。尽量减少娱乐性质的时间消耗（比如 1 话剧集我得分成3天看）只有保证翻译时间量上的投入，才能获得进度的平稳持续及高质量的翻译成果产出。
结语
从2013年9月18日到2014年6月的今天，总算可以抽时间做一次完整的回顾。从4月底发售至今，该书能够一举进入亚马逊、京东上的同类畅销榜（No.1~4 浮动）也属于对我初次翻译出版体验的良好回报吧。
