為什麼字幕組行業不藉助類似 GitHub 的平台眾包協作？

12-16

當前的缺陷：

字幕組的工作存在瑕疵（錯別字等）時，非組內人士難以 pull request 正確的

字幕組的工作存在瑕疵（錯別字等）或不同意見（翻譯方法）時，其他人難以 fork 並編輯出獨立的另一個分支

在不同的番組，各個字幕組難以進行不同的合作模式

為什麼不這樣的可能原因：

字幕組行業的歷史決定了開源精神在這裡水土不服

字幕組為了品牌不願過多允許他人介入

已經形成壟斷的強勢字幕組集團不願新秀以傳統字幕組之外的發展方式登堂入室

缺少像 Git 一樣成熟的字幕組內協作工具，所以缺少像 GitHub 一樣成熟的跨字幕組協作工具

望業內人士與橫跨字幕組與計算機兩個行業的人士不吝賜教。

（註：這裡的並不是說為什麼不把工程文件放在 GitHub 上，而是為什麼沒有一個操作邏輯與 GitHub 類似的平台給字幕組進行眾包協作。）

再次更新：

我沒聽說字幕眾包的。只有字幕組合作的，沒有眾包的。當然有前輩也曾經弄過10+個字幕組翻譯一集新番的壯舉，那只是一集，不說多，一季就得瘋啊。複雜度是指數上升啊。

翻譯眾包的是Galgame和一些文檔、課程什麼的。因為主要矛盾不是質量差，而是人手少。眾包有且僅有這個優勢。

同一個東西，5個特別靠譜的人全部流程做下來（從片源到發布全包），可能比30人的團隊還快。這不僅僅是項目管理軟體的問題了。

更新：

按理說，Git是適合協作的。可以內部弄，也方便改錯。但是沒聽過眾包的先例，眾包的先例基本上都死了。

一些專業CAT軟體有一點Git的影子。但是我們不確定是不是適合字幕組。

你說的想法的一個實現是"路人甲翻譯系統".用於遊戲翻譯。但是，這個系統的邏輯難度比字幕少了很多。

因為一個字幕涉及到時軸、翻譯、聽打這3個內容，每個都會有初步填充和後期校對的狀態，後期涉及到特效等內容，還需要避免衝突，這個系統的確需要考量。

看起來很簡單，但如果要解決實際問題，可能需要開發專業軟體。這個現在我真的沒有看到。

同時我們也不確定自己能不能攢出一個系統來。涉及的東西實在不少。

--------------------

謝邀。

的確找對人了。。。ACI字幕組CDC，UToronto 1st yr CS。

這個問題我們拿出來研究過。
我們的確認為，Git和字幕組相當天造地設。

但是：

從技術上來說：

Git方面：
1.Github需要付費才能開Private Repo。（為什麼需要private，看下面解釋）
2.別忘了牆的存在。
我們敢說我們的內部私密打洞你懂的服務不亞於商業平台，但總有我們照顧不到的人。
3.我們自己可以搭建Git伺服器，沒大關係。
但是，我們很難教會所有組員使用Git。
即使是學CS的，我也不敢說我弄懂了Git是怎麼一回事。
連我們自己都不大明白，又怎麼往下推廣？
有時問題不在於技術是不是成熟，而是自己能不能解決日常問題。
如果真出問題了，誰能解決？如果不能按時解決，又如何？
這都是上新技術前需要考慮的問題。
4.有多少普通人會Git？知道如何發pull request？如果一定要用Git完成，對一般人來說，技術難度太大。
5.如果涉及到合作，那麼所有問題都會被無限放大。教會10個人用Git和教會60人用Git的感覺是不同的，而且他們的水平都需要「合格」。如果水平不夠，難道不做了么？

從操作上來說：
1.不是所有人都有同等話語權的。信息的流通不是完全及時的。
一旦字幕文件變成了視頻中的硬字幕並發布，想撤回，極難；想修改，不可能。
即使是字幕組，作為內容製造者，也不能保證大家看到的是最新的版本。就像巨硬不能保證所有電腦都打了最新的補丁。
2.Pull Request來了，誰有權利merge？還是字幕組自己啊。那麼，這個和在社區等報錯有什麼區別呢？
3.我們自己一向喜歡嘗試新鮮事物。我們研究了各種黑科技。
只要不發生衝突，那麼大家都是共生關係。
我們的黑科技不會自己留著，會和其他組織共享。也沒發現誰找我們麻煩啊。
4.的確，我還沒看到讓我眼前一亮的協作工具。鬧得我們都在研究是不是自己寫一個出來了。
現有的很多辦法都多多少少水土不服。
從專業的CAT軟體到流行的開源OA我們都試過了，沒看到效果特別好的。
5.我知道有組織在用SVN。但是他們都有專業CS背景。
好，但是和我們的流程還是差一些，不能照搬。

從其他方面來說：
1.我不完全確定整個業界如何，但是我們一直在貫徹開源。我們的論壇（ACI中文字幕組社區）的二次開發早已開源（ACICFG/youBBS-ACICFG · GitHub）。我們的作品按照修改的CC-BY-NC-ND 4.0 Int"L協議授權（關於ACI中文字幕組社區）。整個業界來說，即使不開源，大家也會多多少少的互通有無，從各個方面而言。我們的老組員幾乎都有多年CS背景，我們的確在身體力行開源精神。
2.字幕組是品牌，但是，誰都不是全知全能。
發展空間不小，蛋糕遠沒有切完。還不至於必須壓制其他組織才能發展。
而且，很多大的組織在動手幫助小的組織。
3.如果從技術上來說，那麼越先進越好。如果一個技術可以解放生產力，為什麼不用呢？這點對任何組織都是一樣的。
4.如果大家都按照規矩做事，就沒問題了。但是總有不守規矩的。
CCAV可以公然把我們的東西拿走改幾個字就說是自己的。看好，我們是CC-BY-NC-ND協議。
而且沒什麼辦法制裁不按規矩做事的人。最終造成，字幕是機密，不能公開。

所以：

我們還在研究如何解決這個問題。從技術上看看有沒有突破的辦法。

歡迎討論這個問題。無論是在這裡，還是去論壇（ACI中文字幕組社區），還是郵件(cdc[at]chinesesaci.com)，都歡迎。

--------------
@Lasper Rado 說的在理。翻譯真的不是會兩種語言就可以做的。難聽的說，如果水平不過關，翻出的東西都不一定有Google Translate Toolkit準確（順便說下，這東西翻譯科技類文本是神器）。

不同的人翻譯的東西真的是雲泥之別，所以我們現在在審核入組時，如果職位涉及文本，會要求看具體翻譯例子。即使是我們，也在審查時砍了50%的人下去。

即使是開源軟體，也不是你想添一筆就添一筆進去，也需要發pull request，對方審查同意後才能merge。
幸好編程上大家都清楚自己水平程度。
但是，聽打和翻譯（特別是翻譯）上，沒有做過的人會極高的高估自己的能力。別不信，找一點文本，不看原翻譯，自己敲出來，然後和成熟的翻譯對照一下。眼見為實。

最後替所有組織說一句：
一日游的，想牟利的，不吃苦的，心懷不軌的，免開尊口。It "s not child"s play.

組內協作很簡單而且已經做到了，組間協作和眾包很難做到。時間軸、特效什麼的用這個平台倒是湊合，但是翻譯遭遇了這個平台，簡直是災難。

首先Github的用戶群/受眾是程序員，協作的內容是代碼(我簡單粗暴的概括一下，大家領會一下主旨就好)。特點是門檻相對高，需要對編程有一定的了解，同時不懂編程的人(比如我)會覺得很高深不敢隨便改。

而字幕組(共享平台)的用戶群/受眾可以是任何人，共享的內容是字幕，說白了就是一句句的大白話，中國人都看得懂。稍微會一點英語，哪怕只看懂了這句話里一個單詞的人都覺得I can I up，誰都覺得自己對，誰都想修改，而且誰都可以改，最後很可能被改的面目全非。

再說產品。代碼的評價標準量化程度較高，bug少演算法執行效率高數據結構精鍊就可以算是好代碼。而且bug的完善很有必要，莫名死循環和溢出這種漏洞都有較大的不良影響。
而字幕根本沒有量化標準，基本只有「沒翻錯吧」「翻的真牛逼」「真傻逼這句我都會翻」這三種評價，優劣難區分，而且沒有最佳譯法，你覺得這樣翻好，我覺得那樣翻好，兩種翻法都好，除了主觀感覺外沒有任何辦法評價。
即使採用盡量簡化的標準，如「最準確」或是「最簡潔」，也很難得到「最準確/簡潔的翻譯就是最佳翻譯」的效果，因為準確和簡潔是矛盾的，難以兼顧，只有極少數句子可以用抖機靈的方式得到既準確又簡潔的「最佳翻譯」。參考朱生豪與梁實秋兩人翻譯的莎士比亞作品，也可參考YYeTs的《空王冠》，簡潔的極致。
另外字幕完善的空間很有限(只限自家的字幕，他家略去)，完善的工作90%也就是改改錯別字和格式錯誤。這兩種bug的影響極小，最嚴重也只是刺激強迫症們，基本不影響正常觀看。如非腦殘粉/重度強迫症，字幕製作人員在這項上沒有必要投入過多精力。組內也有規定，5處以上重大錯誤(主要是理解錯誤，不包含錯別字、格式錯誤)再重新校對+洗版，否則不予考慮。

字幕組的水平是有差異的，而且由於翻譯這東西主觀色彩過強，即使組間協作也難免發生個人喜好壓倒準確度(aka瞎拽詞)的事情。還是那句話，代碼修改後可以相對容易的判斷效率高低，大白話修改之後沒法判斷。
===============上面幾段里正能量太多我不舒服===============
根本原因在於，翻譯這事不簡單，但是大家都覺得簡單，還都想摻和。也就是都覺得門檻低，其實門檻高得你踩把椅子都邁不過去。

眾包這件事我們當初也是考慮過的，把一些老電影/美劇字幕分發給愛好者，每人兩三分鐘，然後由組內人員負責校對合併。但是看了一組數據之後立馬打消了這個念頭。
這組數據是是12、13兩年字幕組測試的通過率。測試是先郵件初審，過這步之後進測試群考核，通過後算正式進組。
測試群考核的通過率(也就是成功進組的人數÷通過郵件初審的人數)是17.94%。郵件初審的通過率不到20%(郵件數量太多統計不便，只是大概比例)。
兩者相乘，總的通過率只有3.6%左右。

而且，這不是「普遍通過率」，發郵件申請的有小半是海外(多是英美澳加)黨，甚至有不少英語專業的，概括一下就是覺得自己英語還算不錯的人。所以普遍通過率只能更低。
另外，大家都覺得做字幕這東西很拽，誰都想翻幾句哪怕是改幾句體驗一下，混個參與度(我收到過好多求字幕組一日游的私信)。所以如果把字幕眾包給廣大的愛好者們，最後只有一個結果：累死校對。

哪怕眾包設了門檻(僅字幕組成員可參與)也會慘不忍睹。成立字幕組的門檻其實很低的，不信請看雨後春筍般的貼吧字幕組，請看各種影迷自發字幕組，甚至還有MV字幕組(待考證？)——插播一條，有一天我在搜水果姐的MV，搜到了Wide Awake的中字MV，字幕真是把我雷得外焦里嫩，插播完畢——但是質量參差不齊。不客氣地說現在90%的字幕組連英文都看不明白，理解錯誤滿地跑，俚語俗語不知道，句子間的邏輯關係沒理解透就胡亂翻譯，這種情況下能拿出好產品來嗎？不是你愛TA就可以和TA在一起的(我也不知道為什麼寫這句大家忽略吧)。

針對這種情況可以設置「僅認證字幕組的成員可參與」？可是認證的程序沒法處理，沒有「權威機構」，沒有客觀標準。搞不好還要變成虛設——通過認證的只有大組，然後大組們自己玩自己的了。

以上幾段負能量總結起來就是：字幕組尚不成熟，製作字幕的流程以及組內製度尚處在急需完善的階段；字幕的質量評判標準難以量化，門檻難以確定；從業人員水平參差不齊；大家對做字幕這件事缺少理解想啥是啥。
============還是說點跟問題相關的吧===========
針對題主提的幾點：
1.字幕組的工作存在瑕疵（錯別字等）時，非組內人士難以 pull request 正確的
由於在主站發布字幕而不在射手發，任何人都可以去字幕下邊留言提意見，而且每個字幕的壓縮包里都有提意見的郵箱debug (at)http://xxx.com。錯別字什麼的就不要提了，大家都看的出來，實在太多(比如超過了20個)可以重製，少量錯別字不影響觀看，沒有必要投入精力。

2.字幕組的工作存在瑕疵（錯別字等）或不同意見（翻譯方法）時，其他人難以 fork 並編輯出獨立的另一個分支
編輯字幕實在簡單的不能再簡單。。字幕看不下去就下載回來，自己拿記事本修改就行。

3.在不同的番組，各個字幕組難以進行不同的合作模式
是的，各組的人員分工以及制度存在差異，翻譯理念和水平也都存在差異，組間合作的路很長。

4.字幕組行業的歷史決定了開源精神在這裡水土不服
此條略

5.字幕組為了品牌不願過多允許他人介入
善意地說一句，為了質量我們也不願多允許他人介入的

6.已經形成壟斷的強勢字幕組集團不願新秀以傳統字幕組之外的發展方式登堂入室
別亂代表別人，組裡那麼多人管理起來尚且有點吃力，誰有功夫管其他字幕組？

7.缺少像 Git 一樣成熟的字幕組內協作工具，所以缺少像 GitHub 一樣成熟的跨字幕組協作工具
組內協作工具是有的，大家都在用，新版還在內測.現在已經有了一套很實用的組內協作程序(別的組有沒有我不知道喲)，從發片到最後出成品都有嚴格的工序和制度，簡單易上手，容錯率很高。
況且，字幕其實是很簡單的代碼+文本，很多情況下根本不需要用工具，進行各步驟的人員溝通好，做好統一的標記/注釋就可以順利協作了。
跨組協作很難實現。時間軸和後期沒什麼協作的意義，因為結果很單一，並且容易評價(同步情況，特效與視頻的融合程度)，翻譯需要協作可結果又很難評價。

在當前很多字幕組成員都沒看明白英文對話(尤其是長句，或是high-context的短句)的大環境下，各組的這種實力水平是支撐不起一個高效的組間協作系統的，稍安勿躁。

自己專欄的廣告：知乎專欄

GitHub 的概念和工作流程邏輯對程序員以外的人來說並不容易掌握。我自己也用 GitHub，但這套東西裡的黑話很多，圈內大家都懂，圈外不覺得難用才怪。

原因很多，上課無聊倒不如來回答一下：

----
更新：修正錯別字…

1、盜字幕
別覺得不可能。我是做字幕的，和我們關係很好的另一個字幕組的作品曾經同步甚至更快進度的更新到另一個商業站點上，（他們內部有一個基於FO的內部在線編輯系統，我們也有但是聽說他們的故事之後我們暫時不用了…）經過內部長達半個月的排查，終於抓到了內鬼然後踢出去了…

2、翻譯質量
你知道翻譯字幕需要啥么…
你知道我們的校對最怕的就是新人了！
新翻譯總是覺得自己進字幕組了很NB，可是說實話，我們的考核可能是最松的了（也是互相提升啊，你進來了鍛煉了看到校對給你修正的之後自己能力的提升。），翻譯準確度和格式每次都會累死校對，校對每個月都會抱著我的大腿痛哭流涕啊。
換成眾包了質量更難以控制啊…

3、進度速度也不穩定啊…
網上平台你懂得，今天有時間寫點明天沒時間就不寫了。國內網上伸手黨又多的是，發布渠道不好就罵你「BZ立牌坊，喪心病狂失心瘋」。更新不及時那不得抄傢伙「你瞅啥？」？
哀哀…都是淚…

恩就醬紫…

雖雖然不是字幕組，曾經參與數個遊戲漢化，自己組織過2個遊戲漢化。
人員構成方面，由於是民間非營利性組織，成員構成多為學生，以大學生為主，大學一，二年級最多，還有少數高中生。
屬於常見的無名小組，多次項目的人員多數不固定，不存在默契關係
漢化遊戲均為AVG類型，單個遊戲文本量在50W字以上
翻譯流程基本上是初翻-&>校對*N-&>潤色*N (N&>2)
所有漢化均為多名翻譯協作完成，根據文本量和遊戲劇情線路結構人數會有所不同，但基本上是在4-8人之間。

在這樣一個環境下，身為一個職業碼農，自然會想到版本控制和協作平台的使用了。
對於版本控制，最開始考慮過自架SVN或者GIT，沒有成功
1，成本上的原因，自己本身是一個小型漢化組，成品沒有任何收入，資金投入基本是要自掏腰包。在租用一次VPS沒有得到穩定服務支持後，放棄了自租這種方式
2，Github等開放平台，說真的，自己試用了下，對於非代碼的文本雖然可以用，但是支持有限。
3，開放平台必須開源，雖然是小組，有時候還是存在競爭對手抄襲的情況。使用開發平台難以規避此問題。
4，版本控制工具，無論SVN還是GIT，對非碼農行業的翻譯人員，有一定學習成本，由於人員基本上只能網路交流，工具的使用教育執行有一定難度

後來找到google翻譯的翻譯協作平台，包含了版本控制多人協作建議翻譯等功能，感覺其實很好，也是我找到的最滿意的一個翻譯協作平台，但是依然存在一些問題
1）依賴於網路，對於翻譯環境不固定的翻譯人員來講，很難得到試用
2）google本身在國內的不穩定，有一定概率網頁打不開，存在翻譯完存不上去的問題
3）缺少文本批量上傳功能，一個遊戲的文本文件一般在100-200個文件，沒有批量上傳功能實在是難用
4）沒有客戶端(包括PC，手機端)，在業餘翻譯中存在一些特別情況，比如我的組內就有學生用手機錄入翻譯內容的。（另據說別的組內有人先是列印出文本，手寫翻譯之後再等有電腦使用時錄入）
所以說這類業餘的民間漢化組織存在以下問題
1 人員缺乏專業工作環境以及其知識
2 分布在互聯網各個角落，教育與管理上的難度
3 雖然互聯網上的字幕組漢化組遍地開花，但不像軟體工程那樣存在開發模型供參考。目前在漢化組中廣泛使用的就是「翻譯校對潤色」這種簡單三步方式。具體工作方式需要靠自身摸索。
4 沒有利益驅動，人員難以固定，基本上不是協作而是向一點彙報（一般是立項者)的工作方式。很多時候翻譯A和校對A都沒多少交流。

我自己組織的項目時，基本上版本控制最後全由我一人來做，在本地使用私有的GIT進行文本提交工作，實際上並沒有回滾過，查找歷史版本的機會也並不多，畢竟翻譯文本不是代碼那樣。

1 首先說你前面說的缺點吧。
程序的眾包可行是因為程序的bug是可度量的，可標準化的。有問題就是有問題，找誰來說都是有提。形式語言天生有這種優勢，因為它們都是符合邏輯的。
字幕不然。你聽說過現在還存活蓬勃發展的自然語言處理方法還在把自然語言當做一種有嚴格邏輯的東西的么？沒有。
加上翻譯這個過程之後，字幕的對錯與否，更沒有了統一標準。除了過於明顯的錯誤以外，其他的東西，你說錯了，別人還覺得對呢。
2 然後接著說後面幾點可能原因，挨個打臉吧。
1）字幕組的起源恰恰決定了字幕組就是一群開源精神的實踐者。只不過字幕組不是像題主那樣的固執的要搞眾包之類的東西罷了。現在日漫界大部分大組的字幕都是聲明CC授權的題主不知道清不清楚。並且免費無償製作字幕和分享片源，本來就是比束手束腳的開源愛好者們更為激進的網路共產主義。
捎帶一提，基於AVS/VS框架下的視頻壓制領域，可能是開源軟體領域少有的國人貢獻比例相當大的領域了。近七八年以來還在持續更新，而且經常有革命性突破的後期處理濾鏡和剪輯工具，基本都是國人作品。日本人、俄羅斯人和美國人在這個領域已經很多年沒有什麼人出來拯救世界了。
當然，感謝x264，沒有x264，這個世界會大不一樣。
2) 準確點說是為了質量不允許多人介入。眾包翻譯的風格不可能同調，把這樣一批人的譯稿組合在一起交給校對，還不如一個人重新翻譯一遍。ACG圈子裡至今還流傳著某幻聽神組二十多個人做一部柯南劇場版的笑話。
3) 算了吧，這句話本來想讓我直接對題主說你他媽精神有問題找微軟罵去。不過想想題主這麼年輕積極有為熱愛開源還是包容愛護點好。勉為其難解釋一下吧。老子們巴不得有別的新人進入這個行業然後趕緊退休在家坐等看片。誰tm願意辛辛苦苦做個東西出來等著被人罵啊。別說管一個組了，催一個片的項目組都tm是一件比管理軟體項目還要累一萬倍的事情。我手裡的坑坑的最長的有三年！直到去年吃飯我很誠懇的求翻譯給我一句話說自己不想翻了才算這坑徹底爛掉了。我自己作為後期欠翻譯的片子也是罄竹難書。誰tm還有心思管有沒有新組進入這個領域挑戰自己地位啊。。。
4) 由於前面說的字幕質量評價的問題，在字幕組這個形態的組織開始產生之後的很長一段時間裡，一部片子的每一個崗位，都是單點的。甚至為了避免翻譯和校對撕逼，只有一個人做翻譯和校對，由後期負責檢查個錯字就拉倒了。對於大部分小組，或者是主翻有絕對權威的組來講，是不存在需要用到類似Git的情況的。從協作角度來講，這樣的一個或者幾個項目，有一個足夠簡單可靠的項目管理平台就夠用了。
至於跨字幕組合作，不是缺人誰找別的組幫忙？對不起啦文人相輕誰看得起誰啊。。。

字幕眾包這件事在http://viki.com早就做到了呀。

Viki：視頻字幕版的維基百科
理論上，還真有這個類似的。
估計受限於版權問題，不可能公開明做吧。

像知乎這樣，完全：開放、自由、民主去貢獻和評價內容，字幕最終的質量能得到保證么？@黃繼新 @周源最有發言權

如果不能發揮眾包的優勢，那就無法眾包，只能協作。

其實在github上已經有許多字幕項目了，比如：
https://github.com/qiaoxueshi/WWDC_2013_Video_Subtitle
https://github.com/jkyin/Subtitle

可行的原因是：
1. 字幕項目的contributor為原字幕組人員，這個不會影響字幕質量。
2. 勘誤的話，處理Pull request，這個才是發揮群體智慧的地方，contributor可以決定是否merge
3. @Lawrence Li 提到git難度的問題，其實git是入門難，上手就特別容易，相比字幕製作，這難度小很多
4. 字幕組人員可能沒有開發經驗，可以程序員幫忙寫自動化腳本，實現合併，或檢查翻譯風格是否一致

我覺得開源的好處是：
1. 版本控制，不會數據丟失，也可以回滾
2. 對想從事翻譯的人來說，可以從commits中學習翻譯經驗
3. 協作功能，如果組員已經分工，但個別組員時間充裕，可以幫他人翻譯

有這樣的工具的：
Transifex - Continuous Localization Platform就是一個
http://translate.google.com/toolkit（Google Translator Toolkit）也是

字幕工作不可能像軟體那樣開源，就像 @Lasper Rado 說的那樣，代碼的好壞有它自己的一個標準，而字幕的好壞標準很模糊。英語字幕在會英語（過了四六級這樣的一個水平）的觀眾中會覺得沒有門檻，誰都能做的話不說質量差，光是語氣、用詞都會不一樣，要不是有一個風格統一的小組或者一個人來修改的話會影響整個字幕的質量。甚至說你能翻譯的更好，更符合視頻但風格不統一還不如不要。
不說眾包這種模式了，即使設門檻收人還是會收到很多不負責的人。一開始熱情滿滿後來熱情沒了但又不想走還繼續接任務的，做校對的還要從新再翻譯一遍然後自己校對自己。

還有個很根本的原因就是大家把字幕組看的太簡單了，認為他是一群ACG愛好者組成的一個自願者組織，而不是一群有一定基礎經過訓練（像程序員）願意分享的人所組成的服務組織。

兩個網站的圖片上傳不上來，可以了再補回來。

http://addic7ed.com 用的就是眾包的方式進行協作，不知道題主問的是不是這種。

身在某小字幕組，本來想搞個類似git的版本控制，後來索性字幕組寫了流程式控制制的程序。
以交接任務來確定出勤情況和翻譯階段，前期做一個文本分割（當然有時候不是有文本的），比如出了11個任務，翻譯首先登陸接任務，翻譯完成貼上。翻譯之後就是時間軸，校對可同時進行，信息將在兩方面都完成時整合，這個時候已經生成最後的部分初稿。全部任務結束立即自動整合出全檔字幕qq群郵件，只要有空就自己掛上看下檢查下，全部結束後產生最終定稿交給壓制。
用了這種模式避免了git的繁瑣，但是明顯提高效率，我覺得較於git更加方便。

翻譯是譯者對作品一定程度上的再創造，「開源」的模式容易導致用詞以及翻譯風格的不一致，甚至衝突，從而影響質量；相反，這種協作方式用於勘誤應該沒問題。

打軸，翻譯，校對，後期這點工作量還有這麼干？
此外還有神龍呢

產品經理入門的習作就是設計了一個字幕製作愛好者的在線協作平台+信息中心。。
好吧，請摺疊我把。

與其用Github的git，還不如只用Github的Wiki

我曾偶然在bitbucket上看到過galgame漢化組公布用來存漢化文本的項目，所以並不是完全沒有

github有大量社區支持而字幕組很難做到那麼好的技術支持

從協作，產物分發，持續交付上來看是適合字幕製作的。
但最關鍵的一點是，這種持續改進/演化是否與字幕的生命周期相適應。
一旦初版做成之後，是否之後的改進價值與其維護成本相適應是此模式能否維持的核心命題。

很大的原因:時效性
我以前是做動畫字幕的，主要是後期，不過除了翻譯也基本都能幹
片源:
一般深夜番大概凌晨三點左右出片源。
翻譯:
我需要一個能一直待命的翻譯，從出來第一時間就開始翻譯，粗翻24分鐘的動畫大約用時1個半到兩個小時(如果有兩翻譯合作更好)，然後再由另個人或者人手不夠就翻譯自己（日語一級算是最低要求）用時半個小時到一個小時進行校對。
時間軸:
大概早上5到6點可以開始做時間軸，熟練的時間軸做24分鐘動畫可以在20分鐘內完成，但是很多時候的結果是——睡著了……這時只能負責人自己來了……
後期:
可以在反正進行中時提前處理op ed以及標題字幕等需要pos的字幕，等都弄好檢查下ass文件有沒有超框，有沒有奇怪的東西混進去……都ok就avs替換好進去壓就行，壓完需要大致複查，時間軸是否準確/有沒有因為編碼器問題壓壞的部分
發布:
大約早上7點到8點就可以發布

全程傳遞使用的是QQ郵箱，如果以上流程用github，你覺得能第二天早上就出的來么？而且開源就算沒有搗亂的(字幕組之間馬甲卧底挺多)，亂七八糟的人翻譯風格如何把控？跟翻譯的人接觸多了就會知道很多人不好管，有的人不喜歡別人改動他無錯的翻譯認為美化修改後的句子就不是他的作品了……有些事情並不是人多就能好辦事的

沒參加過字幕組，但是自己做過字幕來玩。
我個人以為git是可以運用在這類開發中的。

做個類比，現在很多字體的開發都在使用git，用純文本編輯glyphs，每個glyph用一個文件編輯（見source-code-pro/RomanMM/SourceCodePro_0.ufo/glyphs at master · adobe/source-code-pro · GitHub），可以很方便地做版本控制以及多人協作。然後使用AFDKO生成ttf之類的字體文件，很像我們寫的代碼用git管理，再用編譯器生成二進位文件。

同樣的，從理論上來說，字幕也可以分成多個純文本文件編輯，比如可以將時間軸分段劃分，也可以按人物劃分。一開始可以由幾人給這些分好的段挖坑，比如

# 00.02.30-00.05.00.txt


00:02:31,500 --&> 00:02:35,500
00:02:40,500 --&> 00:02:42,000
......
00:05:42,000 --&> 00:05:44,000
00:05:44,000 --&> 00:05:47,000

# 00.05.20-00.10.00.txt ......

然後就可以分派這些坑給小組的翻譯成員，他們只要填上就可以提交了。

這種方式編輯的字幕易於管理、審查和修正，不需要fork也可以做到互不影響地開發（當然相互之間不能同時編輯一個文件，不然merge的操作會相當繁瑣）。要生成字幕也只需要寫個合併腳本即可，可以說只要團隊中有一個懂得git使用的人就可以組織好這種協作開發模式。當然目前的缺點就是沒有這種現成的腳本可以使用，還需要有心的開發者做點貢獻。

有人說git的門檻高，但其實相比來說，我認為那些字幕軟體的使用也不簡單，反而如果開發流程確定下來，翻譯者只需要記幾個簡單的clone、add、commit、push、pull就能完成這個流程。如果使用GUI的git管理工具就能更加簡化這一過程。如果有人願意寫個小程序自動化這一流程，對於翻譯者來說就根本不需要學習任何有關git的知識了。

有人說開源精神不適合字幕組，但是使用git並不一定就必須開源，架設或使用private git server並不是一件難事，git的優越性在於版本控制和多人協作，而這正是字幕組迫切需求的。

我承認傳統字幕組要接受這種新的合作模式需要磨合，但是如果人人都在使用，他們自然會產生危機感（或者說希望採用更高效的方式），而去主動轉型的。

又有人說翻譯的評判標準難以確定，這就需要管理者的協調了。最終的審核應該交由少數幾個核心成員進行，發現問題後創建issues發送郵件（字幕組一般是用QQ的吧）給翻譯者來更正，或審核者自己修改過來，對於翻譯者相互之間提交的issue和patch應該也以相同幾個審核者的評判標準來決定去留。我覺得這種矛盾在任何合作模式中都會出現，實屬一個管理問題。

當然，對於這種literal的開發，無法像代碼一樣統一代碼風格，總會形成所謂的「翻譯風格不統一」的現象。如何協調維持好這種新的開發模式還有待那些字幕組領導者的探索。