作者：Alex Russell 原文链接： Books! It’s Raining Books!

此时此刻，由于3本新书的问世，同学们可更全面地学习Dojo了。写一本Dojo书的难度与写Python书的难度类似：要讲解的东西太多了！从哪讲起？如果要向任何人解释一切，以什么为线索？令人欣慰的是，这3本书各自遵循了不同的写作思路，面向不同的读者，因此我认为任何层面的Web开发人员几乎都能各取所需。通过对其中两本书在付梓之前的审读（另一本由Dylan和Pete审读），我为它们的深度和着眼点的不同感到吃惊。

Pragmatic的Mastering Dojo一书封面上署了我的名字，不过千万不要因此而误会……这本书其实非常棒！为什么这么说呢？Craig和Rawld不仅向读者展示了这个工具箱的价值所在以及如何用好这个工具箱，而且也深入了它的实现细节，剖析了工具箱的内部工作原理。在构建由易响应JavaScript驱动的UI时，真正的艺术体现在巧妙的平衡上。Mastering Dojo这本书确实有助于读者理解在实现良好用户体验的同时，Dojo还以哪些方式兼顾了某种平衡。 (更多…)

近来，有几位购买了我翻译的《jQuery基础教程》的读者朋友来信，询问了一些问题。本着有信必复的原则，同时也避免“重复劳动”，我把问题和答复放在这里，供广大读者朋友参考。

目前的主要问题有3个：

Q1：关于DOM文档。查看

这个问题是读者对JavaScript与DOM的关系理解不透造成的。

Q2：关于XPath选择符。查看

这个问题是因为jQuery1.2之后不再内置支持XPath选择符造成的。

Q3：jQuery版本。查看
这个问题与Q2类似，因为《jQuery基础教程》基于jQuery1.1，而很多读者下载的则是更高版本。 (更多…)

根据thefreedictionary.com上的解释， syntactic sugar，指的是“语法中的糖分”，但此术语的中心词是“语法”，所以可以说成”含糖的语法”（也可以与下文中的“富糖”、“脱糖”对应）。另外，如果出现频率不高的话，也可以译为“语法糖衣”。

[译文]
含糖语法，是由Peter J. Landin创造的一个术语，指的是为一门计算机语言的语法中添加的附加物或附加成分，它不会影响语言的功能，但却能使人类使用起该语言来”更甜美”一些。含糖语法为编程人员（对计算机规范语言来说，是设计人员）提供了一种编写程序（编写规范）的替代方式，这种方式更具有实用性、更有助于形成较好的程序设计风格，或者使代码读起来更自然。但是，它不会影响形式上的可表达性，也不会让语言拥有某种新功能。

很容易用某种更简单的”核心”语法，将含糖语法转换（“脱糖”）为一个程序（规范）。以Landin为例，其核心是通过一系列操作（如赋值）浓缩成的λ演算。受Landin的启发，一些后来的编程语言，像ML和Scheme，都明确地设计为一种基于要素构件的语言核心。为方便起见，高级特性经过”脱糖”或降解，可以转换为其子集。事实上，这正是在原语基础上构建起来的通常的数学实践。然而，许多现代的、”富糖”型的语言（例如C#）则无法脱糖。但之所以它们的特性仍被视为”含糖”，是因为存在于先驱语言（例如C）中的原语，足以重新创建这些语言。 (更多…)

中国选手：晏紫

同上

中国选手：彭帅

瑞士选手：费德勒

火箭队球员：斯科拉

俄罗斯选手：图尔苏诺夫

费德勒发球

没错，我现在又开始读这本书。虽然 《JavaScript DOM高级程序设计》的第一读者就是我，但我现在仍然要说：我要安排时间再通读它几遍！

好书啊，没办法。翻译一遍，还不够烦吗？——怎么会烦呢？尽管在翻译它时，我倾注的热情和努力已经够多，但我仍然感觉没有完全读透它！我读它读得还不够。

再读 《JavaScript DOM高级程序设计》，我体验到了什么叫享受。毫无疑问，就当前谈论和讲解JavaScript及DOM编程的技术书而言，这本书已经接近该领域的极高点了（其他几本我也知道，但在它面前只能算各有千秋吧）。读一本好书——不是入门级的书——尤其是像《JavaScript DOM高级程序设计》这样适合中高级读者的好书，读者的心态应该是与书背后的作者进行交流。在读它的过程中，跟着作者的思路去假设、去思考、去推断、去印证、去反问、去寻找答案，是之谓交流。我正是因为体验到与作者交流的愉悦，才想起来写这些文字。

事实上，老实说，我现在正抽一切可能的时间做《JavaScript DOM高级程序设计》的审校。书虽然已经出版了，但我自己深知，作为正式翻译的第5本书，我当时（2007年9～11月）的翻译水平还不够好——至少不如现在的状态；而且，对翻译技术书的认识也没有今天这么深入。现在，我已经看到第2章，也单独为它建立了勘误页面。虽然目前发现的错误很少，但却发现语言表达上犯了“的的不休”的毛病，也就是“的”字用得有点过度——这一点，请买第一次印刷的朋友们多多担待。不过，多余的“的”字，我在审校过程中都已经加了删除标记。在第二次印刷时，相信这个毛病就会得到全面、彻底纠正。

为此，我跟杨爽同学要了这本书的英文版，以便对照审校。

文前（致谢、前言、序、内容简介、目录、作者介绍）、正文、附录、封面封底文字，这些都可以作为开始翻译的起点。有没有人认真想过，从哪里下笔最合理、最有效呢？

其实，我的想法是先翻译目录。不过，这里所说的目录，并不限于每章的标题，而是指包含章标题在内的、1～3级，甚至4级标题——换句话说，不是Contents at a Glance，而是完整的Table of Contents。

我现在想到的原因主要有以下三点：

一、有助于了解全书内容结构

译者首先是读者。
读者最关心一本新书的目录，是因为通过目录可以对全书的组织结构和内容纲要一目了然。通过阅读和对照目录，能够时时处处确定自己正在阅读的内容在全书中所处的地位和份量。从而，可以加深对重点、关键内容的理解。

作为读者的译者，关心目录也理所当然。如果能够在翻译全书之前，先把目录翻译出来，放在手边（保存到另一个文件中），就可以像读者一样，对全书内容有一个较为全面、深入的了解。毕竟，标题都是每一章、每一节的灵魂所在呀！因此，通过翻译和查阅目录，对理解作者的原文、确立翻译的基调和提高译文准确性将会大有助益。

二、有助于术语和引用的统一

术语和引用的统一，是翻译技术书这种说明性文体的一项核心原则[注1]。

一本书的目录部分少则10来页，多的可以达到10页、20页，甚至更多。这么多页的目录虽然只是章标题及各级标题的简单汇总，但其中包含的信息，却极为重要。而且，目录中几乎肯定会包含一些常见的、甚至不常见的术语。通过翻译目录事先敲定这些术语的译法，对放心大胆地推敲译文和阐发作者思想会很有帮助。另外，翻译目录时附带确定的章节编号（如：2.1或5.6.3），也有助于在翻译过程中，准确、统一地在译文中定位和使用交叉引用。

三、有助于提高翻译的效率

技术书的翻译是一项强调效率的工作，这一点与文学作品的精雕细琢不同。

如上所述，通过翻译目录能够事先敲定一本书中部分关键术语的译法，这样就可以避免翻译中多次返工（查找替换）的困扰——当然，如果翻译目录时敲定的术语不准确，返工也不可避免。并且，还不止是术语，单说一个简单标题的译法，同一译者在不同时间，就可能会给出两种不同译法。比如：“调试某某程序”和“某某程序的调试”，很可能是基于完全相同的原文。因为这种情况导致返工最没有价值，但这又是翻译过程中经常遇到、不易避免的问题。而通过事先建立并维护一份目录，就可以降低甚至避免这种人为的、无价值的返工，节省宝贵时间。另外，翻译目录时附带确定的章节编号已经有了，届时，只需直接从现成的目录文件中复制，然后粘贴到译稿中即可。

由此可见，从翻译完整的目录着手翻译一本技术书，有诸多优点。根据经验，翻译一本书的目录，少则1～2小时，多则也不过一半天时间，能够获得那么多好处，还是很值得的。更何况，这些内容的翻译到底也省不掉。即使不安排在最初来翻译，在逐章翻译过程中，也还是要“个个歼灭”的——而且，由于化整为零、“歼灭”时间跨度过大，反而埋下了前后不一致的隐患。

——————
[注1]译者常常忽视除术语之外的需要统一表达的要素，如：交叉引用、图题表题、表格相关列、API式文档说明、代码注释以及标点符号等。