突然体会到，iPad 放在 dock 上看，无比登对。 7 hours 48 minutes ago
应 Scott 之邀，负责翻译 GitHub 站点为中文版。700+ 词条，没有上下文，靠推猜去尝试翻译，所以一定会有地方看起来古怪或者不对，如果各位发现了，烦请及时告诉我，我去修正。当然，如果有更好的译法也请告诉我。期间 Henry 帮助 review 和修订了几条，谢谢 Henry。GitHub 目前提供可翻译的词条只是常见的大部分，所以看到有整句英文的不用奇怪。以后应该会陆续开放新的词条供译者翻译。
从我个人的角度来讲，中文版没什么太大意义。一般写代码用到 GitHub 的人，英文一定也没问题。但对于 GitHub 站点本身来讲，这次的全球语言本地化则是另一种意义，表明的是一种态度，一种亲和力。
终于，eventually，finally，《Perl 语言入门（第五版）》出版开卖了，至少在 china-pub 上。去年 11 月底就交的稿，等了一年，花开花落，瓜熟蒂落。虽然是老书再版，却也增加了许多新的内容，比如 Perl 5.10 许多有意思的特性。初学者快速上手的最佳选择。看完这本书，就该动手实践了，或者应该说，边看就该马上实践。
中间生小孩，加上积极性回落了一段时间，到现在终于把前三章翻译审校完成。其中一二两章是我翻译的，第三章是 DaNmarner 翻译的，我刚做完 review。目前 DaNmarner 正在翻译第四章，我接下来计划翻第五章。
原先我在自己的机器上架了 progit.chunzi.me ，方便查阅已经并入到主项目中的各语种翻译（中文），今天才发现一个月前官方博客更新，主站也放出了翻译进度。不过上面的也不是最新的，要看最新的可以直接到 github 项目页上去。
老实说，虽然 git 用了也快一年，但无非是些基本的操作。对于 rebase 什么的一直稀里糊涂，不敢用。所以想借此机会摸摸透。也希望能有更多的人参与到此项目，毕竟人多拾材火焰高。
本项目现在没有 deadline，反正是做一点少一点，愚公移山。但坚决不抛弃，不放弃，总归有一天可以做完的。最近看到一条说法，多动脑子消耗能量能够减肥，不管到底有多少，总归也是 more than nothing。
翻译一本书着实很累。每一次 commit 都累积了几个小时的劳动。还好有团队，相互鼓励和扶持，才能保证进度和质量。一次次地修订，读上一版本的翻译，修订或是增加新版的翻译，然后自己审校，再交叉审校，再通读审校，最后还要对别人的每次更新再复阅，数也数不清了。但即便如此，总还担心有漏网之鱼，或者将来有读者诟病这里那里的问题。
继续。还有 70 个 rev 需要 review 下。Thanks Joe! Thanks Hui! Thanks Qiang!
《Perl Testing：A Developer’s Notebook》一书的翻译即将告捷，其经过是痛苦的，但受益也颇丰。一直想在翻译过程中，结合实例来探讨相关的问题，以作分享和积累，苦于没有闲暇时间，所以一直没有动笔。
和 Joe Jiang 的合作非常愉快。我们各自跳跃章节来翻译，随后自审，然后互审。最后会就一些细节作探讨和修饰。这个过程起初是漫长而叫人抓狂的，不过到最后，当你看到一件精雕细琢的艺术品呈现在眼前的时候，就会觉得这是那么美好，所有的付出都是值得的。就好比素描，起初的寥寥数笔，渐而丰实，最后巨细俱现，这个过程很享受。
关于翻译，特别是技术读物，我觉得最重要的就是不能领会错作者的原意。翻译英文和直接读英文有着极大的差别。阅读的时候，可能只求大致理解。翻译的时候，就要考量句法结构，前后逻辑关系，仔细揣摩各个代词的指代。通常会发现，原先的粗略理解不够精准。这很重要，因为翻译的目的是传播知识，所以必须对所要传播的知识负责任。说起来容易，做起来却很难。有时候工作久了，难免会疲劳，影响判断力。这个可以通过在时间上分而治之来解决。如果累了，就停下来。如果自己都不太确定，宁肯留着不翻译，以后会过头来再斟酌。还有种情况，不可避免的，就是实实在在的理解错误。这种情况比较隐蔽，自己难以定位发现，所以需要别人的帮助。虽然并不能完全保证发现所有的问题，但起码会好很多。就像读者提供勘误反馈一样。
意思没说错是最基本的要求，接下来就要把文句按中文的语言习惯来翻译。外国人喜欢用被动句，我们喜欢用主动句。所以被动转主动是最常见的技巧。外国人喜欢用很多定语或定语从句来作修饰，一般很长，我们可以拆分为几个短句来说。英语也不乏中文成语一样言简意赅的表述，所以要让读者明白，或者用恰当的成语，或者用较长的短句表述清楚，甚至把原来的几个短句合为一个句子。外国人很喜欢用代词，这个很搞脑子。我猜想他们是说不清楚，所以一天到晚用代词来糊涂了事。但中文翻译过来也都对应使用代词，就会让人越看越糊涂，这违反第一原则。所以翻译的时候经常需要扩展，把指代的（有时候是隐含的）内容清晰的表述出来，或者是某一样东西，或者是某一种具体的情况。检验的标准就是，把这段译文给一个没有读过这本书的人，如果他明白了在讲些什么，就说明没有问题了。碰到实在很难翻译的，就只好结合语境和作者的意图，行文至此的情绪，采用相近的表述。
初步翻译，需要通读章节，对全局有所把握。然后逐句翻译，就要反复阅读原文，写成译句后，又要反复在达意和平滑之间寻求平衡点。完成整个章节的翻译后，还需要通读一遍译文，力求保证基本的通顺，修正别字，漏字，标点使用等。完成较大的某一章后，还需再次通读，有些前后需要连贯或者衔接的地方也要注意修改。接下来初次交叉审阅。看别人的译文的时候，一定要保持对一切的怀疑态度。参照原文阅读译文。发现有蹊跷的地方，力求尝试阅读原文后得出自己的理解判断，然后比较现有的译文，是否有所出入，继而思考究竟是哪一种理解出了问题。这通常会找出之前所提到的隐蔽的理解错误。这很重要，如果这次你为了偷懒或者赶时间，想当然地忽略可能存在问题的地方，那你还指望谁能在后续的审校中再花力气去作细致研究和推敲呢？没有机会了，在成书发布之前都不会有谁会修正它了。读者看到这样的内容后，只会对你其他的辛苦付出一概全盘否定，这个代价太大了，任何一个有责任心的翻译工作者都不应当这样草率行事。所以宁可慢慢来，也不能放过一个可疑之处。初次审校可能会作大幅度的修改。看过译文后再行浓缩或者调优的话，表述方式有可能会作许多修订。接下来，原译者还必须反过头来看哪些地方做了修订，修订是否合理。特别是对理解有出入的地方，如果是审校人的错误，可以探讨之后决断。如此之后基本成形。最后可交若干朋友大致通读，寻找他们所能发现的细小问题，略加修订。这才可以交付出版社。所以这样下来，大体上这本书是要反复看过好多次的。
这次的翻译大体耗时 2 月，期间或急或缓。就像谁也不能保证程序没有 bug 一样，我们也不能保证翻译没有一处错误。所能做的，就是尽可能减少 bug。而更多人的审校，就好比重复不同平台上对翻译质量的测试。如果你或者你的朋友对测试有所了解，并且愿意贡献一点时间和精力的话，我们诚挚地恳请您的帮助。正式交稿在 7 月 1 日，不过我们仍然保留不断修订的能力，因为后续还有很多工作要作，继而排版印刷。
谢谢 Joe 。谢谢支持我们的所有人。
终于，正式地，开始了这项翻译工作。《Perl Testing – A Developers Notebook》这本书虽然不算厚，也不算艰深，但要做好翻译并非易事。甚而有些诚惶诚恐。
花了一些时间，目前已经准备停当，可以全身心投入翻译工作了。项目的构架基本上是用 Subversion + Trac + Google Groups。在原始 docbook 格式基础上用 po 格式对照翻译。出于保密协议，所以这一切仅限于项目成员。希望最终的成书不要被世人斥为机器翻译，我的要求不高，至少大多数人说还行就行。
准备这些的时候，稍稍深入地了解了些 docbook 相关的知识，并摘录到：http://del.icio.us/chunzi/docbook 。这时候才发现 del.icio.us 如此好用，以前怎么没觉得呢？后知后觉。又看了些 po 格式的资料，发现 po 天生是用来帮助应用程序做国际化的，如果要翻译类似书籍或者文章之类讲究顺序的东西的时候，po 的编辑器就不那么好用了。比如说 gtranslater 和 poedit。它们都会孤立得看待每一个词条，完成翻译的条目会强制转移的别的位置，这让我很郁闷。所以最终还是用 gedit 直接编辑 po 文件，也没什么特别不方便的地方。
其实原来并不要求用 docbook 来做，而我希望能够表现的更加专业，所以一再要求提供 docbook 格式。如此，一切都变得那么井井有条，快速而优雅。除了转换到 pdf 格式还有些问题（暂时并不需要也不重要）。剩下要做的，就是推敲再推敲。
路漫漫其修远兮，吾将上下而求索。
这是严格意义上的测试驱动，这是一个里程碑。
虽然以前也写过一些用于测试的代码，大都仅以模拟使用的形式编写，类似那些 example code。仔细想想，我也写过正规的测试代码，不过那是在发布模块的时候照葫芦画瓢弄了几个。而这次，是真正的出于自己的需求，并在测试案例的帮助下修正未期遇到的 bug。与此同时的另一个原因是，如果我不用测试驱动开发，就只会落得一团糟、剪不断理还乱的境地。所以这次测试驱动是以一个救世主的身份来到了我的身边。
虽然很早之前就有这个概念，也知道测试驱动的重要性，但真正体会到它的魅力和震撼却只在今天。这多少缘于最近在看《Perl Testing – A Developer’s Notebook》一书这件事的影响。虽然今天的测试案例还只是仅限于 ok() 和 is()。
每写下一个测试案例，然后再写代码去完成或者修正它，最后看到结果中的一堆 ok 开头的测试结果，我的内心就充满了无比的信心。有时候是测试案例本身的问题，但更多是代码没有顾全的原因。当增补一条测试的时候，所作的修正可能会引发之前那些已经通过的测试重又失败。这正是测试的魅力。你永远可以不用摇摇摆摆兜圈子走路，你的身边始终有着盏盏明灯指引方向，告诉你当前的局势。你就可以坦然的镇定的从容的解决那些旁生出来的问题。当一切重新变成整齐划一的 ok 的时候，内心就会无比喜悦。当有新的 bug 被发现后，我所做得就是增加一个对应的测试案例，并使之通过，然后就可以骄傲的说，让暴风雨来得更猛烈些吧。
我觉得自己很酷～
今天算是收获和业绩比较丰硕的。不但完成了昨天开始的《Phalanx 项目》一文的翻译，在论坛答应 joe jiang 之后，立即着手审校他翻译的《Perl Mongers: 如何成功运作 PM 用户组》一文。审校中作了较大的修改，自己感觉还是可以的，并隐隐约约的感觉一些经验相要总结归纳出来，以便和其他人分享。翻译也是一门艺术啊。
对于 wiki.perlchina.org 上的文章管理作了一些整理。体验了 pair review 所带来的信心和驱动力，有点意思。只是拿了老板的钱作了公益事业，心里面有些过意不去。加班吧。日进一寸，愚公移山，总可以完成繁杂的事项的。
好了，休息一下。
