---

3.3.1 如何使用 Savannah 跟踪任务和错误

团队负责人必须确保对潜在的翻译进行审核，确保它们不包含明显的错误和令人困惑的表达，并且符合原文的精神和意图。然而，许多团队往往会遇到一个特定的问题：团队成员依赖负责人进行这些广泛的审查。在一定程度上，这没有问题，负责人应该始终在将翻译安装到存储库之前进行审查——但是依靠单个人来完成这些任务几乎是不可能的（特别是对于大型团队）。团队协调员往往无法及时进行此类审查，导致团队成员感到沮丧，并普遍减慢了翻译过程。

解决这个特定问题的一个方法是在更多人之间分配工作量。例如：成员 D 完成了 foo.html 的翻译，并将 foo.lang.po 上传到 Savannah 的翻译项目的存储库中，将相关任务标记为“准备测试”（当然，等效的做法是向团队的邮件列表发送带有附件翻译的消息，或类似的做法）。然后，成员 A、B 和 C（如果 C 当前很忙，则只有 A 和 B）独立地对其进行审查，并在错误跟踪器中发布评论/建议/错误。他们与 D 之间进行讨论，问题得到纠正，最后由负责人（可能是 A、B、C、D 中的一个）进行最终审查。当大多数问题已经在之前的修订中修复时，进行最终审查会更容易。最后，发布翻译。结果是翻译的质量更高（因为有更多人看过），并且整个负担不会完全落在负责人的肩上。您还可以建立一个内部正式规则：如果一个成员完成了一项翻译，他还必须审查另一篇（或两篇）。

一些翻译可能需要相当长的时间——典型的例子是复杂的文章或演讲稿。最好通过指示，或者更好的是——记录，某人正在处理这篇特定的文章，来避免重复工作。“任务”跟踪器适用于此目的。

在团队成员之间讨论最方便的命名方案和实践，并将约定或规则发布在团队的首页上是明智的。请注意，您可以在跟踪器中创建自定义字段，并且可以根据这些自定义值搜索已解决的错误。

因此，管理这些任务的一种可能的直接方法是

• 如果有人开始从事新的翻译工作，她会创建一个新任务，其“主题”指示文章，例如简单地写上“philosophy/bsd.html”，并将其分配给自己。
• 当翻译完成并准备好进行审查时，翻译人员将“状态”更改为“准备测试”。
• 其他成员对其进行审查，并打开与特定问题相关的错误。通常最好不要将两个不同的问题混在一起——这使得它们更难以讨论，并且难以按严重程度进行跟踪。有些是语法错误，有些是改变整个含义的根本错误，有些只是改进建议。如果项目管理员为每篇文章创建新的类别字段，例如“gnu/gnu-history.lang.html”，“philosophy/microsoft.lang.html”——这将启用诸如“显示所有针对此翻译报告的错误”之类的功能，这很有用。
• 一旦错误（或至少是重要错误）被修复，团队负责人就可以进行最终审查并将翻译安装到官方存储库中，将任务标记为“完成”。未解决的错误自然应该保持打开状态。

如果有令人信服的理由，团队可以选择使用外部资源和最终其他错误（或问题）跟踪系统来管理这些事情。无论您决定什么，请确保只能使用自由软件报告错误，并且提供该服务的软件是自由的。如果读者必须通过像 SourceForge 这样的非自由托管平台来报告关于 gnu.org 翻译的问题，这会给人留下非常不好的印象。

如果您使用某种工具（即错误跟踪系统）来管理翻译中的错误，最好利用 generic.lang.html 并在每个页面上宣传它。有关详细信息，请参见 generic.html。