---

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。