本帖最后由 NoName德里奇 于 2022-11-26 15:43 编辑
前言
对我过去所作的工作有了解的朋友可能知道，我在担任整合包发布版版主之前，
曾长期从事 Minecraft 模组 The Betweenlands 交错次元 的汉化工作与 MCMOD 百科的资料维护。
此外，我还完成或部分参与过一些小模组的汉化和国内搬运项目，
这也是我在 BBS 获得疯狂搬运工勋章的原因。可以说，我也是做模组汉化的过来人。
对汉化 / 翻译有了解的坛友都或多或少知道，原版 Minecraft 的官方中文汉化、
模组汉化和整合包汉化，或多或少地都会产生争议，甚至论战。
前人的例子实在太多，但具体举例难免有点名之嫌，为了避免不必要的口舌特此略去。
然而，难以否认的是，Minecraft 的全球社群，
比国内社群的体量大得多、创造力强得多，产生的优秀作品也多，
这些作品的翻译、汉化，不仅对决定国内的 Minecraft 玩家能够体验到什么样的优秀作品至关重要，
而且对于国内的广大原创内容作者来说，
这些从国际社群引入的新鲜血液，也具有难以估量的借鉴和启发意义，
可以说，对于 Minecraft 国内社群来说，翻译和汉化的重要性从未褪色过，
过去重要、现在重要、将来重要。
作为广大模组整合包玩家的一员、广大模组汉化工作者的一员、
广大模组整合包作者的一员、整合包发布版版主团队的一员，
我的四重身份也让我更加清楚地意识到，“汉化”作为社群内容创作的众多项目之中，
如此事关重大、如此容易产生意见分歧、又如此容易产生作品质量上的天壤之别的一项，
要把这项工作做好，那么让玩家们、汉化作者们能辨别汉化作品的好与坏，是非常关键的。
如果汉化作者能清醒地认识到自己的作品与好作品的差距，
那么自然而然地就会向着好作品的方向去完善自己的作品；
如果每一位汉化作者都能这样做，那么整个汉化圈子的作品质量就能够整体提升。
如果玩家们能够辨识出好的汉化作品，那么优质的汉化作品就能更多地得到推广和采用，
其一这是对这些付出心血努力的汉化作者的最好回报，
其二确保了良币可以有效驱除劣币，好作品能够替代并淘汰坏作品，
其三，作为游戏的语言支持，随着好的汉化作品被整个玩家群体普遍接受，
那么对于同一个游戏内容，这些玩家就可以使用统一的词汇来交流，
抹平交流障碍之后，被翻译 / 汉化的这个原版游戏内容 / 模组 / 整合包本身，
也会被更好地推广，成为间接受益者。
有鉴于此，经与长期从事翻译工作的同伴 清秋 协作，我决定就我们的专业方向对此展开讨论，
选取 Scape and Run: Parasites 逃逸：寄生兽 模组的两版汉化文本作为实例，
浅略地谈一谈模组的汉化作品中，“好作品”和“坏作品”的区别究竟在哪里。
好作品：成功的关键
如果各位不熟悉 Scape and Run: Parasites 逃逸：寄生兽 这个模组，我在这里简单介绍一下。
这是一个以添加“寄生怪物”为主的冒险模组。
在这个模组当中，寄生怪物可以通过杀死、转化正常的生物来进行增殖，发生自我突变和进化，
形成数量庞大的寄生怪物种群和经过多次进化的精英寄生怪兽，供玩家挑战。
因此，在这个模组的汉化工作当中，大量涉及怪兽名称的翻译。
首先，客观地说，英汉两种语言在“起名”方面存在着一些差异。
英语中为某物取名，可以十分简单的从其功能或是外形上下手，
例如寄生体中的“Reeker”，就是从功能上取“Reek”一词，再附加“-er”后缀，就算是取名完毕了。
而在更多的使用例中，甚至会出现没有“-er”，直接使用一个名词作为一个实体的名字。
这就给汉化造成了一定困难。
尽管一般说来，包括实体的汉化在内，实际上，所有的翻译问题都很难有唯一的标准答案。
汉化者本人对文本本身的介入是不可避免、甚至必需的，否则译文本身不能称其为译文；
因此，我们应该用更开放更宽容的态度去看待不同译名之间的区别——
但是，”宽容开放“不等于任意翻译，不等于”为所欲为“，”百无禁忌“。
通常，在进行汉化时，词义、游戏内容的表现是首要参考因素；
汉化者以及玩家的用语习惯，作为次要因素。两者结合分析，最终得出结论。
我们结合例子来看一下。
对“原始种”以及“适应种”的名称汉化
我们直接看语言文件。这一部分节选的语言文件，包含“原始种”的名称文本：
复制代码
从文本上分析，这些实体名称的汉化难度是比较低的，因为它的文本可读性高，没有自造词，
一眼可以基本猜测出它们的设计思路，再辅以一定的游戏内表现分析即可。
我们先对“Primitive Longarms”做做分析。
从词义上说，“Primitive”是“原始种”这一种类的名称，“Longarms”意思是“长的手臂”，
基本没有词义分析的余地，不妨直接考虑用语习惯问题。
对于这类的实体，我们首先考虑一种汉化的模式，即“主词+种类描述”。
在这里，官方译本中的“长臂兽”就是采用了这样的模式。
有些汉化者可能为了突出文本上给玩家的陌生感，会将种类省去，译为“长臂”，这种方式并不合适。
因为这种处理手法通常应用于生造词，比如种族、城市等。
但是，生造词本身作为名字，中文的处理方法一般都是直接音译过来。例子数不胜数，试举几个：
Álfheim → 亚尔夫海姆
Tamriel → 塔玛瑞尔（出自 The Elder Scrolls 系列）
Novigrad → 诺维格瑞（出自 The Witcher 系列）
我们再举一些正面的例子，即添加了种类限定的实体翻译：
Beholder → 眼魔（出自 DND 系列）
Cooker → 厨师
Screamer → 尖啸尸（出自 State of Decay 2）
一般来说，遇到这种主词词义清晰，可以一定程度鉴别种类的，
采用“主词+种类描述”的处理方法，可以最大程度的降低理解难度。
所以，依照以上的一些讨论，针对于原始种的翻译我们完全可以使用“xx兽”，“xx体”的模式进行翻译。
官方译本中使用“xx兽”的模式，中规中矩。
读者可能会疑惑：为什么不以“-er”结尾的“Longarms”“Yelloweye”和“Arachnida”三者也翻译为“xx兽”呢？
这是由于英语本身的语法产生的限制。
英语在构造“-er”类单词时，前面的部分往往是动词，意即“是做xx事情的东西”，
但是在遇见名词的时候就很难这样构造了。
这三者的取名角度都是从外貌上切入的，所产生的都是名词，所以没有“-er”的后缀。
但是这并不妨碍汉化者将这三者也处理为“xx兽”，使得文本的统一性更强。
对“粗杂（Crude）种”的名称汉化
仍然看语言文件：
复制代码
首先我们来逐一分析：
在游戏中，“Herd”是“Host”的进化形态，所以并列讨论。
先做词义分析，前者的词义较多，例如“宿主”“大量”等，其中“宿主”的意义可能性最大，因为比较切题；
再看后者，它的意思就是“群落”。
如果仅从单个来看，前者比较难以挑选词义，但是如果搭配上后者，就能明显看出，
Host 和 Herd 都是想表达“大量”“许多”的意思，这样两者之间的承接关系就更为明显了。
再看看游戏内的实体外观，后者作为前者的进化体，外观看起来就是前者的加长版，上面的骷髅也更多。
我们再从用语上分析。首先我们不可能直接译成“大量”“许多”，这和中文的语法并不贴合。
遇到这样的情况，依然是采用上面的那种模式，即“主词+种类描述”。但也不能译为“大量柱”。
你会发现，无论怎么样，“许多”“大量”这种量词都很难塞入我们的模式当中，中文里并没有这样的用法。
那么类似于这种情况，一种可用的思路是，将“许多”“大量”扩写为“许多的xx”“大量的xx”，
通过扩写处理得到“长有大量xx的柱”的初步翻译后，稍微缩一下句子，就能够得到一个较为适当的译名。
那么，此两者的译文含义就可以处理为“长有大量骷髅的寄生体柱子”“长有更大量骷髅的寄生体柱子”。
在1.9.7的译本中，为了缩写得更为简略，甚至把 Host 直接译为了“骷髅柱”，Herd 译为了“群骷柱”，
更为强调两者之间的进化关系，部分牺牲了 Host 的原文含义。
“Crux”，按照当初想出这个怪物的作者的说法，这个名字基本上是随便找的，
所以我们最好的方法是音译此文本。
然而针对于非专有名词的音译，不能按照专有名词的音译法处理，
尤其是音译完之后非常像是人名的翻译，可以举一些特意改字的音译例子，供大家参考：
Flumph → 呋噜（出自 DND 系列）
Rivellon → 绿维珑（出自 DOS 系列）
“Heed”，词义为“留意”“当心”，目前在游戏内不生成，计划的能力仍未实现，
单独的一个词义让人想破脑袋也无法理解，因而目前除了从外观上下手别无他法。
“Heed”的外观为很多的头颅，如果考虑到“heed”是“head”的一种改写，
可以取“头”的意思，最终定为“多首怪”。
“thrall”太简单了，译为“寄生奴仆”之类的便能切近原意。
对“先天种”的名称汉化
还是直接看语言文件：
复制代码
基本上按照以上的方法都能得出一个比较恰当的翻译，唯一需要提及的是“Rupter”和“Mangler”，
后者为前者的进化体。前者的译名为“裂兽”，那后者完全不必再去精挑细酌一些小词，
简单地处理为“凶裂兽”等和前者有进化语感的译名即可。
当然，若是你真的很想精挑细选出一个比较好的词，也是可以的，但前提是能够充分地体现出两者之间的关系。
对模组术语的分析
“Hive”，“Colony”两个，前者出现在“Call of the Hive”“Hivestone”等，目前统一为“寄群”，
“Colony”则是模组添加的一种种群机制，目前只是译为“种群”，两者的区分需要等到游戏内容完善后才能知晓，
目前只有“Colony”的内容是较为完善的，“Hive”对应于模组内的哪块内容目前尚未得知。
但为了区分，或可将前者更改为“寄巢”，后者更改为“寄群”，如此更为妥帖。
“Parasitic”和“Infested”，两者指称的是方块的寄生程度的区别，
前者指的是完全寄生转化，而后者只是部分寄生，方块颜色上还未完全转化为寄生种族的黑色。
“Assimilated”，指的是生物被寄生种群同化，此时转化还不完全。
当演化阶段提升后，一名同化种会迅速地转变为适应种，此时才寄生并转化完毕。
对翻译模式的总结
在 Scape and Run: Parasites 逃逸：寄生兽 模组的汉化项目中，汉化者确定了一种固定的译名模式：
通常使用“xx兽”“xx虫”“xx+种类限定词”的译法，如果实体的种类限定不太明显，
则简单的选择“xx体”，可选用的还有“xx魔”“xx怪”等，
但是使用这类在常规语义上有一定价值评判的种类限定字时，还需妥善地考虑清楚词与实体之间的关系，
例如长相特别凶恶、危险程度特别高的，比较适用于“魔”这种字眼。
对于没有办法在中文中使用“xx+种类限定词”译法的原文，进行适当扩写，补足缺失的名词，再在此补足的基础上缩写，
对于完全生造的词汇，则采用音译的方式翻译原文。
需要注意的是，音译时汉化者在对非专名的原文翻译时，不妨采用不是特别常用的音译字，
且此字最好能够从某种角度合适地切入到实体自身的性质中，
这样的译文既未违背原文的发音要求，还能最大程度地给读者带来美感。
对于在进化层级上有先后关系的实体，在译文处理上，考虑在不过多破坏原文词义的前提下，清晰地表露出这一层关系。
总的来说，一定要灵活地将 原文词义 与 游戏内表现 结合在一起，找到最适合的词义。
切忌只是将原文丢入翻译软件中，单靠臆想选出词义。
坏作品：失败的根源
我们选取一个坏作品的例子来分析，同样地，我们会在分析每一个问题之前，展示对应的语言文件片段。
缺乏“构词法”模式，语言风格不统一
复制代码
各位可以清楚地注意到，在这一段汉化中，
有些使用我们文中提到的“xx+种类限定词”译法，有些又只是使用了一个描述行为的词语。
甚至有一个使用了双引号括住的译文——双引号往往是在翻译人物称号或昵称时使用，
放在此处显然不合适。
在游戏汉化中，采取一种统一的模式（或者说“构词法”），确保整个译文风格上的统一，
才能够符合人类的记忆逻辑，才能够最大程度降低玩家的记忆负担。
如果犯了偏爱使用诡词、奇词，为了这些词语而破坏译文的语法结构的错误，
又或者是在风格上想一出是一出，随意混用不同的“构词法”，
那么就会像上面这样，写出整体上风格混沌不堪的译文，给玩家的阅读理解造成极大负担。
除此之外，在处理实体的进化层级的问题上，译文也暴露了严重的问题。
“绞杀虫”“断裂虫”两者的关系不明朗，“宿主”和“虫群”更是“貌离神也离”。
如果说前面的风格问题只是影响记忆，那后面的关系处理问题就会影响游玩理解了，属于是硬伤。
术语汉化失误，造成大批的错误翻译
复制代码
前文我们已经讨论过，在 Scape and Run: Parasites 逃逸：寄生兽模组中，
出现的“Hive”“Colony”和“Parasitic”“Assimilated”两组术语；
然而，在这一版作品中，汉化者将“Hive”“Assimilated”和“Parasitic”三者简单混同，
“Hivestone”成了“寄生石”，“Assimilated Bear”译成了“寄生熊”，
这种术语的混同翻译，好比图片打了马赛克，造成了严重的信息量损失，属于明显的错误翻译。
而“Colony Carrier”的翻译“噬境妖虫”，则属于缺乏支撑、凭空构造的译文，
很难从中体现出模组作者想要表达的原意。
总结：好作品和坏作品的区别在哪里
刚才我们经过了一番长篇大论，将针对同一个模组的好坏汉化作品作了详尽的对比分析，
综上所述，我们可以总结出，一个汉化作品“不坏”的及格线，包含以下几条：
在社群中经常有一部分玩家喜欢用“机翻”与否来衡量作品标准，但实际上，比起一棒子打死“机翻”，
我认为上面的及格线要科学得多。
写在最后
这是一段题外话。
我曾经在某个 QQ 群里讨论时说，
我们希望能够公平地评价每一个模组或者整合包的汉化作品，
让好作品得到推广，让坏作品自然淘汰，避免劣币驱逐良币；
这时，一位群友插嘴说：
说完扬长而去。
这话听得我很不是滋味。
我作为整合包发布版版主之一，我衷心希望，好作品和坏作品，
是按照它们的质量高低，被公平地对待的。
我们不能听任不好的作品大行其道，更不能因此让好的作品明珠暗投，
我们不能让这些倾尽业余时间和创作热情，
用自己的知识与努力，默默为社群添砖加瓦的这些创作者心寒。
我深刻地明白这项工作任重而道远，“士不可以不弘毅”，路漫漫其修远兮，吾将上下而求索；
如果这是一场千里之行，我希望始于足下，
就从这篇文章发出去、被大家看到的此时此刻开始。
前言
对我过去所作的工作有了解的朋友可能知道，我在担任整合包发布版版主之前，
曾长期从事 Minecraft 模组 The Betweenlands 交错次元 的汉化工作与 MCMOD 百科的资料维护。
此外，我还完成或部分参与过一些小模组的汉化和国内搬运项目，
这也是我在 BBS 获得疯狂搬运工勋章的原因。可以说，我也是做模组汉化的过来人。
对汉化 / 翻译有了解的坛友都或多或少知道，原版 Minecraft 的官方中文汉化、
模组汉化和整合包汉化，或多或少地都会产生争议，甚至论战。
前人的例子实在太多，但具体举例难免有点名之嫌，为了避免不必要的口舌特此略去。
然而，难以否认的是，Minecraft 的全球社群，
比国内社群的体量大得多、创造力强得多，产生的优秀作品也多，
这些作品的翻译、汉化，不仅对决定国内的 Minecraft 玩家能够体验到什么样的优秀作品至关重要，
而且对于国内的广大原创内容作者来说，
这些从国际社群引入的新鲜血液，也具有难以估量的借鉴和启发意义，
可以说，对于 Minecraft 国内社群来说，翻译和汉化的重要性从未褪色过，
过去重要、现在重要、将来重要。
作为广大模组整合包玩家的一员、广大模组汉化工作者的一员、
广大模组整合包作者的一员、整合包发布版版主团队的一员，
我的四重身份也让我更加清楚地意识到，“汉化”作为社群内容创作的众多项目之中，
如此事关重大、如此容易产生意见分歧、又如此容易产生作品质量上的天壤之别的一项，
要把这项工作做好，那么让玩家们、汉化作者们能辨别汉化作品的好与坏，是非常关键的。
如果汉化作者能清醒地认识到自己的作品与好作品的差距，
那么自然而然地就会向着好作品的方向去完善自己的作品；
如果每一位汉化作者都能这样做，那么整个汉化圈子的作品质量就能够整体提升。
如果玩家们能够辨识出好的汉化作品，那么优质的汉化作品就能更多地得到推广和采用，
其一这是对这些付出心血努力的汉化作者的最好回报，
其二确保了良币可以有效驱除劣币，好作品能够替代并淘汰坏作品，
其三，作为游戏的语言支持，随着好的汉化作品被整个玩家群体普遍接受，
那么对于同一个游戏内容，这些玩家就可以使用统一的词汇来交流，
抹平交流障碍之后，被翻译 / 汉化的这个原版游戏内容 / 模组 / 整合包本身，
也会被更好地推广，成为间接受益者。
有鉴于此，经与长期从事翻译工作的同伴 清秋 协作，我决定就我们的专业方向对此展开讨论，
选取 Scape and Run: Parasites 逃逸：寄生兽 模组的两版汉化文本作为实例，
浅略地谈一谈模组的汉化作品中，“好作品”和“坏作品”的区别究竟在哪里。
好作品：成功的关键
如果各位不熟悉 Scape and Run: Parasites 逃逸：寄生兽 这个模组，我在这里简单介绍一下。
这是一个以添加“寄生怪物”为主的冒险模组。
在这个模组当中，寄生怪物可以通过杀死、转化正常的生物来进行增殖，发生自我突变和进化，
形成数量庞大的寄生怪物种群和经过多次进化的精英寄生怪兽，供玩家挑战。
因此，在这个模组的汉化工作当中，大量涉及怪兽名称的翻译。
首先，客观地说，英汉两种语言在“起名”方面存在着一些差异。
英语中为某物取名，可以十分简单的从其功能或是外形上下手，
例如寄生体中的“Reeker”，就是从功能上取“Reek”一词，再附加“-er”后缀，就算是取名完毕了。
而在更多的使用例中，甚至会出现没有“-er”，直接使用一个名词作为一个实体的名字。
这就给汉化造成了一定困难。
尽管一般说来，包括实体的汉化在内，实际上，所有的翻译问题都很难有唯一的标准答案。
汉化者本人对文本本身的介入是不可避免、甚至必需的，否则译文本身不能称其为译文；
因此，我们应该用更开放更宽容的态度去看待不同译名之间的区别——
但是，”宽容开放“不等于任意翻译，不等于”为所欲为“，”百无禁忌“。
通常，在进行汉化时，词义、游戏内容的表现是首要参考因素；
汉化者以及玩家的用语习惯，作为次要因素。两者结合分析，最终得出结论。
我们结合例子来看一下。
对“原始种”以及“适应种”的名称汉化
我们直接看语言文件。这一部分节选的语言文件，包含“原始种”的名称文本：
- entity.srparasites.pri_longarms.name=Primitive Longarms
- entity.srparasites.pri_manducater.name=Primitive Manducater
- entity.srparasites.pri_summoner.name=Primitive Summoner
- entity.srparasites.pri_reeker.name=Primitive Reeker
- entity.srparasites.pri_yelloweye.name=Primitive Yelloweye
- entity.srparasites.pri_bolster.name=Primitive Bolster
- entity.srparasites.pri_arachnida.name=Primitive Arachnida
- entity.srparasites.pri_devourer.name=Primitive Devourer
从文本上分析，这些实体名称的汉化难度是比较低的，因为它的文本可读性高，没有自造词，
一眼可以基本猜测出它们的设计思路，再辅以一定的游戏内表现分析即可。
我们先对“Primitive Longarms”做做分析。
从词义上说，“Primitive”是“原始种”这一种类的名称，“Longarms”意思是“长的手臂”，
基本没有词义分析的余地，不妨直接考虑用语习惯问题。
对于这类的实体，我们首先考虑一种汉化的模式，即“主词+种类描述”。
在这里，官方译本中的“长臂兽”就是采用了这样的模式。
有些汉化者可能为了突出文本上给玩家的陌生感，会将种类省去，译为“长臂”，这种方式并不合适。
因为这种处理手法通常应用于生造词，比如种族、城市等。
但是，生造词本身作为名字，中文的处理方法一般都是直接音译过来。例子数不胜数，试举几个：
Álfheim → 亚尔夫海姆
有人想要将此词在通行译本中按照“精灵的家”（abode of the Álfar）翻译，这种一般都是没有汉化经验，也没有阅读经验，甚至语言学经验也寥寥的汉化者。
Tamriel → 塔玛瑞尔（出自 The Elder Scrolls 系列）
Novigrad → 诺维格瑞（出自 The Witcher 系列）
我们再举一些正面的例子，即添加了种类限定的实体翻译：
Beholder → 眼魔（出自 DND 系列）
Cooker → 厨师
Screamer → 尖啸尸（出自 State of Decay 2）
一般来说，遇到这种主词词义清晰，可以一定程度鉴别种类的，
采用“主词+种类描述”的处理方法，可以最大程度的降低理解难度。
所以，依照以上的一些讨论，针对于原始种的翻译我们完全可以使用“xx兽”，“xx体”的模式进行翻译。
官方译本中使用“xx兽”的模式，中规中矩。
读者可能会疑惑：为什么不以“-er”结尾的“Longarms”“Yelloweye”和“Arachnida”三者也翻译为“xx兽”呢？
这是由于英语本身的语法产生的限制。
英语在构造“-er”类单词时，前面的部分往往是动词，意即“是做xx事情的东西”，
但是在遇见名词的时候就很难这样构造了。
这三者的取名角度都是从外貌上切入的，所产生的都是名词，所以没有“-er”的后缀。
但是这并不妨碍汉化者将这三者也处理为“xx兽”，使得文本的统一性更强。
对“粗杂（Crude）种”的名称汉化
仍然看语言文件：
- entity.srparasites.host.name=Host
- entity.srparasites.hostii.name=Herd
- entity.srparasites.crux.name=Crux
- entity.srparasites.heed.name=Heed
- entity.srparasites.thrall.name=Thrall
首先我们来逐一分析：
在游戏中，“Herd”是“Host”的进化形态，所以并列讨论。
先做词义分析，前者的词义较多，例如“宿主”“大量”等，其中“宿主”的意义可能性最大，因为比较切题；
再看后者，它的意思就是“群落”。
如果仅从单个来看，前者比较难以挑选词义，但是如果搭配上后者，就能明显看出，
Host 和 Herd 都是想表达“大量”“许多”的意思，这样两者之间的承接关系就更为明显了。
再看看游戏内的实体外观，后者作为前者的进化体，外观看起来就是前者的加长版，上面的骷髅也更多。
我们再从用语上分析。首先我们不可能直接译成“大量”“许多”，这和中文的语法并不贴合。
遇到这样的情况，依然是采用上面的那种模式，即“主词+种类描述”。但也不能译为“大量柱”。
你会发现，无论怎么样，“许多”“大量”这种量词都很难塞入我们的模式当中，中文里并没有这样的用法。
那么类似于这种情况，一种可用的思路是，将“许多”“大量”扩写为“许多的xx”“大量的xx”，
通过扩写处理得到“长有大量xx的柱”的初步翻译后，稍微缩一下句子，就能够得到一个较为适当的译名。
那么，此两者的译文含义就可以处理为“长有大量骷髅的寄生体柱子”“长有更大量骷髅的寄生体柱子”。
在1.9.7的译本中，为了缩写得更为简略，甚至把 Host 直接译为了“骷髅柱”，Herd 译为了“群骷柱”，
更为强调两者之间的进化关系，部分牺牲了 Host 的原文含义。
“Crux”，按照当初想出这个怪物的作者的说法，这个名字基本上是随便找的，
所以我们最好的方法是音译此文本。
然而针对于非专有名词的音译，不能按照专有名词的音译法处理，
尤其是音译完之后非常像是人名的翻译，可以举一些特意改字的音译例子，供大家参考：
Flumph → 呋噜（出自 DND 系列）
Rivellon → 绿维珑（出自 DOS 系列）
“Heed”，词义为“留意”“当心”，目前在游戏内不生成，计划的能力仍未实现，
单独的一个词义让人想破脑袋也无法理解，因而目前除了从外观上下手别无他法。
“Heed”的外观为很多的头颅，如果考虑到“heed”是“head”的一种改写，
可以取“头”的意思，最终定为“多首怪”。
“thrall”太简单了，译为“寄生奴仆”之类的便能切近原意。
对“先天种”的名称汉化
还是直接看语言文件：
- entity.srparasites.carrier_heavy.name=Heavy Carrier
- entity.srparasites.buglin.name=Buglin
- entity.srparasites.mangler.name=Mangler
- entity.srparasites.carrier_flying.name=Flying Carrier
- entity.srparasites.rupter.name=Rupter
基本上按照以上的方法都能得出一个比较恰当的翻译，唯一需要提及的是“Rupter”和“Mangler”，
后者为前者的进化体。前者的译名为“裂兽”，那后者完全不必再去精挑细酌一些小词，
简单地处理为“凶裂兽”等和前者有进化语感的译名即可。
当然，若是你真的很想精挑细选出一个比较好的词，也是可以的，但前提是能够充分地体现出两者之间的关系。
对模组术语的分析
“Hive”，“Colony”两个，前者出现在“Call of the Hive”“Hivestone”等，目前统一为“寄群”，
“Colony”则是模组添加的一种种群机制，目前只是译为“种群”，两者的区分需要等到游戏内容完善后才能知晓，
目前只有“Colony”的内容是较为完善的，“Hive”对应于模组内的哪块内容目前尚未得知。
但为了区分，或可将前者更改为“寄巢”，后者更改为“寄群”，如此更为妥帖。
“Parasitic”和“Infested”，两者指称的是方块的寄生程度的区别，
前者指的是完全寄生转化，而后者只是部分寄生，方块颜色上还未完全转化为寄生种族的黑色。
“Assimilated”，指的是生物被寄生种群同化，此时转化还不完全。
当演化阶段提升后，一名同化种会迅速地转变为适应种，此时才寄生并转化完毕。
对翻译模式的总结
在 Scape and Run: Parasites 逃逸：寄生兽 模组的汉化项目中，汉化者确定了一种固定的译名模式：
通常使用“xx兽”“xx虫”“xx+种类限定词”的译法，如果实体的种类限定不太明显，
则简单的选择“xx体”，可选用的还有“xx魔”“xx怪”等，
但是使用这类在常规语义上有一定价值评判的种类限定字时，还需妥善地考虑清楚词与实体之间的关系，
例如长相特别凶恶、危险程度特别高的，比较适用于“魔”这种字眼。
对于没有办法在中文中使用“xx+种类限定词”译法的原文，进行适当扩写，补足缺失的名词，再在此补足的基础上缩写，
对于完全生造的词汇，则采用音译的方式翻译原文。
需要注意的是，音译时汉化者在对非专名的原文翻译时，不妨采用不是特别常用的音译字，
且此字最好能够从某种角度合适地切入到实体自身的性质中，
这样的译文既未违背原文的发音要求，还能最大程度地给读者带来美感。
对于在进化层级上有先后关系的实体，在译文处理上，考虑在不过多破坏原文词义的前提下，清晰地表露出这一层关系。
总的来说，一定要灵活地将 原文词义 与 游戏内表现 结合在一起，找到最适合的词义。
切忌只是将原文丢入翻译软件中，单靠臆想选出词义。
坏作品：失败的根源
我们选取一个坏作品的例子来分析，同样地，我们会在分析每一个问题之前，展示对应的语言文件片段。
缺乏“构词法”模式，语言风格不统一
- entity.srparasites.pri_longarms.name=长臂
- entity.srparasites.pri_manducater.name=影匿
- entity.srparasites.pri_summoner.name=唤虱
- entity.srparasites.pri_reeker.name=游猎
- entity.srparasites.pri_yelloweye.name=黄眸飞虫
- entity.srparasites.pri_bolster.name=活性缸
- entity.srparasites.pri_arachnida.name=拟蛛
- entity.srparasites.pri_devourer.name=贪噬
- entity.srparasites.host.name=宿主
- entity.srparasites.hostii.name=虫群
- entity.srparasites.crux.name=徘徊者
- entity.srparasites.heed.name=颤栗
- entity.srparasites.thrall.name="奴隶"
- entity.srparasites.overseer.name=监察
- entity.srparasites.bomber_light.name=空袭者
- entity.srparasites.carrier_heavy.name=携虫体
- entity.srparasites.buglin.name=虫灵
- entity.srparasites.mangler.name=绞杀虫
- entity.srparasites.worker.name=工虫
- entity.srparasites.carrier_flying.name=飞行携虫体
- entity.srparasites.rupter.name=断裂虫
- entity.srparasites.warden.name=看守
- entity.srparasites.marauder.name=掠夺者
- entity.srparasites.monarch.name=王虫
- entity.srparasites.grunt.name=仆役
- entity.srparasites.sentry.name=哨兵
- entity.srparasites.kyphosis.name=弯脊
- entity.srparasites.bomber_heavy.name=重型空袭者
- entity.srparasites.carrier_colony.name=噬境妖虫
- entity.srparasites.wraith.name=幻灭
- entity.srparasites.bogle.name=狞兽
- entity.srparasites.haunter.name=祟魔
- entity.srparasites.succor.name=寻觅孢体
- entity.srparasites.anc_dreadnaut.name=空天主宰
- entity.srparasites.anc_overlord.name=远古魔君
各位可以清楚地注意到，在这一段汉化中，
有些使用我们文中提到的“xx+种类限定词”译法，有些又只是使用了一个描述行为的词语。
甚至有一个使用了双引号括住的译文——双引号往往是在翻译人物称号或昵称时使用，
放在此处显然不合适。
在游戏汉化中，采取一种统一的模式（或者说“构词法”），确保整个译文风格上的统一，
才能够符合人类的记忆逻辑，才能够最大程度降低玩家的记忆负担。
如果犯了偏爱使用诡词、奇词，为了这些词语而破坏译文的语法结构的错误，
又或者是在风格上想一出是一出，随意混用不同的“构词法”，
那么就会像上面这样，写出整体上风格混沌不堪的译文，给玩家的阅读理解造成极大负担。
除此之外，在处理实体的进化层级的问题上，译文也暴露了严重的问题。
“绞杀虫”“断裂虫”两者的关系不明朗，“宿主”和“虫群”更是“貌离神也离”。
如果说前面的风格问题只是影响记忆，那后面的关系处理问题就会影响游玩理解了，属于是硬伤。
术语汉化失误，造成大批的错误翻译
- entity.srparasites.carrier_colony.name=噬境妖虫
- entity.srparasites.sim_bear.name=寄生熊
- entity.srparasites.sim_enderman.name=寄生末影人
- entity.srparasites.sim_endermanhead.name=行走头颅（末影人）
- entity.srparasites.sim_adventurer.name=寄染冒险者
- entity.srparasites.sim_adventurerhead.name=行走头颅（冒险者）
- entity.srparasites.sim_bigspider.name=寄生巨蛛
- entity.srparasites.sim_human.name=寄生人类
- entity.srparasites.sim_humanhead.name=行走头颅（人类）
- entity.srparasites.sim_villager.name=寄生村民
- entity.srparasites.sim_villagerhead.name=行走头颅（村民）
- entity.srparasites.sim_cow.name=寄生牛
- entity.srparasites.sim_cowhead.name=行走头颅（牛）
- entity.srparasites.sim_horse.name=寄生马
- entity.srparasites.sim_horsehead.name=行走头颅（马）
- entity.srparasites.sim_pig.name=寄生猪
- entity.srparasites.sim_pighead.name=行走头颅（猪）
- entity.srparasites.sim_sheep.name=寄生羊
- entity.srparasites.sim_sheephead.name=行走头颅（羊）
- entity.srparasites.sim_wolf.name=寄生狼
- entity.srparasites.sim_wolfhead.name=行走头颅（狼）
- entity.srparasites.incompleteform_medium.name=未转化完全状态
- entity.srparasites.incompleteform_small.name=未转化完全状态
- entity.srparasites.sim_dragone.name=寄生末影龙
- entity.srparasites.sim_dragonehead.name=行走头颅（末影龙）
- tile.srparasites.parasiterubble_stone.name=寄生石头
- tile.srparasites.parasiterubbledense_wall.name=寄生压缩石头
- tile.srparasites.parasiterubbledense_biome.name=寄生压缩生物群系石头
前文我们已经讨论过，在 Scape and Run: Parasites 逃逸：寄生兽模组中，
出现的“Hive”“Colony”和“Parasitic”“Assimilated”两组术语；
然而，在这一版作品中，汉化者将“Hive”“Assimilated”和“Parasitic”三者简单混同，
“Hivestone”成了“寄生石”，“Assimilated Bear”译成了“寄生熊”，
这种术语的混同翻译，好比图片打了马赛克，造成了严重的信息量损失，属于明显的错误翻译。
而“Colony Carrier”的翻译“噬境妖虫”，则属于缺乏支撑、凭空构造的译文，
很难从中体现出模组作者想要表达的原意。
总结：好作品和坏作品的区别在哪里
刚才我们经过了一番长篇大论，将针对同一个模组的好坏汉化作品作了详尽的对比分析，
综上所述，我们可以总结出，一个汉化作品“不坏”的及格线，包含以下几条：
- 词义表达准确；
- 译名符合游戏内容在游戏内的实际表现；
- 符合玩家的用语习惯。
在社群中经常有一部分玩家喜欢用“机翻”与否来衡量作品标准，但实际上，比起一棒子打死“机翻”，
我认为上面的及格线要科学得多。
写在最后
这是一段题外话。
我曾经在某个 QQ 群里讨论时说，
我们希望能够公平地评价每一个模组或者整合包的汉化作品，
让好作品得到推广，让坏作品自然淘汰，避免劣币驱逐良币；
这时，一位群友插嘴说：
公平？这年头居然还有人在网络上要公平？
说完扬长而去。
这话听得我很不是滋味。
我作为整合包发布版版主之一，我衷心希望，好作品和坏作品，
是按照它们的质量高低，被公平地对待的。
我们不能听任不好的作品大行其道，更不能因此让好的作品明珠暗投，
我们不能让这些倾尽业余时间和创作热情，
用自己的知识与努力，默默为社群添砖加瓦的这些创作者心寒。
我深刻地明白这项工作任重而道远，“士不可以不弘毅”，路漫漫其修远兮，吾将上下而求索；
如果这是一场千里之行，我希望始于足下，
就从这篇文章发出去、被大家看到的此时此刻开始。
这个坏作品是我的，好孩子不要学，其中犯了很多错误值得作为经验。一开始寄生虫模组这个作品的翻译我只是进来给它改个翻译名而已，不是主要翻译人（清秋和飘寂叶才是），其实我不适合做这种工作，做了的结果就是一坨答辩，这个改版的作品也只是初版的翻译，我是用来给更好的翻译人试刀的（我也把这个东西放在百度网盘了），本来想着还整第二版第三版更替的（如果原本的翻译者不继续工作的话），因为在discord上其中一位翻译者飘寂叶私聊我说可能不再翻译这个模组，我只想着准备帮忙做一下1.9.6之后版本的翻译工作吧，这个模组短时间内要是没人接手我就想着帮帮忙，别落后了翻译工作。
改翻译名的原因，这个是为了避免出现一些不必要的麻烦：我不知道你们看没看过那个动漫（和那个动漫名重了，不排除以后有些小鬼在这方面搞事儿），不管这种麻烦的出现的概率有多小，一旦出现便不好解决（我是被背刺过的人，所以想帮一把，并不是否认翻译者的付出）。更何况这个mod曾被籽岷推广，再小的风险也可能会被扩大，需要警惕。之后的工作在百科我也会负责到底
英文生造词确实让人头疼，尤其是在不了解一些特定背景的情况下
在cfpa从事了几年的汉化工作，虽然我的作品质量不敢保证非常优秀，但是最基础的用词连贯、表达清晰、符合用词习惯等要求对我来说也是非常容易达到的。正如版主所说，机翻 ≠ 劣质产品，一个作品的好与坏不能怪罪到软件上，人家软件又有什么错，这和枪一样，在恐布分子手里就是暴徒，在反恐队员里就是保护我们这些平民的盾。不可否认，我在遇见生僻词与大量语言文本的时候，我无法做到不使用软件来辅助我进行汉化，因为难度对我来说太大了，虽然如此 但在我的作品里是基本看不出来我用了机翻的痕迹。一棒子打死机翻那我只想过去给两个大嘴巴子，自己不行凭什么要怪软件不行 人家软件放在那里，人家有什么错2333
htr1214572831 发表于 2022-11-26 19:50
这个坏作品是我的，好孩子不要学，其中犯了很多错误值得作为经验。一开始寄生虫模组这个作品的翻译我只是进 ...
没事的，慢慢来，我也不敢保证我的作品在初版就非常好，我的也是慢慢来完善的，我相信你一定能行的，加油。
谢谢
还是要追求高品质的啊