使用版本控制來進行翻譯協作

acid-free發表於2012-07-10

以前翻譯書籍,喜歡單騎走天下。800多頁的書,自己一個人慢慢啃、慢慢譯。雖然對該書內容比較熟悉,遇到生僻的術語也可以先找英文資料吃透了概念再去參考已有的譯法仔細推敲,但其中有個問題,就是在表達流暢方面沒人跟我一起推敲。所以,理解成什麼樣子就成了什麼樣子。等待譯稿提交,這件事也就高高掛起,不再問津。

當然當時那麼做的主要原因是書太厚,內容也比較專,如果找另外一個人來一起協作的話,一是溝通成本比較高,二是要有個信得過的能一起完成翻譯的人。

後來我在某家公司工作時,在團隊裡學到的重要一點是,結對(pair)合作的形式能很快提高彼此的水平。比如在寫程式碼時,細節地方怎麼處理比較好一目瞭然;就某個地方的效能問題爭論不下時寫個benchmark程式直接去測試一下,孰優孰劣一下就水落石出了。這種協作方式的好處在於:溝通簡單、有效,還能迅速彌補彼此的短板。

所以拿到手頭的任務時,我決定拉朋友入夥兒,結對翻譯。這本書並不厚,所以在這次翻譯中做一次嘗試也未嘗不可。結對翻譯要解決的第一個問題是溝通問題。比如,某個術語怎麼翻譯,兩個人需要討論;或者某個術語A譯者決定這麼使用,那麼B譯者也要在出現的地方採用一致的譯法。這時候版本控制工具的作用就凸顯出來了。一檢視提交記錄,很快就能知道另外一個譯者最近在做什麼了;遇到什麼問題,就直接記在筆記裡,有空了再慢慢討論。兩個人都是從同一個地方取最新的公共檔案,看同一本書,所以有空時更新一下本地的倉庫,很快就能看到最近大家提交的問題,開始討論,而不用花很長的時間去介紹背景、理清上下文。

以前自己翻譯時,在本地建立一個git倉庫,所有譯稿直接提交,作用不算很大。大概基本作用就是版本控制了;但版本控制工具的作用不僅僅在於控制版本,還能提供很強的跟蹤功能,也就是上面提到的作用了。

現在,我們選用了一個免費的第三方git倉庫託管服務,bitbucket。下面大概說說建立倉庫的流程:

  • 在bitbucket上建立新倉庫。比如,我的使用者名稱是dinnywu,建立了load-translation。
  • 在本地建立程式碼倉庫,將bitbucket上的git倉庫加為遠端倉庫:
$ mkdir -p ~/load-translation
$ cd !$
$ git init
$ git remote add origin ssh://git@bitbucket.org/dinnywu/load-translation.git
  • 建立目錄結構:
$ tree -v ../load-translation/
../load-translation/
├── Errata.md
├── Issues.md
├── README.md
├── Terminology.md
├── ph-stuff
│   ├── 20100520_翻譯回稿模板.doc
│   ├── 20110315_譯者須知.doc
│   ├── 翻譯協議書-負載均衡實戰.doc
│   ├── 負載均衡實戰-第章.doc
│   └── 負載均衡實戰-試譯稿.doc
└── translation
    ├── 負載均衡實戰-關於作者.docx
    ├── 負載均衡實戰-關於技術審校者.docx
    ├── 負載均衡實戰-前言.doc
    ├── 負載均衡實戰-第1章.doc
    ├── 負載均衡實戰-第2章.doc
    ├── 負載均衡實戰-致serverlove的特別感謝.docx
    └── 負載均衡實戰-致謝.docx
  • 然後提交檔案結構:
$ git add README.md Terminology.md Errata.md Issues.md
$ git commit -m "First Commit. Add some markdown fiels as common knowledge base."
$ git push -u origin master

另外一個人想要獲取這些檔案,只要做一個git clone(初次)或git pull(後續)操作就可以了。其中各個檔案的作用如下:

  • Errata.md:儲存翻譯過程中發現的一些筆誤或概念性錯誤,收集起來最終一起反饋給原作者。
  • Issues.md:存放一些有待解決的問題,比如尚未想到合適譯法的術語、將原始碼放到圖靈社群。
  • REAME.md:用來存放公用內容,比如如何編輯Markdown檔案、檔名命名規則和中耕日期。
  • Terminology.md:用來存放書中出現的一些術語的譯法,供其他人蔘考。

這樣,另外一個人看一下提交log就知道我最近在做什麼。我們採用的是最小提交規則,就是隻要有任何新加內容,就順手提交上去。這樣,別人一看log,就知道我在做什麼了。例如:

$ git log -1
commit d40f4f54fb11488d486cea168ac9dbc3a1dd9ff2
Author: Dinny Wu 
Date:   Mon Jul 9 19:31:44 2012 +0800

    Add "That said" into Terminology.md

目前來說,我們覺得這個溝通的過程還是比較有效的。但由於圖靈要求最終提交的是word文件,所以我們提交的翻譯內容都是doc文件。Git沒有原生的Word文件比較功能。比如提交的markdown檔案,git是可以生成diff的:

$ git diff HEAD^
diff --git a/Terminology.md b/Terminology.md
index add07b1..5322eb1 100644
--- a/Terminology.md
+++ b/Terminology.md
@@ -9,6 +9,7 @@
 - Overprovision => 超量配置
 - Package(Javascirpt)=> 模組(在JavaScript中不可譯為包)
 - Sequence Number(TCP) => 序列碼(TCP)
+- That said, … => 即便如此,...
 - Web - 單獨出現時不翻譯;Web Page譯為Web頁面,Web Site譯為網站
 - What makes it tick => 它究竟是如何工作的
 - You'd be forgiven that … => … 情有可原

但提交的是Word檔案的話,就只能簡單地看出二進位制檔案不同:

$ git diff HEAD^^^ HEAD^^
diff --git a/translation/負載均衡實戰-第2章.doc b/translation/負載均衡實戰-第2章.doc
index 6a9305a..2d45e30 100644
Binary files a/translation/負載均衡實戰-第2章.doc and b/translation/負載均衡實戰-第2章.doc differ

這點上如果以後圖靈支援最終提交的譯稿採用Markdown或其他文字格式的文件就好了。

暫時就分享這些內容了,歡迎大家交流:)


作者:武海峰(ID:acid-free),開源軟體擁護者;關注Linux系統構建及部署、Ruby on Rails開發和移動應用開發。轉載請註明出處和作者。

相關文章