翻译两本书

接下来真的是要很忙了。有两本 Perl 的书要翻译。一本是 Effective Perl Programming,2nd Edition

另一本是 Automating System Administration with Perl,2nd Edition

还是和 cnhacktnt,joejiang 一起协作。

翻译是体力活

翻译一本书着实很累。每一次 commit 都累积了几个小时的劳动。还好有团队,相互鼓励和扶持,才能保证进度和质量。一次次地修订,读上一版本的翻译,修订或是增加新版的翻译,然后自己审校,再交叉审校,再通读审校,最后还要对别人的每次更新再复阅,数也数不清了。但即便如此,总还担心有漏网之鱼,或者将来有读者诟病这里那里的问题。

继续。还有 70 个 rev 需要 review 下。Thanks Joe! Thanks Hui! Thanks Qiang!

Google Ads

翻译即将告捷

《Perl Testing:A Developer’s Notebook》一书的翻译即将告捷,其经过是痛苦的,但受益也颇丰。一直想在翻译过程中,结合实例来探讨相关的问题,以作分享和积累,苦于没有闲暇时间,所以一直没有动笔。

和 Joe Jiang 的合作非常愉快。我们各自跳跃章节来翻译,随后自审,然后互审。最后会就一些细节作探讨和修饰。这个过程起初是漫长而叫人抓狂的,不过到最后,当你看到一件精雕细琢的艺术品呈现在眼前的时候,就会觉得这是那么美好,所有的付出都是值得的。就好比素描,起初的寥寥数笔,渐而丰实,最后巨细俱现,这个过程很享受。

关于翻译,特别是技术读物,我觉得最重要的就是不能领会错作者的原意。翻译英文和直接读英文有着极大的差别。阅读的时候,可能只求大致理解。翻译的时候,就要考量句法结构,前后逻辑关系,仔细揣摩各个代词的指代。通常会发现,原先的粗略理解不够精准。这很重要,因为翻译的目的是传播知识,所以必须对所要传播的知识负责任。说起来容易,做起来却很难。有时候工作久了,难免会疲劳,影响判断力。这个可以通过在时间上分而治之来解决。如果累了,就停下来。如果自己都不太确定,宁肯留着不翻译,以后会过头来再斟酌。还有种情况,不可避免的,就是实实在在的理解错误。这种情况比较隐蔽,自己难以定位发现,所以需要别人的帮助。虽然并不能完全保证发现所有的问题,但起码会好很多。就像读者提供勘误反馈一样。

意思没说错是最基本的要求,接下来就要把文句按中文的语言习惯来翻译。外国人喜欢用被动句,我们喜欢用主动句。所以被动转主动是最常见的技巧。外国人喜欢用很多定语或定语从句来作修饰,一般很长,我们可以拆分为几个短句来说。英语也不乏中文成语一样言简意赅的表述,所以要让读者明白,或者用恰当的成语,或者用较长的短句表述清楚,甚至把原来的几个短句合为一个句子。外国人很喜欢用代词,这个很搞脑子。我猜想他们是说不清楚,所以一天到晚用代词来糊涂了事。但中文翻译过来也都对应使用代词,就会让人越看越糊涂,这违反第一原则。所以翻译的时候经常需要扩展,把指代的(有时候是隐含的)内容清晰的表述出来,或者是某一样东西,或者是某一种具体的情况。检验的标准就是,把这段译文给一个没有读过这本书的人,如果他明白了在讲些什么,就说明没有问题了。碰到实在很难翻译的,就只好结合语境和作者的意图,行文至此的情绪,采用相近的表述。

初步翻译,需要通读章节,对全局有所把握。然后逐句翻译,就要反复阅读原文,写成译句后,又要反复在达意和平滑之间寻求平衡点。完成整个章节的翻译后,还需要通读一遍译文,力求保证基本的通顺,修正别字,漏字,标点使用等。完成较大的某一章后,还需再次通读,有些前后需要连贯或者衔接的地方也要注意修改。接下来初次交叉审阅。看别人的译文的时候,一定要保持对一切的怀疑态度。参照原文阅读译文。发现有蹊跷的地方,力求尝试阅读原文后得出自己的理解判断,然后比较现有的译文,是否有所出入,继而思考究竟是哪一种理解出了问题。这通常会找出之前所提到的隐蔽的理解错误。这很重要,如果这次你为了偷懒或者赶时间,想当然地忽略可能存在问题的地方,那你还指望谁能在后续的审校中再花力气去作细致研究和推敲呢?没有机会了,在成书发布之前都不会有谁会修正它了。读者看到这样的内容后,只会对你其他的辛苦付出一概全盘否定,这个代价太大了,任何一个有责任心的翻译工作者都不应当这样草率行事。所以宁可慢慢来,也不能放过一个可疑之处。初次审校可能会作大幅度的修改。看过译文后再行浓缩或者调优的话,表述方式有可能会作许多修订。接下来,原译者还必须反过头来看哪些地方做了修订,修订是否合理。特别是对理解有出入的地方,如果是审校人的错误,可以探讨之后决断。如此之后基本成形。最后可交若干朋友大致通读,寻找他们所能发现的细小问题,略加修订。这才可以交付出版社。所以这样下来,大体上这本书是要反复看过好多次的。

这次的翻译大体耗时 2 月,期间或急或缓。就像谁也不能保证程序没有 bug 一样,我们也不能保证翻译没有一处错误。所能做的,就是尽可能减少 bug。而更多人的审校,就好比重复不同平台上对翻译质量的测试。如果你或者你的朋友对测试有所了解,并且愿意贡献一点时间和精力的话,我们诚挚地恳请您的帮助。正式交稿在 7 月 1 日,不过我们仍然保留不断修订的能力,因为后续还有很多工作要作,继而排版印刷。

谢谢 Joe 。谢谢支持我们的所有人。

docbook2odf

Joejiang 告诉我可以用 docbook2odf 将 docbook 格式的文件转为 OpenOffice 的 odf 格式。不过默认输出的格式不够漂亮。我想应该可以优化的,先不着急,以后再看。这里是安装方式:

wget http://open.comsultia.com/docbook2odf/dwn/docbook2odf_0.211.deb
sudo gdebi docbook2odf_0.211.deb

与神同在 – screen

2005 年 PerlChina 上海聚会的时候,Joe Jiang 就兴致勃勃地向我们就介绍说 screen 如何奇妙。只可惜当时的我木呐有余,就当是看变戏法一样,过后就没放心上。许久以来,这多少也是我心中未决的事情之一。既然 《BSD HACKS》也提到了这个命令,不如像模像样的学学用用看吧。我买的是中文版的书,印刷还不错,谬误却不少。此乃题外话。

ssh 远程连接到服务器,当你正在编辑一个文件调试错误的时候,公司的破网再次断线,你一定会抓狂。网通了,再连上去,重新 cd 重新 vi 。或者,你正在服务器上运行一个漫长的测试,而下班时间到了,是中断现在的进度,回家从新开始呢还是继续加班? screen 就是你的救星。

screen 想象成服务器上的一个无形的 windows 窗口。在你登录到服务器上之后,打开这个窗口,然后在里面干活吧。在你要暂时离开或者意外断线,就好比暂时最小化了这个窗口。在你重新登录到服务器上的时候,你再最大化这个窗口,继续做事。就这么简单。

下面的示例都在远程的服务器上运行,当然你也可以在本地的 Ubuntu Desktop 上测试。这个无所谓。

开一个终端,输入:

$ screen -S chunzi

-S 参数指定一个名字,以后我们可以通过这个名字再打开这个虚拟窗口。

貌似 clear 了一下,然后还是在 shell 里面。实质上,我们这个时候已经在 screen 里面了。screen 有很多命令,要键入这些命令,都需要先键入 CTRL+a。我们可以在里面先 ls 一下,然后 CTRL+a, d 离开虚拟窗口。d 就是 detach。你会看到又回到了之前的 shell ,输出的那一行告诉你暂时离开了 screen。

$ screen -S chu
[detached]

窗口到哪里去了?用 -ls 参数,也可以用 -list

$ screen -ls
There are screens on:
        9309.chunzi        (Detached)
1 Sockets in /var/run/screen/S-chunzi.

我是个好奇的人,到 /var/run/screen/S-chunzi 下面一看:

$ ls -l /var/run/screen/S-chunzi
prw------- 1 chunzi chunzi 0 2007-02-16 16:52 9309.chunzi

看到开头的 p 了吗?嘿嘿。

现在如果重新进入 screen,可以:

$ screen -r chunzi

-r 是 reattach 的意思。自然的,我们看到了先前在 chunzi 那个虚拟窗口下的 shell 内容,原先操作的记录都还在。

假如你没有 detach 出来,就到同事的位子上,要给他看你刚才做的事情,可以登录服务器之后,用

$ screen -rd chunzi

来断开之前你自己座位上的那个。d 还是 detach 的意思,-rd 就是说,我要接管。如果回到座位,你会看到:

$ screen -r chunzi
[remote detached]

当然 screen 用起来不止于此,你可以在 screen 里面开几个不同的终端窗口。比如 CTRL+a, c 就是 Create 一个新窗口。CTRL+a, x 就可以锁定你这个 session,必须要键入密码才能继续。

有趣的是,当一处用 x 命令锁定的时候,你是可以用 -r 没有 d 的形式连到相同的虚拟窗口中。此时你再解锁,无论你在哪一个窗口操作,都可以在另一个窗口中观看操作的过程!这样,你和你的同事可以一起做一件事情,XP 结对开发从此可以让两个人天各一方!

有了 screen 你就不再担心什么,随时随地都可以继续停留在虚无中的桌面。就好像神在替我们保管一样。现在我才明白 Joe 以前为什么那么兴奋地要于我们分享,只要家里的机器开着,他在任何仅有 putty 的地方,都可以继续写 blog,看书,上 irc 聊天,随时随地,无所限制。典型的 hack 作风。

script 和 scriptreplay

这是两个命令。script 好比是摄影机,它帮你录下在 shell 里操作的全过程。scriptreplay 就好比是录像机,把录下来的东西回放给你看。Joe 用它来帮助教学,这样就不必每次上课的时候重复操作演示。这里是 joe 的演示

$ script
Script started, file is typescript

script 开始运行,并把操作记录保存到默认的日志文件 typescript 中。然后随便你做些什么,比如说 ls 之类的,然后 Ctrl+D 或者输入 exit 退出:

$ exit
Script done, file is typescript

现在你可以 more typescript 一下,其中可以看到你一系列操作的痕迹。包括退格键之类的。

单是如此还不能用 scriptreplay 播放,因为每个操作没有对应的时间索引信息。所以这次试试看:

$ script -t 2> time.log
Script started, file is typescript

-t 的意思是把时间点数据往 STDERR 输出,当然我们不希望这些时间数据混杂在我们稍后的操作中,所以用 2 > time.log 重定向到 time.log 文件中。然后试着做些操作,最后退出。这时候就可以回放了,如下,scriptreplay 的第一个参数是时间索引文件,然后才是 script 的日志文件:

$ scriptreplay time.log typescript

看到了什么?如果你想 2x 的速度回放,可以

$ scriptreplay time.log typescript 2

试试看把 2 改为 0.5 ?

谢谢 joe 分享了这两个奇妙的工具。除了教学中可以用之外,我想诸如报告 bug ,协作开发,或者记录 cron 作业或者其他 shell 脚本的操作过程等方面也都可以用。比起用 flash 录制,它更轻便,而且保存了 native 的字符编码,便于调试分析。绝对 Coool。

讲课

因为公司业务的需要,我给另一位同事讲授 Perl 语言,并安排他从事基于 Catalyst 的 web 软件项目的开发。

这是一位年轻的同事,之前仅接触过 asp,各方面的基础都不是很好,一头撞上来要开始学习“晦涩”的 Perl 确实挺有困难的。而我,总希望将所有知道的东西都按照来龙去脉给于介绍或者说明,首先是使他知其然,知其所以然,其次是希望籍此帮助深化记忆。今天整整花了一个下午,大约六个小时,讲了一些基础,以及相关联的内容。讲到口干舌燥,大口喘气。之前一次 PerlChina 上海小聚,为朋友们介绍 Catalyst 的时候也是,从头到尾,事无巨细的一一阐述,足足说了一个多小时。感觉奇累。想想做老师的讲课真不容易,讲课完全是体力劳动加上脑力劳动。

另外,在讲的过程中,我还在想,其实讲解教授,说了一大堆,未必就有一大堆的效果。有时候还应该留一些不讲。这叫有的放矢。所以读大学的时候,某些章节看上去很简单,老师却会花上大篇幅的来回讲解巩固,留下下一次再来分解。所以看来,自己会和教别人会完全是两码事,当然前者是后者的基础。教授更加侧重于知识的灌输技巧和方法。

本来看到 joe 换了单位去做培训工作,还乱想着自己以后也可以去做这方面的工作,现在看来还有很多路要走。

文章翻译后记

今天算是收获和业绩比较丰硕的。不但完成了昨天开始的《Phalanx 项目》一文的翻译,在论坛答应 joe jiang 之后,立即着手审校他翻译的《Perl Mongers: 如何成功运作 PM 用户组》一文。审校中作了较大的修改,自己感觉还是可以的,并隐隐约约的感觉一些经验相要总结归纳出来,以便和其他人分享。翻译也是一门艺术啊。

对于 wiki.perlchina.org 上的文章管理作了一些整理。体验了 pair review 所带来的信心和驱动力,有点意思。只是拿了老板的钱作了公益事业,心里面有些过意不去。加班吧。日进一寸,愚公移山,总可以完成繁杂的事项的。

好了,休息一下。