翻译无小事：要有使命感

当你录入每一个字的时候，无论正确或者错误，优雅或者蹩脚，它都有可能（如果没有在你自己日后的审查或者出版社的编审环节中被发现和解决的话）变成历史，保存在大大小小的图书馆里，被成千上万的（纸书和网络连载、电子版的）读者看到并对他们产生影响。

很多技术书，首印以后可能不会重印，所以，错误可能永远留在那里。勘误表当然能起到一定作用，但是请注意，我们没有办法将勘误表送到每个读者手里。而且，想想拿着勘误表在书上改正，该是一件多么痛苦的事情。

翻译无易事：不要过于自信

著名翻译家傅雷当年全职在家里专事翻译，呕心沥血，不过“日译千字 ”。（当然，我们毕竟翻译的是技术文档，难度和要求都小得多，我见过有经验的译者全职翻译每日万字左右的。）

有的译者会说：“这本书我读起来很轻松啊，翻译没问题！” 其实，翻译和阅读不同，能差不多看懂，和逐字逐句转变成地道流畅的中文，让读者（可能包括基础稍差的）在不接触原文的情况下容易地理解原作者所说的意思，基本上不是一回事。

有的译者会说：“这本书里的技术我很精通，翻译起来很容易。” 其实，翻译书的时候，所面临的技术问题相对较少（因为书往往是自成一体的，凡事多有来龙去脉。但是注意，只是相对！你很可能遇到自己不熟悉甚至根本不懂的技术领域），除了有些原书代码、叙述等等本身就有错，一般不难解决。毕竟你把开发环境架起来，试一下，基本上都可以搞定。 常见的错误，反而更多是因为英文本身不理解或者误解造成的。往往一个小小的复数、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. 翻译中，遇到自己不懂、不好解决的问题，首先要多查多问。如果在交稿前仍然没有解决，请在稿中突出（颜色、下划线加批注）标出，提醒编辑，由编辑来处理。千万不要掩饰、隐藏起来，铸成大错。

另外，特别推荐思果先生的翻译原则 ，请反复体会：

上个月，我又参加了Mozilla公司组织的一次研讨会，这一次讨论的是Web数据库。虽然研讨会的议题很有意思，但我觉得会议期间大家对另一个问题的争论似乎更值得关注。争论中，与会者针对浏览器到底应该为JavaScript提供什么样的API分成两派。一派坚持认为原生的JavaScript API应该尽量保持低级化，然后由库开发者在低级API基础上再去构建更好用的接口。另外一派，也是我所在的阵营，则认为中级API才是大势所趋。没有人认为浏览器应该向开发人员提供高级API。所谓低级、中级、高级到底都是什么意思呢？

低级API

低级API仅为提供基本功能而设计。由于只要能实现相应功能即可，因此这种API不需要很直观或者很好理解。有时候，低级API确实会给初级甚至中级开发人员造成理解上的困难。这样一来，借由人们频繁使用来发现相应API问题的机会就大为减少了。大家都会指望库开发者在这些低级API基础上实现直观、好用的API，以便于普通开发人员使用。doument.cookie就是说明低级API最好的一个例子。

作为JavaScript开发人员操作cookie的唯一接口，document.cookie可谓有史以来最难使用的一个API。关于cookie，我专门写过一篇文章，还探讨过它的安全性问题，其中都涉及到如何在JavaScript中使用它们；因此，这里只能算是一个简单的介绍了。要设置cookie，必须以正确的cookie格式来设置document.cookie属性，例如：

要取得cookie，则需要读取document.cookie，返回的字符串是如下列所示的名值对格式：

而为了得到想要的值，必须先从这个字符串中查找相应的名字，然后再解析出相应的值。

之所以把这种API归类为低级API，是因为其实现要求你必须先了解cookie的内部格式，然后才能使用它。实际上，document.cookie属性只是在简单地模仿Set-Cookie和Cookie这两个对开发人员不可见的HTTP首部。为了写cookie，必须要理解字符串的确切格式，这涉及到其中的名和值必须采用URI编码形式，而其他片段之间必须以一个分号和一个空格来分隔，此外还必须知道设置过期日期的正确日期格式。反过来也一样，在读cookie时，你同样需要知道返回的字符串是什么格式，然后才能从中解析出想要的数据。这就是所谓的“遇繁不简，遇简也不简”。一句话，这种API对于不了解cookie的人根本没有用。

如果大多数开发人员都不会直接使用某个API，你就可以说它是低级API。不用，是因为使用它们所需的知识储备（Cognitive Overhead）太多了。绝大多数开发人员在使用JavaScript读写cookie时，最终都会求诸于一个JavaScript库例如YUI中的Cookie工具（YUI2和YUI3），这些工具把那些令人讨厌的实现细节都隐藏起来了。

这正是那些低级API的支持者所愿意看到的：浏览器应该只提供基本功能，而基于这些功能开发易用API的任务应该交给开发人员社区。这些人支持低级API有一个主要的理由，即围绕基本功能可以实现任何层次的抽象，开发人员也会因此获得更多选择，从而更好地利用基本功能。

低级API的问题在于浪费时间。如果你创建了低级API，那结果就是潜在用户的数量会很少。至于什么时候能够出现好用的抽象工具，只能指望某一天这些用户中有（一个或几个）人会意识到确实有必要去做这件事，以便其他社区人员更好地利用该API。如果你想让新API尽快地被别人使用，你就会明白应该怎样去改进它，低级API根本不合适。

提示：大多数服务器端语言（如 ASP.NET、JSP、PHP）都提供了读写cookie的原生抽象，但JavaScript始终都没有。

高级API

这一争论的另一个极端是高级API。高级API设计出来就是为了让开发人员直接使用的，并且一般都非常直观。这种API不仅要考虑提供某种功能，而且还要提供使用相应功能的友好、易用的接口。高级API设计首先考虑的是开发人员的方便，因而通常需要对开发人员使用API的方式从理论上作出归纳。显然，这又是一个问题：谁能确切地知道某个人希望怎么去使用一个API呢？因此，在浏览器中提供原生的高级API几乎就是一个不可能完成的任务。

各式各样的JavaScript库就是高级API的典型例子。这些库都面向相同的浏览器，但为实现相同功能而提供的接口却差别很大。使用jQuery的方式与使用YUI截然不同；这是件好事，因为开发人员可以选择。可是，如果你告诉YUI开发人员必须使用jQuery语法写代码——因为只能使用一种语法；或者相反，会怎么样呢？相信对此提出抗议的开发人员一定会成群结队。强迫人们必须以某种方式开发是不幸之源。只有抽象，或者说只有随时都可以提高和降低抽象级别，才会让开发充满乐趣，也才能激励开发人员不断地创新。

高级API要求的知识储备非常低，因此开发人员无需了解太多就可以直接使用。但值得高兴的是，没有人认为浏览器应该提供高级AIP。大家都希望有所选择，都希望不同程度的抽象。

中级API

折衷方案是中级API。以我的观点来看，中级API是浏览器所应该研究和实现的。顾名思义，中级API处于低级和高级之间，兼具二者之长。所谓中级API，（我的定义）就是针对最常见的应用提供简单的接口，同时能够通过扩展实现更强大的操作和对不常见应用的支持。第一部分，常用的接口，是非常简单、无需抽象即可直接使用的。而不常用接口可以更复杂一些，甚至可以“让人摸不着头脑”，因为很少会有人用。

XMLHttpRequest是不错的中级API中最出色的例子。使用它最常见的情形就是发送一次GET请求，然后取得XML数据。实现这个过程的代码不多：

虽然有人会说onreadystatechange这个事件处理程序看起来有点麻烦，但实际上，你要做的不过是检查一点信息，以确定是否接收到了正确的数据。可是，所有必需的信息都已经各就各位了，而且也已经转换成了方便访问的格式：HTTP状态就在那摆着，而XML也已经转换成了DOM格式。为了给你提供这些数据，API已经做了不少的工作了。

另一种不太常见的用法就是在URL中包含提交的表单数据。虽然代码难看点，但仍然可以接受：

除此之外，你当然还可以把XMLHttpRequest对象用于更复杂的处理中，例如Comet。问题的关键在于，它在常用情形下很简单，而且还能轻易地支持更复杂、更不常见的用例。这样一来，JavaScript库也容易在后台构建一个比较好用的接口，帮我们处理那些复杂应用下的琐碎细节。尽管每个JavaScript库在如何发起Ajax通信方面各有各的方式，但XMLHttpRequest接口的设计能够很好地适应所有方式。

注意：有些人认为XMLHttpRequest也属于低级API。我承认它不是最清晰的API，但在常见用例中它确实非常简便易行。不要忘了，最初在设计这个对象的时候，常见用例就是从服务器上取得XML数据。从那个时候到现在，常见用例已经变了，但人们照样还在使用同一个API。在我看来，这恰恰表明了它是一个不可多得的中级API。

总结

我主张浏览器应该原生提供中级API，这样才能自如地应对常见用例，同时还可以为不常见的用例留下扩展的空间。API的抽象程度太低，不利于广泛流传，更不容易引起开发社区的重视；API的抽象程度太高，由于限制的用例太专，人们要么能用，要么根本就用不了。目前来看，较新的API似乎有低级化的倾向，如此一来，开发人员在实际使用它们之前，往往需要有第三方来实现一些必要的抽象。我希望能够阻止这种趋势，好让常见用例实现起来更简单，以便人们能够立即使用它们，同时还可以对它们加以扩展。而中级API能够同时满足这两个条件。

从诞生至今的大部分时间里，焦虑、抨击、蔑视和误解一直与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高级技术经理 哲学博士
于加利福尼亚州森尼维耳市

昨天，我负责了Yahoo!公司组织的一次面试活动，感触颇深的是其中的应聘者提问环节。我得说自己对应聘者们提出的大多数问题都相当失望。我希望听到一些对在Yahoo！工作充满激情的问题。在昨天的应聘者中，只有一个人的问题是我认为最好的，那个人问我：“你觉得怎么才能成为优秀的前端工程师？”我觉得很有必要把这个问题从面试房间里拿出来讨论一下。

首先，前端工程师必须得掌握HTML、CSS和JavaScript。只懂其中一个或两个还不行，你必须对这三门语言都很熟悉。也不是说必须对这三门语言都非常精通，但你至少要能够运用它们完成大多数任务，而无需地频繁地寻求别人的帮助。

优秀的前端工程师应该具备快速学习能力。推动Web发展的技术并不是静止不动的，没错吧？我甚至可以说这些技术几乎每天都在变化，如果没有快速学习能力，你就跟不上Web发展的步伐。你必须不断提升自己，不断学习新技术、新模式；仅仅依靠今天的知识无法适应未来。Web的明天与今天必将有天壤之别，而你的工作就是要搞清楚如何通过自己的Web应用程序来体现这种翻天覆地的变化。

计算机科学这个大门类下面的许多分支在人们眼中实际上都不外乎科学。但是，我们所说的前端不是什么科学，而是艺术。艺术家不仅要掌握谋生的技术，还要懂得如何运用。对同一个问题的解决方案在这种情况适用，在另一种情况下可能就不适用。对Web应用程序的前端而言，解决同一问题的方案经常会有很多。没有哪个方案是错的，但其中确实有一些是更合适的。优秀的前端工程师应该知道在什么情况下使用哪种方案更合适，而在什么情况下应该重新选择。

优秀的前端工程师需要具备良好的沟通能力，因为你的工作与很多人的工作息息相关。在任何情况下，前端工程师至少都要满足下列四类客户的需求。

1. 产品经理——这些是负责策划应用程序的一群人。他们能够想象出怎样通过应用程序来满足用户需求，以及怎样通过他们设计的模式赚到钱（但愿如此）。一般来说，这些人追求的是丰富的功能。
2. UI设计师——这些人负责应用程序的视觉设计和交互模拟。他们关心的是用户对什么敏感、交互的一贯性以及整体的好用性。他们热衷于流畅靓丽但并不容易实现的用户界面。
3. 项目经理——这些人负责实际地运行和维护应用程序。项目管理的主要关注点，无外乎正常运行时间（uptime）——应用程序始终正常可用的时间、性能和截止日期。项目经理追求的目标往往是尽量保持事情的简单化，以及不在升级更新时引入新问题。
4. 最终用户——当然是应用程序的主要消费者。尽管我们不会经常与最终用户打交道，但他们的反馈意见至关重要；没人想用的应用程序毫无价值。最终用户要求最多的就是对个人有用的功能，以及竞争性产品所具备的功能。

那么，前端工程师应该最关注哪些人的意见呢？答案是所有这四类人。优秀的前端工程师必须知道如何平衡这四类人的需求和预期，然后在此基础上拿出最佳解决方案。由于前端工程师处于与这四类人沟通的交汇点上，因此其沟通能力的重要性不言而喻。如果一个非常酷的新功能因为会影响前端性能，必须删繁就简，你怎么跟产品经理解释？再比如，假设某个设计如果不改回原方案可能会给应用程序造成负面影响，你怎么才能说服UI设计师？作为前端工程师，你必须了解每一类人的想法从何而来，必须能拿出所有各方都能接受的解决方案。从某种意义上说，优秀的前端工程师就像是一位大使，需要时刻抱着外交官的心态来应对每一天的工作。

我告诫新来的前端工程师最多的一句话，就是不要在没有作出评估之前就随便接受某项任务。你必须始终记住，一定先搞清楚别人到底想让你干什么，不能简单地接受“这个功能有问题”之类的大概其的说法。而且，你还要确切地知道这个功能或设计的真正意图何在。“加一个按钮”之类的任务并不总意味着你最后会加一个按钮。还可能意味着你会找产品经理，问一问这个按钮有什么用处，然后再找UI设计师一块探讨按钮是不是最佳的交互手段。要成为优秀的前端工程师，这种沟通至关重要。

无论从哪个方面讲，我都觉得前端工程师是计算机科学职业领域中最复杂的一个工种。绝大多数传统的编程思想已经不适用了，为了在多种平台中使用，多种技术都借鉴了大量软科学的知识和理念。成为优秀前端工程师所要具备的专业技术，涉及到广阔而复杂的领域，这些领域又会因为你最终必须服务的各方的介入而变得更加复杂。专业技术可能会引领你进入成为前端工程师的大门，但只有运用该技术创造的应用程序以及你跟他人并肩协同的能力，才会真正让你变得优秀。

延伸阅读

• Nicholas C. Zakas如何面试前端工程师
• 如何通过Nicholas C. Zakas的面试

Nicholas C. Zakas的书

早就打算写这篇文章了，但时至今日才决定动笔。如果你投了简历，那么应该会在面试你的人名单里找到我的名字。你现在就有点紧张了，（好啦，别不好意思）面试总会让人感觉有点不舒服。作为面试官，我其实并不算难对付，但如果你想在我们谈话之后让我放你过关，你确实得做一些必要的准备。

• 回答问题。我问你一个问题，你必须要回答它。我遇到应聘者在回答我问题时顾左右而言他的情况太多了。我知道你会有些紧张，说几句不着边际的话可能有助于缓解，但请你不要喋喋不休，要赶快回到正题上来。我不想知道你的宠物猫最近又出了什么新状况，我只想听到你的回答。假如你没有听明白我问的是什么，可以要求我再解释一下，重复几遍问题或者换一种问法，对我而言没有什么。

• 告诉我你不知道什么。如果我问到了你不知道的问题，一定要告诉我。我不认为你的大脑里可以装得下百科全书。在知道了你不知道什么以后，我对你的评估才会更加公平。问题仍然要回答，但我会给你一些提示，同时也可以考察一下你解决问题的能力。

• 不要放弃。在我面试你的过程中，不要总想着放弃。如果你被我前面的话不幸言中，那么你可能会面对一个让你不知所措的问题，而且你也告诉我你答不上来了。此时此刻，千万不要打退堂鼓！我会尽力提醒你，让你找到正确答案；因此不要随随便便打断我说：“我真的不知道。”在我们这个行业，你经常会遇到没有现成解决方案的挑战，到时候你会轻易放弃吗？我必须知道你具备解决问题的能力，而不是遇到一点挫折就轻言放弃。

• 不用担心怪问题。有些公司的确有吓唬应聘者的传统，他们会让你回答一些类似脑筋急转弯似的稀奇古怪的问题。对那种面试方式，我不敢苟同。我提的所有问题都有答案，而且绝大多数还不止有一个正确答案；我保证一个怪问题也不会问你。因为这样既会让你难堪，又对我毫无意义。你大可放心，我的每个问题都至少会有一个正确答案。

• 自圆其说。如果你提到了某个解决方案或者强调自己掌握了某方面知识，请做好进一步讨论它的准备。假设我问了一个问题，你在回答这个问题时提到：“对，因为IE不支持CSS3……”然后，你最好能够跟我讨论一下要是IE支持CSS3你会怎么办。

• 不要说自己是专家。大多数面试中可能都需要注意这一条，但我对这一条尤其敏感。我从来不会把应聘者划分为三六九等，因此你也不必告诉我你属于哪个等级。一旦你声明自己已经跻身“专家”的行列，我怕有些问题会让你下不来台。我确实见过自称专家而又确实是专家的人。但是，我认为真正的专家不会自己说出来，而是会做给你看。

• 不要靠卖弄赚取我的好印象。如果我想知道什么，我会问。我知道在面试时需要了解哪些信息，只要一听到有人说“想不想看一个绝妙的技巧？”或者其他类似的话，我都有一种立即中断面试的冲动。所以，请尽力回答好我的问题即可。

• 充满激情。如果你想得到跟我一起工作的机会，请给我一个愿意跟你共事的理由。最好的理由就是要有激情，把你主动、积极学习的热情展示出来。希望你能谈一谈产品、公司，以及为什么想得到这份工作。尤其要注意最后一点，我不想听你说你当前的工作如何如何讨厌。当然，可以解释一下为什么现在或者过去没有从事你喜欢的工作，但你一定要告诉我你对自己今后的成长有何打算，还有为什么你应聘的这个职位能够有助于你的成长。

没错，我确实希望将来有可能被我面试的所有人都看到这篇文章。我希望你能在我面试你时表现得非常好，真的，确实如此。说来也简单，只要你留意上述这些常见的问题，并且原原本本地展示你自己就足够了。说不定哪一天，你就会跟我坐到同一间办公室里了。

注意，My Yahoo!团队正在招聘呢。如果你是一位有才华的软件工程师，又对创造价值和Yahoo!公司充满激情，请跟我联系，咱们谈谈。

延伸阅读

• Nicholas C. Zakas如何面试前端工程师
• Nicholas C. Zakas谈怎样才能成为优秀的前端工程师

Nicholas C. Zakas的书

面试前端工程师对我来说是一件非常有意思的事，因为面试过程很大程度上也是自我提升的过程。无论大公司还是小公司，之所以在如何招聘到真正有能力的前端工程师方面会遇到同样的问题，就是因为负责招聘的那些人不知道自己公司需要什么样的人，结果问问题时也问不到点子上。经过这几年在行业里的摸索，我总结出了自己的一套很有效的面试前端工程的方法。

有的应聘者说我不好对付，但留给他们这样的印象也并非我所愿。我觉得之所以他们说我不好对付，主要是因为我问他们问题时问得太细了。以前我曾专门写过一些东西，告诉应聘者怎么才能通过我的面试以及怎样才能成为优秀的前端工程师应该具备什么样的素质，而我的面试可以说完全是按照那两篇文章的标准进行的。我不会问一些特别偏门的问题，也不认为出几道逻辑题就能考出人的真实水平。我唯一的想法就是确定你能否胜任我们要招的这个职位。为此，我需要简单地考察如下几个方面。

基本知识

我们生活在互联网时代，你想知道的任何事情几乎都能在15分钟内找到相关信息。可是，能找到信息并不等于你会使用它。我认为所有前端工程师至少都应该掌握某些基本的知识，才能有效地完成自己的工作。如果一遇到问题，就停下工作上网四处搜索解决方案，怎么可能保证按期完成工作呢？听听，还有谁在说“我不知道，但我可以上网搜到。”请这些同学把手举起来，让大家认识一下（immediately raises a flag for me.）。下面我列出一些基本的知识点，这些都是我认为一名前端工程师（无论工作年头长短）在没有任何外来帮助的情况下就应该知道的。

• DOM结构——两个节点之间可能存在哪些关系以及如何在节点之间任意移动。
• DOM操作——怎样添加、移除、移动、复制、创建和查找节点。
• 事件——怎样使用事件以及IE和DOM事件模型之间存在哪些主要差别。
• XMLHttpRequest——这是什么、怎样完整地执行一次GET请求、怎样检测错误。
• 严格模式与混杂模式——如何触发这两种模式，区分它们有何意义。
• 盒模型——外边距、内边距和边框之间的关系，IE < 8中的盒模型有什么不同。
• 块级元素与行内元素——怎么用CSS控制它们、它们怎样影响周围的元素以及你觉得应该如何定义它们的样式。
• 浮动元素——怎么使用它们、它们有什么问题以及怎么解决这些问题。
• HTML与XHTML——二者有什么区别，你觉得应该使用哪一个并说出理由。
• JSON——它是什么、为什么应该使用它、到底该怎么使用它，说出实现细节来。

重申一下，上述这些知识点都应该是你“想都不用想”就知道的东西。我一开始问的所有问题都是想摸清你对所有这些领域知识的掌握程度。虽然上面列出的这些知识点并没有面面俱到，但我觉得你至少应该掌握这些，才有可能跟我坐到一间办公室里来。

少量提问

我非常赞同面试者问的问题越少越好。反复问应聘者各种问题既不公平，也很无聊。我在任何一次面试中，通常只问三个大问题，但每个问题又会涉及我所能想到的多个方面。回答每个大问题一般要经过几个步骤，这样我就可以在每个步骤中穿插着问一些小问题。比如说：

这个问题牵扯到一组我想要考察的基本知识点：DOM结构、DOM操作、事件处理、XHR和JSON。如果我要求你换一种处理股票价格的方式，或者让你在页面中显示其他信息，就可以把更多的知识点包括进来。对于经验比较丰富的应聘者，我也可以自如地扩展要考察的知识范围，最简单像JOSN与XML的区别、安全问题、容量问题，等等。

我还希望应聘者给出的任何解决方案中都不要使用库。我想看到最原生态的代码，你就当页面中没有包含任何库。你说你对哪个库了解多少多少，但我不能把关于库的知识作为评判能力的因素，因为库是会随时间变化的。我需要的是真正理解库背后的机制，特别是能够徒手写出一个自己的库的人。

解决问题

做为一名前端工程师，最值得高兴的事莫过于解决同一个问题会有很多种不同的方法，而你要做的就是找出最合适的方法来。我在提问的时候，经常会在应聘者解释完一种方法后问他们还有没有第二种方法。此时我会跟他们说，假设你的这个方法由于种种原因被否决了，那么你还能不能给出另一种方法。这样做可以达到两个目的。

首先，可以测试出他们是否在毫无意义地复述书本中的东西。不能不承认，某些人确实有过目不忘的天赋，听他们在那里滔滔不绝地讲，你会觉得他们什么都明白。可是，只要一跟这些人谈到怎么查找方案无效的原因，以及能否拿出一个新方案来，他们往往就傻眼了。这时候，如果我听到“我不明白这个方案为什么不够好”之类的反问，心里立刻就明白我的问题已经超出了他们的能力范围，而他们只是想拿自己死记硬背的结论来蒙混过关。

其次，可以测试出他们已经掌握的（还是那句话，“想都不用想”就知道的）浏览器技术知识。如果他们对浏览器平台的核心知识有较好的理解，想出解决同一问题的不同方案根本没有那么难。

对一名前端工程师来说，这绝对是最重要的能力。前端工程师在工作中遇到本该如此却并未如此的难题（说你啦，IE6），应该说是一件很平常的事。一个方案无效就无计可施的人，做不了前端工程师。

考核应聘者解决问题能力的另一层原因，与我的个人喜好有关。在搞清楚应聘者知道什么不知道什么之后，我就会想着问一个他们知识领域之外的问题。这样做的目的，就是想看看他们怎样运用已有的知识解决新问题。在解决问题的每一步，我也准备了一些提示，以防有人会卡壳打艮（在我面前15分钟一言不发，对我评价这个人毫无帮助）。我真正感兴趣的，是他们能够从上一步前进到下一步。我希望看到一个人就在我眼前学到新知识。

注意：所有问题都与浏览器技术相关。我不相信出几道抽象的逻辑题，就能够考出某人解决Web技术问题的能力。在我看来，这无异于让素描大师画肖像（或者让刘翔跟博尔特同场竞技），没有意义，也得不到任何有价值的信息。

有激情

要成为一名优秀的前端工程师，最重要的莫过于对自己做的事要有激情。我们的技能都不是从学校中或者研讨会上学来的，因此前端工程师必须具备自学能力。浏览器技术的变化可谓日新月异，所以也只有不断提升自己的技能才做得到与时俱进。我虽然不能强迫谁必须多看博客、不断学习，但想应聘前端工程师的人恐怕还是必须得这么做。

你怎么知道谁对这种工作有没有激情？实际上非常简单。我只问一个简单的问题：“目前你对什么Web技术最感兴趣？”这个问题永远不会过期，而且也几乎不可能出错……除非你答不上来。就眼下来说，我希望你对这个问题给出的技术中包括WebSocket、HTML、WebGL、客户端数据库，等等。只有对Web开发充满激情的人，才会坚持不懈地学习新知识、掌握新技能；这些人才是我真正想要的。当然，我会让他们详细解释自己提到的技术，以保证他们不是随口念叨了几个时髦的新词汇。

最后一点

计算机科学或者Web设计方面的知识当然也有用，但那都是基本知识之外的东西。只要基本知识在那儿了，一切就都有了基础，想扩充知识面也不难。可是，如果等到正式上班以后，还得从头学习基本技能，那种难度是不可同日而语的。另外，高级前端工程师与一般工程师相比，肯定需要掌握更多的技能。而面试几乎没有经验的大学毕业生，我也会有一套完全不同的程序。我在这篇文章里列出来的都是一些最基本的东西。

对于那些还没有多少面试经验的人，我总是喜欢告诉他们，面试完了只要问自己一个问题就行：你想以后跟这个人在一起共事吗？如果不管为什么，回答是不，那就是不。

延伸阅读

• 如何通过Nicholas C. Zakas的面试
• Nicholas C. Zakas谈怎样才能成为优秀的前端工程师

Nicholas C. Zakas的书

请看
命名函数表达式探秘

原文链接：http://yura.thinkweb2.com/named-function-expressions/
本文链接：http://www.cn-cuckoo.com/2009/12/22/named-function-expressions-demystified-1320.html

Table of Contents

1. 前言
2. 函数表达式与函数声明
3. 函数语句
4. 命名函数表达式
5. 调试器中的函数名
6. JScript的bug
7. JScript的内存管理
8. 测试
9. Safari中存在的bug
10. SpiderMonkey的怪癖
11. 解决方案
12. 替代方案
13. WebKit的displayName
14. 对未来的思考
15. 致谢

看来（根据一位专家的说法是这样，不过还是感觉有点言不由衷），JavaScript最后真的流行起来了。

[此处是youtub.com中一段视频，可惜被"墙"了]

对我这个从小就呆头呆脑的人来说，这段视频像是咒语又像是玩笑。（这要看你是否跟我站在了相同的立场上：绿壳鸡蛋不就流行过吗？）

我搞不清楚为什么道格（Doug）要编故事。他并不在网景公司。他亲耳听到过我回忆JavaScript诞生的经过，我在Ajax大会的发言中也讲过了。难道是想混淆视听，想在Web开发人员中掀起一股提前讨论MicroHoo C#语言的风潮？

谁知道呢，要计较这些就没完了。不过，鉴于本周是我参与创立的mozilla.org 10周年，我打算讲一点历史。

正如我多次重申过的，而且Netscape的其他人也可以证明，我是因为Netscape要在浏览器中“实现Scheme”才被招聘进公司的。当时，至少负责客户端技术的汤姆·帕坎（Tom Paguin）、迈克尔·托伊（Michael Toy）和瑞克·谢尔（Rick Schell），以及一个叫马克·安德森（Marc Andreessen）的家伙认为Netscape应该在HTML中嵌入一种语言，一种源程序式的编程语言。而我这个新人要去说服“尖脑壳”的老板几乎是不可能的——实际上更多的则是他们在向我解释问题。

到底是不是要基于Scheme并没有定论，但Scheme确实是吸引我加入Netscape的一个原因。在此之前，我在SGI公司期间，尼克·汤普森（Nick Thompson）引导我学习了SICP（Structure and Interpretation of Computer Programs，《计算机程序的构造和解释》）。

当时真正需要的是一种有说服力的概念验证，也就是一个演示程序。在我交付演示程序之后，这个程序在极短的时间内就变为了既成事实。

没错，在加入Netscape后不久，我被调出服务器团队——由于人员不足，我在这个团队干了一段时间，在那里与麦库尔·吐温斯（McCool Twins）和阿瑞·卢奥托嫩（Ari Luotonen）有了一段时间不长但很快乐的合作；1995年下半年，阿瑞和我创建了PAC（Proxy Auto Config，代理自动配置）——的时候，Oak语言已经改名为Java，而Netscape正与Sun协商将该语言包含在Navigator中。

Netscape公司内部争论的最大焦点变成了：“为什么要包含两种语言？为什么不只用Java？”得到的回答是：必须有两种语言分别面向编程圣殿中的两类最不可能走到一块的开发人员：组件开发人员——这类人使用C++或（我们希望的）Java和脚本开发人员（爱好者或专业人员）——这类人编写直接嵌入在HTML中的代码。

至于是否使用已有的语言，而不发明一门新语言，也不是我说了算的。上峰的“军令”就是这门语言必须“看起来像Java”。这样，不仅排除了Perl、Python和Tcl，也排除了Scheme。后来，1996年，约翰·奥斯特豪特（John Ousterhout）前来推广TK时，还曾因Tcl错过机会而惋惜过。

谈不上自鸣得意，但我确实为自己吸收了Scheme式的一类函数和Self式的原型（尽管不那么主流）而感到高兴。至于Java的影响，特别是Date的Y2K bug和原始类型与对象类型（如string与String）差异的影响则是非常不幸的。

时光倒转回1995年春天：我记得在此期间见到了比尔·乔伊（Bill Joy），我和他讨论了垃圾收集的细节（card marking for efficient write barriers）。比尔一上来就完全理解了我们所说的一门易用的“脚本语言”与Java的关系，他还拿微软平台的VB与C++之间的关系作类比。据我所知，比尔是我们在Sun公司的支持者。

基普·希克曼（Kipp Hickman）和我在1995年4到5月间研究了Java，基普也开始写他自己的JVM。他和我编写了NSPR的第一个版本，作为他的JVM之下的可移植层。而我在5月中上旬创建Mocha的原型时，也将该版本用作了相同的目的。

比尔说服我们放弃基普的JVM，因为它会导致与Sun的JVM中的bug无法兼容（在那个时候可谓智慧的预言）。而此时此刻，Mocha已经通过在Netscapte Navigator 2.0（的初期测试版）中的快速原型和嵌入证明它自己。

除此之外，应该说都是对历史的歪曲和调侃。JS在客户端打败了Java，只有Flash能与其竞争，而Flash又支持JS的一个衍生品——ActionScript。

现在再回到流行的问题上。其实谈不谈这个问题都无所谓。然而，那些散布于互联网的流行的Ajax库，却经常以被掰碎了、压扁了，然后再以链接形式挑出来的纯文本的形式存在。难道不可以共享吗？

有一种想法——受到了不少人的质疑，最近一次发出质疑声音的人是道格——在可能将会非常长寿的script标签属性中嵌入“神秘的散列码”（crypto-hashes）。这是个好主意吗？

恐怕不是。一方面因为“神秘的散列码”理论上的完备性问题，另一方面则因为其广为人知的药饵攻击（poisoning attacks）。

还有一个主意倒是不错，这个主意我是先从罗布·塞尔（Rob Sayre）那里听说的：通过HTML5中script标签的share属性支持一种可选的“公认的URL”：
<script src=”http://my.edge.cached.startup.com/dojo-1.0.0.js”
shared=”http://o.aolcdn.com/dojo/1.0.0/dojo/dojo.xd.js”>
</script>

如果浏览器首先下载了共享的URL，而且根据HTTP的缓存规则它依然有效，那么就可以使用缓存（及预编译）的脚本，而不必从src属性指定的URL中下载。

这就避免了散列药饵的问题。这个方案只要求内容作者保证src属性指向的文件与share属性指定的这个库的公认（或流行）的版本相同即可。不过当然，我们必须信得过相应的DNS。（Ulp.）

这个方案可以避免在script标签属性值中嵌入不可预测的散列码。

欢迎大家就此问题给我留言。

好了，这次真的回到JavaScript流行的问题上了。我们都知道有些Ajax库的确流行。那JavaScript流行吗？很难说。有些Ajax开发人员表示（也证明）了对它的喜爱。但也有很多人骂它，也骂我。我依然认为JavaScript是C和Self草草结合的结果（或一个私生子）。我又想起了约翰逊博士（http://en.wikipedia.org/wiki/Dr._Samuel_Johnson）的那句话：“好的不是原创的，而原创的都不好。”

不过，这没什么。Web总要发展，否则只有死路一条。JS也一样，要不就不会有ES4了。说到ES4，很快将有下文。

Firefox 3好像也会流行的， 它的空间与时间性能测试预示了这一点。相关内容呢，我以后还会陆续地谈到。

中文链接：www.cn-cuckoo.com/css/thesis-of-Hakon-Wium-Lie/

原文链接：people.opera.com/howcome/2006/phd/

翻译进度列表：

• 2009-1-7，“灵感”
• 2009-11-1，“第1章 导言”

Håkon Wium Lie出生于1965年7月26日，是土生土长的挪威人。现为Opera Software的CTO（Chief Technology Officer，首席技术官）。他的个人页面、维基百科词条。

1994年，Håkon Wium Lie提出了层叠样式表的概念，并于当年10月提交了他的样式表建议——Cascading HTML style sheets。1996年12月，他亲自主持并以他的建议为基础创建的Cascading Style Sheets, level 1，正式成为W3C的推荐标准。后来，几乎所有主要浏览器都实现了CSS。CSS的普及，结束了长达数年之久的“表现性HTML”的历史，开创了标准Web开发中结构、表现、行为分离的新时代。

1995年， Håkon Wium Lie针对测试Web浏览器在呈现HTML标记、CSS2.1样式、PNG图像及数据URI方面的支持情况，提出了Acid2建议。该建议后来由Web标准组织开发并发布，成为判定新（版）浏览器对Web标准支持情况的一个重要依据。

另外，Håkon Wium Lie与另一位CSS标准的制定者Bert Bos合著的Cascading Style Sheets: Designing for the Web, 3rd Edition 2005年5月由Addison-Wesley Professional出版。也是学习CSS的一本优秀图书。这里还有一篇发表于A List Apart的他们合写的文章：Printing a Book with CSS: Boom!

总而言之，翻译这篇论文的想法由来已久了。原因很简单，这篇论文是Håkon Wium Lie在他提出CSS的建议10年后写就的，其中全面翔实地包含了大量与CSS及Web发展有关的珍贵资料，是研究和学习CSS不可多得的重要参考文献。翻译这篇论文的过程，也是学习和研究的过程。希望自己在翻译完这篇论文后，对CSS和Web的理解能上升到一个新的层次。

想知道怎样在今天的Web上创造伟大的用户体验吗？UI专家Bill Scott和Theresa Neil通过本书向读者展示了超过75种基于富交互构建Web界面的模式。作者以自己在Sabre、Yahoo!和Netflix多年的工作经验为依托，把精挑细选的各种最佳实践归结为6个重要原理，深入浅出地向读者阐释了如何有效利用当前的Web技术。本书每一部分都围绕一个设计原理展开讨论，通过学习本书，读者可以掌握以下原理。

直截了当：通过页内编辑、拖放和直接选择等模式实现基于上下文的内容编辑。
简化交互：借助“轻量级”上下文工具，有效减少用户与站点的不必要交互。
足不出户：采用覆盖层、嵌入层、动态内容和页内流程模式保证访问者不离开当前页面。
提供邀请：向用户发出进入下一级交互的邀请，帮助用户发现站点的功能。
巧用变换：学习何时、何地、以何种方式使用动画、电影转场效果及其他变换手段。
即时反应：以实时搜索、实时建议、实时预览及更多模式，为用户提供丰富的交互式体验。

本书以当前最流行的Web站点为例，介绍了大量行之有效的Web界面设计模式。如果你想构建或重构站点，并希望站点以丰富的交互为特色，那本书就是你出奇制胜的宝典。

“本书提供了富因特网应用程序（RIA）设计人员和开发人员（或开发团队）作出明智选择时必须知道的一切。对于当今主流的Web设计师而言，（本书）应该人手一册。”

——Erin Malone，Tangible UX负责人

当当网读者评论

读者：Drek
来自：广州市
标题：很多新的，流行的理念
评分：4星
发表于 2009-10-11 23:53
我是个程序员，可惜在的公司太小，美工，前台，后台，设计，样式都要一手包办。其实挺郁闷的，为了在点脱离这情况，学多点广博的知识，早日飞翔，成就梦想。
而涉及到的知识都要去看，去学。
界面也要自己去处理。所以看到了本书，站在一个程序员的角度考虑，里面的设计思想其实很潮的。没有你想不到，只有你做不到的。书是针对界面设计，没有任何提及程序，代码如何实现的，也没有提及美工方面如何处理的。
可以说同一个设计相思，可以用不同东西去实现，只要你会的。
所以感觉如果作为程序员，又要考虑界面设计的朋友，本书值得一看。如果就美工和单纯是界面设计的，也给予了你不同的设计思想。
当然，世事没有完美的，程序，界面或者流行一时，2，3年间也许变化很大，为了适应自己的工作，或者适应这个时代，可以得到的资源都不要放过哦

读者：斯泰普斯
来自：上海
标题：赏心悦目
评分：5星
发表于 2009-09-11 09:16
书不错，材质也不错，很有手感。
价格比china-pub贵几块，但我还是等待当当出来才买的。
是一本值得收藏的借鉴的书。
个人推荐。
注：可结合另一本《网站优化》一同阅读。

http://product.dangdang.com/product.aspx?product_id=9345032

卓越亚马逊读者评论

读者：微微
来自：
标题：设计手段与模式
评分：5星
发表于2009-09-08 10:31:23
大凡设计师都是这样来的：先学会对付细节问题，然后尝试系统解决，最后学会总结问题与应对手段。
这本书讲述了6个界面设计原理，对应14种设计模式，以及提供了超过70种具体设计手段。
书中的实例来自flickr, yahoo, google等国外比较大型的网站，部分细节已经不复存在。刚好，你可以通过观察现在的设计，对比书中留存的旧时实例，去思考背后的设计思路。
模式和具体手法都是在不停变化的。
读完这本书，希望大家可以总结出自己网站适用的新的手段、模式。

目录

序
前言
原理一：直截了当
第1章：页内编辑
1.1 单字段行内编辑
1.2 多字段行内编辑
1.3 覆盖层编辑
1.4 表格编辑
1.5 群组编辑
1.6 模块配置
1.7 选择编辑模式的原则
第2章：利用拖放
2.1 趣味瞬间
2.2 拖放的用途
2.3 拖放模块
2.4 拖放列表
2.5 拖放对象
2.6 拖放操作
2.7 拖放集合
2.8 实现拖放的挑战
第3章：直接选择
3.1 切换选择
3.2 集合选择
3.3 对象选择
3.4 混合选择
原理二：简化交互
第4章：上下文工具
4.1 上下文交互
4.2 费茨定律
4.3 上下文工具
4.4 实时可见工具
4.5 悬停即现工具
4.6 开关显示工具
4.7 级联递进工具
4.8 二级菜单
原理三：足不出户
第5章：覆盖层
5.1 对话框覆盖层
5.2 详情覆盖层
5.3 输入覆盖层
第6章：嵌入层
6.1 对话框嵌入层
6.2 列表嵌入层
6.3 详情嵌入层
6.4 标签页
6.5 嵌入层与覆盖层
第7章：虚拟页面
7.1 虚拟滚动
7.2 内置分页
7.3 滚动分页：传送带
7.4 虚拟摇摄
7.5 伸缩式用户界面
7.6 分页与滚动
第8章：流程处理
8.1 Google Blogger
8.2 魔法原理
8.3 交互式单页
8.4 嵌入式部件
8.5 对话框覆盖层
8.6 配置程序
8.7 静态单页
原理四：提供邀请
第9章：静态邀请
9.1 引导操作邀请
9.2 漫游探索邀请
第10章：动态邀请
10.1 悬停邀请
10.2 预期功能邀请
10.3 拖放邀请
10.4 推论邀请
10.5 更多内容邀请
10.6 邀请的优点
原理五：巧用变换
第11章：变换模式
11.1 加亮和减暗
11.2 扩展与折叠
11.3 自恢复式淡出
11.4 动画效果
11.5 聚光灯效果
第12章：变换的目的
12.1 增添魅力
12.2 增进沟通
原理六：即时反应
第13章：查询模式
13.1 自动完成
13.2 实时建议
13.3 实时搜索
13.4 微调搜索
第14章：反馈模式
14.1 实时预览
14.2 渐进展现
14.3 进度指示
14.4 定时刷新
尾声：富交互的原理和模式
索引

本书作为《jQuery基础教程》的升级版，涵盖了 jQuery 1.3的全部新特性，特别是新增了介绍 jQuery UI（jQuery官方用户界面插件库）的内容。本书前 6章以通俗易懂的方式介绍了 jQuery的基本概念，主要包括 jQuery的选择符、事件、效果、DOM操作、AJAX支持等。随后 3章从理论到实践，通过表格操作、构建功能型表单、实现滑移和翻转效果等实例，深入浅出地讲解了如何创造性地运用 jQuery提供的丰富而强大的 API。本书最后两章专门介绍了如何使用和编写 jQuery插件。值得一提的是，本版新增的附录 D分门别类地列出了所有 jQuery API，为高效使用 jQuery提供了方便。

本书内容

第1章将带领读者对jQuery有个大概的了解。这一章先简单介绍jQuery及其用途，然后的内容主要涉及如何下载和设置jQuery库，同时也会指导你使用jQuery编写第一个脚本。

第2章讲述如何通过jQuery中的选择符表达式及DOM遍历方法，在页面中的任何地方找到想要的元素。这一章将展示如何使用各种选择符表达式为页面中的不同元素添加样式，其中一些是通过纯CSS方式做不到的。

第3章介绍如何通过jQuery的事件处理机制，在浏览器发生事件时触发行为。同时，还会介绍如何以不唐突的方式添加事件（甚至在页面加载完成之前）。此外，这一章还将深入更高级的主题，例如事件冒泡、委托和命名空间。

第4章介绍通过jQuery实现动画的技术，从中我们能够体会到隐藏、显示和移动页面元素时那种轻松自如的感觉。

第5章讲述如何通过命令改变页面。本章讲述的是动态修改HTML文档结构及其内容的技术。

第6章讨论通过jQuery轻松地访问服务器端功能的各种方法，而且不用像过去那样刷新页面。

接下来3章（第7、8、9章）主要以实例为主，即在前几章学习的基础上，创建常见问题的稳健jQuery解决方案。

第7章“表格操作”，讲述排序、筛选和为信息添加样式并创建优美实用的数据布局。

第8章“创建功能性表单”以客户端数据验证为主题。届时，将设计一个具有适应能力的表单布局，还会实现基于客户端与服务器通信的交互式表单功能，例如自动完成。

第9章“滑移和翻转”介绍如何在显示页面元素时增强它们的美感和实用性。其中，动态显示和隐藏信息的方式既可以是自动的，也可以是用户控制的。

第10和11章的主题是jQuery库的第三方扩展，将向读者展示扩展这个库的各种方式。

第10章“使用插件”介绍Form插件和官方用户界面插件集合jQuery UI。同时，还将介绍到哪里寻找其他流行的jQuery插件并了解它们的功能。

第11章“开发插件”将讨论如何利用jQuery强大的扩展能力，从头开发自己的插件。不仅包括创建自己的实用函数，还有添加jQuery对象方法、添加自定义选择符表达式，等等。

附录A“在线资源”提供了很多与jQuery、JavaScript以及通常的Web开发有关的内容丰富的网站信息。

附录B“开发工具”推荐了一些有用的第三方程序和实用工具，用于在个人的开发环境中编辑和调试jQuery代码。

附录C“JavaScript闭包”将帮助读者理解闭包——什么是闭包，怎么利用闭包。

附录D“快速参考”提供了jQuery的简明参考，包括所有方法和选择符表达式。在实际开发中，在明确自己目标的情况下，通过这个简单明了的附录，能够方便快捷地找到正确的方法和选择符。

本书能够为您节省宝贵的Web开发时间。有了这些针对真实问题的解决方案放在手边，大多数编程难题都会迎刃而解。
今天，用PHP开发的2000万个网站充分表明，PHP已经成为一门最流行的脚本语言。本书将PHP的特性与经典实例丛书的独特形式组合到一起，足以帮您成功地构建跨浏览器的web应用程序。在这个修订版中，您可以更加方便地找到各种编程问题的解决方案，本书中内容涵盖了：

• 表单处理
• session管理
• 数据库交互
• 使用Web 服务

从初学者常见的问题到高级Web编程技术，这本问题指南中包含了丰富的、具有实际应用价值的实例，可以满足使用PHP生成动态Web内容的任何人的需要。书中的每个实例都细致地讨论了所提供解决方案背后的逻辑和思想，用源自PHP专家的洞察力帮你轻松地掌握这门语言。书中更新了PHP5的有关内容，并详细地解释了如何使用新增的语言特性，比如面向对象能力的巨大改进和新的PDO数据访问扩展等。书中特别增加了有关类和对象的部分，包含了以下基本内容：

• 处理XML
• 与JavaScript交互
• 用PHP构建Web 服务
• 使用SOAP和REST架构

《PHP经典实例（第二版）》中超过250个实例，为你每天都要面对的诸多问题提供了足够丰富的解决方案。而且，每个实例的讨论部分都浸透着对每个PHP开发人员极为有益的理念。
David Sklar 是Ning的一名软件开发人员。在1996年发现PHP能够满足他编写web编程需要的时候，他创建了PX（http://px.sklar.com），这是一个可以让PHP用户交换程序的场所。此外，他还是《Learning PHP5》（O’Reilly）和《Essential PHP Tools》（Apress）的作者。

Adam Trachtenberg 是eBay的一名技术讲师，也是《Upgrading to PHP5》（O’Reilly）的作者。他经常会在O’Reilly Conference和LinuxWorld上发表演讲。他还拥有科伦比亚大学商学院的MBA学位。

前言
第1章字符串
第2章数字
第3章日期和时间
第4章数组
第5章变量
第6章函数
第7章类和对象
第8章Web基础
第9章表单
第10章访问数据库
第11章Session和数据保持
第12章XML
第13章Web自动化
第14章消费Web服务
第15章建立Web服务
第16章互联网服务
第17章图形
第18章安全和加密
第19章国际化和本地化
第20章错误处理，故障排除和测试
第21章性能调谐和负载测试
第22章正则表达式
第23章文件
第24章目录
第25章命令行PHP
第26章PEAR和PECL

我在高教自考《英汉翻译教程》一书中推荐过一位英国学者，名叫西奥多•萨沃里（Theodore Savory）。他在1957年发表的The Act of Translation 一书中写道：

A fair conclusion from these ideas is that the translator’s work may be analysed into the answering of three questions. Faced with a passage in its original language, he must ask himself:

(ⅰ) What does the author say?

(ⅱ) What does he mean?

(ⅲ) How does he say it?

This method of analysis may be applied to the paragraph, to the sentence, or even to the phrase.

要想翻译意思，必须先弄清楚原文的意思。正如萨沃里所说，译者必须先问自己第一个问题：作者说的是什么？但若到此为止，那是很不够的。因为这时你看到的只是字面上的意思，若动手翻译，难免弄出机械的字对字的译文。因此，译者还必须问自己第二个问题：作者的意思是什么？只有正确地回答了这个问题，才抓住了作者所要表达的意思。这时动手翻译，才能真心做到翻译意思。

一．深入考虑关键词语的含义。我们学英语，往往喜欢在一个英语词和一个汉语词之间划等号，对一个词的某一个意思印象较深，一见这个词，须首先想到这个意思。这就会妨碍我们深入考虑这个词在这个上下文里的含义。

例1 He wasn’t drinking that night because he was the designated driver .

那天晚上他没有喝酒，因为他是指定的司机。

例2 He’s always lethargic after little sleep.

小睡之后他总是懒洋洋的。

例3 The thought of going out in the rain and fog discouraged him.

到雨中和雾里去的想法使他打了退堂鼓。

例4 Our teacher has a true interest in her students.

我们的老师对学生有真正的兴趣。

例5 He speaks out about problems in government.

他坦率指出政府中存在的问题。

例6 the history of the church from the middle ages down to the present.

这个教堂从中世纪到目前的历史。

例7 That’s the last we’ll hear of it.

这将是我们最后一次听到。

这7个例子，译文的问题都出在名词没有处理好。driver不等于司机。英语喜欢用名词来表示人的某种能力。a good cook 是指很会做菜的人，a good singer 是指唱歌唱得好的人。after little sleep 相当于when he doesn’t get enough sleep。the thought of …相当于when he thought of…。interest 在这里是concern。government 一词在这里没有冠词，是一个不可数名词，相当于governance, 意思是“治理国家”。the church 是指the whole body of Christian believers。the last 在这里得意思是a final mention。基于以上的理解，我们可以把上述7个例子的译文修改如下：

⒈ 那天晚上他没有喝酒，因为已确定由他开车。

⒉ 他一睡眠不足，就无精打采。

⒊ 一想到外面又是雨，又是雾，他就打退堂鼓了。

⒋ 我们的老师真正关心自己的学生。

⒌ 他坦率指出治理国家方面存在的问题。

⒍ 基督教从中世纪到现在的历史。

⒎ 以后不要再提这件事了。

下面请看另一组例子。

例8 I’ll have a dozen eggs.

我将有一打鸡蛋。

例9 Well, mate, let’s get going.

好吧，伙计，我们走。

例10 She suffers from arthritis.

她饱受关节炎的痛苦。

例11 Training to be a doctor is tough.

培训医生是非常艰苦的事情。

例12 The car doors lock automatically.

车门自动锁上了。

例13 Drop me a note.

给我留个条。

例14 She emptied her glass.

她倒空了玻璃杯。

这7句话，译文的问题都在于动词没有处理好。例8这句话，十有八九是在小商店对售货员说的，如果是这样，I’ll have 的意思就是“我要买”。Longman Dictionary of Contemporary English 对这一短语的解释是say this to ask for something that you have chosen in a restaurant or shop (见have 2条，义项34)。例9有mate 一词，这句话可能是领班或组长对一起干活的人说的。如果是这样，get going 的意思就是“开始干活儿”。The Dictionary of Contemporary American English 对这个短语的解释是to begin work on something (见get 条，义项17)。单说suffer, 是有遭受痛苦的意思。但suffer from 一种疾病，则只表示患有这种疾病。 Training是从动词train演变出来的动名词。train作为及物动词，意思是训练别人，作为不及物动词，意思就是接受训练。例11就是用的第2个意思，因为没有宾语。例12值得注意的是动词的时态，lock是一般现在时，而不是过去时或现在完成时，因此这不是已经完成的一次性动作，而是可以反复做的动作，也就是说这是车门具有的一种能力。根据Oxford Advanced Learner’s Dictionary 的解释，drop sb. a line/note 意思是to send a short letter to sb. 例14有代词her, 这就表明她不是在洗杯子，而是在和别人喝酒或其他饮料，各人有自己的杯子。既然这样emptied 就不是把杯子里的东西倒掉，而是喝光。基于以上的理解，这7个例子的译文可修改如下：

8． 我买一打鸡蛋。

9． 好吧，伙计。咱们开始干吧。

10．她患了关节炎。

11．学医是非常艰苦的事情。

12．车门能自动锁上。

13．给我写封短信。

14．她一饮而尽。

英语的动词是最活跃的一个词素。从以上几个例子看，首先要判断一下这句话可能是在什么情况下说的，接着就要看动词是及物还是不及物动词，用的是什么时态，还要看动词跟什么词搭配，有没有什么特殊的含义。这些因素都考虑到了，就能比较准确地把握这句话的意思了。

二．充分发挥汉语的表达力。汉语历史悠久，具有极强的表达力，翻译时也不必给原文里的每一个词提供对应词。每个词都能对上，不一定就是好的译文，过于机械的译文并不可取。抓住了原文的意思之后，就要反复思考怎样用汉语表达最好。

例15 We gave the sick boy special attention.

我们给病孩特别关照。

例16 She lectured her children on good table manners.

她告诫孩子们要有好的餐桌礼仪。

例17 She takes in stray cats who have no homes.

她收养无家可归的流浪猫。

例18 His death in a car accident was just another statistic in the death rate.

它在车祸中的死亡不过是死亡率中的另一个统计数字。

例19 It was two Decembers ago when she visited us.

她来我们这里做客是在两个十二月份之前。

例20 He put his arms around his girlfriend and squeezed her.

他搂住女友用力挤。

例21 She is full of stress because her boss gives her too much work.

她充满压力，因为老板给她干的活太多。

从the sick boy 可以看出这句话比较正式，是大夫或护士在向领导汇报工作，或向参观者客观地介绍情况，而不可能是对家长说话，因为面对家长就要说your boy。“病孩”是逐字翻过来的，而汉语里现成的说法是“患儿”。“餐桌礼仪”和“流浪猫”也都是逐字翻译，汉语里常说“吃饭要有吃饭的样子”，也常说“野猫”，为什么不用呢？亦步亦趋地跟着英文走，生造一些刺耳的字眼，是不可取的。后四个例子，词不达意，十分费解，有的甚至可笑。纵然字面上与原文对得很紧，又有什么用呢？仔细思考一下，这些例子的译文可改为：

15．我们给这个患儿特别关照。

16．她教训孩子们吃饭要有吃饭的样子。

17．她收养无家可归的野猫。

18．他死于车祸，不过是给死亡统计数字增加了一个数。

19．她来我们这里做客是前年十二月份的事了。

20．他搂住女友，搂得紧紧的。

21．她的压力很大，因为老板给她干的活太多。

下面再看一组例子。

例22 While I do not agree with what you say, I understand your reason for saying it.

虽然我不同意你说的话，但我理解你这样说的原因。

例23 She worries about the safety of her children at school.

她担心在学校上学的孩子们的安全。

例24 We have grave doubts about his honesty.

我们对他的诚实性有很大的怀疑。

例25 The injured horse was dispatched by its owner.

受伤的马被他的主人杀死。

例26 I told my son to watch out for ice on the road ahead.

我告诉儿子提防前面道路上的冰。

例27 He has youthful good looks.

她长着年轻英俊的脸。

例28 We listened to the plane engine drone on until we fell asleep.

我们听着飞机引擎不停地嗡嗡叫直到睡着。

例29 He started to cry.

他开始哭。

例30 My stubborn little boy would not put his coat on; he said, “No, no.”

我那倔强儿子不愿意穿外衣，他说，“不，不。”

例31 I’ m tired of standing; let’s find some chairs.

我站累了。我们找些椅子吧。

这10个例子译文都很别扭，究其原因，都是跟原文跟的太紧。前3例中reason, safety和honesty都是名词，但在这种场合，汉语要用疑问词才比较通顺。汉语不像英语用那么多代词，尤其是物主代词。“主人”前面“它的”二字显然是多余的。英语往往以介词短语作修饰语，若照样译成汉语，则显得死板；若用个动词，句子就活了。对人或物的描写，英语多落在名词上，汉语多落在形容词上。英语多用主从结构，在许多情况下，靠的就是until, before 之类的连词。翻译时，不能看见until 就译“直到”，看见before就译“之前”，必须灵活处理才听着顺耳。这10个例子中，最别扭的就是例29了。虽然译文每个字都和原文相对应，但其节奏让人听了实在难受。最后两句表达不充分。不要把no和“不”划等号，既然这里说的是孩子不愿穿衣，“穿”字为何不说出来呢？找椅子，无非是为了坐坐，为何不说出来呢？加上“坐坐”二字，和前半句有所呼应，意思也完整。根据以上情况，译文可改为：

22．虽然我不同意你说的话，但我理解你为什么这样说。

23．她担心自己的孩子们在学校是否安全。

24．我们对他是否诚实有很大的怀疑。

25．受伤的马被主人宰了。

26．我告诉儿子提防前面路上有冰。

27．他又年轻，又漂亮。

28．我们听着飞机引擎不停地嗡嗡叫，后来就睡着了。

29．他哭起来了。

30．我那倔强儿子不愿意穿外衣，他说，“不穿，不穿。”

31．我站累了，咱们找两把椅子坐坐吧。

要想提供好的译文，弄清原文的意思之后，不能逐字照译，而要把原文撇开，反复思索怎样才能最好地把这个意思用汉语表达出来。词语怎样处理，语序如何改变，结构怎样调整，加不加语气词，都要考虑。语气词是汉语特有的，运用得当，可为译文增色不少。一个呆板的句子，加一个“了”字就全活了。有时顺不顺要靠耳朵来决定，读出声来，听一听，很有用。自己拿不定主意，还可以问问周围的人，听听他们的感觉。我就常问家里人，特别是体育方面的问题问儿子，服饰方面的问题问老伴。有时在一个地方卡住了，那就先放一放，不定什么时候，灵机一动，想出一个好的译法来。这时候，心中的喜悦真是难以用语言来形容。你有过这样的体验吗？

1922年，茅盾在“‘直译’与‘死译’”一文中写道：“近来颇有人诟病‘直译’；他们不是说‘看不懂’，就是说‘看起来很吃力’。我们以为直译的东西看起来较为吃力，或者有之，却决不会看不懂。看不懂的译文是‘死译’的文字，不是直译的。

1934年，茅盾在“直译•顺译•歪译’一文中写道：“‘直译’这名词，在‘五四’以后方成为权威。这是反抗林琴南氏的‘歪译’而起的。我们说林译是‘歪译’，可丝毫没有糟蹋他的意思；我们是觉得‘意译’这名词用在林译身上并不妥当，所以称它为‘歪译’。”

1980年，茅盾在《茅盾译文选集》序中回忆这一段往事，他写道：“后来有的译者随意增删原著，不讲究忠实原文的‘意译’，甚至‘歪译’，那就比林译更不如了。”

从以上情况看，在二三十年代，反对直译的人所反对的是看不懂或看起来吃力的译文；反对意译的人所反对的是随意增删原著、不讲究忠实原文的译文。

鲁迅也是积极主张直译的。

后来有人提出直译和意译是一回事，是无法区分的。

1946年，朱光潜在“谈翻译”一文中写道：“所谓‘直译’是指依原文的字面翻译，有一字一句就译一字一句，而且字句的次第也不更动。所谓‘意译’是指把原文的意思用中文表达出来，不必完全依原文的字面和次第。‘直译’偏重对于原文的忠实，‘意译’偏重译文语气的顺畅。哪一种是最妥当的译法，人们争执得很厉害。依我看，直译和意译的分别根本不应存在。……想尽量表达原文的意思，必须尽量保存原文的语句组织。因此直译不能不是意译，而意译也不能不是直译。”

1953年，林汉达在“翻译的原则”一文中写道：“正确的翻译是直译，也就是意译。死译和胡译不同，呆译和曲译不同，这是可以划分的，它们都是错误的翻译。正确的翻译是分不出直译或意译的。”

1959年，周建人为《外语教学与翻译》写了一篇文章，题目是“关于‘直译”’。他在文中写道：“直译既不是‘字典译法’，也不是死译、硬译，它是要求真正的意译，要求不失原文的语气与文情，确切地翻译过来的译法。换一句话说，当时所谓直译是指真正的意译。”

如果说四五十年代人们认为直译也就是意译，二者无法区分，那么到了七八十年代人们又对直译和意译分别作了分析。

1982年，周煦良在“翻译三论”一文中写道：直译可以分为三类：第一类是译音而不译意。如democracy译为“德谟克拉西”，而不译为“民主”。第二类是照字面译。如crocodile tears译作“鳄鱼的眼泪”，而不译作“虚伪的眼泪”。第三类是不按照中国语言习惯和词序而按照原文的结构或词序的翻译。如“‘你来了，’她说”。最后，他指出“这样一些直译好像为数不少，但就一篇文章，一部书来看，直译的成分毕竟是少数。”

1978年，许渊冲在“翻译中的几对矛盾”一文中也谈到直译与意译的问题，他说：“直译是把忠实于原文内容放在第一位，把忠实于原文形式放在第二位，把通顺的译文形式放在第三位的翻译方法。意译却是把忠实于原文的内容放在第一位，把通顺的译文形式放在第二位，而不拘泥于原文形式的翻译方法。”最后他得出五点结论，归纳成两点就是：一．译文和原文相同的形式能表达和原文相同的内容时，可以直译，不能表达时就意译；二．原文的表达形式比译文精确、有力时，可以直译，译文的表达形式比原文精确、有力时，可以意译。

1979年，王佐良在“词义•文体•翻译”一文中写道：“要根据原作语言的不同情况，来决定其中该直译的就直译。该意译的就意译。一个出色的译者总是能全局在胸而又紧扣局部，既忠实于原作的灵魂。又便利于读者的理解与接受的。一部好的译作总是既有直译又有意译的：凡能直译处坚持直译，必须意译处则放手意译。”

从以上情况看，七八十年代的译者对直译和意译作了分析和比较，采取了兼容并蓄的态度。这说明当代的译者比二三十年代乃至四五十年代的译者在理论上都更加成熟了。

在国外，译界的同行也同样在这一方面进行探讨。英国剑桥大学乔治•斯坦纳教授主张意译。他在1975年发表的After Babel一书中发挥了17世纪英国学者约翰•德莱顿关于意译的主张。他写道：“翻译的正确道路，既不应是直译，也不应是模仿，而应是意译(paraphrase)。所谓意译，就是‘译者有一定限度的自由，他要时刻看到作者，这样就不至于迷失方向，但他主要是紧跟作者的意思而不死扣字眼，他可以对作者的意思加以引伸，但不能改变。’据德莱顿说，这就是埃德蒙•沃勒和西德尼•戈多尔芬1658年翻译维吉尔的史诗《伊尼德》(Aeneid)第四卷时采取的方法。更重要的是，德莱顿本人翻译维古尔、贺拉斯、奥维德、朱文纳尔、乔叟等人的著作时，也采用了这种方法，在他评论 别人的译作时(如1685年出版的Sylvae一书的序言)所阐述的也是这种方法。通过意译，‘作者的精神可以得到传播，而不会遭受损失。’好的翻译好比是‘一种写生’。最理想的情况是，译作不剥夺原作的权威，而能向我们表明假如原作本来就是用我们的语言创作的，它会是个什么样子。”

国外还有一些学者表达了类似的看法。你同意他们这种看法吗？

一

许多人写文章讨论翻译中的风格问题，倒也的确大都涉及文学作品的翻译。风格能不能译，大体上有两种意见。

一种意见认为风格是能译的。早在1922年茅盾就曾写道：“直译的意义若就浅处说，只是‘不妄改原文的字句’；就深处说，还求‘能保留原文的情调与风格’。”

1954年茅盾在全国文学翻译工作会议上的报告中说道：“文学的翻译是用另一种语言，把原作的艺术意境传达出来，使读者在读译文的时候能够像读原作时一样得到启发、感动和美的感受’。这样的翻译，自然不是单纯技术性的语言外形的变易，而是要求译者通过原作的语言外形，深刻地体会了原作者的艺术创造的过程，把握住原作的精神，在自己的思想、感情、生活体验中找到最适合的印证，然后运用适合于原作风格的文学语言，把原作的内容与形式正确无遗地再现出来。”

1980年茅盾在“《茅盾译文选集》序”中写道：“很重要的一点是能将他的风格翻译出来。譬如果戈理的作品与高尔基的作品风格就不同，肖伯纳的作品与同样是英国大作家的高尔斯华绥的作品的风格也不同。需将一个作家的风格翻译出来，这当然是相当困难的，需要运用适合于原作风格的文学语言，把原作的内容与形式正确无遗地再现出来。除信、达外，还要又文采。这样的翻译既需要译者的创造性，而又要完全忠实于原作的面貌。这是对文学翻译的最高要求。”

这个意见是有人支持的。1961年刘隆惠在“谈谈文艺作品风格的翻译问题”一文中写道：“对于文学翻译，不仅要求通顺流畅，而且要求表达原作的风格。”他还说：“我认为风格并不是不能译，而是难译。其所以难是在于译者必须具备两个条件。其一是要有认识风格的水平；其二是要有表现风格的能力。”

另一种意见认为风格是不能译的。1959年周熙良在“翻译与理论”一文中写道：“有人自诩翻译哪一个作家就能还出这个作家的面目或风格，我看这只是英雄欺人语；据我所知，就有翻译家对本文还不大能弄懂得，就大吹自己的翻译是旨在表现原作诗一般美丽的风格。依我看，对一个作家或者风格的认识也还是根据对作品本文的理解而来的，否则便是空话。教外国文学的人最喜欢谈风格，但是，对于一个搞实际翻译的人来说，风格却是一个最难谈得清楚的东西。我觉得，在通常情形下，它好像只是在无形中使译者受到感染，而且译者也是无形中把这种风格通过他的译文去感染读者的，所以既然是这样情形，我看就让风格自己去照顾自己好了，翻译工作者大可不必为它多伤脑筋。……我觉得翻译工作者如果要花许多功夫去钻研作品的风格，还不如花点功夫去培养自己的外语感受能力好些，因为翻译工作究竟是和语言文字打交道的工作，而语言却不止是数字符号那样抽象而无情的东西。”

二十多年以后，周熙良依然坚持自己的这一看法。1982年他在“翻译三论”一文中写道：“严复只提雅，而不提原文风格，我们现在提文学翻译要有风格，也不宜要求译出原文风格：原文风格是无法转译的。……我仍旧认为风格是无法翻译的，风格离不开语言，不同的语言无法表达同样的风格。”

这一种意见也是有人支持的。1961年张中楹在“关于翻译中的风格问题”一文中写道：“在同一语言的领域里，尚且不宜摹访一个作者的风格；在翻译方面，把原作译成另一种语言而要保持同一风格，这是更不易做到的工作。……我是极为赞同周熙良同志的‘不必多伤脑筋’的说法的。”

总起来看，持第一种意见的人较多，持第二种意见的人较少。我的看法是，第一种意见恐怕只是一种理想，未必能够达到，或者说很难实现；第二种意见又未免过于极端。

1979年罗新璋在“读傅雷作品随感”一文中说过这样一句话：“服尔德的机警尖刻，巴尔扎克的健拔雄快，梅里美的俊爽简括，罗曼罗兰的朴质流动，在原文上色彩鲜明，各具面貌，译文固然对各家的特色和韵味有相当体现，拿《老实人》的译文和《约翰•克利斯朵夫》一比，就能看出文风上的差异，但贯穿于这些译作的，不免有一种傅雷风格。”可见即使是名家的译作也难免既有原作的风格，又有译者的风格，而不可能是单纯的原作的风格。

二

翻译非文学作品，是否也有一个如何对待风格的问题呢？有的。

1979年，王佐良在“词义•文体•翻译”一文中说道：“一篇文章的风格只是作者为表达特定的内容而运用语言的个人方式，它与内容是血肉一体的，而不是外加的、美化的成分。”我的理解，这里所谓“一篇文章”泛指任何用文字写成的东西，非文学作品也不例外。在同一篇文章里，他还写道：“在翻译工作里，也必须注意语言与社会场合的关系。译文同样有一个适合社会场合的问题。译者同样必须能根据原文的要求，写出各种不同的语类、文体。例如翻译请贴、通知、布告、规章、病历与病情公告之类的“应用文体”，译者应该知道在译文里怎样寻到相等的内行的格式和说法。”

1982年，周熙良在“翻译三论”一文中写道：“实际上，许许多多的翻译只要文字通顺，就达到要求了，并不需要译成文学，也不可能译成文学。社会科学文章、报纸社论、科技文章、调查报告、都属这一类。”他还说：“美既不能用，雅又不能照严复当时提出的那样去理解，那么究竟应当怎样理解呢？我认为应当作为‘得体’来理解。得体不仅仅指文笔，而是指文笔基本上必须根据内容来定；文笔必须具有与其内容相适应的风格。”

我觉得，文学作品的风格可能因人而异，每个作家都有自己的风格。而非文学作品则往往是某种类型的文章具有一些共同的特点，形成这类文章的共同风格。无论是谁写作，都会采用这种风格。比如科学论文和法律文件，在用词方面力求准确，在表达方面力求清楚易懂，着重客观叙述，不带感情色彩，好像一个人在板起面孔来说话。而科普文章或普法读物则要使用生动的语言，灵活的句子，让读者觉着你在微笑着向他传授知识，或说明道理。用中文写文章是这样，用英文写文章也是这样，这两种语言是相通的。例如《世界版权公约》第二条第二款：

Unpublished works of nationals of each Contracting State shall enjoy in each other Contracting State the same protection as that other State accords to unpublished works of its own nationals, as well as the Protection specially granted by this Convention.

任何成员国国民未出版的作品，在其他各成员国中均享有后者给予其国民之未出版的作品同等的保护，并享有本公约所专门授予的保护。

这段译文既符合原文的风格，也符合中文法律条文共同的风格。如此说来，你看到文字如此谨严的原文时，只要译成同样谨严的文字就行了。所以，在风格问题上，翻译非文学作品比翻译文学作品简单多了。风格也不是那么虚无缥缈、不可捉摸了。你说是不是？

“对于我们并非专门从事文学翻译的初学者来说，在表达方面只要做到两点就够了。第一，能区别口语与书面语，该文的时候文，该白的时候白，翻译对话像对话，翻译叙述像叙述；第二，能根据不同的文体使用不同的语言，翻译新闻像新闻，翻译文件像文件，翻译故事像故事，翻译诗歌像诗歌。如果在正确理解原文的基础上，能使译文做到这两点，这就很不错了。”这段话是我在《英汉翻译教程》一书中提出的目标。你同意吗？

⒈一词多义。弄清原文的意思，在汉语中选用适当的词语。例如：
Born in 1879 in Ulm, Germany, Albert Einstein was two years old when his parents moved to Munich, where his father opened a business in electrical supplies.
阿尔伯特·爱因斯坦于1879年出生在德国的乌尔姆城。在他两岁的时候，父母移居慕尼黑。他的父亲在慕尼黑开了一家工厂，生产电气器材。（句中business一词，据有关资料介绍是指factory，而不是store，故译作“工厂”。

⒉英语名词和介词用得多，汉语动词用得多。
Psychologically there are two dangers to be guarded against in old age. One of these is undue absorption in the past.
从心理方面来说，到了老年，有两种危险倾向需要注意防止。一是过分地怀念过去。（如译作“对过去的过分怀念”，则不顺。

⒊英语代词用得多，汉语实词用得多。在一个句子里，英语可以先出代词，后出实词；汉语则先出实词，后出代词。
One day, while I was playing with my new doll, Miss Sullivan put my big rag doll into my lap also, spelled “d-o-l-l” and tried to make me understand that “d-o-l-l” applied to both.
有一天我正在玩一个新娃娃，沙利文小姐把我的大布娃娃也放在我腿上，然后写了“d-o-l-l”这几个字母，她是想让我知道“d-o-l-l”既可以指新娃娃，也可以指旧娃娃。（如译作“指二者”，就不顺；如译作“两个都指”，意思既不清楚，句子也压不住。
If they are disappointed at one place, the drillers go to another.
钻探石油的人如果在一个地方得不到预期的结果，便到另一个地方去钻探。

⒋英语动词有时态，时间概念往往通过时态表现出来：汉语动词没有时态，表示不同的时间，往往需要加时间状语。
It is like a dream to me now, floating through my mind in slow motion. Many children were playing close to the water, and we were stunned by their ignorance and daring.
现在回想起来，就仿佛是一场梦，当时的情景还在我脑海里缓缓浮动。那一天，许多孩子在靠近水边的地方玩耍，他们那样大胆，不知道危险就在眼前，使我们非常吃惊。（译文加了“那一天”。

⒌英语被动语态用得多，汉语被动式用得少，有时不用被动形式也可以表示被动的含义，有时可以用无主语句。
When the whale is killed, the blubber is stripped off and boiled down, either on board ship or on shore.
鲸鱼杀死以后，把鲸脂剥下来熬油，这项工作有的是在船上进行的，有的是在岸上进行的。（不一定译成“鲸鱼被杀死以后”，不用“被”字仍可表示被动的含义。
Great sums of money have been spent, for example in the deserts of Egypt, in “prospecting” for oil.
在石油“勘探”方面，已经花了大笔的钱，比如在埃及的沙漠里进行的勘探工作就是如此。（原文是被动语态，但未说明谁是施动者。译文用了无主句。

⒍英语并排用几个名词、动词或形容词时，其排列顺序可能要考虑到词的长短（长的放在后面，这样节奏较好或分量的轻重（重的放在后面，这样不显得头重脚轻。汉语除了考虑常用的顺序以外，还常常考虑词的音调。分量的轻重关系不大，常把分量重的词放在前面。
…setting aside big tracts of land where nobody can fish, shoot, hunt, nor harm a single living creature with furs, fins or feathers.
……圈出大片土地，不准钓鱼，不准打鸟，不准打猎，凡是长皮的，长毛的或者长鳃的动物，一概不许伤害。（原文fish, shoot, hunt,由轻到重，feathers最长，放在最后。汉语则“长皮的，长毛的”连下来较顺。

7.英语一般避免重复，代称用得多，不但名词可以用代词来替代，动词、形容词也有相应的词来替代。汉语则不怕重复，实称用得多。
English grammar is very difficult and few writers have avoided making mistakes in it.
英语语法十分困难，作家很少不犯语法错误的。（译文重复“语法”二字。

8.英语连词用得多，汉语连词用得少。例如表示条件或原因，汉语不一定用“如果”或“因为”之类的词，意思就包含在上下文里面了。
This film showed how they put aside a thousand acres out West where the buffaloes roam and nobody can shoot a single one of them. If they do, they get in jail.
电影演的是他们怎么在西边儿把一千英亩土地划出来，让水牛自由行动，谁也不准开枪打死一只。打死了，就得坐牢。（译文第二句没有用连词，没有用主语，重复了第一句里的“打死”二字。

9.词的搭配，如形容词与名词的搭配，副词和动词的搭配，主语与谓语的搭配等，英语可以用的搭配，往往不能直接译成汉语，这就需要选择适当的词语，或者改变句子的结构。

The road we have long been traveling is deceptively easy, a smooth superhighway on which we progress with great speed, but at its end lies disaster.
我们一直在走的这条路表面上很好走，是一条平坦的超级公路，我们可以高速前进，但是走到尽头却要遇到灾难。（原文lies disaster 不能直译，只好改变句子结构，译作“遇到灾难”。

10.英语常以抽象名词做主语，后面接表示具体动作的动词。这种主谓搭配，在汉语里是很少用的，一般都要改变句子结构。
Anger and bitterness had preyed upon me continually for weeks and a deep languor had succeeded this passionate struggle.
几个星期以来，我又气又恨，感到非常苦恼，这种感情上的激烈斗争过去之后，我感到浑身无力。

11.英语有些副词和动词的搭配无法直接译过来，可将原文副词的含义译成谓语或分句，放在句末。
So heedful a writer as Henry James, for instance, on occasion wrote so ungrammatically that a schoolmaster, finding such errors in a schoolboy’s essay, would be justly indignant.
就拿亨利·詹姆士来说吧，连他这样细心的作家写的东西，有时也不合语法。要是小学老师在学生的作文里发现那样的错误也会生气，而生气是完全应该的。

12.英语有些副词放在句首，具有丰富的内容，译成汉语可以适当地加以发挥。
Ideally, one day, researchers will know enough about the genesis of earthquakes……
最理想的情况是，有朝一日研究人员能够对地震的成因……有足够的了解。

13.主语的位置。英语往往把目的状语或其他成分放在句首，然后再出主语，主语与动词靠得较近。汉语则往往先出主语。
To protect the whale form the cold of the Arctic seas, nature has provided it with a thick covering of fat called blubber.
大自然为了保护鲸鱼，使它不致在北冰洋受冻，便让它长了厚厚的一层脂肪，叫做鲸脂。

14.英语的书面语差不多每个句子都要有主语，汉语的主语则不那么重要，如果前面已把主语说清楚，后面的句子不一定用主语。甚至在一个句子里应该出现另外一个主语的时候，这个主语仍然可以省略。
They used this kind of scare tactic when I was growing up. I wonder what they use today.
我小的时候，他们用过这种吓唬人的办法。现在用什么办法，就不得而知了。（译文第二句，两个主语“他们”和“我”都没有出现。

15.英语有who, which等词,可以引出定语从句，汉语多用并列分句，或单成一句，有时可把定语从句先处理。
Richardson, who served as both Secretary of Defense and Secretary of Health, Education and Welfare during the Nixon Administration, was talking about the negotiations for a Law of the Sea treaty, which came to a virtual conclusion last week after six years of deliberations.
理查森曾在尼克松政府中担任国防部长和卫生、教育和福利部长，他是在谈到关于海洋法条约的谈判时说这番话的。（译文用了并列分句
I have never had much patience with the writers who claim from the reader an effort to understand their meaning.
有些作家，读者要费力气才能看懂他们的意思，我对这样的作家一向是没有多少耐心的。（原文中的定语从句在译文中提前处理。

16.英语的主语部分可以很长，其中包括几个介词引导的短语作定语，汉语往往用分句来表达，或者独立成句。
The 180-page document, with more than 300 articles and eight annexes, definitively covers every conceivable issue dealing with the seas, from the definition of what constitutes an island to the jurisdiction over fish that live in fresh water but spawn in the ocean.
这份长达一百八十页的文件，有三百余条，并有八个附件。它涉及能够想到的每一个与海洋有关的问题，从岛屿的定义，到对在淡水生长而在海洋产卵的鱼类的管辖权，都做了明确的规定。（原文中的主语部分独立成句。

17.英语除了有who, which等词外，还有动词的-ing形式，因此句子可以很长，但组织得很严密。汉语叙事，则多用并列结构，一层一层地把事情说清楚。有时可以把较长地句子译成几个短句。
In the winter of 1879, James Lecky, exchequer clerk from Ireland, and privately interested in phonetics, keyboard temperament, and Gaelic, all of which subjects he imposed on me, dragged me to a meeting of a debating society called The Zetetical: a junior copy of the once well known Dialectical Society founded to discuss John Stuart Mill’s Essay on Liberty when that was new. 　　1879年冬天，詹姆斯·莱基拉我去参加一次辩论会。莱基是爱尔兰人，在财政部门当职员，有空喜欢研究语音，练习弹琴，学习盖尔语，他还硬让我也学这些东西。这次他带我去参加的辩论会是一个名叫“探索学会”的团体举办的。当年约翰·斯图尔特·米尔的文章《论自由》刚刚发表时候，成立过一个“辩证学会”来讨论这篇文章，这个学会曾名噪一时。探索学会就是仿照这个学会建立起来的，只是没有它那么有名罢了。（原文虽然较长，但并不很复杂。主语部分有一个同位语和一个定语从句，谓语部分有一个同位语和一个状语从句。译文则分成了五个句子。

18.汉语一般不用一连串的定语，一连串的“的字。适当地在“的”字前增加动词，就显得有些变化，不那么单调。
The resounding success of the Curacao experiment whetted the appetites of Florida livestock raisers for a similar feat that would relieve them of the scourge of screw-worms.
库拉索岛上的实验取得巨大的成功.引起了佛罗里达州牲畜饲养者的兴趣.他们也想以同样的办法消除螺旋锥蝇这一祸害.(原文主语部分是一名词定语,若译作“库拉索岛上的实验的巨大成功”,就连用了两个“的”字.如在第二个“的”字前面加上“取得”二字，就好一点。现在把这一部分译成一个分句就更好了。

19.英语在一个句子里往往先说个人的感受，再说与感受有关的动作，最后才说最初发生的事情。汉语则相反，往往按照事情发生的顺序来叙述，最后才说个人的感受。
The most important day I remember in all my life is the one on which my teacher，Anne Mansfield Sullivan, came to me. I am filled with wonder when I consider the immeasurable contrast between the two lives which it connects.
在我的记忆里，安妮·曼斯菲尔德·沙利文老师来的那一天，是我一生中最重要的日子。从这一天开始，我的生活和以前迥然不同，一想到这一点，我就感到非常兴奋。

20.表达同样的意思，英语的结构比较紧，汉语的结构比较松。
A gang of men, under the direction of their energetic and likeable foreman, 25-year-old Phineas P. Gage, was working on a new line of the Rutland and Burlington railroad.
一伙工人正跟着他们的领班在拉特兰－伯灵顿铁路的新线路上干活。这位领班名叫菲尼斯·P·盖奇，二十五岁，他精力充沛，待人和气。（原文是一简单句，有一个主语，一个谓语动词，却包含了这么多内容，结构显得比较紧。译文分为两句，第二句还包含两个并列分句，结构显得比较松。

21.拆句的情况多，合句的情况少。
Poets as we know have always a made great use of alliteration. They are persuaded that the repetition of a sound gives an effect of beauty.
我们知道，诗人一般总喜欢押头韵，觉得重复一个声音会产生美的效果。（原文两句都比较短，译文合成一句，语气较顺。

22.注意文体，应该用口语的地方，选用适合口语的词句。
“I remember thinking, ‘No. No. It’s not Jackson, it’s not my husband, it’s not my Jackson,’” she said. “But it was. He was lying in the street, right across from our house. The police said a man shot him over a parking space.”
“记得我当时就想:‘不，不。不是杰克逊，不是我丈夫，不是我的杰克逊’”她说。“可是，那不是别人，正是他。他躺在大街上，就在我们的房子对面。警察说，为了争一块停车的地方，人家把他打死了。”

23.一段文章的最后一句，特别是全文最后一段的最后一句，要比较有力，否则文章煞不住。中英文都是这样。翻译时就要把这最后一句的分量表达出来，给人以深刻的印象。
Words have weight, sound and appearance; it is only by considering these that you can write a sentence that is good to look at and good to listen to.
词具有一定的分量、声音和形状，只有考虑到这些因素，写出来的句子才能既好听，又好看。（若把“好听”放在最后，就压不住了。

24.题目可以照原文译，也可以根据文章的内容拟定。
A Valentine to One Who Cared Too Much.
衷肠曲（这个题目是参照文章的内容拟定的。原题的意思是：在情人节写给一个人的信，这个人关心的事情太多了。

25.遇到中国读者可能不熟悉的典故、人名、地名等，除了加注以外，还可以在译文中加几个字，略加说明。
I learned a great many new words that day. I do not remember what they all were; but I do know that mother, father，sister, teacher were among them — words that were to make the world blossom for me, “like Aaron’s rod, with flowers.”
那一天我学了许多新词，也记不清都有哪些词了。但是其中肯定有“母亲”、“父亲”、“姐姐”、“老师”——后来就是这些词把一个美好的世界展现在我的面前，就像《圣经》上说的“亚伦的杖开了花”一样。（这个典故出自《旧约·民数记》第17章第8节。为了帮助中国读者了解，译文加了“就像《圣经》上说的”几个字。

定语如果不译成定语，又能译成什么呢？

关于定语从句的译法，已经看到不少文章。各种教程和专著中也有专门的章节加以论述。这里只举两个例子。

例1 The police are concerned for the safety of the 12-year-old boy who has been missing for three days.
那个12岁的男孩失踪三天了，警方对他的安全感到担忧。

例2 Each of London’s districts had a distinct character that marked it off from its neighbours.
伦敦的每个区都有鲜明的特征，与邻近地区不同。

例1的译文用了两个主谓结构，也可以说是两个并列短句。若译作“警方对那个已失踪三天的12岁男孩的安全感到担忧”，异文就因定语太长而不顺了。例2的译文用了一个主语带两个并列的谓语。总之，这两个例子，原文都是主从结构，而译文都是并列结构。这也正是英汉两种语言在句子结构方面最大的区别。

例3 Police investigating the train derailment have not ruled out sabotage.
警方调查火车出轨事件，没有排除人为破坏的可能。

例4 Any event attended by the actor received widespread media coverage.
这位演员参加任何一项活动，媒体都作了广泛报道。

例3和例4，原文各有一个分词短语*作定语：investigating…和attended by …。例3的译文用了一个主语带两个并列谓语，例4的译文用了两个主谓结构，这和上回所说的定语从句的译法是完全一样的。译文中没有出现“调查火车出轨事件的警方”之类的话。

例5 He was the only one to speak out against the decision.
只有他站出来反对那项决定。

例6 He had long coveted the chance to work with a famous musician.
他长期渴望有机会与著名音乐家一起工作。

例5和例6，原文各有一个动词不定式短语作定语：to speak out … 和 to work with …。例5的译文直接把定语变成了谓语。例6的译文用了一个“连动式”（参看胡裕树《现代汉语》第363页），把原文动词不定式短语化作“连动谓语”的一部分。这样处理，译文比较简洁。我们设想一下，假如例5保持原文的结构，译为：“他是唯一一个站出来反对那项决定的人”，一个17个字的句子里，定语竟占了14个字，是不是显得长了一点？

例7 The cut in interest rates is good news for homeowners.
降低利率对于私房买主来说是个福音。

例8 I admire her coolness under pressure.
我佩服她在压力下能保持冷静。

例7和例8，原文各有一个介词短语作定语：in interest rates 和 under pressure。译文没有按原文的结构，译作“利率的降低”和“在压力下的冷静”，而是加了动词，译为“降低利率”和“在压力下能保持冷静”。我感觉，相对而言，英语名词用的多，汉语动词用的多。英语里常见一个句子只有一个谓语动词，剩下一大堆名词，用介词串连起来。这种句子译成汉语时，往往需要增加一些动词，这样才能使译文顺畅。

最后谈一谈单词作定语的问题。有人可能觉得，遇到单词作定语时，主要是个选词问题，只要选一个适当的词放在那里就行了。在有些情况下，也的确是这样，但有时也不这么简单。

例9 Loose clothing gives you greater freedom of movement.
衣服宽松，可以活动自如。

例10 I don’t want you mucking up my nice clean floor.
我这地板又干净，又漂亮，不想让你弄脏。

这两句译文都把定语变成了谓语，句子中间有停顿，听起来从容、自然。若照原文的结构，译成“宽松的衣服使你活动起来更为自在”和“我不想让你弄脏我干净漂亮的地板”，倒显得过于拘谨了。

例11 A few cushions formed a makeshift bed.
临时用几个垫子拼了一张床。

例12 His mere presence made her feel afraid.
他当时在场，这就足以让她害怕了。

这两句译文都把定语变成了状语，这也是翻译过程中常用的一种方法。汉语总说“拼了一张临时床”，听起来很怪，那就不如说“临时……拼了一张床”了。mere是用来加强语气的，但mere presense 在汉语里很难找到相应的搭配，只好在后半句用“足以”来加强语气了。

例13 With a few notable exceptions, everyone gave something.
人人都给了些东西，只有几个人例外，很是显眼。

例14 It’s been a nail-biting couple of weeks waiting for my results.
这两个星期等结果，弄得我坐卧不安。

这两句译文都把定语放到句子末尾来处理。notable和nail-biting在原来的位置上是很难译的，那就最后来处理吧。在汉语句子里，往往先说具体的事情，最后才评论、表态，或说出自己的感受。

定语是一种修饰语，状语也是一种修饰语，和定语有相似之处，这里就不多说了，请读者自己去琢磨。

在英译汉方面，除了理解问题外，我集中谈了一个定语问题。这是因为我在审订译稿的过程中发现，许多句子问题就在于定语没有处理好，或者放大一点说，修饰语没有处理好。因此，把修饰语处理好，译文的质量就能提高一大步。不知你有没有同感。

看一篇东西，可以有不同的目的。若为获取信息，抓住大意就可以了。

若是为了消遣，那就可以看懂多少算多少。若是为了翻译，那就非透彻理解原文不可。

有时似乎觉得懂了，但翻译起来还是不知如何下手，究其原因，可能仍是未能真正理解原文。在这种情况下，若勉强去译，便会采取机械的办法，逐字翻译，许多误译就是这样产生的。

例1  We want to get all the parties back to the negotiating table.
例2  Their differences have been thrown into sharp relief by the present crisis.

虽然party一词可以指“政党”，但此处与negotiating table相联系，便指“谈判的一方”了。所以，例1的意思是：我们想把有关各方拉回到谈判桌上来。Differences一词本身是有“差别”的意思，但在这个上下文里，它却指“意见分歧”。例2的意思是：目前的危机使得他们的分歧更加引人注目。

例3  He was found guilty of murder.
例4  There is no right of appeal against the decision.

涉及法律时，find不一定表示“发现”，而可以指“裁决”、“判决”。Appeal也不一定表示“呼吁”，而可以指“上诉”。因此，例3的意思是：经裁决，他犯有谋杀罪。例4的意思是：关于这项判决，没有上诉权。

例5  The end result of her hard work was a place at medical school.
例6  To graduate with honors from college

在学校教育方面，work就指学习，a place就是an opportunity to study at a university,也就是一个入学名额，而不是一个工作职位。With honors指的是“以优异的成绩”，而不是“感到荣幸”。因此，例5的意思是：她勤劳学习，终于进了医学院。例6的意思是：以优异的成绩从大学毕业。

例7  This new production radically reinterprets the play.
例8  The doorway is a 19th century reconstruction of Norman work.

在文化方面，production和戏剧相联系，就指“一次演出”。因此，例7的意思是：这次演出体现了对这部戏的全部理解。例8是什么意思呢？能不能译作：门廊是19世纪罗马建筑的翻版？不行。首先，Norman不是罗马，而是指11世纪欧洲大陆的诺曼人征服英国后在英国流行的诺曼式建筑风格；其次用“19世纪”修饰“罗马建筑”也是不行的。例8的意思是：门廊是19世纪时模仿诺曼式建筑修建的。

例9   You’ll be expected to replace any broken glasses.
例10  Round here, you leave school at sixteen and next thing you know, you’re married with three kids.

在生活方面，所谈内容往往与当地的风俗习惯相联系。二十年多前，我在澳大利亚到一位朋友家去做客。主人从商店租了一百只玻璃杯，打碎了一只，归还时就照价赔偿。例9就是店主对顾客说的一句话，意思是；玻璃杯如有损坏，你要负责赔偿。例10的用词很简单，但究竟是什么意思呢？能不能译作“这儿，你十六岁时离开了学校，接着，你带着三个孩子结了婚。”？或译作“……你和有三个孩子的人结了婚。”？从原文的时态看，这里说的不是一次性的已经完成的动作，而是一种反复出现的现象，句中的you也不是指具体的某人，而是泛指。这样就可以看出这句话说的是当地一种普遍的生活方式。因此，例10的意思是：这一带的人十六岁中学毕业，接着就结婚，生三个孩子。

例11  I hate to say I told you so.
例12  Ed couldn’t make it so they sent me instead.
例13  Go on – read it to us.

英语有许多习语（idioms）, 其含义往往不是从字面上可以看出的。以上三例中的I told you so，make it和go on都是习语，翻译时，不能取其字面上的含义，而要把它看作一个整体来处理。如果不知道它的意思，那就要到词典里去查一查。

如果你手边有一本Oxford Advanced Learner’s Dictionary,在词条tell里就可以查到I told you(so), 解释为：used when sth. bad has happened, to remind sb. that you warned them about it and they did not listen to you.得到这个解释之后，就能看出例11的意思不是“我真不想说是我告诉你的”，而是“我不愿意显得自己有先见之明。”

用同样的办法查make it, 可以查到4条解释，第3条解释为：to be able to be present at a place. 因此例12的意思就不是“埃德做不出来……”, 而是“埃德去不了，所以他们就派我去了。”

Go on共有8条解释，最后一条是：used to encourage sb. to do sth.因此，例13的意思就不是“继续—给我们读下去”，而是“念吧—念给我们听听。”

综上所述，一个词用在不同的场合会有不同的含义，译者不能只想到自己最熟悉的那个含义，而要充分利用上下文，依靠能够获得的相关信息，判断出词的确切含义。遇到习语，更要勤查词典，切忌忘文生意。

近年来，我参加了几本双语词典的审订工作，上面所举的例子都是我在实际工作中遇到的。我还发现，经我审订的译文，有的也还有改进的余地，甚至还有些错误没有改掉。这一方面说明个人的能力总是有限的，另一方面也说明保证译文不出错是很不容易的，翻译过程中需要照顾的地方很多，精力一分散，顾此失彼，便会出错。要想少出错误，译者必须兢兢业业，认真从事，慎之又慎。

上面说的是如何确切理解原文，以免误译。下面谈一谈怎样避免因表达不当而造成的误译。

例14  His novels nicely describe life in Britain between the wars.
他的小说细致地描述了两次大战期间英国的生活状况。

例15  No dessert for me, thanks. It was as much as I could do to finish the main course.
谢谢，别给我甜食了。我只能吃完主食。

看来译者不一定没有看懂原文，只是在用汉语表达时用词不精确。例14只要把“期间”改为“之间”就行了。例15把main course机械地译为“主食”，字面上好像是对应的，但译者忘了“主食”是与“副食”相对而言的，通常指“用粮食制成的饭食”，和main course不是一回事儿。因此，例15后一半可改为“我吃完这道主菜就不错了。”

要想避免这样的误译，可以倒回去，把译文和原文对照一下，看它是否和原文的意思相吻合。这样做，你觉得很困难吗？

1980年出版了张培基等四位学者编著的《英汉翻译教程》。作者在“翻译的标准”一节中写道：“我们主张把翻译标准概括为‘忠实、通顺’四个字。”“所谓忠实，首先指忠实于原作的内容。”“忠实还指保持原作的风格。”“所谓通顺，即指译文语言必须通顺易懂，符合规范。”

1983年出版了吕瑞昌等五位学者编著的《汉英翻译教程》。关于翻译标准的论述，与第一本书是一致的。书中写道：“我们不妨用‘信、顺’两字来概括我们今天汉英翻译的标准。所谓‘信’是指忠实于原文的内容，包括思想、感情、风格等，即把原文完整而准确地表达于译文中，对原文内容尽可能不增不减。所谓‘顺’，是指用词正确得体，行文流畅通顺，符合英语习惯;避免逐字死译、生搬硬套，使不懂汉语的英语读者也能看懂。”

这两本书是受教育部委托编写的高校通用教材，一本讲英译汉，一本讲汉译英，二十多年来，一直在我国高校广泛使用。

我基本上同意这两本书关于翻译标准的提法，但我不赞成把风格放在忠实里面来谈。我们不必因为严复提出了“信、达、雅”，谈翻译标准就一定要谈风格。因为风格是一个比较复杂的问题。把原文的风格完全翻译过来，这恐怕是不大可能的，但也不是说风格就完全不能翻。译者只能尽力而为。译文的风格除了包含一部分与原文一致的风格，必然还包含其他因素。而且翻译不同类型的作品，对风格的要求也不尽相同。英译汉还比较好办，汉译英就更难把握了。

我在99年为全国高等教育自学考试编写了一套教材，题为《英汉翻译教程》。关于翻译标准，我是这样写的：“对我们初学翻译的人来说，我想可以提出两条要求：（一）忠实；（二）通顺。‘忠实’主要是指内容……要力求准确地表达原作者的意思。‘通顺’指的是语言。如果原文是通顺易懂的，那么译文也要尽量做到通顺、易懂。”我认为，真正做到上述两条，也并不容易。风格在翻译过程中是个不可回避的问题，但可以慢慢展开讨论，而不必写在翻译标准之中。

十多年前，我对外国译者关于翻译标准的看法作过一些探讨，写过一篇文章，题为“外国译者追求什么样的译文？”， 发表在《中国翻译》1992年第4期上。现将其中的部分引文介绍如下。

K. J. Maidment 在其所译Minor Attic Orators写的序言（1940）中说道：“关于译文本身，我只需要说我的目标一直是既确切（accurate）,又通顺(readable),但我充分意识到往往二者都没有做到。”

G. P. Goold 在为其所译Propertius的Elegies一书写的序言（1990）中说道：“我在本书中主要是力图以可靠的拉丁文本和优美、确切的（graceful and accurate）英译本把普洛佩提乌斯介绍给尽可能多的读者：当然首先是介绍给古典文学学者和研究人员，但也同样介绍给一般的文学爱好者。”（这个版本是拉丁文和英文对照本。）

Michael R. Katz and William G. Wagner 在为车尔尼雪夫斯基的《怎么办？》英译本写的前言（1989）中说道：“出版这个新译本，是为了提供方便，使英国和美国读者第一次看到车尔尼雪夫斯基的《怎么办》一书的完整译本……我们希望这个完整、确切、通顺的（complete, accurate and readable）译本能使英美读者不仅了解车尔尼雪夫斯基这本小说对人类生活产生了多大的影响，而且了解它推动历史前进的动力是从哪里来的。”

Ronald Hingley  在为其所译《契珂夫全集》写的序言（1964）中说道：“主要目的是为舞台演出提供脚本。译本一向以高度确切（strict accuracy）为宗旨，但希望避免学究气。译本从未有意识地为了字面上的忠实而使得台词不能上口，或违背原作的精神。”

Michael Grant在为其所译《西塞罗选集》写的前言（1960）中说道：“译者的主要任务之一是使译文通顺 (readable )，否则就没有人看，也就不能达到介绍原作者的目的。在今天如果译者使用修辞色彩很浓的英语，他的译文就不会通顺，也就没有人看。……西塞罗的修辞手段是他所受的语言训练的产物，是他的风格中不可分割的一部分。如果丢掉它，你就丢掉了人们最赞赏他的一个方面，损失还不止于此。如果保留它，我在前面已经指出，你就丢掉了另外一样东西－当代通顺的英语。这种进退两难的困境是没有折中办法可以解决的。因此，我既然不准备放弃努力，要尽可能地接近真正的现代英语，就不得不放弃西塞罗的修辞手段。至于读者遭受的损失，我是非常清楚的。”

Horace C. P. McGregor翻译了西塞罗所著《论神性》一书。他在“译者的话”（1970）中说道：任何一篇文章都包含着妥协的成分。一个句子在这种语言里通顺流畅，在另一种语言里就会拖沓累赘。一个精彩的短语如果按字面译成另外一种语言里就可能不像样子。一个单词在另一种语言里也可能难以找到相应的词。……我的目标是真正的翻译，然而是低标准的，我有一定程度的自由，可以改变原来的语言形式，但决不有意识地脱离原作的意思和语气。最主要的是我力图使西赛罗的英文译本和拉丁文原文一样通顺（readable）。

Edward G. Seidensticker翻译了紫式部的《源氏物语》。他在前言 (1976)中指出：此前Arthur Waley翻译的《源氏物语》是很自由的，他作了大胆删节，也作了大量的增补与美化。他说：“新译本可以称得上是个全译本，但其字数比Waley大加删节的译本还要少。这就说明无论Waley取得了多么精彩的效果。……他的节奏(rhythms)是与原作迥然不同的，原作较为明快、凝练，用词节省，不罗嗦。如果说翻译的目标应该在一切重要方面包括节奏在内模仿原作的话，那么这里提供的译文规定要达到的目标，可以说比Waley的译文所要达到的目标多得多。”

George Gihiam 在美国康奈尔大学任职，参加了Norton Critical Edition这套丛书的编辑工作。他在为陀思妥耶夫斯基的《罪与罚》英译本写的序言（1989）中写道：“我们选择《罪与罚》一书的英译本，标准是这个译本能用当代英语确切地(accurately)体现陀思妥耶夫斯基的十九世纪俄语原作，能用今天的英语表现出和原作相一致的风格(style)，不以现代词语或维多利亚时代的词语歪曲原作，而且译文本身是通顺的(readable)。根据这些原则，我们认为Jessie Coulson的译本似乎是最好的译本，经与牛津大学出版社接洽，在这里重印出版。”

从以上几段引文来看，accuracy和readability 是译者追求的共同目标。其他方面，各位译者的侧重点是不同的，风格、精神、修辞手段、语气、节奏，不一而足，有时甚至故意反其道而行之，可见问题之复杂。
鉴于以上情况，我们在开始时不妨就以信（忠实）和达（通顺）为目标吧。你觉得这两条会很容易做到吗？

翻译界有一个提法：翻译理论与实践。有人写书，以此为书名。有的学校开课，以此为课程名称。这个提法甚至进入了国家教育部门制定的学科目录。仿佛这个提法概括了翻译领域的全部内容。

其实，在翻译理论与实践之间，还有一个层次，那就是语言对比。所谓语言对比，就是研究英汉两种语言的异同，从而看出英语和汉语各自的特点。相比之下，各自的特点就清楚了。

二十世纪中期，王力先生在《中国语法理论》第六章“欧化的语法”中花了很大的篇幅进行语言对比，指出各自的特点，探讨英语对汉语的影响。八十年代以后，从事这方面研究的人多了起来，出版了专著，还成立了专门的机构。

我个人进行语言对比，是从对照着原文研究《毛选》的译文开始的。我在研究了大量的译例之后，得出了若干规律性的认识，分二十个题目，写成了《汉英翻译五百例》，于1980年出版。

例如，许多译例表明：“在一个汉语句子里或相连的几个句子里，往往有些词或词组重复出现。”“英语和汉语相反，在一般情况下是避免重复的。”“汉语重复，英语不重复，这是两种语言的一个明显的不同之处。”有了这点认识，汉译英时就多用代称，英译汉时就多用实称，不必拘泥于原文了。

语言对比主要是注意句子结构，或者说注意翻译过程中各个成分在句中的变化。译文之所以有时会因过于机械而不顺，就是因为迁就原文的结构，而没有考虑译文的结构应有哪些变化。好的译文之所以好，就是因为句内各成分都放在了应放的位置，符合译入语行文的习惯。美国翻译理论家奈达说过：

To preserve the content of the message the form must be changed .说的大概也是这个意思。

是不是看几本书就行了？诚然,这方面的书也是有的。但只看别人得出的结论往往印象不深，时间久了，也许就忘了。因此最好亲自动手进行比较，或者至少把别人结论拿来验证一番。其实，语言对比是很有趣的，通过对比，你会发现许多过去未曾注意的东西。而且你的注意力也不会完全局限于译例。每当你有所发现的时候，你就会去查阅关于英语的权威性著作，也会去查阅关于汉语的权威性著作，看看他们对这个问题是怎么说的。比如，在我研究前面提到的“实称”与“代称”的问题时，就参考了Randolph Quirk等四位学者所著的A Grammar of Contemporary English。书中有一节专门论述substitution，我看到不仅名词有替代的说法，动词、形容词、副词等也都有替代的说法，他们把所有这些替代的说法统一称为“pro-forms”。看到这里我感到一阵惊喜，顿时觉得自己对这个问题的了解深入了一步。一个人要是学问有长进，就会感到欣慰，要是日有所进，就会觉得其乐无穷。

对比两种语言，认识其各自的特点，主要是通过研究译例来进行的，是与翻译实践紧密相连的。若用这方面的研究成果来指导翻译实践，翻译起来就会得心应手，认识越深刻，就越得心应手。不信你试试。

严复就是用他那优雅的古文把进化论的思想介绍到中国，感动了一大批有识之士，包括当朝皇帝，推动他们变法维新。他翻译的《天演论》，虽未尽“信”尽“达”，一个“雅”字却表现的淋漓尽致。

林纾虽不懂外语，却在别人帮助之下，用他那精美的文言文将184种外国文学作品介绍到中国。《林译小说丛书》曾使十一二岁的钱钟书“增加学习外国语文的兴趣”。数十年后，大学问家钱钟书“偶尔翻开一本林译小说”，发现“它居然还没有丧失吸引力”。

周熙良教授就很强调研究语言。他写过一篇文章，题目是“翻译三论”，发表在《翻译通讯》1982年第六期。他在“翻译与语言”一节中指出，初搞翻译的人要看点汉语语法，注意到一些语言现象，这有助于摆脱原文的束缚。他说：“一个搞翻译的人对语言不感兴趣，翻译水平是不大会提高的。”

近年来，研究翻译的人多了起来，各种出版物也多了起来，介绍翻译理论、翻译技巧、翻译方法、翻译经验，吸引着初上译途的人的眼球。这些出版物既然都是研究的成果，都会给人以启迪。但对一个译者来说，最重要的不是通晓多少种翻译理论，掌握多少条翻译技巧，而是不断提高自己的语言水平。最后决定译文质量高低的是译者使用语言的能力。一位有经验的译者，可能说不出多少翻译理论和技巧，他靠的是自己在语言方面的造诣，他能告诉你的是怎样学好语言。

单其昌写了一本《汉英翻译技巧》，请杨宪益作序。杨先生在肯定了作者的研究方法之后指出，要避免翻译工作中出现错误，“主要还是要多读一些好的英美文学作品，逐步理解这种外国语言的内在规律。”接下去，他还介绍了自己的学习经历，“在我掌握了基本语法之后……到了我上高中时，我就完全丢开了语法书，只去广泛阅读文学作品了。”

我的老师王佐良教授译过一本《彭斯诗选》，其中有一首题为“一朵红红的玫瑰。”他在题为“答客问：关于文学翻译”的广播稿中提到，自己对这首诗的译文并不满意。接下去，他说，“作为一个译者，我总是感到需要不断锻炼，要使自己的汉语炼得纯净而又锐利。”老先生这样孜孜不倦，精益求精，是非常值得我们学习的。

英国剑桥大学George Steiner 教授写过一本书，名叫After Babel。在第一章的末尾，他说了这样一句话：A study of translation is a study of language。这也许是对翻译研究最好的概括。你不想在语言上下点功夫吗？

要想提高自己的翻译能力,一定要通过实践。实践可以分为两类,直接的实践和间接的实践。

所谓直接的实践,就是自己亲身参加的实践,也就是自己动手翻译。一回生,二回熟,日积月累,第一手经验多了,做起来得心应手,翻译能力有所提高。所谓“熟能生巧”,就是这个道理。但自己能译的东西是有限的，从这种实践中得出的经验也是有限的。因此，还需要借助于间接的实践。

所谓间接的实践,就是研究别人的译文。比如,一篇文章在手,准备翻译,这时先找一些有关的资料或同类文章的译文看一看,在词语和风格方面定会有所借鉴。常作翻译的人都会这样做。别人的译文是别人直接实践的产物,你看了别人的译文,就是从事间接实践。从总结经验的角度来看,直接实践和间接实践具有同等的价值。因此,有空的时候,找一些译文来,尤其是好的译文,加以研究,总结出一些规律性的东西,对于提高自己的翻译能力是大有好处的。

不过我还是要强调,只看别人怎样翻译,自己并不动手译,是不行的。我为高等教育自学考试编过一套翻译教程,有些学校办了辅导班。有一次,一位老师告诉我,他的学生只看我的书,并不作练习。我听了大为惊讶,连忙写了一片短文,登在《英语学习》杂志上。我说,学翻译犹如学游泳。只在岸边看别人游,或只听教练讲解,是学不会的。你说是不是这么个理儿?

其实向名家学习,随时都能做到。那就是不要求面授,而是去自学，去研究名家的译文。可以采用以下三种方法。

第一种方法:先不看译文,自己先根据原文翻译一遍，然后拿自己的译文和名家的译文相比较,从差距中就可以看出自己的弱点和问题,然后有针对性地克服自己的缺点,提高翻译能力,定会收到较好的效果.

第二种方法:研究译文。将原文和译文对照研究,从中得到启发。

周煕良教授是我非常崇敬的一位译者,他不仅从事文学翻译,而且喜欢讨论翻译问题,发表看法。几年前,我拿原文对照着看,他译的英国作家高尔兹华绥所著《福尔赛之家》。首先映入眼帘的是这样一段话。

Those privileged to be present at a family festival of the Forsytes have seen that charming and instructive sight — an upper middle-class family in full plumage.

译文是:

碰到福尔赛家有喜庆的事情,那些有资格去参加的人都曾看见过那派中上层人家的兴盛气象,不但看了开心,也增长见识。

原文charming and instructive是定语,和sight搭配,但译成汉语,若想保留这样的搭配是很困难的。译文把原文的定语放到后面去处理,语言就顺了。当然,放到后面,就不一定是定语了。

第三种方法:研究不同的译文。有些作品经不同的人翻译,便出现了不同的译本,而且都是很好的译本。例如《红楼梦》，近年来就出版了两个译本,一个是国内出版的杨宪益和他的夫人戴乃迭的译本,取名A Dream of Mansions, 另一个是英国出版的David Hawkes的译本,取名The Story of the Stone.这两个译本都很好, 不少人做了对比研究。

更为可贵的是原译者提供的修订译文。把修订后的译文和原译文比较一下,看译者是怎样修改自己的译文的,往往可以看出许多问题.

鲁迅的短篇小说“孔乙己”是这样开始的:

鲁镇的酒店的格局,是和别处不同的:都是当街一个曲尺形的大柜台,柜里面预备着热水,可以随时温酒。

这段话,在杨宪益和戴乃迭译的Lu Xun Selected Works（1956,1980）里是这样译的:

The layout of Luzhen’s taverns is unique. In each, facing you as you enter, is a bar in the shape of a carpenter’s square where hot water is kept ready for warming rice wine.

后来,在这两位译者译的Selected Stories of Lu Hsun（1960,1972）里,这段话就改为:

The wine shops in Luchen are not like those in other parts of China. They all have a right-angled counter facing the street, where hot water is kept ready for warming wine.

为什么这样修改,译者没有说,我们也无法询问,只能自己揣摩。全段讲的是鲁镇的酒店,第二个译文的wine shops作定语,一下子就把读本的注意力集中到“酒店”身上,下文也好安排。因此,比第一个译文以layout作主语为好。至少我们可以看出,原文以“格局”为主语,译文用layout不如用wine shops作主语好。认识到这一点,我们在做翻译时也就不必拘泥于原文的句子结构了。你说是不是?

大学毕业后，留在北外当老师，后来有幸参加毛泽东、刘少奇、周恩来等领导人著作的翻译和修订工作，参加重要文件的翻译工作。当时我觉得学习外语，能做这样的工作，是无上的光荣，这种感受也鞭策我努力钻研。

有一天，我看到这样一句话：

“吃一堑，长一智。”

“a fall into the pit, a gain in your wit.”

没想到天下竟有这样好的译文，它本身就像一句谚语，然而它又与原文如此接近，如此吻合，使我惊讶不已。

后来我又看到这样一句话：

夺取这个胜利，已经是不要很久的时间和不要花费很大的气力了;巩固这个胜利，则是需要很久的时间和要花费很大的气力的事情。

To win this victory will not require much more time and effort, but to consolidate it will.

原文里重复出现的词语，译文没有重复，一个小小的will竟然替代了原文用二十多个字表达的意思。我在这里看到了道地的英语。

每当我看到这样好的译例，就回想起小时候在海边玩耍，捡拾贝壳。阳光下，那贝壳五光十色，绚丽多彩，拿在手里，别提多么高兴了。

近年来，参加了几本词典的审定工作。原书都是英英词典，加上汉语译文后，变成英汉双解词典。译文对不对，顺不顺，这就是审定者所要解决的问题。例如：

原文：The cold weather frosted up the track last night.

译文：昨晚寒冷的天气使跑道上结了霜。

改为：昨晚天气寒冷，跑道上结了霜。

原文：My toes were frostbitten from skating too long.

译文：滑冰的时间太长使我的脚趾冻伤了。

改为：滑冰的时间太长，我的脚趾冻伤了。

改动虽然不大，译文弄得比较通顺了，这也是对词典的贡献。

翻译有没有苦恼，有的。鲁迅先生在《且介亭杂文二集》中说过：“譬如一个名词或动词，写不出，创作时候可以回避，翻译上却不成，也还得想，一直弄到头昏眼花，好象在脑子里面摸一个急于要开箱子的钥匙，却没有。”译者这时的确感到心急如焚，焦头烂额，可是一旦找到合适的译文，就会感到格外痛快。

译者还有一种苦恼，那就是一个长篇在手久久不能完成。我译《大卫·科波菲尔》时，就有这种体会。前后三年时间，一天都不敢歇息，更谈不上娱乐。家里人抱怨，“连跟你说话的工夫都没有。”三年里，我天天跟书中的角色打交道，把他们的言行和思想感情用汉语表现出来，他们成了我生活的一部分，以至于在快译完全书的时候，怀着沉重的心情仿佛向他们一一告别，痛苦得很呀。

几年以后，忽然有一天出版社的责编打来电话，说我的书快要出版了。我兴奋极了。取回样书的那一天，我对老伴说，我又有了一个儿子，我已经把他接回来了，他的名字就叫“大卫”。

总之，翻译蕴藏着无穷的乐趣，等待喜欢他的人去发掘。干这一行，就要爱这一行，否则怎么能做得好呢？

得知Karl Swedberg和Jonathan Chaffer共同编写这本jQuery教程的消息后，我深感荣幸。作为第一本jQuery图书，本书为其他jQuery——实际上，也为其他JavaScript——图书，树立了一个新标杆。从第一版面世以来，本书始终高居最畅销JavaScript图书榜首，究其原因，概源自其内在的高品质和对细节的关注。

我尤其高兴是Karl和Jonathan共同执笔写的这本书，因为我对他们非常了解，也知道他们是写这方面书的最佳人选。作为jQuery开发团队的核心人员，我在过去的几年间对Karl有了充分的了解，特别是对他编写本书的情况十分熟悉。看看最终作品就会知道，作为开发人员和曾经的英文教师，由他来完成这个写书任务简直是老天的巧妙安排。

我还有机会与他们两位见过面——对于从事分布式的开源项目工作的我们来说，这种见面机会应该算是极为难得的事情了。当然，他们目前依旧是jQuery社区的中坚分子。

jQuery社区中有许许多多不同的人在使用jQuery，其中包括设计人员、开发人员、有编程经验的人和没有编程经验的人。即使是jQuery团队内部，也有很多不同背景的人为这个项目的发展提供各自的建议。但是来自五湖四海的jQuery用户却有着同样一个目标，即我们这个由开发人员和设计人员组成的社区，其宗旨就是让JavaScript开发变得越来越简单。

此时此刻，重申开源项目是社区导向的，或者说开源项目的目标就是帮助新用户快速上手，好像总有几分陈词滥调的意味。然而，这些宗旨对jQuery而言绝非表面上做做姿态，这些理念恰恰正是项目本身绵绵不绝的动力源泉。在jQuery团队中，除了维护核心代码的人之外，实际上还有更多的人在负责管理社区、撰写文档和编写插件。虽然库本身的稳定性至关重要，但代码背后的社区也绝对不容忽视。一个项目是等闲平庸、举步维艰，还是处处都能够满足甚至超出用户的期许，可以说完全取决于社区。

我们如何运营项目，用户如何使用我们的代码，是jQuery与大多数开源项目（以及大多数JavaScript库）的根本差异所在。jQuery项目及其社区是具有高度智慧的。我们深知是什么让jQuery带给了用户不同的编程体验，并且也在竭尽全力把这些知识和智慧传递给我们的用户。

袖手旁观永远不会理解jQuery社区，只有参与其中，潜心钻研，才能获得切身体验。我们衷心希望本书读者有朝一日都能够加入jQuery社区。无论是加入我们的论坛、邮件列表还是博客，jQuery社区都能为你更好地利用jQuery提供各方面帮助。

对我个人而言，jQuery绝不仅仅就是一些代码块那么简单，它是这几年来，为了让这个库更有价值，社区成员日积月累的所有经验的大汇聚。其中蕴涵着一次次惊心动魄的起起落落，一次次开发过程中的奋斗挣扎，当然还有看着它不断成长和成功带来的喜悦。它贴近用户和团队成员，反映他们的需求，并且日益成长完善。

我一开始看到这本书将jQuery作为一个统一的工具来讨论时，第一感觉是书中介绍的jQuery跟我印象中汇聚各种经验的jQuery不太一样，但吃惊之余，更多的还是心潮澎湃。能够看到别人通过学习、理解进而塑造出的jQuery，作为项目创始人而言，其创造之乐也莫过如此了！

我决不是唯一一个超越工具-使用者关系层面去欣赏jQuery的人。我不确定能否准确地逻辑出原因，但我已经多次看到这样的场面——当用户恍然领悟到jQuery的效力时，他们的脸上会情不自禁地流露出会心的微笑。

还有一个特别的时刻，也只有jQuery用户才能体会到——有一天，他们突然意识到自己使用的工具，实际上远远不是一个简单的工具，他们将顿悟原来可以彻底换个思维方式来编写动态Web应用程序。想想吧，那个时刻将会多么美妙，而我认为这绝对是jQuery项目最大的价值所在。

希望手捧本书的读者朋友，也能够体验到那美妙的时刻。

John Resig

jQuery创建人，Mozilla公司技术推广专家，畅销书Pro JavaScript Techniques作者[①]

Foreword
I feel honored knowing that Karl Swedberg and Jonathan Chaffer undertook the task of writing Learning jQuery. As the first book about jQuery, it set the standard that other jQuery — and, really, other JavaScript books in general — have tried to match. It’s consistently been one of the top selling JavaScript books since its release, in no small part due to its quality and attention to detail.
I’m especially pleased that it was Karl and Jonathan who wrote the book since I already knew them so well and knew that they would be perfect for the job. Being part of the core jQuery team, I’ve had the opportunity to come to know Karl quite well over the past couple years, and especially within the context of his book writing effort. Looking at the end result, it’s clear that his skills as both a developer and a former English teacher were perfectly designed for this singular task.
I’ve also had the opportunity to meet both of them in person, a rare occurrence in the world of distributed Open Source projects, and they continue to be upstanding members of the jQuery community.
The jQuery library is used by so many different people in the jQuery community. The community is full of designers, developers, people who have experience programming, and those who don’t. Even within the jQuery team, we have people from all backgrounds providing their feedback on the direction of the project. There is one thing that is common across all of jQuery’s users, though: We are a community of developers and designers who want JavaScript development to be made simple.
It’s almost a cliché, at this point, to say that an open source project is community-oriented, or that a project wants to focus on helping new users get started. But it’s not just an empty gesture for jQuery; it’s the liquid-oxygen fuel for the project. We actually have more people in the jQuery team dedicated to managing the jQuery community, writing documentation, or writing plugins than actually maintaining the core code base. While the health of the library is incredibly important, the community surrounding that code is the difference between a floundering, mediocre project and one that will match and exceed your every need.
How we run the project, and how you use the code, is fundamentally very different from most open source projects — and most JavaScript libraries. The jQuery project and community is incredibly knowledgeable; we understand what makes jQuery a different programming experience and do our best to pass that knowledge on to fellow users.
The jQuery community isn’t something that you can read about to understand; it’s something that you actually have to participate in for it to fully sink in. I hope that you’ll have the opportunity to partake in it. Come join us in our forums, mailing lists, and blogs and let us help guide you through the experience of getting to know jQuery better.
For me, jQuery is much more than a block of code. It’s the sum total of experiences that have transpired over the years in order to make the library happen. The considerable ups and downs, the struggle of development together with the excitement of seeing it grow and succeed. Growing close with its users and fellow team members, understanding them and trying to grow and adapt.
When I first saw this book talk about jQuery and discuss it like a unified tool, as opposed to the experiences that it’s come to encapsulate for me, I was both taken aback and excited. Seeing how others learn, understand, and mold jQuery to fit them is much of what makes the project so exhilarating.
I’m not the only one who enjoys jQuery on a level that is far different from a normal tool-user relationship. I don’t know if I can properly encapsulate why this is, but I’ve seen it time and time again — the singular moment when a user’s face lights up with the realization of just how much jQuery will help them.
There is a specific moment where it just clicks for a jQuery user, when they realize that this tool that they were using was in fact much, much more than just a simple tool all along — and suddenly their understanding of how to write dynamic web applications completely shifts. It’s an incredible thing, and absolutely my favorite part of the jQuery project.
I hope you’ll have the opportunity to experience this sensation as well.
John Resig
Creator of jQuery

]]> http://www.cn-cuckoo.com/2009/07/07/learning-jquery-1-3-forward-930.html/feed 0 http://www.cn-cuckoo.com/2009/07/02/translators-words-for-designing-web-interfaces-901.html http://www.cn-cuckoo.com/2009/07/02/translators-words-for-designing-web-interfaces-901.html#comments Thu, 02 Jul 2009 09:15:13 +0000 为之漫笔 http://www.cn-cuckoo.com/2009/07/03/%e3%80%8aweb%e7%95%8c%e9%9d%a2%e8%ae%be%e8%ae%a1%e3%80%8b%e8%af%91%e8%80%85%e5%ba%8f-901.html 2005年，一组前端技术的组合由于被命名为Ajax而广为人知。此后，随着Ajax应用的迅速普及，新Web时代的帷幕也徐徐拉开。仅仅几年间，各种“桌面般的”Web应用程序和新Web应用平台层出不穷。从Google Maps、Flickr、Netflix到Google Docs、Yahoo! Mail、Gmail，再到Twitter、Facebook、Digg……。在21世纪第一个10年临近尾声之际，现代Web发展的成果已经蔚为大观。

界面，不仅是现代Web应用程序与传统Web应用程序的分水岭，曾经也是横亘于传统Web应用程序与桌面应用程序之间的一道难以逾越的“鸿沟”。然而，Ajax及其框架技术突飞猛进的发展，不仅让一个或者少数几个HTML页面中容纳整个Web应用程序（或复杂功能组件）成为可能，而且也让现代Web应用程序的界面，展示出了堪与桌面应用程序媲美的耀眼风姿。

读者手中拿着的这本书，是两位出色的UI设计专家Bill Scott和Theresa Neil，在他们多年潜心研究、深入实践的基础上，结合现代认知心理学的最新发展成果和流行Web应用程序的界面设计实例，以六大设计原理为依托，以最佳设计实践为着眼点，奉献给我们的一本精彩绝伦的现代Web界面设计权威指南。

从译者的角度来看，本书既是一本Web界面设计手册，又是一本Web界面实例参考，它基本上涵盖了现代Web界面设计的普遍规则和最佳实践。Web界面设计人员通过阅读本书，可以迅速在当前或将来的项目中发现最合适的应用场景；开发人员通过阅读本书，能够轻松地将丰富的示例映射为自己头脑中的编码要点；Web项目的管理人员通过阅读本书，就有了在与客户商讨界面设计方案时的“共同语言”。哪怕你购买本书只是出于对其中漂亮Web界面的好奇，甚或只是想通过本书了解目前最流行的Web站点，相信在阅读本书之后，你会发现本书为你揭开了现代Web应用程序为什么如此令人着迷的奥秘。

感谢金照林、柳安意在对本书中耕时付出的努力，感谢徐定翔为译者翻译本书提供支持，感谢本书编辑陈元玉指出或纠正本书译稿中存在的问题。翻译本书的过程中，译者尽最大努力确保术语统一、准确，也尽最大努力以简洁、地道的中文为读者重现原书的意境和风貌。但是，囿于个人的水平，书中的问题和疏漏之处在所难免，敬请读者朋友给予批评指正。译者邮箱是lsf.email[at]gmail.com，个人网站是http://www.cn-cuckoo.com。

译者 2009年6月14日于北京

豆瓣上的《Web界面设计》

言归正传。对一些表示虚义的词，应该利用“意会”来“翻译”，如果非要“言传”这些词，即非要直译其字面意思，结果不是啰里啰嗦，就是不伦不类；举两个小例子：

[例1]The most significant change reflected in this thenth edition is a new chapter on computer graphics(Chapter 10).

如果把这句话里的reflected in翻译出来，效果并不好。如：“第10版中反映出的最大变化是关于计算机图形学的新的一章（第10章）”

仔细咂吧咂吧滋味，好像是不会说中国话的人翻译的。没错，这种多此一举的翻译，恰好应了中国的一个成语，即“画蛇添足”。你看，要是去其两“足”，只剩下“第10版最大的变化是新增了关于计算机图形学的一章（第10章）”，岂不更简练、更明确？

[例2]Most of this chapter focuses on the discipline of 3D graphics in which abstract models of three-dimensional worlds are encoded and then used to produce two-dimensional images.

没错，引导定语从句的in which是万万不可“言传”的。你猜自怎么着，硬是有“敢为天下先”的，看人家翻译的：“这一章的大部分内容集中在3D图形学科，其中对三维现实世界的抽象模型被编码，然后用来生成二维图像”。

in which引导的定语从句，如果相对较短，可以让它直接“修饰中心词”（即此处的宾语discipline of 3D graphics）；如果像这里比较长，就要郑重其事一点，给人家一套独立的谓语结构，不要舍不得。比如：“这一章的大部内容集中在3D图形学方面，也就是如何对三维现实世界的抽象模型进行编码，然后再据以生成二维图像的技术”。

类似地，in that、in ways都不能“言传”，而是要“意会”。归根到底，还是那句话：翻译要翻译意思，不是翻译字面。

Ryan Dewsbury，一介技术人员，关注非技术性的用户体验——软件应该带给用户流畅、无障碍的感觉——由来已久。溯本求源，概肇始于他本人曾受到C++模板技术生成代码的强烈震撼。那种如饮甘醴、如沐春风的感觉，让这位C++程序员久久不能释怀。然而，离开工作单位，面对作为软件用户的非技术人员（家人、朋友）却又无法言传那种美妙的“用户体验”。这让他很不爽！——“我决定抽时间编写一个客户端应用程序，让它带给用户的优雅体验，就如同开发者看到写得漂亮的代码一般”。

于是，他用C++开发了一款体积小巧、界面简洁，类似今天Google Talk的即时通信软件。结果受到用户追捧，达到百万级的下载量——简洁作为一种价值观，与full-function（全功能）相对；这与Google对用户体验的理解不谋而合。但是，C++做界面似乎笨拙了点，因此简单的HTML+CSS时常令他心驰神往。

2005年，Ajax被人发现了。虽然基于Ajax技术的Google Maps让Ryan Dewsbury惊呼：桌面级用户体验现身于Web了！然而，在了解“事实真相”后，又不免“怅然若失”——“我知道使用JavaScript存在着很多的局限性。由于这些局限性，几乎不可能用它来构建一个大型复杂的客户端应用程序”——潜台词：“浴火重生”的JavaScript虽然强大，但浏览器不兼容性问题太严重，学起来简直烦人透顶，哪有丝毫“用户体验”可言？简直令人失望至极。更何况，一人之力怎与Goolge的Maps团队相比呢？看来是没有希望开发出具有Google Maps般用户体验的Web应用程序了，唉！

但是，峰回路转，在Ryan Dewsbury熟悉的Java语言与能带给用户更好体验的Ajax应用程之间架起一座“彩虹桥”的Google Web Toolkit（GWT）发布了。真的吗？可以用Java开发Ajax应用程序——不用学习JavaScript、不必面对复杂的浏览器兼容性问题？呵呵——当然要“抢鲜”试一试喽。

结果，仅用3周时间，Ajax应用程序Gpokr诞生了，而且全Java开发；这是一个在线游戏应用程序。发布以后，引得GWT开发团队的高人纷纷赶来试用。在感谢这些GWT“之父”们之后，Ryan Dewsbury没忘提一句“最让我激动不已的，就是GWT编译器能够把优美的Java代码转换成JavaScript”——这不正是自己魂牵梦萦、上下求索的代码生成技术的翻版吗？对Java技术人员及至本书作者而言，GWT相当于提供了C++中的模板技术。GWT编译器就是代码生成器，能把Java代码转换成JavaScript——简直重现了作者当年的那种如饮甘醴、如沐春风的感觉，很有点天作之合的味道，不是吗？接着，作者又发感慨“于是，任何人都可以创建向用户交付美好体验的应用程序，而可靠的GWT则给我留下了深刻的印象”，这不是如获至宝的感觉是什么？

分享分享分享，强烈的“共产主义”精神，反复地刺激着从未写过书的Ryan Dewsbury的思想深处，他的灵魂所在地。对呀，要是写本书就好了，这么一个“令人惊叹的工具”哪能没本书来宣传宣传呢？当时市面上还没有出GWT的书，不过Ryan Dewsbury也没有写书经验。没写过怎么了，反正“当时可以说也没有什么人对GWT很在行”。不会写，先做例子呀！通过做例子，既能搞通GWT，又能掌握相关的Web技术。来他个博观约取、厚积薄发……总之，先埋头编上几个月的程序再说。

Ryan Dewsbury

当然，最好是找几个流行的Ajax应用程序参考着做。比如：Google Start Page（http://www.google.com/ig）、基于Ajax的多搜索引擎集成、Blog文章编辑器、即时通信系统（这个简单，以前用C++就做过，呵呵。不过，这次要基于开发网页了）。最后，来个更牛的基于网页编辑数据库的程序（这个好像跟那个管理MySql的phpAdmin类似，不过那是管理本地数据库文件，而这个管理的则是远程数据库，厉害吧）。嘿，还别说，几个例子做下来，对GWT简直门清了，以前那些似是而非的Web概念也都清晰了。嗯，写书这个想法还真不错哩。

又经过几个月的日夜奋战，本书就新鲜出炉了。

内存管理

JavaScript有垃圾收集机制，Objective-J同样也有，因此Objective-C中出现的保持或释放内存的代码，在Objective-J中是看不到的。DOM操作导致的很多常见的内存泄漏问题，Cappuccino框架可以帮我们处理。

但这并不是说对象不可能泄漏。任何垃圾收集语言（language），都有可能偶尔保持对象引用而不释放，这一点应该正确看待。

类目

通过类目（Categories）可以为类添加方法，而不必创建新的子类或修改类的源代码。当类目被加载后，新方法（或方法）就会变成所有类实例的一部分。

这一特性在很多情况下都很有用，例如，可以利用它为内置类添加方法。假设我们想让所有CPString对象都具有一个能够返回反转字符串的方法，可以像下面这样定义一个类目：

这样，就可以在任何字符串上调用reverse来取得反转字符串了。

定义类目的语法是@implementation，后跟要添加到的那个类，再后跟括在括号中的类目名称。在@end关键字之前添加的任何方法，都将成为类目的一部分。注意，不能通过类目添加实例变量，尽管可以动态修改JavaScript对象，也不能添加。

在上面reverse方法的实现中，有几个特别值得一提的地方。例如，reversedString是按照声明JavaScript字符串的典型方式声明的。这完全归功于一种名叫“免费（toll-free）”的技术，借助该技术任何JavaScript对象（如数组或字符串），可以同时作为JavaScript对象和Cappuccino对象存在。因此，这个字符串可以调用CPString的length和characterAtIndex:等方法，也可以调用现有的JavaScript方法和运算符（如+）。

作用域

多数情况下，Objective-J与JavaScript的作用域规则是相同的。没有以var特别声明的变量就是全局变量，而使用var声明的变量则具有函数/方法级的作用域。不符合这两条规则的变量是实例变量和文件作用域变量。

本教程前面曾介绍过，实例变量通过@implementation块声明。当在类中使用那些变量时，它们具有对象级作用域——不是全局作用域，只属于每个对象实例。但是，如果忘记声明了某个实例变量，那么该变量就像在JavaScript代码中一样，会变成全局变量。

文件作用域变量则是Objective-J新引入的一种变量。如果是在函数或方法实现的外部使用var关键字声明一个变量，则该变量（有时候也称其为静态变量）就具有文件级作用域。这种变量可以被同一文件中的其他代码访问。这种变量对于不依赖全局对象而实现各种共享对象的技术提供了便利。如果文件中只包含一个类，也可以把这种变量看成是“类变量”。

以下代码展示了Objective-J中主要的作用域规则：

结束语

Objective-J简明教程至此就结束了。这门语言只是对JavaScript简单而直观的扩展，绝大多数开发人员不用费吹灰之力即可掌握它。

要想参考本教程中完整的代码清单，可以下载这个Person.j文件。

使用对象和类

了解了Objective-J对象和类的基本情况下，接下来我们看一看如何使用它们。下面的代码创建一个新Person对象，并设置了其name属性：

Objective-J中的方法调用叫做“消息”（messages），为对象发送消息需要使用方括号表示法，如：[object message]。如前所述，有些方法是类方法，要通过类来调用——alloc就是一个类方法。Objective-J中的每个类都有一个名叫alloc的特殊的类方法，该方法返回相应类的一个新实例。

上面的例子在Person类上调用了alloc方法，结果返回了一个Person实例。然后，我们又调用了该实例的init方法。无论alloc还是init都返回一个对象的引用，而我们把这个对象赋给了变量myPerson。就像alloc一样，每个类都会从CPObject继承init方法。

alloc类方法与JavaScript、C++及Java语言中的new关键字相似，都是创建新的实例。而init实例方法则与这些语言中的构造器相似，都是对新创建的实例执行初始化。

有一些会指定自定义的init方法，如CPView的自定义init方法签名如下：

每个子类都要确保调用其父类的init方法。以下是前面Person类的自定义init方法，该方法直接接收名字参数：

首先，调用超类的init方法，结果会返回一个对新初始化实例的引用。此时，必须把这个引用赋值给self变量（以防超类的init方法因新实例而抛弃原始的实例）。然后，检查self确保其正确返回，如果检查通过则执行针对当前类的操作，即把aName赋值给name。最后，返回self以便调用代码获得这个新初始化对象的引用。

Objective-J中的self等价于JavaScript中的this。可以说this引用JavaScript对象，而self引用Objective-J对象。与JavaScript类似，self.foo引用的是foo实例变量；但与JavaScript不同的是，self不是必需的，即可以在任何实例方法中使用foo。

Cappuccino中的很多类都为创建对象提供了一种略有不同的模型，但却更加便捷。在创建对象时，这些类不调用alloc和init，而是实现各自的类方法以返回新对象。注意，在类方法中，self引用类自身。

可以像下面这样调用这个类方法：

导入代码

JavaScript所欠缺的一种众望所归的特性，就是以像Java或C一样的方式导入代码。对此，Objective-J添加了@import语句：

有两种类型的导入语句。尖括号表示框架代码，而引号表示本地项目代码。导入框架代码时，会使用内置的搜索路径机制从定义的位置中搜索目标文件。而导入本地代码时，则只会查找与导入文件相关的位置。