从一个翻译 bug 谈起

有朋友很意外地谈到一个翻译 Bug,这本是很正常的一件事:每个参与的人都是自由软件爱好者,是用业余时间来点做事希望对其他人有用,每个人都不可能一点错误不犯。

有问题的翻译出自 Bash,这个问题第一次出现是在 4.1 版本,当时正好有一位新任维护人员接手。的确,可以改进的地方很多,bash 的翻译也确实存在一些琐碎的问题。

然而,经历过几次类似的事情之后,我有些话想对那些对自由软件翻译发表评论的批评者说。指出问题是好事,愿意指出问题的朋友才是好朋友,但是有问题批评时是否也应该注意点分寸?批评完了是不是得让被批评者知道?

翻译和编写代码都是软件开发过程中的组成部分。代码可以有几十、上百甚至上千个 bug,有人报告之后编码人员按照一定顺序修,开源社区中先修哪个后修哪个、修哪个不修哪个,很大程度上要取决于维护者的好恶。与之相对比的是,有一句翻译有点问题,就可能成为别人的笑柄、谈资,最后这些谈话的人都只是动动嘴而没有想过找翻译人员修正它。

我不禁想问,为什么代码可以有几十个 bug,而翻译却容不得一个失误?为什么代码的 bug 有人报告,而翻译的问题只能当作谈资?

有些人觉得翻译不是什么难事。如果只是翻译一句两句,的确不见得有多困难;然而不幸的是一个完整的桌面至少有几万条界面翻译,用户要翻译风格统一,要翻译准确,要翻译美观,要…… 哪位读者若不相信,想试一试,请和我联系,;-)

翻译人员不一定会写代码,这本不是翻译人的职责——同样,写代码的也不要求得会翻译。有人因此说翻译人员不会测试,看似给了一个挺恰当的理由,但实际上很牵强,甚至是有谬误的。单个的翻译人员,可能忽视测试就提交了翻译,这是工作的失职;而翻译人员能做的测试,也不是大部分职业程序员就能做的。

翻译决不是一个软件的附属品,翻译人员的工作也不比软件编写者低一等。如果你维护过一个有很多其他语言用户的软件,便能更容易体会到翻译对于一个软件的价值。翻译者常常是使用测试版软件的吃螃蟹的人,报告一部分 bug,还要为更广义的本地化、国际化做出思考和行动。

很希望将来发现了翻译问题的人都能站出来报告问题,而不是站出来发文聊天。类似的事情我遇见过多次,有我自己的过失也其他人工作的疏漏。目前自由软件的翻译急需大家的反馈:不管是错误,还是觉得哪里不舒服,选择一个翻译人员能听到的办法说,而且这显然比对着空气和不知处理办法的用户说有效得多 :-/

This work by Aron Xu is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported.