为什么字幕组行业不借助类似 GitHub 的平台众包协作?

当前的缺陷: 字幕组的工作存在瑕疵(错别字等)时,非组内人士难以 pull request 正确的字幕组的工作存在瑕疵(错别字等)或不同意见(翻译方法)时,其他人难以 fork 并编辑出独立的另一个分支在不同的番组,各个字幕组难以进行不同的合作模式 为什么不这样的可能原因: 字幕组行业的历史决定了开源精神在这里水土不服字幕组为了品牌不愿过多允许他人介入已经形成垄断的强势字幕组集团不愿新秀以传统字幕组之外的发展方式登堂…
关注者
251
被浏览
11380

22 个回答

再次更新:

我没听说字幕众包的。只有字幕组合作的,没有众包的。当然有前辈也曾经弄过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)xxx.com。错别字什么的就不要提了,大家都看的出来,实在太多(比如超过了20个)可以重制,少量错别字不影响观看,没有必要投入精力。

2.字幕组的工作存在瑕疵(错别字等)或不同意见(翻译方法)时,其他人难以 fork 并编辑出独立的另一个分支
编辑字幕实在简单的不能再简单。。字幕看不下去就下载回来,自己拿记事本修改就行。

3.在不同的番组,各个字幕组难以进行不同的合作模式
是的,各组的人员分工以及制度存在差异,翻译理念和水平也都存在差异,组间合作的路很长。

4.字幕组行业的历史决定了开源精神在这里水土不服
此条略

5.字幕组为了品牌不愿过多允许他人介入
善意地说一句,为了质量我们也不愿多允许他人介入的

6.已经形成垄断的强势字幕组集团不愿新秀以传统字幕组之外的发展方式登堂入室
别乱代表别人,组里那么多人管理起来尚且有点吃力,谁有功夫管其他字幕组?

7.缺少像 Git 一样成熟的字幕组内协作工具,所以缺少像 GitHub 一样成熟的跨字幕组协作工具
组内协作工具是有的,大家都在用,新版还在内测.现在已经有了一套很实用的组内协作程序(别的组有没有我不知道哟),从发片到最后出成品都有严格的工序和制度,简单易上手,容错率很高。
况且,字幕其实是很简单的代码+文本,很多情况下根本不需要用工具,进行各步骤的人员沟通好,做好统一的标记/注释就可以顺利协作了。
跨组协作很难实现。时间轴和后期没什么协作的意义,因为结果很单一,并且容易评价(同步情况,特效与视频的融合程度),翻译需要协作可结果又很难评价。

在当前很多字幕组成员都没看明白英文对话(尤其是长句,或是high-context的短句)的大环境下,各组的这种实力水平是支撑不起一个高效的组间协作系统的,稍安勿躁。

自己专栏的广告:知乎专栏
为什么?