从一个翻译 bug 谈起

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

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

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

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

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

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

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

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

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

成为 Debian Maintainer 前要做的几件事

今天我收到了一封邮件,询问关于做 Debian Maintainer 的事情让我给他写几条建议。非常高兴看到越来越多的人参与到 Debian 社区之中,以下是我所写的一点东西,希望有用。

Debian Maintainer (DM)是有个别软件包上传权限的 Debian 开发人员,是成为正式 Debian Developer (DD)前的一个步骤。在开始前需要清楚,为 Debian 贡献点力量是很容易的事情,但要成为“官方”的人员则需要付出很多时间和努力。

1. 尽可能多地使用 Debian 完成日常工作。也就是说,成为开发者前,先做一个用户。

2. 阅读 Debian New Maintainer’s Guide 学习 Debian 打包的基本知识(英文版中文版)。这些知识能帮助你让不太复杂的软件包工作起来,但是与满足 Debian 标准之间还有相当大的距离。这个过程中可以独立地重新打包一个已经在仓库中的包,完成后和别人现有的工作进行对比,找出自己的不足。这个包一般不需要很复杂,初学时直接弄复杂的包很可能只会浪费很多精力。做包的过程中遇到任何问题都可以找有经验的人询问清楚,这对提高水平非常有益。

3. 寻找一个感兴趣的软件进行打包,WNPP (Work-needing and Prospective Packages)列表是一个不错的开始。打包前需要考虑:自己是否有足够的知识和能力来维护这个包?在可预见的一段日子里是否有充足的时间和精力来进行更新和修复 Bug?如果答案都是肯定的,那么就动手把它打包好,期间遇到问题则找人咨询指导。

4. 当经过反复检查和测试,觉得软件包已经比较完善时,寻找一位 Debian Developer 帮你检查和上传软件包,这位 DD 此时便是你的 sponsor。

当找到一位愿意帮忙的 DD 后,他会对你的软件包进行彻底的检查,指出(可能)存在的问题并请你修改。这时要做的就是参考他的意见修改软件包,并把结果再发给他,这是一个极好的学习机会。如此反复若干次后软件包最终会符合 Debian 的标准,之后 sponsor 便会将其上传到 Debian 仓库。需要说明的是,经由 sponsor 上传的软件包的维护者是打包人而非 sponsor,所以它的各种更新、任何 Bug 报告都是打包人的责任。在维护软件包上,普通维护人员与正式的 DD 间的差别仅在于能否直接上传,其他的完全相同。

这个步骤进行期间,需要多次阅读 Debian Policy Manual 并确保自己的软件包符合里面的全部要求。最好再读一下 Debian Developers Reference,里面介绍了很多 Policy Manual 中没有提到的细节和最佳经验。

如果打算申请 DM/DD,则应尽早开始维护软件包,因为申请 DM 需要经过一段时间的软件包维护作为评价的材料,以此证明你能够胜任。

5. 不是有软件包被上传到仓库就说明你已经符合了成为 DM 的要求。你必须通过一段时间的努力(更新软件、修复 Bug、回应用户请求),来使你的 sponsor 相信你已经有能力来处理好某个特定软件包,这样他们才会在接下来的申请流程中推荐你。

一些 sponsor 会在他们觉得合适时向你提议申请 DM,另外一些不会,作为新维护人员要在自己觉得差不多合适的情况下和 sponsor 进行沟通,听取他的意见看是否可以申请。

6. 申请 DM 前要让至少一位你 sponsor 之外的 DD 对你的 GPG 密钥进行数字签名,且密钥本身至少要 2048 RSA 或更强。签署密钥不需要对技能的考察,其目的是确认每个密钥的控制者确实是他本人,从而构建 Web of Trust,因而任何人都可以参与到密钥签名活动当中。签名时一般需要双方在现实生活中见面,互相检查身份证或护照确认无误后,交换事先打印好的 GPG key fingerprints 并在稍后进行签署、上传到公共密钥服务器。通常可以在一些较大型的开源软件活动前和时间/地点都方便的 DD 联系好,在聚会时举办一个密钥签名活动。另外,如果给你签名的只有你的 sponsor,则你的密钥仍不符合要求,因为 Debian 无法确信这份申请是否是你的 sponsor 伪造的。

接下来就是按照 Debian 的官方流程来进行申请。

经过一番辛苦成为 DM 之后,便可以考虑是否要申请 DD 以及可能的申请计划。申请 DD 的要求比 DM 更细致,涉及的方面也更多。DM 和 DD 都拥有或多或少的特权,如此多的要求是为了确保申请者能够正确把握手中的特权,为社区做积极的贡献。如果觉得这个过程好繁琐,那么就不要申请 DM,直接参与到维护过程中,其区别如前所述仅仅是能否直接上传而已。

附:Debian 项目里一些名词的含义

1. Maintainer: 泛指软件包维护人员,包括 Debian Developer (DD)、Debian Maintainers (DM) 和 Sponsored maintainers。

2. Debian Developer (DD): 又称 Debian Member,官方 Debian 开发人员,是 Debian 项目的正式成员。能直接上传到 Debian 的任意仓库,有大部分服务器的登陆帐号,有在全项目内选举、投票和提出议案的权利。

3. Debian Maintainer (DM): DM 是一部分能够直接上传某些特定软件包的开发人员,是打包人员通向正式 Debian Developer 的必经之路。

3. Sponsored maintainers: 很多开发人员没有申请 DM/DD,而是选择通过一位 DD 来协助上传软件包。他们对于自己的软件包和其他开发人员没有任何更多的区别,同时又不必去经历相对繁琐的申请流程。

4. Non-uploading DD: Debian 为迎接那些不参与打包,但是参与文档、翻译、网站和设施维护等工作的人进入 Debian 社区所设立的 DD 类型,与其他 DD 的区别是没有上传软件包的权限。(参考文档

5. Sponsor: 协助其他没有上传权限的开发人员,检查软件包并将符合要求的上传到官方仓库的 Debian Developer。

6. NM Process: New Maintainer Process,一位 Sponsored Maintainer 或 DM 申请成为正式的 DD 的过程,需要经过 ID Check, Process & Procedure 和 Task & Skills 等多项测试。不要将 NM Process 误认为是申请 DM 的流程,它是申请 DD 的。

7. Advocate: 一位现任的 Debian Developer 以个人名义向 Debian 项目正式推荐某人成为 Debian Maintainer 或 Debian Developer。

8. Debian New Maintainer: 又称 Applicant、Perspective Maintainer 等,是正在申请成为 DD 的人。不要与 DM 混淆,这是申请 DD 的人。

9. Application Manager (AM): NM Process 中申请人被确认有现任 DD 推荐后,会有一位专门的负责人来对他进行考核,这个人就是他的 AM。

10. WNPP: Work-Needing and Prospective Packages 的缩写,指需要有人接手或帮助的软件包。这个概念不是模糊的,而是有明确的定义的。

11. MIA: Missing In Action 的缩写,指某位 Maintainer 长时间不参与维护自己的软件包,同时别人也没能成功地与之取得联系。这样的 Maintainer 被称为 Zombie Maintainer 。如果他是 DD,那么他的 Debian 项目帐号会被锁定,一年内无回应则会删除。

12. Debian Project: Debian 项目是构建自由的通用操作系统(The Universal Operating System)而自发组织的,致力于满足各种各样的用户需求,并执着于追求其自身所信仰的“软件自由”。参阅 Debian Social Contract (Debian 社会契约),DFSG(Debian 自由软件指导方针) 和 Debian Constitution (Debian 宪章)。

申请成为 Debian 开发人员需要经历一些看似繁琐的过程,尤其是申请 Debian Developer 所需要经历的 NM Process,笔者认为来者难免会望而生畏,不胜其烦。如果你有这样的感觉,不妨看看这个幻灯片:Debian New Maintainer Process: History and Aims by bubbles, moray and daf.

Things to do before becoming a Debian Maintainer

Today I received a mail asking me to give him some advice on how to become a Debian Maintainer and Debian Developer, I am glad to hear more people getting interested on joining Debian, :-)

The 1st thing to keep in mind is that, involving Debian’s development is easy, but becoming something _official_ requires a lot of time and efforts, so just be patient, :)

Here are my advices:

  • 1. Become a regular user of Debian (use it to do your everyday work as much as possible, in other word you have to be a user before you are a developer).
  • 2. Learn to make Debian package by reading Debian New Maintainer’s Guide[1]. This step gives you some basic ideas and methods on how to package software for Debian, but it’s still a bit far from making your package fits the Debian standards. You can find an existing package to work on it independently and then compare your work with the official one so you can find if there is any thing you still don’t know yet. Please don’t make very complex package here because it may just cost you many time on figuring out problems. It’ll be good if you ask some skilled people to give their opinions on your work (and in fact you can ask at any time before, during and after the process).
  • 3. Find a software that you are interested in packaging it, and make sure you have enough knowledge/time to make and maintain it in the foreseeable future, if you can’t do either of the two you should find another one to work on. Then, package it and check for any problems you can find, never try to hide problems when you are stucked, what you need to is do is just asking others for advice and mentoring, :)
  • 4. When you believe your package is made to the best condition that you can do, find an official Debian Developer to check your package and to see whether it’s ready to become part of Debian release (he’s called a _sponsor_).

    If there is one would like to help, he would do a throughout check on your package and find problems (and land mines) as much as he can. He might reject your package and ask you for improvements, then don’t be shy and just do what he has advised (DDs always think it is a good time to train new maintainers) and send your result back. Finally he is satisfied and uploads you package to Debian archive.

    Try to get your first package uploaded as soon as possible if you’d like to achieve your aim at becoming DM/DD.

    You’ll have to read Debian Policy Manual[2] if you haven’t read it yet, and you may need to read it for several times while you are making your package. If you have enough time, it’ll be better if you read Debian Developers Reference[3] as well.

  • 5. It does not mean you can be a DM as your first (or even more) package being uploaded. Your sponsor must be convinced that you have the ability to manage upcoming updates and bug reports for some specific package and then he would be happy to advocate you. This could usually be achieved by several good uploads (means he is satisfied with your work and nothing is required to be changed) and some bug management (optional). You can talk to your sponsor about advocating you to be a DM when you see fit.
  • 6. It’s a requirement that your GPG key is signed by at least one Debian Developer and your key must be 2048R or stronger. If you don’t have, try to get one while you are processing the previous steps. Key signing does not need any skill-based judgment and you only need to find and meet some Debian Developers so they can check your identity.
  • So you are a DM after some time of hard work, then you could plan on becoming a DD now. Being a DD is much more complex than becoming a DM, since you’ll have many privileges and people have to make sure you have the ability to use it correctly. You’ll need to read through all Debian documents and read/ask again about the details then.

    [1]http://www.debian.org/doc/maint-guide/
    [2]http://www.debian.org/doc/debian-policy/
    [3]http://www.debian.org/doc/developers-reference/

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