Minecraft Wiki

除另有声明,转载时均必须注明出处若簡繁轉換出錯,請以遊戲內為準请勇于扩充与修正内容有兴趣逛逛我们的微博沟通交流,欢迎到社区专页需要协助,请在告示板留言

致全體港澳用户:Minecraft 現已於最新正式版加入繁體中文(香港)翻譯,多謝各位嘅支持!

了解更多

Minecraft Wiki
Advertisement

任何人都可以编辑这个页面!

这是Lakejason0的用户页,但鼓励其他用户编辑这个页面及其子页面。
如果你的编辑被过滤器阻止,请将你的更改建议发布至讨论页

Iron Pickaxe JE3 BE2.png
该页面的编辑正在进行中。 讨论

请帮助我们扩充或改进这篇文章。

此页面用来记录我对于MCWZH的一点点论证。

另请参见:如何管理中文Minecraft Wiki

前提性的结论[]

  • 玩家群体总体是松散的,凝聚力弱的群体。
  • 玩家群体所需要的优先重视,不那么需要的自然不那么重视。
  • 玩家群体的扩大通常意味着难以达成共识。

主要的几个结论[]

  • 中文Minecraft Wiki是维基。
  • 中文Minecraft Wiki是记载Minecraft相关内容的Wiki。
  • 中文Minecraft Wiki是英文Minecraft Wiki的子语言项目,但不只是一个子语言项目而已。
  • 中文Minecraft Wiki是Minecraft中文本地化的重心。
  • 中文Minecraft Wiki的管理模式是“小圈子式”的。

具体论证[]

维基性[]

中文Minecraft Wiki是基于MediaWiki软件运作的,因此,其主要优势和主要限制都在于MediaWiki软件本身。

可视化编辑[]

可视化编辑一直都是一个(除了处理表格以外,甚至对于表格都很鸡肋)华而不实的东西,其原因主要在于其对于模板的支持实在是惨不忍睹。而偏偏,MediaWiki软件的一大优势就是模板,因此,如果使用可视化编辑无法发挥模板的作用,那么可视化编辑在可预见的未来就一直会是一个新手爱用但是会造成管理困难的东西,其间接后果就是劝退新人。这不利于中文Minecraft Wiki吸纳新鲜血液。

农场[]

中文Minecraft Wiki依赖Gamepedia这个Wiki农场运作,因此很多事务也受到Gamepedia本身的牵制。比如注册登录问题等。

Minecraft相关性[]

中文Minecraft Wiki收录Minecraft相关内容,包括但不限于Java版基岩版、历史内容、Minecraft DungeonsMinecraft Earth等。

Java版[]

Java版是Minecraft Wiki一直以来就在记录的东西,内容较为完整详实,但是存在新旧内容混杂,旧内容无法及时得到更新的问题。

基岩版[]

基岩版是后来才有的,因此Wiki原有的很多的只适用于Java版的内容,由于各种原因无法得到标注。这导致中文Minecraft Wiki的基岩版内容在事实上存在很多的漏洞,也是基岩版玩家的一个痛点。

Spin-offs[]

Minecraft Earth和Minecraft Dungeons由于SEO的关系,依然建在了原来的Minecraft Wiki里。这些内容大多并不详细,需要很多人帮忙完善。

子语言项目性[]

中文Minecraft Wiki是英文Minecraft Wiki的子语言项目,其工作的一大内容就是将英文Minecraft Wiki的内容翻译过来。

中文Minecraft Wiki真的只是英文Minecraft Wiki的子语言项目?[]

由于子语言项目性,中文Minecraft Wiki长期以来的运作模式都是EN怎么做我们照做。但是,英文站点的质量日益下滑,处理事情的流程和时间也变得越来越长,这导致很多内容在英文站点也是没有的。中文Minecraft Wiki的维护者大多也只会同步一些主空间条目,没有时间与精力去做原创内容的验证,因此在很长一段时间内,中文Minecraft Wiki一直不允许主条目的大段原创内容。除了担心内容重复、质量不高等原因外,另一点就是怕原创内容被下一个编辑者从EN同步时就删掉了。由于以上原因,现在中文Minecraft Wiki也慢慢放开了这个限制,但是不同步问题依然需要编辑者有反向同步的能力才能顺利完成。

原创教程[]

写了一篇教程/制作数据包/实例:蜜蜂助手

目前来说,原创教程除了质量良莠不齐的问题以外,就是曝光度不高,被修改的可能性也不高。因此,本来应该由大部分人改进的原创教程最后可能就荒废了。

本地化重心性[]

中文Minecraft Wiki的管理人员同时也有Minecraft Java版的Crowdin项目的管理权,因此Minecraft内容的译名,产出或传播都主要依靠中文Minecraft Wiki和其合作的组织(例如MCBBS)。

中文为什么这么“麻烦”[]

我前后参与了原版Minecraft、RAA和Sodium的翻译。现在我来谈谈为什么中文这么“麻烦”。

首先,中文对于外来语的接纳便利性较低。举个例子,菌光体的英文Shroomlight,对于法语等欧洲语言来说,他们拥有共同的被称作“词根”的东西,并且词根之间是可以以相似的方式拼接的,所以可能的译名很快速就出来了:Lampignon和Champilampe,分别由灯“lamp”和蘑菇“champignon”组成。而中文不存在词根对应,也不存在词根拼接融合,所以这种构词法所产生的词必须考虑其所指代东西的更多的性质,等等。同样,音译的忍耐程度也比日语低许多。

其次,中文的易读性标准也略有不同。与一些语言习惯于灵活变化同一种词在语段中出现的形式不同(比如德语中两个表达中国的方式),中文对于一致性和本地化的要求更高,就和上面说的一样,翻译的时候即使考虑的量等同甚至略高于英语翻译到其他欧洲语言的程度,也会导致词不达意。问题就在于,为了达到本地化需求的低线,常常会导致“bikeshed”问题,而原因就是考虑的量过多了。而过多是否必要呢,这还无法regularize。虽然仔细讨论通常结果不会太差,可读性也会有所提升,但是付出的精力真的多于英语翻译到其他欧洲语言。

以及,中文的机器翻译依然不成熟。机器翻译达不到那个本地化需求的低线,因为目前较为靠谱的机器翻译都是基于机器学习的,即大方向抓住,但也只抓大方向。那自然,一些小词的一致性也就没法保证了,也就达不到上述的那个低线了。除了选词差异,更大的问题其实就出在语法差异上了,也就是分析语(孤立语)和屈折语的区别了,比如动词。中文里动词是没有标志的,英文里动词和名词的标志也不明显,对译的时候机器翻译也自然没法胜任判断词性的工作,比如“Tropical fish flops”。

至于熟语,嗯……自然,也没法保证。使Here be dragons都可以变成“ドラゴンになれ!”的英-日机翻,我觉得足以说明问题了。

因此,中文的本地化工作,必须得有不缺一点点心眼的人。显然,不可能每个方面都做到完美,所以对于Minecraft,只能说是必须得有一个熟悉Minecraft的方方面面,经验也足够的人了。

译名标准化[]

……据我所知,Minecraft是唯一能够让玩家自己参与译名决定的较热门游戏。通过本地化平台Crowdin,每个普通玩家都可以提交自己最满意的译名,此乃民主。但弊端也很明显:面对庞大且复杂的玩家群体,能够找到十全十美的译名基本上是不可能的事情。译名的诞生(例如下界合金、苦力怕等)免不了旷日持久的争论。每个人都渴望得到Proofreader这个职位,但没人能保证Proofreader不专断,因为他们掌握着译名的生杀大权,对待普通玩家的态度取决于自己。另一方面,由于译名经常不能令人满意,争执、口水战甚至是决裂是容易发生的事情,因此我们能做的只能是遵循少数服从多数原则,挑选出尽量令玩家满意的译名。设立译名讨论群,目的是为了将高质量玩家聚集在一起,在遵守群规的前提下和谐而有序地讨论译名。我们应该做的是团结起来,设法化解Mojang给我们带来的挑战,而不是为了一个译名争得你死我活,两败俱伤。

——引自User:Lxazl5770/Translation,最后更新于2020年6月6日,经过一定修改

中文Minecraft Wiki在还没有Java版本地化的时候便启动了译名标准化项目。现在,这个项目现在便直接与Crowdin挂钩,直接通过游戏本体推送出去。

但是,译名标准化项目的决定流程也逐渐地由于Craft Lawrence等人的小圈子式决定出现了一些问题,而做出了使决策变得更开放、民主和拖沓的改变。类似于下界合金谓词等译名的决定就足以体现拖沓这一性质。

就拿谓词来说?[]

这个词一开始并没有出现在语言文件里[来源请求],于是翻译这个词主要是为了Wiki的译名标准化。

这个词语作为例子,主要体现的是Wiki在面对技术性专有名词时的拖沓。

首先争论的点是……关注度。“谓词”这个词,初期共识主要是“不知所云”,于是大家主要在找一些其他的词汇去替换,比如“判据”,“断言”等等。

慢慢地,在这个层面的辩论行不通了,大家便又把重点放到了“准确性”和“对应性”上。“谓词”的好处就是,他和“Predicate”一一对应,在一些GB/T文件[来源请求]中也将“谓词”定成了Predicate的翻译。“断言”(对应assert)则相对的被认为是概念转移,可能会导致歧义,诸如此类。

后来chyx等一些人又提出“Predicate”这个概念可能和离散数学的谓词有相似性。提出后,一部分人坚持选择“谓词”。

后来……Crowdin上其实有了字符串,于是就真的得定了。最后就定成了谓词。

但是,此时SPGoding等人的教程已经用了断言/其它译名了。

他们给出的理由也很简单,从逻辑角度上,整个Predicate文件是个table,而每个Predicate文件里的predicate才更像谓词。

目前,Predicate的译名已定为“战利品表条件”。

看到这里你可能会疑问,为什么别人用了其它译名就不行?

我说不清楚,但是“译名标准化”,我想这五个字应该能够说明为什么会争吵成这个样子,吧。

译名群工作标准化的几个设想[]

个人认为译名讨论由于各种原因暂无法regularize,故先搁置一段时间。

这一周想了一下,译名群的工作流程大概是这样的:

  给出Context->提出译名->讨论译名->得出译名

但实际情况是:

  给出Context
  提出译名          ->       得不出译名
  讨论译名

而以上三个流程,相互促进,相互作用,也就是:

没有讨论就没Context,没提出就没讨论,没Context就没得提出。

举个例子吧,Netherite是咋样的呢?

首先,我们有一个最基础的Context,就是词根。词根是语言本身的属性。

然后到了游戏事实,也就是材质啊功能啊这些。

然后到了思维发散,也就是类似于在“Minecraft小说世界观”下的讨论,比如某位mnjs提出的岩棉,比如下界玄铁。

然后,Context几乎发掘完了,就只能讨论了。

结果是,既然没有Context提出了,那就只有做选择题了,结果没得选。

大家:然后要不我们再提点译名?然后还是没得选。

然后大家:“那就只有做选择题了”,但是没得选。

然后,大家:pow定了下界玄铁?

大家:那我觉得不行,我觉得blablablabla……

但是还是没得选啊,于是pow给了个投票。

大家:那……就下界合金吧.jpg

例子给到这里。

基本上就是,几个阶段并行,不好拆开,但不拆开又很混乱。

设想1[]

通过文件把流程规定好。

这个方案好像很合理,但是不符合实际。实际情况就是上面这样,遇到一个很有争议的就会很麻烦。

小圈子性[]

中文Minecraft Wiki的编辑者多集中活跃在管理群内,而管理群需要Gamepedia账号(在登录系统合并后不再是障碍)才可进入,且入口并不明显。这是出于便于管理和躲避闲人的目的,但是在一定程度上限制了吸收新鲜血液的能力。

中文Minecraft Wiki相较英文站来说,活跃编辑者不多,这导致很多工作无法及时完成,但同时,很多事情的决定变得短平快,相较于英文站点迅速许多。

相对地,由于小圈子性,Minecraft的其他许多小圈子并不能融入,也间接导致了大家“讨厌Wiki的缺点”但是却鲜有非活跃编辑者想来主动解决的现状。

就拿某个IP用户来说,摘要和讨论页到处说你们怎么不努力改机器翻译,但实际上,看到就改就慢慢没有了。还好,他还知道改,更多的人可只会抱怨。

Advertisement