有朋友很意外地谈到一个翻译 Bug，这本是很正常的一件事：每个参与的人都是自由软件爱好者，是用业余时间来点做事希望对其他人有用，每个人都不可能一点错误不犯。
有问题的翻译出自 Bash，这个问题第一次出现是在 4.1 版本，当时正好有一位新任维护人员接手。的确，可以改进的地方很多，bash 的翻译也确实存在一些琐碎的问题。
然而，经历过几次类似的事情之后，我有些话想对那些对自由软件翻译发表评论的批评者说。指出问题是好事，愿意指出问题的朋友才是好朋友，但是有问题批评时是否也应该注意点分寸？批评完了是不是得让被批评者知道？
翻译和编写代码都是软件开发过程中的组成部分。代码可以有几十、上百甚至上千个 bug，有人报告之后编码人员按照一定顺序修，开源社区中先修哪个后修哪个、修哪个不修哪个，很大程度上要取决于维护者的好恶。与之相对比的是，有一句翻译有点问题，就可能成为别人的笑柄、谈资，最后这些谈话的人都只是动动嘴而没有想过找翻译人员修正它。
我不禁想问，为什么代码可以有几十个 bug，而翻译却容不得一个失误？为什么代码的 bug 有人报告，而翻译的问题只能当作谈资？
有些人觉得翻译不是什么难事。如果只是翻译一句两句，的确不见得有多困难；然而不幸的是一个完整的桌面至少有几万条界面翻译，用户要翻译风格统一，要翻译准确，要翻译美观，要…… 哪位读者若不相信，想试一试，请和我联系，;-)
翻译人员不一定会写代码，这本不是翻译人的职责——同样，写代码的也不要求得会翻译。有人因此说翻译人员不会测试，看似给了一个挺恰当的理由，但实际上很牵强，甚至是有谬误的。单个的翻译人员，可能忽视测试就提交了翻译，这是工作的失职；而翻译人员能做的测试，也不是大部分职业程序员就能做的。
翻译决不是一个软件的附属品，翻译人员的工作也不比软件编写者低一等。如果你维护过一个有很多其他语言用户的软件，便能更容易体会到翻译对于一个软件的价值。翻译者常常是使用测试版软件的吃螃蟹的人，报告一部分 bug，还要为更广义的本地化、国际化做出思考和行动。
很希望将来发现了翻译问题的人都能站出来报告问题，而不是站出来发文聊天。类似的事情我遇见过多次，有我自己的过失也其他人工作的疏漏。目前自由软件的翻译急需大家的反馈：不管是错误，还是觉得哪里不舒服，选择一个翻译人员能听到的办法说，而且这显然比对着空气和不知处理办法的用户说有效得多 :-/