转载《翻译的艺术——致译者的一封信》
2010年02月28日 翻译
原文作者：刘江（CSDN&《程序员》总编）
原文链接：http://blog.csdn.net/turingbook/archive/2009/10/13/4665015.aspx
翻译无小事：要有使命感
当你录入每一个字的时候，无论正确或者错误，优雅或者蹩脚，它都有可能（如果没有在你自己日后的审查或者出版社的编审环节中被发现和解决的话）变成历史，保存在大大小小的图书馆里，被成千上万的（纸书和网络连载、电子版的）读者看到并对他们产生影响。
很多技术书，首印以后可能不会重印，所以，错误可能永远留在那里。勘误表当然能起到一定作用，但是请注意，我们没有办法将勘误表送到每个读者手里。而且，想想拿着勘误表在书上改正，该是一件多么痛苦的事情。
翻译无易事：不要过于自信
著名翻译家傅雷当年全职在家里专事翻译，呕心沥血，不过“日译千字 ”。（当然，我们毕竟翻译的是技术文档，难度和要求都小得多，我见过有经验的译者全职翻译每日万字左右的。）
有的译者会说：“这本书我读起来很轻松啊，翻译没问题！” 其实，翻译和阅读不同，能差不多看懂，和逐字逐句转变成地道流畅的中文，让读者（可能包括基础稍差的）在不接触原文的情况下容易地理解原作者所说的意思，基本上不是一回事。
有的译者会说：“这本书里的技术我很精通，翻译起来很容易。” 其实，翻译书的时候，所面临的技术问题相对较少（因为书往往是自成一体的，凡事多有来龙去脉。但是注意，只是相对！你很可能遇到自己不熟悉甚至根本不懂的技术领域），除了有些原书代码、叙述等等本身就有错，一般不难解决。毕竟你把开发环境架起来，试一下，基本上都可以搞定。 常见的错误，反而更多是因为英文本身不理解或者误解造成的。往往一个小小的复数、this、the、被动语态、and等连词的翻译或者理解错误，会造成整句、整段甚至多段的译文难以理解，或者逻辑错误。
翻译之难在于，它不仅考验你的：
1. 技术能力 。一本书涉及的技术内容可能很丰富，一个译者不见得能够全部精通。
2. 英文水平 。我们这一代的人所受的英文教育，基本上是不能轻松应付翻译这种工作的。
3. 中文水平 。理工科出身的我们，语文最多只是中学水平，而且教法学法很畸形。大家应该都有同感。
更考验你的：
4. 研究能力 。翻译中肯定会遇到技术或者非技术的词和短语你没见过、不知道的，而且有不少词和短语字典里也没有现成答案。
5. 逻辑思考能力 。英语很多句子里的代词和其他意义不那么明显的表达，需要通过上下文的逻辑思考进行推断。
6. 知识面 。原作者会追溯历史，讲很多老的技术，也会纵横开阖地进行横向比较，涉及很多其他平台或者技术（有些还很冷僻）。原书里还会有很多仅限于欧美文化 （名人名言、历史、地理、游戏、影视、歌曲……）的比喻、闲话等等。比如计算机书里常常出现的Yogi Berra。
7. 耐力 。翻译往往要持续数月，而且大部分同学肯定都是业余工作，深夜孤灯，而且一本书里肯定有你不喜欢或者没感觉的部分，但是还是得翻译出来，其辛苦程度可知……
8. 细心 。毛糙的译者交出的稿子，错别字、标点符号、术语一致性都会是大问题，更令编辑头疼的，还可能存在大量零散的漏译、英文拼写错误，以及最严重的，因为 粗心而造成的严重漏译（有时候单复数没有看清楚，指示代词没有理解对，会造成整句的误译；有时候连词的误译，会弄反整段话的逻辑）。
9. 沟通能力 。翻译往往不是一个人完成的，而且所有译者都要和编辑打交道。不及时沟通，可能造成整个项目的失败——因为交稿延期或者稿件不符合出版社要求、编辑工作时间很长，最终出版进度一拖再拖，出书的时候已经过时或者没有市场了。
10. 交际圈 。遇到自己无法解决的问题，尤其是特定领域的问题，需要相关的专家支援。
翻译无难事：也没什么大不了的
翻译毕竟只是一种转换别人现成文字的工作，并没有什么完全无法克服的困难，何况我们面对的知识技术文献而已，含义基本准确固定，对艺术性没有太多要求。
只要做到以下这几点，翻译就没什么大不了的。
1. 多想：带着逻辑思考去翻译。
翻译本身大多时候是在词、短语和子句的层次工作，但是思考层次必须提高。一本书都是从总到分逐层细化的树状结构，翻译时脑子里要有更大范围的上下文。
和 阅读时应该在脑子里读出作者的逻辑脉络（这一章先讲了什么，又讲了什么，这一点又分为几部分、几个步骤……，对于这个问题，先说了Solution A，然后又说了Solution B，C，A的问题是……，B的问题是……，C克服了这些毛病……作者对这些选择的态度是A不好，B不好，C好……）一样，翻译时也要有类似的脑图。
翻译一个词时，要考虑全句、全段、上下几段甚至全节、全章和全书的整体思路和作者倾向。
另 外，原书是肯定会有错的，像Effective Java那样的名著，曾经被日文版译者找出大量错误。我们所出的《SQL解惑》一书，作者虽然是世界级权威，但是我们的译者也发现了大量错误。按照逻辑， 根据自己的技术基础，可以发现各种错误。整理勘误表，提供给编辑，反馈给原作者。
2. 多查：善于利用工具。
傅雷当年“日译千字 ”，有论者说，是因为没有那么方便的工具。的确如此。今天，任何问题在没有充分查找的情况下，就说无法解决，都是不负责任的。
图灵公司的论坛 （实名制，需要提供自己的个人信息进行申请）上有一个网上的词汇表 ，收集了很多常见的不容易处理、有歧义的术语、习语以及其他词语的译法，请优先参考。
我们不仅有很好的英语字典、够用的中文字典，而且有方便的网上内容，Wikipedia、FreeDictionary。当然，还有Google等等搜索引擎。有了Google、有道这样的语料库，基本上没有什么问题是无法解决的。请参考：图灵推荐工具 。
高效查询的关键在于，该查的时候一定要查！其次，要知道上哪里查比较权威。直接Google的结果，往往会误导你，迷糊你。
专有名词（人名、公司名、电影名……）不知道一定要查，否则你很可能连他说的是什么都没有搞清楚！这种笑话非常常见，我见过一个稿子，把某乐队的专辑翻译成什么纪念册的……
当然，知道这是个专有名词，有时候也是需要智慧的。
不熟悉的术语、领域名词一定要查，否则就会翻译得牛头不对马嘴，轻者也是外行话。
译文里想用成语、典故或者比较少见的自己不太有把握的词，也请查中文字典。这些少见词往往不能望文生义，往往感情色彩比较特别（贬义多）。对自己的中文水平要有正确认识。比如“明日黄花”而不是“昨日黄花”。再比如“望其项背”只能用否定。
3. 多问：善于利用别人。
谁也不是全知全能，百科专家。有时候，问对了人，比自己查找、研究半天，效果好得多。
请记住，你不是一个人在战斗。
图灵公司有经验丰富的编辑，他们看过无数类似或者相关的稿件，很可能你的问题早已经被解决了。遇到问题，请多多与编辑沟通，不要企图隐藏或者糊弄过去 。对编辑的修改意见，不要轻易否定，尤其是标准、规章、规矩性的要求，请尽量遵守。
如果在稿件中对原文有比较特殊的处理（原文有错，对原文的句序、句式、说法等等有较大改变，原文某句不宜翻译，或者翻译出来对中国读者无用、无效、无意义，等等），没有按照原文翻译，请在稿中用批注说明，不要让编辑再浪费时间琢磨 。
请一定加入图灵俱乐部论坛 ，有许多和你一样在翻译和曾经翻译过书的译者以及行业内的专家，会为你分忧，和你讨论。
4. 开放：多一双眼睛总是好的。
我们要求译者将序、前言、致谢和前三章内容翻译完毕之后，尽快贴到图灵俱乐部论坛 上，接受内部审读。
我们也要求编辑将修改意见更多地开放，接受更多人的检查。
我们鼓励译者在个人网站、blog、论坛等等场合在征得编辑的同意后，公开少量章节的翻译草稿，听取广大读者的意见。一般章节开放数量不能超过原书的四分之一。而且必须在最前面写上：
“本文节选自即将由人民邮电出版社图灵公司出版的《XXX》（英文版XXXXXX）一书，已经过图灵公司授权，如需转载，请与contact@turingbook.com联系。”
5. 翻译完了自己再看一遍
这一点虽然容易，但是一般都做不到。许多错误被编辑发现之后，译者第一个反应会是，啊，这个怎么都错了！为了防止自己犯被读者痛骂、被啐一脸口水、被扔一身鸡蛋的错误，谨记。
最后两点重要的说明
1. 翻译中，发现任何涉及意识形态（说到中国、共产主义、共产党、社会主义、马克思主义等等）、政治、民族（尤其是藏族、维吾尔族、回族）和宗教以及其他敏感话题，请在稿中突出（颜色、下划线加批注）标出，提醒编辑，由编辑来处理。
2. 翻译中，遇到自己不懂、不好解决的问题，首先要多查多问。如果在交稿前仍然没有解决，请在稿中突出（颜色、下划线加批注）标出，提醒编辑，由编辑来处理。千万不要掩饰、隐藏起来，铸成大错。
另外，特别推荐思果先生的翻译原则 ，请反复体会：
二、切不可译字，要译意，译情，译气势，译作者用心处。记住，译者最大的敌人是英文字。
三、切不可抱定一个英文字只有一个中文译文解释，以不变应万变。如果你译一个英文字把认定的一个意思写下，再和上下文一同看，觉得不大象话，你可能错解了那字的意思，赶快细查字典。
四、切不可抱死一两本英汉字典做翻译工作。不论编得多好的英汉字典都不很可靠，这种字典有先天的缺陷，有人谋的不臧；并非无用，而绝不完全可靠。多备几本好英文字典，不怕辛苦多翻翻。
五、不要以为译好就十全十美。整段、整句会漏译，数目字会看错（这一点最不能得到别人原谅），英文会看错，中文会不通顺，至少逐字逐句对一两次，过些时再看一两次（单看译文是否可以过得去）。你多找出一个错，别人就少发见一个。
六、不懂的题材，千万不要率尔翻译。至少也要找一两本有关的书或大一些的百科全书查一查。如能找到专家请教一下更好。西方的学问分门别类，每一门都极高深，得到各科通俗的常识都不容易，不用说全部的知识了。
七、没有绝对把握的中文字词或成语不要用。成语用得贴切，不啻锦上添花；但失之毫厘，谬以千里，用得不对，反而贻人笑柄。用时也许觉得是神来之笔，其实仔细一查，似是而非，或意思正正相反。
《JavaScript高级程序设计（第2版）》序
2010年01月17日 Web开发, 好书, 翻译
从诞生至今的大部分时间里，焦虑、抨击、蔑视和误解一直与JavaScript如影随形。JavaScript刚刚问世那几年，很多“严肃的程序员”都认为它不够严肃。
相比之下，.COM泡沫时期加入Web开发行列的许多文科生，则普遍觉得JavaScript深不可测、晦涩难懂。就算那些耐力和韧性俱佳者能够把JavaScript琢磨得很透，但仍然摆脱不掉竞争性浏览器提供的不同实现给他们带来的麻烦。凡此种种，最终导致粗制滥造的脚本越来越多。另一方面，拜Web前端代码的无比开放性所赐，各种坏习惯不断从一个站点被粘贴进另一个站点的源代码中。那些实现活该臭名昭著，可是，JavaScript这门语言也因此被严重拖累，背上了不该有的坏名声了。
2001年前后（随着Internet Explorer 6的发布），浏览器实现已经大为改进，Web开发实践也开始得到改善，呈现出了二者水乳交融的局面。作为Ajax核心的XMLHttpRequest对象正慢慢地为人们所发现，一种新的桌面风格的用户交互模式出现在浏览器中。允许JavaScript操作Web文档结构和内容的DOM API已经定型。而CSS，不管人们如何曲解或者无视它，也无论浏览器开发商怎样丧心病狂地实现它，都已经成长得足够茁壮，它的美妙和反应敏捷令它能够与新的Web交互能力配合无间。最终，JavaScript一扫颓势，变得令人惊诧、让人兴奋、使人敬畏。想想2004年第一次使用Google Maps时的情景吧，那种感觉你或许还记忆犹新。
Google Maps是新兴应用程序的典型代表。这类浏览器编程与后端编程并重的应用程序，不禁令人对Web浏览器窗口中那块“画布”的未来浮想联翩。（除Google Maps之外，早在2003年就基于网页邮件客户端提供类似Outlook功能的Oddpost，也是这类应用程序的一个了不起的先驱。）随着这类应用程序如雨后春笋般大量涌现，以及支持它们的浏览器的市场份额不断攀升，一个Web应用全面复兴的时代真的到来了。“Web 2.0”诞生了，Ajax也成了“IT”技术。Web似乎在一夜之间脱胎换骨，重新激发起了人们的兴趣。而JavaScript作为唯一的Web编程语言，也变得更有意思了。
有意思，但用好它却不简单。JavaScript以及在DOM和BOM中为其定义的API不一致的实现，给跨浏览器编程造成了比原本大得多的困难。前端设计行业还远未成熟。大学教学计划并没有（至今仍没有）做出相应的调整，以满足相关的培训要求。
到2004年底，JavaScript无疑已经成为最重要的编程语言。但从学术角度看，它依然不具备进入一类学科的资格。Web虽然已经翻开了新的一页，但在培养足够的知识全面、训练有素的人才方面，我们依然面临着严峻的挑战。
为此，很多技术作者挺身而出，撰写了不少有关JavaScript的图书。几年来，这类书虽然也出了不下几十本，但总体来说仍然不尽如人意。其中有的在推销与落伍的浏览器有关的技术，有的则在卖弄容易剪贴但却不好扩展和维护的技术。让人想不通的是，许多JavaScript图书让人觉得作者好象并不真正喜欢JavaScript，或者他们不认为读者应该喜欢它，再或者他们根本不相信读者能够完全理解JavaScript。
2005年，Nicholas C. Zakas这本书的第一版面世，为前端工程领域奉献了一本真正的好书。当时，我和雅虎的同事们正在创建YUI（Yahoo! User Interface Library，Yahoo!用户界面库），打算将其作为公司前端工程的基础，同时也借以推广我们这门新学问的最佳实践。每到周五，我们就聚到一间教室里讨论前端工程，也向大家讲解JavaScript、CSS以及在浏览器中创建Web应用程序的知识。我们从已出版的高级JavaScript及DOM脚本编程方面的图书中认真挑选了几本，想让新工程师通过它们掌握如何构建耐用、基于标准且容易维护的Web应用程序。Zakas的书一出版，马上就被选为我们的JavaScript内部培训课本。
从那时起我们就一直使用他的书。我们一致认为这本书太有用了，于是就跟Zakas商量，让他加入雅虎帮我们建立公司的前端工程社区。
Zakas在书中传达的理念与众不同——JavaScript既需要严肃认真地对待，但也是完全可以理解和掌握的。如果你是个程序员，这本书会告诉你JavaScript与各种编程语言的关系，以及如何运用你已经习以为常的各种编程模式。你可以理解JavaScript的继承机制及其固有的动态特性（虽不合传统，但却十分自由十分强大），可以从Zakas这位尊重和理解JavaScript的同道那里学会欣赏JavaScript这门语言。
如果你曾经是一名文科生，在网络泡沫时期步入了这个行业，至今也没有转行，而且想要弥补自己在JavaScript方面的不足，你会发现Zakas是一位难得的良师益友。他可以帮你实现从“会做”到“做好”的转变。他能让你认真地理解这门严肃的学问。最重要的是，他不会让你先入为主地产生对这门语言应该理解多深的想法。相反，通过他严肃、耐心、通俗易懂的讲解，你自然而然地会对这门语言有同样深刻的认识。
本书是经过扩展、更新和改进后的第二版，删除了上一版中与今天的职业需求无关的主题，并用我们在2005年至2008年学习的新知识更新了剩余的内容。这几年是JavaScript发展的重要时期，Zakas则始终位于最前沿孜孜不倦地学习这些新知识。他这些年一直在致力于建造新一代最流行的Web个人门户（My Yahoo!），以及开发Web上最受欢迎的站点（Yahoo!主页）的新版本。Zakas以他作为老师和作者的独特视角，筛选出由这些超复杂、超大型应用程序磨砺出的经验，并将这些经验融入到了本书的字里行间。
他给出的解决方案远远超出了一本好书的范畴，只有每天都与代码同呼吸共命运的人，才有可能与读者分享如此具有实用价值的知识。
说实话，本书新版的面世对我和各位读者而言真是个莫大的喜讯。因为它的内容比上一版更有价值、更能反映JavaScript最新的发展成果，因此也更加令人不可错过。
埃里克·米拉利亚（Eric Miraglia）
YUI高级技术经理 哲学博士
于加利福尼亚州森尼维耳市
Nicholas C. Zakas，Yahoo!主页首席前端工程师，个人网站www.nczonline.net。《Professional JavaScript for Web developers, 2nd Edition》作者。最新专著《High Performance JavaScript》（O’Reilly Media; 1 edition,March 15, 2010）。
Nicholas C. Zakas谈怎样才能成为优秀的前端工程师
2010年01月10日 Web开发, 原创, 翻译
Original Post：What makes a good front end engineer?
Nicholas C. Zakas，2007年8月15日
翻译完成：2010年1月10日，最后更新：2010年1月10日
昨天，我负责了Yahoo!公司组织的一次面试活动，感触颇深的是其中的应聘者提问环节。我得说自己对应聘者们提出的大多数问题都相当失望。我希望听到一些对在Yahoo！工作充满激情的问题。在昨天的应聘者中，只有一个人的问题是我认为最好的，那个人问我：“你觉得怎么才能成为优秀的前端工程师？”我觉得很有必要把这个问题从面试房间里拿出来讨论一下。
首先，前端工程师必须得掌握HTML、CSS和JavaScript。只懂其中一个或两个还不行，你必须对这三门语言都很熟悉。也不是说必须对这三门语言都非常精通，但你至少要能够运用它们完成大多数任务，而无需地频繁地寻求别人的帮助。
优秀的前端工程师应该具备快速学习能力。推动Web发展的技术并不是静止不动的，没错吧？我甚至可以说这些技术几乎每天都在变化，如果没有快速学习能力，你就跟不上Web发展的步伐。你必须不断提升自己，不断学习新技术、新模式；仅仅依靠今天的知识无法适应未来。Web的明天与今天必将有天壤之别，而你的工作就是要搞清楚如何通过自己的Web应用程序来体现这种翻天覆地的变化。
计算机科学这个大门类下面的许多分支在人们眼中实际上都不外乎科学。但是，我们所说的前端不是什么科学，而是艺术。艺术家不仅要掌握谋生的技术，还要懂得如何运用。对同一个问题的解决方案在这种情况适用，在另一种情况下可能就不适用。对Web应用程序的前端而言，解决同一问题的方案经常会有很多。没有哪个方案是错的，但其中确实有一些是更合适的。优秀的前端工程师应该知道在什么情况下使用哪种方案更合适，而在什么情况下应该重新选择。
优秀的前端工程师需要具备良好的沟通能力，因为你的工作与很多人的工作息息相关。在任何情况下，前端工程师至少都要满足下列四类客户的需求。
- 产品经理——这些是负责策划应用程序的一群人。他们能够想象出怎样通过应用程序来满足用户需求，以及怎样通过他们设计的模式赚到钱（但愿如此）。一般来说，这些人追求的是丰富的功能。
- UI设计师——这些人负责应用程序的视觉设计和交互模拟。他们关心的是用户对什么敏感、交互的一贯性以及整体的好用性。他们热衷于流畅靓丽但并不容易实现的用户界面。
- 项目经理——这些人负责实际地运行和维护应用程序。项目管理的主要关注点，无外乎正常运行时间（uptime）——应用程序始终正常可用的时间、性能和截止日期。项目经理追求的目标往往是尽量保持事情的简单化，以及不在升级更新时引入新问题。
- 最终用户——当然是应用程序的主要消费者。尽管我们不会经常与最终用户打交道，但他们的反馈意见至关重要；没人想用的应用程序毫无价值。最终用户要求最多的就是对个人有用的功能，以及竞争性产品所具备的功能。
那么，前端工程师应该最关注哪些人的意见呢？答案是所有这四类人。优秀的前端工程师必须知道如何平衡这四类人的需求和预期，然后在此基础上拿出最佳解决方案。由于前端工程师处于与这四类人沟通的交汇点上，因此其沟通能力的重要性不言而喻。如果一个非常酷的新功能因为会影响前端性能，必须删繁就简，你怎么跟产品经理解释？再比如，假设某个设计如果不改回原方案可能会给应用程序造成负面影响，你怎么才能说服UI设计师？作为前端工程师，你必须了解每一类人的想法从何而来，必须能拿出所有各方都能接受的解决方案。从某种意义上说，优秀的前端工程师就像是一位大使，需要时刻抱着外交官的心态来应对每一天的工作。
我告诫新来的前端工程师最多的一句话，就是不要在没有作出评估之前就随便接受某项任务。你必须始终记住，一定先搞清楚别人到底想让你干什么，不能简单地接受“这个功能有问题”之类的大概其的说法。而且，你还要确切地知道这个功能或设计的真正意图何在。“加一个按钮”之类的任务并不总意味着你最后会加一个按钮。还可能意味着你会找产品经理，问一问这个按钮有什么用处，然后再找UI设计师一块探讨按钮是不是最佳的交互手段。要成为优秀的前端工程师，这种沟通至关重要。
无论从哪个方面讲，我都觉得前端工程师是计算机科学职业领域中最复杂的一个工种。绝大多数传统的编程思想已经不适用了，为了在多种平台中使用，多种技术都借鉴了大量软科学的知识和理念。成为优秀前端工程师所要具备的专业技术，涉及到广阔而复杂的领域，这些领域又会因为你最终必须服务的各方的介入而变得更加复杂。专业技术可能会引领你进入成为前端工程师的大门，但只有运用该技术创造的应用程序以及你跟他人并肩协同的能力，才会真正让你变得优秀。
延伸阅读
Nicholas C. Zakas的书
 |
 |
 |
 |
本博客专注于Web前后端技术和技术翻译。目前正在翻译《JavaScript高级程序设计（第2版）》。新浪微博（t.sina.com.cn/lisf），Twitter（@cncuckoo，仅仅用于跟踪国外牛人；我翻不了墙，无法接受各位朋友的follow，抱歉！） 
