尽管gigix在序言里说“还负责全书的文字修润”,但是如果首次的翻译已经不堪入目,那么再加修润无疑是愈行愈远,毫无帮助;何况从某些章节的翻译来看,根本就是脱离了英文原文在那儿做盲目的所谓修润(如果有的话)。而技术书籍的根本我个人以为“忠实原文,行文流畅”是至少应具备的。
可惜,8个人参与翻译的这个中文版再次让人失望,尽管许多人对它的总体评价尚可。但是这么多人参与,无疑必会有鱼目混杂嫌疑,何况“国内J2EE技术圈里小有名气的人物”未必一定有过硬甚至基本的英文翻译水平。
在顺畅的阅读之余,拿起英文原版书来对照一番吧,以便对中文的质量心里有底。我们不相信权威,更不应相信经过“翻译”的权威。看看第9/10章的翻译和原文对比,相信你会对此作出自己的判断。我只对比了第9章部分中英文(有两到三页),但是漏译、误译数量相当可观,绝非所谓勘误所能解决。
(译者维护的勘误表)http://forum.javaeye.com/viewtopic.php?t=16269&postdays=0&postorder=asc&start=15&sid=2c8c875475c3436287ee8dd06ea38e89
鉴于此,我有理由怀疑Robbin负责的全部翻译(即9/10章)。
看来多人合作也要慎重啊。
(尽管我初学J2EE,并无太多这方面的基础知识和技术积累,但看到9章第二段里的transaction demarcation译成“声明式事务”时,无论如何也无法容忍。)
建议读过本书中文版或未开始读的朋友重读或直接阅读英文版9/10章。
其它章节的翻译有待进一步观察。
在讨论区里对第16章做了部分校对,也就五六页的样子,但是误译/待改进之处已数十计,没有心情再继续校对下去。这部分是 刘天北 负责翻译的。
让我们记住JavaEye吧……不知道责编们是干什么的,无语。
中文版还是要谨慎购买……
2. E-P86-L13
原文:Although they make sense only as components, we usually want to persist objects, not components.
原译:entity bean仅仅作为组件才有意义:但我们通常需要持久化的是对象,而不是组件。
试译:把它们(entity bean)看作组件才说得通,但是我们通常愿意坚称其为对象,而非组件。
你的试译压根就是乱译,不知道你有没有开发过j2ee应用。根本没有理解persist的意义,就只从字面上翻译。
还是尊重别人原译吧。
dlee的第5/12章就目前看,或许比较忠实原文,尚可一看,不过在看过的p81-87中,仍有不少比较严重的误译。举例如下:
1. E-P84-L2
原文:Microsoft drew on expert knowledge of J2EE
原译:...,微软从J2EE专家这里汲取了大量知识。...
试译:...,微软汲取了大量成熟的J2EE知识。...
2. E-P86-L13
原文:Although they make sense only as components, we usually want to persist objects, not components.
原译:entity bean仅仅作为组件才有意义:但我们通常需要持久化的是对象,而不是组件。
试译:把它们(entity bean)看作组件才说得通,但是我们通常愿意坚称其为对象,而非组件。
3. E-P87-L9 不可容忍!整段译错
原文:Interestingly, the only characteristic of a component that appears in the literature on component software that the practitioners didn’t cite was that components are likely to be sourced from third parties; this is one area in which component theory hasn’t been realized in practice.
原译:有趣的是,组件的另一个重要特征似乎从未在相关著作中出现过:组件可能是由第三方编写的。看起来,这是组件理论尚未认识到的一个实践领域。
试译:有趣的是,这些同事(注:上文提到作者对其同事作了一个调查,指的就是参与调查人员)唯一没有指出但在组件软件相关文献中出现过的一个特征是:组件可以是由第三方编写的。看来,这是组件理论在实践中尚未涉足(realized:实现,译成:认识,知道?似乎也可,作者在这儿有戏谑之意)的唯一一块地方了。