随性

这是我读的第一本中文编程书/译本，以下是我站在我个人的角度找出的一些觉得可以改进的地方，并且给出了我自己的一些建议。

首先，是译名混乱的问题。

通过SUS 所规范的官方一致性测试，且由OPEN GROUP（UNIX 商标的持有者）正式授权 （p. 1)

1996年，X/Open 与开放软件基金（OSF）合并，成立The Open Group……出于修订并加强POSIX 标准和SUS 规范的目的，IEEE、Open 集团以及ISO/IEC 联合技术委员会…… （p. 10）

短短十页，The Open Group 出现三处不同译名，译者随性改名是一回事，团队之间没有交流好，没有统一译名又是一回事。同样，书中Sun Microsystems 的翻译一直在SUN 微系统公司（p. 3）、SUN 公司（p. 3）和保留原文之间徘徊，i-node（p. 281）不时会被翻译为i 节点（p. 252），System V 也不时会被翻译为系统 V （前言 p. 3），真的好奇普通读者第一次见到这些名词会不会被绕到晕头转向。

相比其他理工学科那些可能有一百多年历史的中文术语，译名问题在计算机这个历史短、门槛低、变化大的学科最为常见。选择什么译名倒不至于说会影响读者理解，但确实是翻译实践中最容易解决的一个问题，只要统一信源，比如大家都以中文维基百科上写的名称为准，或是大家都保留原文（一劳永逸），这种问题就可以解决。也许有人会说系统V 也是常见译名，的确，我查了一下，1992年确实有本叫《UNIX系统V/386操作系统》的书，但当年北京友谊宾馆还把sauce 称为“少司”呢（《国际菜谱》，1987，p. 9），译者在翻译时不能光靠自己的知识储备，也要看一下近期的趋势，一来每人的知识储备不一样，一个团队对同一种概念就可能有好几种译名，容易造成混乱，二来如今提倡与国际接轨，不必事事改个中文名，比如macOS，iPhone，Solaris，就连当初的“红帽“系统如今都是直接称Red Hat 的多，何必多此一举徒增困扰呢。而且，就开头The Open Group 这个名字的翻译情况来看，这几位译者恐怕是查也没查过这个名字，连人家官网都不愿意看一下就想当然地给人家安了几个名字，严谨程度实在不敢恭维，仿佛一个考四级的考生，只想译完了事，毫无职业道德可言。

除了译名问题，还有原文提示的问题。一般而言，比较重要的概念、术语都应保留或提示其原文，而非仅是译者自以为难翻译的名称。在这一点上，我感觉本书就做得更是过于随性。在本书第二章，我们可以见到译文对一些表达做出了提示，比如会话首进程（session leader）、进程组组长（process group leader）和root（超级用户），有些则保留了原文，比如syslogd 和httpd，但还有一些重要的概念，比如中断机器指令（以及后面的“为了响应中断0x80”，p. 35），比如堆栈，比如信号，比如系统调用，是从头到尾都没有给出原文。我不知道别的读者怎么想，但就我看来，译者们纠结的心情简直可以用跃于纸上来形容：这些概念实在太难用中文表达了，唯有在后面用括弧添上些英文，但结果一碰到自己在别的书看到过的概念就想也不想就照搬了（就像上面的System V 和堆栈一样），或者一碰到别人都会保留英文的地方就想也不想地就保留下来了。这个问题和译名问题既相似又不同，相似的地方在于都会造成不必要的混乱，因为每个译者明显都是按照自己的知识储备来翻译这些概念（甚至只是硬翻），那么读者要读通这本书，不仅要有编程知识，还要有与译者相当的词汇储备，徒增学习负担；而不同的地方是，你没办法像处理System V 这种名字一样处理signal 这样的概念，不然可能出现整页纸都是英文的情况。其实，在个人经验上来讲，在某个概念首次出现时用中文（英文）的形式表达是有利于读者的，一方面不至于整本书都中英混杂，难以阅读，另一方面可以方便不熟悉这种译名的读者。

上面说那么多其实可以总结成一句行规，尽量不要给人家取中文名，第一次出现的概念给出英文以便对照，定好了的译法不要随便改。也许有人说译名只是小事，但就像一个程序也是由许许多多“问题不大“的算法拖慢的，忽视小问题就会导致整个译本质量的降低。其实给出原文不仅可以消除误解，减轻术语混乱带来的负担，最重要是可以帮助读者积累英文词汇，毕竟计算机不是一门可以用纯中文学习的学科，经常说读原著如何如何难，读文档如何如何难，搜索如何如何难，都是平时英文概念积累不够，书里书外两个世界。总之还是那句，感觉本书几名译者之间没有交流，大家都在根据自己的想法满头苦干，整个翻译过程缺乏计划，导致整本书都非常混乱，希望可以改进，令中译本越来越好，帮助更多的读者。

p.s.

本书译者称本书原书作者写作功底差，但没有具体指出哪里差（或者是我没看到也说不定），只是给出了一封邮件，主要是作者回信承认原文描述不够浅显，但私以为本书就存在非常浅显的问题，去谈论原作用词艰深或是作者的文笔尚且过早。

而且作者开篇已经讲明希望读者有一定编程基础，甚至对各种标准应有所了解，实在不能强求本本书都像APUE 那般清晰。

至于文笔和理解，只能说翻译本身是件非常艰难的事，我们要正视这一点，译者甚至要比作者更懂作品。海明威写的书本身也有很多拼写错误，但不影响他的巨作流传海外。对于非专业译者来说，如果真的想长期从事这份工作，先专注改正自己的小问题方为上策。积累相关知识，让自己能读懂原文，其实是翻译工作的前提。技术类书籍作者能写得浅显当然最好，但艰深本身不是错。如果作者不写，译者就抓瞎，译文是没有希望的，但这个是译者个人追求高低的问题，影响翻译质量的说到底是译者怎么处理那些每一页都能看到的平凡简单的词汇。同时，我也希望出版社能多找有心人，且是有能力的人来负责翻译，并优待翻译工作者，如此才能两方和气。

p.p.s

昨天写完这篇评论，心有不安，怕用词可能过激，”惹怒“一些觉得本书翻译质量没问题的读者，特来补充。

小弟曾从事翻译工作，学习过一些翻译理论，所指出的问题均是行业内最基本的要求，甚至只能说是任何正式写作的基本要求，比如术语前后要一致，名词不能想当然（尤其是各种名字，Facebook 甚至会要求你在提及Facebook 时大写首字母，链接），所提出的建议也是基于本人的实践经验。诚然，每人追求不同，个别读者本身可能对出版行业的期望不是很高，甚至觉得有得看就很好，所以反而可能会觉得是我在对本书吹毛求疵，但我指出的均是多加注意便可轻松提高翻译质量的写作问题，甚至只是态度问题。至于那些觉得有得看就不错的朋友，我想说，你这句话可以藏在心里，因为说出来没有一点价值，出版这些书不是施舍，不是做慈善，少一点抱怨不会让书变好，把问题反馈出来也不会让你没书看，只会让出版社知道读者的需求，以后花多点心思在校审上，价格可能会贵一些，质量却会好很多。如今计算机著作因为需要专业人士进行翻译，而因为酬劳问题愿意从事这项工作的专业人士不多，更多的只是想把名字印在书上，所以门槛已经算是很低，如果以一个基本写作要求作为标杆你都算太高的话，那你的想法对这个行业真是百害而无一利（说不定什么时候就出一套《从零入门Ios开发》系列丛书）。