本帖最后由 WuzgXY 于 2021-2-7 22:16 编辑
你可以在GitHub页面找到最新的帖子内容。因为一些原因，LWHK决定将帖子的更新全部放置到GitHub上进行，这意味着本站将不会再更新。我们会持续作改动，获取最新内容请至GitHub。
不推荐继续在MCBBS阅读。
前言
粗略查了查，似乎目前站内还没有一个当前版本（指1.12.2以后）的汉化流程教学。其实很多时候不是没有人翻译，而是很多人自己做了个翻译，也想共享出来，却找不到门路，找到人之后，还需要手把手的教学。但其实这些可能都不是完全必要的，如果有足够详细且系统的帖子能够写明一些规范化处理的流程（或者说，正是在书写的过程中，这一过程被规范化了），那么想要参与到汉化工作之中来的人就能很快的上手并充分输出自身的生产力了（悲）。
总而言之，以上所说的就是本帖的目的——当前版本下的汉化流程，以及提交流程，我会尽量将我所知道的流程尽可能的写清楚，方便之后的人查阅和学习。
但在这之前要注意，如果你的英语水平还很差，那么我还是不建议你参与到汉化工作中来。有些人可能觉得，翻译的工作不是查一查词典，找一找语法书就好了吗？这样想的人，学识水平还需要提高，我们可以引用一段本雅明的《译者的任务》中的文段，来阐明这一问题：
模组的文本明显不是文学作品，然而它们总有着部分的相似之处。这里也很明显的说出了一些问题，这些问题至今在大部分翻译者那里都存在着——如果你的句子仅仅是纯粹的词语+语法的堆砌，那么你的译文毫无疑问就是拙劣的译文。而那些甚至连最基本的中文语序以及逻辑都把握不到的翻译者，翻译出来的东西简直惨不忍睹，不忍直视，甚至称不上这里所说的“拙劣的译文”。毫无疑问，这里所说的两种不好的译文，都是由于经验的不足而导致的，这一经验指的不是英语阅读的经验，而是将其从英语转变为中文的经验，这同时考校了你双边的实力。
然而说了这么多，实际上本篇教程和“如何汉化”是没有关系的，如何翻译一个句子，一个词，这些不在我们的教程范围之内。鉴于当今的形式，所以如果你翻译的很烂，那么你有很多机会可以自我训练。本篇解决的是那些“如何递交汉化”以及“除了自身的翻译水准，成为一个合格的Minecraft模组翻译者还需要学会哪些技能”，甚至只是“我对翻译有兴趣，我应该做那些准备”的问题。
对于那些只是对翻译有兴趣，想看看翻译需要做哪些准备而且有些怕麻烦的人而言，只需要看前面两章，即“如何找到模组中的语言文件？”和“如何搭建一个适合翻译工作的工作区域？”即可，最后一章的第一小节关于机翻的也得看，避免出问题。
如果你是想要认真参与到翻译，或者说已经开始了翻译但是觉得自己的专业性有待提高的人，那么其余的章节就是为了你而准备的，掌握了GitHub的相关技巧，你就可以比较专业的管理你自己的翻译长期项目，并且可以与他人一起合作了。
话不多说，我们开始正题。
来自 LWHK organization
不推荐继续在MCBBS阅读。
前言
粗略查了查，似乎目前站内还没有一个当前版本（指1.12.2以后）的汉化流程教学。其实很多时候不是没有人翻译，而是很多人自己做了个翻译，也想共享出来，却找不到门路，找到人之后，还需要手把手的教学。但其实这些可能都不是完全必要的，如果有足够详细且系统的帖子能够写明一些规范化处理的流程（或者说，正是在书写的过程中，这一过程被规范化了），那么想要参与到汉化工作之中来的人就能很快的上手并充分输出自身的生产力了（悲）。
总而言之，以上所说的就是本帖的目的——当前版本下的汉化流程，以及提交流程，我会尽量将我所知道的流程尽可能的写清楚，方便之后的人查阅和学习。
但在这之前要注意，如果你的英语水平还很差，那么我还是不建议你参与到汉化工作中来。有些人可能觉得，翻译的工作不是查一查词典，找一找语法书就好了吗？这样想的人，学识水平还需要提高，我们可以引用一段本雅明的《译者的任务》中的文段，来阐明这一问题：
模组的文本明显不是文学作品，然而它们总有着部分的相似之处。这里也很明显的说出了一些问题，这些问题至今在大部分翻译者那里都存在着——如果你的句子仅仅是纯粹的词语+语法的堆砌，那么你的译文毫无疑问就是拙劣的译文。而那些甚至连最基本的中文语序以及逻辑都把握不到的翻译者，翻译出来的东西简直惨不忍睹，不忍直视，甚至称不上这里所说的“拙劣的译文”。毫无疑问，这里所说的两种不好的译文，都是由于经验的不足而导致的，这一经验指的不是英语阅读的经验，而是将其从英语转变为中文的经验，这同时考校了你双边的实力。
然而说了这么多，实际上本篇教程和“如何汉化”是没有关系的，如何翻译一个句子，一个词，这些不在我们的教程范围之内。鉴于当今的形式，所以如果你翻译的很烂，那么你有很多机会可以自我训练。本篇解决的是那些“如何递交汉化”以及“除了自身的翻译水准，成为一个合格的Minecraft模组翻译者还需要学会哪些技能”，甚至只是“我对翻译有兴趣，我应该做那些准备”的问题。
对于那些只是对翻译有兴趣，想看看翻译需要做哪些准备而且有些怕麻烦的人而言，只需要看前面两章，即“如何找到模组中的语言文件？”和“如何搭建一个适合翻译工作的工作区域？”即可，最后一章的第一小节关于机翻的也得看，避免出问题。
如果你是想要认真参与到翻译，或者说已经开始了翻译但是觉得自己的专业性有待提高的人，那么其余的章节就是为了你而准备的，掌握了GitHub的相关技巧，你就可以比较专业的管理你自己的翻译长期项目，并且可以与他人一起合作了。
话不多说，我们开始正题。
来自 LWHK organization
如何找到模组中的语言文件？
右键你的模组，使用压缩软件的方式进行打开。例如，我使用的是360压缩，那么右键模组文件之后，会出现如下提示：
点开之后是这个样子：
依次进入：assets\模组 ID\lang，就会发现：
1是英文的语言文件，2是中文的语言文件，如果没有2，就说明这一个模组没有中文的翻译，你可以按照其英语文本进行翻译，翻译完之后，把文件改名为2，也就是zh_cn.lang，然后将其放进上述的目录，这样，这样你在游戏中就可以读取到翻译了！
顺带一提，在1.12.2中，语言文件为.lang文件，但在1.12.2以上的版本中，则是.json文件。
如何搭建一个适合翻译工作的工作区域？
如果上述都还是一些人尽皆知的小技巧，那么，接下来的内容就只有翻译工们才会知道了，而且每位翻译工都有自己的舒服的一些工具，有些工具性能较好，有些工具则是功能取胜，这些全看个人选择，所以，以下只是我个人的经验之谈。
在这里，必要的部分只有文本编辑器，在必要的部分之后，我会列出可选的软件，这些软件有一些可以提升你的工作效率，有些则关乎你接下来提交汉化的路径。
文本编辑器
对我而言，我装的文本编辑器有两个：
词典以及在线词典网站
如果你的词汇量足够丰富，那么你在进行翻译的过程中肯定可以顺畅无比。但是实际上很多人根本做不到这样，因此词典软件就必不可少了。
我个人使用的词典是欧路词典：https://dict.eudic.net/
个人感觉还是不错的，安装了桌面版之后，打开划词翻译，打开vsc，只需要选中你想查询的词，即可查出意思，非常好用。
有道词典的桌面版也不错，然而和我的电脑有bug，所以卸了，但是有道的划词检索很快，不像欧陆，有时候划词检索不出来，还会卡住，但这些情况还是较少的。
长句子翻译非常推荐DeepL，令人惊叹的翻译准度，以至于我的哲学论文有很大一部分的内容都是它帮助我翻译的：
https://www.deepl.com/
顺带一些在线词典网站推荐：
https://dict.mcmod.cn/mc模组词典
https://translate.google.cn/谷歌翻译
如果你有苹果移动端设备并且使用方便，直接打开手机，在主屏幕下滑打开搜索栏，输入英语词汇即可翻译。词典种类很丰富，甚至部分支持其它几个印欧语系的语言、日语及汉语。
进阶小技巧
汉化中总是会遇上那种重复率很高，已经定番的词，比如red，green这种颜色，而且这种词往往不会是单个出现，而是一次性出现17个，也就是原版所有颜色的合集。而且，如果一次性出现很多次（比如在装饰类模组里），那给人带来极强的烦躁感。
这时候我们就需要一些小工具了，我个人推荐的是Quicker：https://getquicker.net/
我不负责从头教，你可以自己去搜一搜相关的使用教程。这个小工具用处很大，这里只是列举出其中的一种。
这是我自己写出来的一个小的替换颜色的方法，难度不高，可以自己尝试一下。
或者复制这个，然后粘贴在quicker上：
https://getquicker.net/sharedaction?code=73bfacbd-69c8-41b8-1a2a-08d83f7686c1
=============================================
如果你想实时与同伴一同汉化一个项目，该怎么操作呢？
vsc有个拓展，叫做Live share，登陆之后就可以分享你当前的工作区了！只需以链接的形式发送给朋友，朋友点击，然后接受，就可以实时翻译了！
装了拓展之后，会在vsc的下方显示这个东西：
点击之后，就会提示你登录，登陆之后，按着提示最后点击OK，右下角就会提示，已经将连接置入剪贴板。
发送到朋友那里之后，朋友点进去，将会是这样：
注意，你的朋友也需要登录！！
然后只需点击“打开 Live Share for Vs Code”，就可以完成了！
汉化提交的多种途径
在mc中，汉化提交可以以多种途径进行，但大体上分为：
对于新手而言，如果你确实想要参与到翻译工作中，最好是直接看使用Weblate进行汉化工作页面，因为weblate平台 就是专门为了新手可以方便的和易上手的进行翻译而设计的，所以不要浪费了943的一片良苦用心。
注意，如果你只是想单纯的进行汉化工作，自己使用或是给周围有限的人使用，那么提交汉化是完全没有必要的，这一部分只是写给那些想要融入当前模组翻译汉化圈子的人。但是，如果你翻译了一个看上去从未有人翻译的模组，而且你也不介意让更多的人使用到你的翻译，那么请务必将你的翻译通过各种渠道转交给官方仓库或者是weblate的人员，重复造轮子实在是太花费人力了。对于这样的好心人，我们真的非常感激你的无私行为。
通过GitHub进行汉化工作
如果你想通过GitHub来进行你的汉化流程，那么首先你得了解GitHub是什么，以及它的相关操作。
GitHub入门
本节将会告诉你如何注册GitHub账号，以及GitHub的一些你需要认识的术语，以及这些术语所代表的操作如何进行，这些都是重中之重，很多汉化者被卡在了这一步。所以在这一节里，我会尽可能的配上图片，这样讲解的更为清晰明了。先申明，本人没有编程经验，对于GitHub的操作难免也有疏漏的地方，所以也恳请各位看官斧正一二，感激不尽。
提前声明，对于某些地区的用户来说，GitHub的速度奇慢无比。这时候必须通过特殊手段解决这一问题，但在本篇帖子，我不会介绍这些方法（因为不能）。
申请账号
这是进入GitHub的第一步。首先打开网址：https://github.com/
然后你大概会看见如下的网页：
如果你始终加载不出来，[数据删除]
接着你需要注册一个账号，只需要遵循着引导流程，即可注册一个属于你自己的账号了。如果在注册过程中出现了验证等加载不出来的情况，那么可能也需要使用特殊途径进行网页加载。
注册完毕后，你的界面将会变成这样：
可能在一些小细节上有出入，但无伤大雅，大体一致即可。
到了这里，你就拥有了一个GitHub账号了！
相关概念以及工作流程
在这一小节中，我会先介绍汉化提交的流程，然后再流程之中抓出相应的概念进行讲解。
工作流程大体为找到仓库→Fork→修改Fork过来的仓库→发送Pull Request（拉取请求）到原仓库。
接下来是详细讲解：
为什么需要Fork？
你应该注意到，你其实对别人的仓库是没有修改的权限的（废话）。所以Fork的操作就相当于，你将他的仓库抄了一遍，然后你在这个抄本上进行修改，这是可以的，因为这是你的抄本。
我们引一段资料：
引用自：https://blog.csdn.net/模组uRooKie/article/details/82219255
注意这里的用词，“变成你的”意味着你对于这个仓库有着完全的控制权，包括删除仓库，所以修改你自己的仓库也自然不在话下了。
将仓库clone到本地（可选，较为重要）
当你同时参与了多个项目的汉化之后，你会遇到一个严峻的事实：每天打开游览器，登上GitHub，一旦作者们更新勤奋，你就要开始手忙脚乱的跳网页，找位置。pr自己的仓库，打开自己的仓库。有时候要连续开4、5个页面，才能到你想要的那个仓库位置。一个仓库还好，如果是十多个，那就太累人了，况且GitHub的网页加载速度并不快。
这个时候，最好的解决方案就是将你负责的仓库拉取到本地，你只需要在你的本地就能够将一切任务处理完毕，无需上GitHub的网页版，极为的方便。
这是利用GitHub桌面版将仓库clone到本地的教程：
https://www.jianshu.com/p/1e45b93bd593
只需进行下载并安装了桌面版GitHub之后，执行教程的第二步，就可以将仓库拉取到本地了！接下来的任务就是进一步把你的仓库clone到本地，这样就根本无需打开网页端的GitHub，本地一站式解决！
但是这里还有一个极为严重的问题：一般而言，只有早上**点的时候才能以很快的速度进行clone，一旦不在这个时间区域内，clone的速度就只能听天由命了，而且绝大部分时候都慢的犹如龟爬，仅有 几K/s 的速度。
这里有一些别人写过的方法，可以供你参考：
https://zhuanlan.zhihu.com/p/144016106
改Host时灵时不灵，大部分情况下没什么用。
码云没试过，可以稍微尝试一下。
这是一个成功clone的仓库在GitHub桌面版的样子：
更改之后的操作：
如果你想要更加完善你的本地Git操作，那么这两个扩展必不可少：
安装之后，只要你熟悉GitHub的操作，你将很快明白这两个扩展如何使用。
Pull Request
什么是Pull Request？
这是一个比较清晰的介绍：
https://www.zhihu.com/question/21682976
Pull Request 翻译过来就是“拉取请求”。我们在Fork的仓库里做的修改都只是自己的，和原仓库没有什么关系。但是如果你想把你的修改合并到原仓库，那么，你需要问一问作者，“我能不能把我的修改合并到你的仓库呢？”，这一过程就被叫做“拉取请求”。这一过程实质上就是把你做的修改同步到原仓库那边，但这一过程必须询问过仓库主人，因为“未经许可修改仓库”是不被允许。
网上有极多的pr教程，如果觉得我说的不够清晰，那么请自行百度。只需输入“GitHub Pull Request”即可。
这是一个比较清晰的教程：
https://www.cnblogs.com/zhangjianbin/p/7774073.html
在熟练之后，我们很快就能发现在这里涉及的工作流程的实际样貌：Fork→修改自己的仓库→发送pr。
有些新手可能会有疑问：我直接修改作者仓库里的内容，它也会提示我发起pr，那为什么一定要先Fork再pr呢？
实际上，这样子做确实可以发起pr，但是这并不意味着你没有Fork作者的仓库，我们可以看一个例子（保密起见，我把名字掩去，但这确实是同一个人）：
这是一个新手对一个原作者仓库连续发起的三个pr，可以肯定，这个新手肯定是直接修改了原作者的仓库，并且连续修改了三次，导致发起了三次pr。我们可以看看这三个pr都是从哪里发起的：
可以看到，这位新手对着原作者仓库的分支，连续用三个不同的分支向其发起了pr，而这些分支其实都是来源于他Fork的仓库的：
也就是说，你在修改原作者仓库的时候，GitHub自动的为你Fork了原作者的仓库，并将你的改动应用到你的Fork仓库的不同分支上（然而，改动的转移规则有点不明确），然后再从这些分支发起pr到原作者的仓库那里。这样做实际上没有能够理解pr的本质：pr是实际上是两个分支之间的合并，不仅仅是两个仓库之间的合并，即便在同一个仓库，你也可以用A分支 pr B分支，这是完全可以。
而这种连开三个pr有什么不好的地方？其实从操作层面上来说，没有太多的不好的地方，但这里批判这种连开三个pr的行为不是说他不好，而是在说，这种行为其实说明pr发起者没有理解pr的意义，不仅如此，也不了解GitHub的pr机制，以及这里谈及的Git的工作流程。一个最显而易见的问题是：如果你根本不能理解pr是如何运作的，那么，你应该如何为你的pr追加新的改动？正确的操作是：你得在你pr对应的分支上再继续commit，这些commit会自动推送到这个分支开启的pr上，然后你的追加改动就可以成功的被原作者看到了。如果你不了解pr的机制，你可能就会把追加过后的内容再开一个pr，这样子效率十分低下。
Review
这是一个看上去可以被忽视的过程，但实际上，如果你不想被其它的翻译者锤，你最好做这一道流程。
具体该如何做呢？这里放出LWHK的一个pr，来供大家作为讲解例子。
打开pr页面之后，我们点击此处：
进入到如下界面：
在本页面中，本次pr的所有文件更改内容都会显示出来。将鼠标移至每一行前面，可以发现多了一个小加号：
点击这个+，你就可以针对于这一行的内容进行评论，评论完之后，点击start a Review即可，如果你只是单纯的想发表一下对于这一行的一些想法，那么你可以点击Add single comment，如果突然间没意见了，可以点击cancel。
完成了所有文件的查看之后，你可以点击屏幕右上角的这个。如果你觉得有很多地方需要更改，那么就点击Request changes（请求修改），如果你发现没有什么好改的，你就点击approve（批准，赞成），如果你只是来划水或者你觉得你的意见其实不是非常大，你可以点击comment。
有时候你需要特定的人帮助你Review你的pr，这时候你可以在pr里发送@信息，或者在右边的这里指定他帮助你pr（注意，这一操作只有仓库主人才可以进行！如果你没有该仓库的权限，那么你是无法在右边专门指定人为你Review的，此时你只能@他过来）：
这是@的例子：
再次警告：无论你觉得你的实力多强，只要你不是神，你就会犯错误，而且往往是低级的错误，这些时候如果没有人帮助你Review，那么你的错误将会被别人看到，被别的汉化者锤，如果你不想这样，请你一定要找人帮助你Review！！
最后贴上一些例子，都是我自己的：
https://github.com/CFPAOrg/Minecraft-mod-Language-Package/pull/768
https://github.com/CFPAOrg/Minecraft-mod-Language-Package/pull/779
https://github.com/Phylogeny/JEIEnchantmentInfo/pull/1
我在这里再BB多两句。圈子内有一些翻译工因为各种各样的原因而离开了翻译团队，独自一人进行翻译工作。我个人对这些破事情仅保持愉快的吃瓜态度，对于事件的当事人的人品、性格等也不予置评。我想强调的是，如果你很想为中国的模组翻译做出自己的一份贡献，你最好加入一个像样的翻译团队，而不是学习这样的前辈进行单干。CFPA也好，自己组织也好，在GitHub的也好，在weblate也好，一定要有人帮你Review！！那些出来独自干活的，自由是自由，但是这并不意味着他们的翻译文本就是很好的。
前段时间的匠魂事件我就不说了，改动大，可以，你只要把理由给出来，你说的有理由，说的人信服，那我就能同意你修改这些历史遗留的翻译问题。哪怕你全是自造的词，只要你能给出理由说服我，并且把翻译的词典写出来，我都会赞同。但是，如果你的翻译仅仅是保持了一种形式上的美观，而没有考虑到具体的内容，以及玩家对于历史翻译的认知粘性，那么我会认为你就是在乱翻译，瞎翻译。我不是说你翻译得有问题，而是说你这个翻译不是为了大家翻译，是为了自己而翻译。如果你的翻译，在形式上就是为了大众而翻译的，但是这些翻译有没有经过社区、群众的讨论，那么这些翻译就丧失了自己的本质。一份本真的的翻译不仅是字词上的优美，意义上的准确；还应该包括群众的意见，社区的反馈。这一意见和反馈就是Review的所代表的内容，这也是我希望每个做翻译的人都要找人帮助自己Review的原因。
如何优雅（或者说保证眼睛不瞎）地Review
有两种办法：
与原仓库同步
很多时候，作者更新了仓库，然后你发现他新加入了一些物品，理所当然的，语言文件里也多出了这些新物品的条目。你很快就意识到了这一点：你的仓库落后于作者的仓库，如果你想翻译这些新的内容，那么，你必须把新的内容拉取到你的仓库。最简单的方法就是在你的仓库发起一个反向pr，不是你pr他，而是他pr你。
如果使用是本地操作，就得使用命令行进行fetch + merge了，请参考：
https://www.cnblogs.com/jjliu/p/11775845.html
命令行在本地仓库极为有用，建议认真在网上找教程学习。
原库提交（不推荐新手）
原库提交，指的就是向模组的原仓库提交你的汉化。这一行为无异于宣称你开始负责本模组的汉化，所以不推荐新人这样做，逐步积攒经验之后，才有能力承担一个模组的官中。
官库提交的流程与以上提到的提交流程是一个流程，按着操作即可。
注意，原库提交意味着模组作者不会帮助你Review，你必须自行找人，@他过来帮助你Review才行。
CFPA提交（仅限1.12.2）
自动汉化模组的提交途径是我最推荐新手使用的，因为自动汉化的维护者会帮你Review（逃）。提交手段与上述的并无二致，唯一要注意的是文件存放的位置。
CFPA仓库地址以及项目存放位置
CFPA仓库地址：https://github.com/CFPAOrg/Minecraft-mod-Language-Package
注意，所有的汉化项目 应该被放置到该路径下：
点进这里后，你会发现成吨的已经汉化过了的项目（感谢各位的辛勤付出），你需要将你的文件上传至此处，但你必须适当的存放你的文件。还记得第一节中的模组的压缩包结构吗？即 assets\模组 ID\lang ，你会发现，这里的每个项目也都是这样存放的，你需要手动为你的文件创建一个新的文件夹，并将文件夹命名为模组id，然后在其中再次创建一个名为lang的文件夹，然后再把你的汉化文件放进去。这一操作本质上就是将模组文件夹的结构复刻到仓库里，只不过这一次，多了你新放进去的汉化文件。
注意，你最好把你所翻译的对应英语文本同样放进去，这样会方便后来者查看。其它语言的则不用。
通过GitHub搭建翻译团体，以及进行翻译管理
通过Weblate进行汉化工作
weblate是由业界知名人士酒石酸菌所带领的CFPAorg所搭建的一个翻译平台。上手难度极低，基本没有任何门槛，你只需要在对应的网站登录，选择自己想要翻译的模组，然后就可以开始轻松愉悦的翻译了！模组更新的新条目也会及时的被爬虫爬到库里，非常方便！
但是首先：
其次，请尝试是否可以登上这个网站：https://cfpa.team/
该网站为CFPA的介绍页，你可以在这里获得CFPA的详细信息。如果上不去，可以尝试[数据删除]。
实在不行，可以访问QQ群：630943368，在群内下载文件《weblate 使用说明》进行阅读，由于上手难度真的太低了，所以这里不再赘述。
汉化的一些注意事项
考虑到可能看这篇的大部分都是新手翻译者（废话，大佬本来就不多），所以，除了一些硬件上的需求，还得提前说好一些mc翻译圈内的规矩，避免冲塔/自爆卡车，然后怪我在贴内没有说清楚。
每天一个机翻小技巧，有手就能学废
不允许机翻！！！
机翻是一种极为严重的错误行为，任何在模组翻译圈中的机翻行为都必须完全抵制。在这里我要谨慎的区分开我前面谈到的，利用Quicker帮助替换颜色文本和机翻具有本质性区别。我们抵制机翻不是为了证明某种由人翻译所产生的抽象本质的威严性，而是为了抵制由机翻带来的不通顺的，错误的，乃至于离谱的翻译。这种抵制建立在纯粹的实用层面上，而不是在抽象的行为区分上。这里可以引出一个非常明显的悖谬：面对着一个翻译的比人更像人的机器，我们是应该抵制呢？还是支持呢？如果一个人不使用这样的机器生产翻译，而是自己翻译（质量上肯定差于机器翻译），那么，站在用户的角度，我们是应该支持，还是抵制呢？
我个人不愿意从纯粹的行为角度区分机翻和人翻，这样子似乎走入了某种本质性幻觉之中，我们试图在人翻和机翻之间找到某种本质性裂缝，这一裂缝展开了价值上的区分。然而，这样的裂缝真的存在吗？我认为这是需要辩驳的。
抛开纯粹的思辨，如果我们站在实用的立场上，我们就可以发现，在颜色替换这样的例子上，其与机翻有实用层面的本质区别。在这种情境下，人翻和机翻在纯粹语词的层面没有差别，这意味着在纯粹实用的层面也没有区别，你根本无从分辨哪个是机翻哪个是人翻，你只能凭借非实用层面的因素进行区分。但是这样的区分在我看来，构不成价值上的判断，所以无须批判颜色替换的问题，需要批判的是由机翻带来的坏翻译。
可以参考土球的一篇小文章，或许会对你有一些帮助：https://www.mcbbs.net/thread-899249-1-1.html
蝙蝠的文章也很好：https://www.mcbbs.net/thread-899199-1-1.html
意外情况
有时你会发现，你翻译出来的文本出现了奇怪的问题：明明把翻译文件放进了模组文件内，但游戏中不加载；加载了，居然是乱码；又或者只有单独的一些东西没有加载。这些情况我会在本节中为你们梳理一下，避免被坑。
不加载
不加载又分为两种情况：完全不加载和部分不加载。
完全不加载
部分不加载
部分不加载，则有可能是因为key错误，所谓的key错误，就是语言文件中每一行的左边部分，1.12.2的lang是以 = 为界，1.12.2以上的json文件则为 : 为界，你需要单独检查一下那些有了翻译，但是游戏中没有加载的词条的key。
这是一个修复了key错误的commit：
https://github.com/LWHK/LWHK-Simplified-Chinese-Translation/commit/0c8a8914f5f0124fa31c521997b983d8c556c877#diff-306fabd320470aaa7a1f902a579b1a4a
也有一些情况，那就是根本没有key，作者把文本写进了代码中，这个情况你就需要较高的技术力了。如果你懂代码，那么你就能明白怎么改；如果你不懂代码，在issue界面和作者反馈问题就好了，不必勉强自己。
这是一个issue反馈（@NoName德里奇 的例子）（为了避免误会，提前声明：他本人懂代码）：
https://github.com/Mysticmods/MysticalWorld/issues/126
这个是比较特殊的情况，一般而言，你只需要说清楚哪里没有key，希望作者改进就好了。
如果你确实不精通英语，甚至书面表达都颇为吃力，那么你可以使用这一套模板，填写入相应的信息之后，将中文删掉即可（由德里奇友情提供）：
https://github.com/0999312/Sakura_mod/issues/new
这是一个手动改硬编码的例子（前提是你能看得懂作者是怎么样写的）：
https://github.com/TUsama/Roots/commit/a12922af9aa8b1a17e756444749e4c11bfd6022b
文字乱码
文本都会涉及到一个问题，那就是编码问题。如果你的文本是UTF-8的编码，然而你的游戏使用了GBK的编码方式，那么自然只能出现乱码。详细的可以去网上搜一搜。
在vsc中，下方导航条的右侧会显示出vsc当前是用什么编码打开该文件：
注意，无论是lang还是手册，编码格式一定得是UTF-8，不能是其它的。有些模组自带手册，但是忘记定义了调用Java解码的字符集，此时Java就会调用你的系统默认的字符集进行解码。如果使用UTF-8进入游戏，则会通篇全为乱码。但是这不是你的问题。你要做的就是在他的仓库的issue那里贴上这个pr，作者自然就会明白了。
你可以在GitHub页面找到最新的帖子内容。因为一些原因，LWHK决定将帖子的更新全部放置到GitHub上进行，这意味着本站将不会再更新。我们会持续作改动，获取最新内容请至GitHub。
不推荐继续在MCBBS阅读。
前言
粗略查了查，似乎目前站内还没有一个当前版本（指1.12.2以后）的汉化流程教学。其实很多时候不是没有人翻译，而是很多人自己做了个翻译，也想共享出来，却找不到门路，找到人之后，还需要手把手的教学。但其实这些可能都不是完全必要的，如果有足够详细且系统的帖子能够写明一些规范化处理的流程（或者说，正是在书写的过程中，这一过程被规范化了），那么想要参与到汉化工作之中来的人就能很快的上手并充分输出自身的生产力了（悲）。
总而言之，以上所说的就是本帖的目的——当前版本下的汉化流程，以及提交流程，我会尽量将我所知道的流程尽可能的写清楚，方便之后的人查阅和学习。
但在这之前要注意，如果你的英语水平还很差，那么我还是不建议你参与到汉化工作中来。有些人可能觉得，翻译的工作不是查一查词典，找一找语法书就好了吗？这样想的人，学识水平还需要提高，我们可以引用一段本雅明的《译者的任务》中的文段，来阐明这一问题：
文学作品的基本特性并不是陈述事实或发布信息。然而任何执行传播功能的翻译所传播的只能是信息，也就是说，它传播的只是非本质的东西。这是拙劣译文的特征。但是人们普遍认为为文学作品的实质是信息之外的东西。就连拙劣的译者也承认，文学作品的精髓是某种深不可测的、神秘的、“诗意的”东西；翻译家如要再现这种东西，自己必须也是一个诗人。
模组的文本明显不是文学作品，然而它们总有着部分的相似之处。这里也很明显的说出了一些问题，这些问题至今在大部分翻译者那里都存在着——如果你的句子仅仅是纯粹的词语+语法的堆砌，那么你的译文毫无疑问就是拙劣的译文。而那些甚至连最基本的中文语序以及逻辑都把握不到的翻译者，翻译出来的东西简直惨不忍睹，不忍直视，甚至称不上这里所说的“拙劣的译文”。毫无疑问，这里所说的两种不好的译文，都是由于经验的不足而导致的，这一经验指的不是英语阅读的经验，而是将其从英语转变为中文的经验，这同时考校了你双边的实力。
然而说了这么多，实际上本篇教程和“如何汉化”是没有关系的，如何翻译一个句子，一个词，这些不在我们的教程范围之内。鉴于当今的形式，所以如果你翻译的很烂，那么你有很多机会可以自我训练。本篇解决的是那些“如何递交汉化”以及“除了自身的翻译水准，成为一个合格的Minecraft模组翻译者还需要学会哪些技能”，甚至只是“我对翻译有兴趣，我应该做那些准备”的问题。
对于那些只是对翻译有兴趣，想看看翻译需要做哪些准备而且有些怕麻烦的人而言，只需要看前面两章，即“如何找到模组中的语言文件？”和“如何搭建一个适合翻译工作的工作区域？”即可，最后一章的第一小节关于机翻的也得看，避免出问题。
如果你是想要认真参与到翻译，或者说已经开始了翻译但是觉得自己的专业性有待提高的人，那么其余的章节就是为了你而准备的，掌握了GitHub的相关技巧，你就可以比较专业的管理你自己的翻译长期项目，并且可以与他人一起合作了。
话不多说，我们开始正题。
来自 LWHK organization
2021.12 数据，可能有更多内容
你可以在GitHub页面找到最新的帖子内容。因为一些原因，LWHK决定将帖子的更新全部放置到GitHub上进行，这意味着本站将不会再更新。我们会持续作改动，获取最新内容请至GitHub。不推荐继续在MCBBS阅读。
前言
粗略查了查，似乎目前站内还没有一个当前版本（指1.12.2以后）的汉化流程教学。其实很多时候不是没有人翻译，而是很多人自己做了个翻译，也想共享出来，却找不到门路，找到人之后，还需要手把手的教学。但其实这些可能都不是完全必要的，如果有足够详细且系统的帖子能够写明一些规范化处理的流程（或者说，正是在书写的过程中，这一过程被规范化了），那么想要参与到汉化工作之中来的人就能很快的上手并充分输出自身的生产力了（悲）。
总而言之，以上所说的就是本帖的目的——当前版本下的汉化流程，以及提交流程，我会尽量将我所知道的流程尽可能的写清楚，方便之后的人查阅和学习。
但在这之前要注意，如果你的英语水平还很差，那么我还是不建议你参与到汉化工作中来。有些人可能觉得，翻译的工作不是查一查词典，找一找语法书就好了吗？这样想的人，学识水平还需要提高，我们可以引用一段本雅明的《译者的任务》中的文段，来阐明这一问题：
文学作品的基本特性并不是陈述事实或发布信息。然而任何执行传播功能的翻译所传播的只能是信息，也就是说，它传播的只是非本质的东西。这是拙劣译文的特征。但是人们普遍认为为文学作品的实质是信息之外的东西。就连拙劣的译者也承认，文学作品的精髓是某种深不可测的、神秘的、“诗意的”东西；翻译家如要再现这种东西，自己必须也是一个诗人。
模组的文本明显不是文学作品，然而它们总有着部分的相似之处。这里也很明显的说出了一些问题，这些问题至今在大部分翻译者那里都存在着——如果你的句子仅仅是纯粹的词语+语法的堆砌，那么你的译文毫无疑问就是拙劣的译文。而那些甚至连最基本的中文语序以及逻辑都把握不到的翻译者，翻译出来的东西简直惨不忍睹，不忍直视，甚至称不上这里所说的“拙劣的译文”。毫无疑问，这里所说的两种不好的译文，都是由于经验的不足而导致的，这一经验指的不是英语阅读的经验，而是将其从英语转变为中文的经验，这同时考校了你双边的实力。
然而说了这么多，实际上本篇教程和“如何汉化”是没有关系的，如何翻译一个句子，一个词，这些不在我们的教程范围之内。鉴于当今的形式，所以如果你翻译的很烂，那么你有很多机会可以自我训练。本篇解决的是那些“如何递交汉化”以及“除了自身的翻译水准，成为一个合格的Minecraft模组翻译者还需要学会哪些技能”，甚至只是“我对翻译有兴趣，我应该做那些准备”的问题。
对于那些只是对翻译有兴趣，想看看翻译需要做哪些准备而且有些怕麻烦的人而言，只需要看前面两章，即“如何找到模组中的语言文件？”和“如何搭建一个适合翻译工作的工作区域？”即可，最后一章的第一小节关于机翻的也得看，避免出问题。
如果你是想要认真参与到翻译，或者说已经开始了翻译但是觉得自己的专业性有待提高的人，那么其余的章节就是为了你而准备的，掌握了GitHub的相关技巧，你就可以比较专业的管理你自己的翻译长期项目，并且可以与他人一起合作了。
话不多说，我们开始正题。
来自 LWHK organization
如何找到模组中的语言文件？
右键你的模组，使用压缩软件的方式进行打开。例如，我使用的是360压缩，那么右键模组文件之后，会出现如下提示：
点开之后是这个样子：
依次进入：assets\模组 ID\lang，就会发现：
1是英文的语言文件，2是中文的语言文件，如果没有2，就说明这一个模组没有中文的翻译，你可以按照其英语文本进行翻译，翻译完之后，把文件改名为2，也就是zh_cn.lang，然后将其放进上述的目录，这样，这样你在游戏中就可以读取到翻译了！
顺带一提，在1.12.2中，语言文件为.lang文件，但在1.12.2以上的版本中，则是.json文件。
如何搭建一个适合翻译工作的工作区域？
如果上述都还是一些人尽皆知的小技巧，那么，接下来的内容就只有翻译工们才会知道了，而且每位翻译工都有自己的舒服的一些工具，有些工具性能较好，有些工具则是功能取胜，这些全看个人选择，所以，以下只是我个人的经验之谈。
在这里，必要的部分只有文本编辑器，在必要的部分之后，我会列出可选的软件，这些软件有一些可以提升你的工作效率，有些则关乎你接下来提交汉化的路径。
文本编辑器
对我而言，我装的文本编辑器有两个：
- 轻量编辑器：Notepad++（不再推荐）
原本我是想着说，如果不谈，那么这款软件其实完全是可以推荐的。但是自从我上了它的官网，我发现作者已经到了非常嚣张的地步，所以还是不推荐了，如果想用轻量编辑器，换一个Notepad3**可能会好一些。（据传闻Sublime也是一款不错的轻量编辑器，但我没有尝试过。）
之所以我会说你需要一款轻量编辑器，是因为有时候其实你根本不需要这么多的功能，你只需要一定的语法高亮，看看排版，查查错误，仔细看看翻译质量。这时候，如果再搬出一些庞然大物，那有点杀鸡用牛刀的意味。
- 主要编辑器：VSCode
这位就是我们汉化工作的主要工作区域，这是它的下载地址：https://code.visualstudio.com/
下载完成后，界面是这样的：
在上面我分别标注出了几个需要注意的地方。然后你就可以开始你的工作区搭建了！
首先是点进扩展管理，在上面搜索"Chinese (Simplified) Language Pack for Visual Studio Code"，然后安装第一个跳出的插件，你就会发现你的界面已经变成了中文。
然后你还需要安装以下扩展：
- Minecraft Lang Colorizer（必装）
- Minecraft JSON Schemas（自选）
第一个是使得vsc支持读取lang文件，这是对比图：
需要注意的是，如果你在安装了这个扩展之后，lang文件没有发生变化，你需要手动将一个lang文件设置为lang文件格式，之后，vsc就可以自动为你设置了。
基本上，安装了这些之后，你就可以畅通无阻的进行你的汉化工作了！
词典以及在线词典网站
如果你的词汇量足够丰富，那么你在进行翻译的过程中肯定可以顺畅无比。但是实际上很多人根本做不到这样，因此词典软件就必不可少了。
我个人使用的词典是欧路词典：https://dict.eudic.net/
个人感觉还是不错的，安装了桌面版之后，打开划词翻译，打开vsc，只需要选中你想查询的词，即可查出意思，非常好用。
有道词典的桌面版也不错，然而和我的电脑有bug，所以卸了，但是有道的划词检索很快，不像欧陆，有时候划词检索不出来，还会卡住，但这些情况还是较少的。
长句子翻译非常推荐DeepL，令人惊叹的翻译准度，以至于我的哲学论文有很大一部分的内容都是它帮助我翻译的：
https://www.deepl.com/
顺带一些在线词典网站推荐：
https://dict.mcmod.cn/mc模组词典
https://translate.google.cn/谷歌翻译
如果你有苹果移动端设备并且使用方便，直接打开手机，在主屏幕下滑打开搜索栏，输入英语词汇即可翻译。词典种类很丰富，甚至部分支持其它几个印欧语系的语言、日语及汉语。
进阶小技巧
汉化中总是会遇上那种重复率很高，已经定番的词，比如red，green这种颜色，而且这种词往往不会是单个出现，而是一次性出现17个，也就是原版所有颜色的合集。而且，如果一次性出现很多次（比如在装饰类模组里），那给人带来极强的烦躁感。
这时候我们就需要一些小工具了，我个人推荐的是Quicker：https://getquicker.net/
我不负责从头教，你可以自己去搜一搜相关的使用教程。这个小工具用处很大，这里只是列举出其中的一种。
这是我自己写出来的一个小的替换颜色的方法，难度不高，可以自己尝试一下。
或者复制这个，然后粘贴在quicker上：
https://getquicker.net/sharedaction?code=73bfacbd-69c8-41b8-1a2a-08d83f7686c1
=============================================
如果你想实时与同伴一同汉化一个项目，该怎么操作呢？
vsc有个拓展，叫做Live share，登陆之后就可以分享你当前的工作区了！只需以链接的形式发送给朋友，朋友点击，然后接受，就可以实时翻译了！
装了拓展之后，会在vsc的下方显示这个东西：
点击之后，就会提示你登录，登陆之后，按着提示最后点击OK，右下角就会提示，已经将连接置入剪贴板。
发送到朋友那里之后，朋友点进去，将会是这样：
注意，你的朋友也需要登录！！
然后只需点击“打开 Live Share for Vs Code”，就可以完成了！
汉化提交的多种途径
在mc中，汉化提交可以以多种途径进行，但大体上分为：
- 使用GitHub进行汉化工作。
- 使用Weblate进行汉化工作
对于新手而言，如果你确实想要参与到翻译工作中，最好是直接看使用Weblate进行汉化工作页面，因为weblate平台 就是专门为了新手可以方便的和易上手的进行翻译而设计的，所以不要浪费了943的一片良苦用心。
注意，如果你只是想单纯的进行汉化工作，自己使用或是给周围有限的人使用，那么提交汉化是完全没有必要的，这一部分只是写给那些想要融入当前模组翻译汉化圈子的人。但是，如果你翻译了一个看上去从未有人翻译的模组，而且你也不介意让更多的人使用到你的翻译，那么请务必将你的翻译通过各种渠道转交给官方仓库或者是weblate的人员，重复造轮子实在是太花费人力了。对于这样的好心人，我们真的非常感激你的无私行为。
通过GitHub进行汉化工作
如果你想通过GitHub来进行你的汉化流程，那么首先你得了解GitHub是什么，以及它的相关操作。
GitHub入门
本节将会告诉你如何注册GitHub账号，以及GitHub的一些你需要认识的术语，以及这些术语所代表的操作如何进行，这些都是重中之重，很多汉化者被卡在了这一步。所以在这一节里，我会尽可能的配上图片，这样讲解的更为清晰明了。先申明，本人没有编程经验，对于GitHub的操作难免也有疏漏的地方，所以也恳请各位看官斧正一二，感激不尽。
提前声明，对于某些地区的用户来说，GitHub的速度奇慢无比。这时候必须通过特殊手段解决这一问题，但在本篇帖子，我不会介绍这些方法（因为不能）。
申请账号
这是进入GitHub的第一步。首先打开网址：https://github.com/
然后你大概会看见如下的网页：
如果你始终加载不出来，
接着你需要注册一个账号，只需要遵循着引导流程，即可注册一个属于你自己的账号了。如果在注册过程中出现了验证等加载不出来的情况，那么可能也需要使用特殊途径进行网页加载。
注册完毕后，你的界面将会变成这样：
可能在一些小细节上有出入，但无伤大雅，大体一致即可。
到了这里，你就拥有了一个GitHub账号了！
相关概念以及工作流程
在这一小节中，我会先介绍汉化提交的流程，然后再流程之中抓出相应的概念进行讲解。
工作流程大体为找到仓库→Fork→修改Fork过来的仓库→发送Pull Request（拉取请求）到原仓库。
接下来是详细讲解：
- 在curseforge上找到自己想要汉化的模组，这里随便以一个模组为例：
这里以JEI做个例子，点进去之后，我们可以找到这个图标：
点进这个图标，就可以跳转到这个模组对应的GitHub仓库，这样我们就找到了可以提交汉化的模组的GitHub仓库了。 - Fork
这是JEI的仓库：
我们点击右上角的Fork，将这份仓库Fork为自己的。（如果你不明白为什么需要这样做，你可以跳转到相应的章节查看解释）。 - 修改仓库的内容
到了这一步，你就可以将你之前的汉化提交到 GitHub上了。首先你需要找出你汉化过后的文件，然后将你的文件上传到GitHub。如何上传呢？首先你得找到藏在仓库中的对应文件。还记得第一小节里的那个zh_cn.lang吗？我们已经知道了这一文件在模组文件的哪个位置，而GitHub仓库储存了这一模组的全部文件，那么我们只需要找到仓库中同样的位置就好了。
一番查找之后：
记住这个位置，你的文件应该上传到lang文件夹里，就和在模组里一样！其中的几个文件夹名字是不固定的，取决于模组的名字，相信你一眼就能明白哪些是不固定的了。
这里换了一个仓库，点击圈内按钮，选择upload file，就可以上传文件了！
- 拉取请求
这个仓库是你的，但是你的仓库知识原仓库的一个副本，如果你想要把你的修改合并到原仓库，那么你应该怎么做？这时候我们就需要发送Pull Request（拉取请求，简称PR）到原仓库。
我们先回到原仓库，依次点击：
然后你会在页面的下方看到你和原仓库的对比，游览且发现没问题之后，点击Create Pull Request，然后填上一些你想说的就好了。
注意，在pr的信息填写里，不要给欧美的作者发中文，他们是看不懂的。你的目的是给他们发送汉化文件，不是使用中文和他们聊天！。（但可以用英文和他们聊）
遵照上述的流程，你就可以顺利将你的汉化提交至作者那边了！但是你还是需要稍微等待，毕竟作者也不可能一直守着电脑，等到作者有空的时候，他会回复你，并决定是否采用你的汉化文件。
Fork
为什么需要Fork？
你应该注意到，你其实对别人的仓库是没有修改的权限的（废话）。所以Fork的操作就相当于，你将他的仓库抄了一遍，然后你在这个抄本上进行修改，这是可以的，因为这是你的抄本。
我们引一段资料：
如果你 “Fork” 一个仓库，则是指复制它。特别是当你 Fork 属于别人的仓库时，你将制作他们仓库的完全一样的副本，之后这个副本便变成你的。
引用自：https://blog.csdn.net/模组uRooKie/article/details/82219255
注意这里的用词，“变成你的”意味着你对于这个仓库有着完全的控制权，包括删除仓库，所以修改你自己的仓库也自然不在话下了。
将仓库clone到本地（可选，较为重要）
当你同时参与了多个项目的汉化之后，你会遇到一个严峻的事实：每天打开游览器，登上GitHub，一旦作者们更新勤奋，你就要开始手忙脚乱的跳网页，找位置。pr自己的仓库，打开自己的仓库。有时候要连续开4、5个页面，才能到你想要的那个仓库位置。一个仓库还好，如果是十多个，那就太累人了，况且GitHub的网页加载速度并不快。
这个时候，最好的解决方案就是将你负责的仓库拉取到本地，你只需要在你的本地就能够将一切任务处理完毕，无需上GitHub的网页版，极为的方便。
这是利用GitHub桌面版将仓库clone到本地的教程：
https://www.jianshu.com/p/1e45b93bd593
只需进行下载并安装了桌面版GitHub之后，执行教程的第二步，就可以将仓库拉取到本地了！接下来的任务就是进一步把你的仓库clone到本地，这样就根本无需打开网页端的GitHub，本地一站式解决！
但是这里还有一个极为严重的问题：一般而言，只有早上**点的时候才能以很快的速度进行clone，一旦不在这个时间区域内，clone的速度就只能听天由命了，而且绝大部分时候都慢的犹如龟爬，仅有 几K/s 的速度。
这里有一些别人写过的方法，可以供你参考：
https://zhuanlan.zhihu.com/p/144016106
改Host时灵时不灵，大部分情况下没什么用。
码云没试过，可以稍微尝试一下。
这是一个成功clone的仓库在GitHub桌面版的样子：
更改之后的操作：
如果你想要更加完善你的本地Git操作，那么这两个扩展必不可少：
- GitHub Pull Requests and Issues
- GitLens-Git supercharged
安装之后，只要你熟悉GitHub的操作，你将很快明白这两个扩展如何使用。
Pull Request
什么是Pull Request？
这是一个比较清晰的介绍：
https://www.zhihu.com/question/21682976
Pull Request 翻译过来就是“拉取请求”。我们在Fork的仓库里做的修改都只是自己的，和原仓库没有什么关系。但是如果你想把你的修改合并到原仓库，那么，你需要问一问作者，“我能不能把我的修改合并到你的仓库呢？”，这一过程就被叫做“拉取请求”。这一过程实质上就是把你做的修改同步到原仓库那边，但这一过程必须询问过仓库主人，因为“未经许可修改仓库”是不被允许。
网上有极多的pr教程，如果觉得我说的不够清晰，那么请自行百度。只需输入“GitHub Pull Request”即可。
这是一个比较清晰的教程：
https://www.cnblogs.com/zhangjianbin/p/7774073.html
在熟练之后，我们很快就能发现在这里涉及的工作流程的实际样貌：Fork→修改自己的仓库→发送pr。
有些新手可能会有疑问：我直接修改作者仓库里的内容，它也会提示我发起pr，那为什么一定要先Fork再pr呢？
实际上，这样子做确实可以发起pr，但是这并不意味着你没有Fork作者的仓库，我们可以看一个例子（保密起见，我把名字掩去，但这确实是同一个人）：
这是一个新手对一个原作者仓库连续发起的三个pr，可以肯定，这个新手肯定是直接修改了原作者的仓库，并且连续修改了三次，导致发起了三次pr。我们可以看看这三个pr都是从哪里发起的：
可以看到，这位新手对着原作者仓库的分支，连续用三个不同的分支向其发起了pr，而这些分支其实都是来源于他Fork的仓库的：
也就是说，你在修改原作者仓库的时候，GitHub自动的为你Fork了原作者的仓库，并将你的改动应用到你的Fork仓库的不同分支上（然而，改动的转移规则有点不明确），然后再从这些分支发起pr到原作者的仓库那里。这样做实际上没有能够理解pr的本质：pr是实际上是两个分支之间的合并，不仅仅是两个仓库之间的合并，即便在同一个仓库，你也可以用A分支 pr B分支，这是完全可以。
而这种连开三个pr有什么不好的地方？其实从操作层面上来说，没有太多的不好的地方，但这里批判这种连开三个pr的行为不是说他不好，而是在说，这种行为其实说明pr发起者没有理解pr的意义，不仅如此，也不了解GitHub的pr机制，以及这里谈及的Git的工作流程。一个最显而易见的问题是：如果你根本不能理解pr是如何运作的，那么，你应该如何为你的pr追加新的改动？正确的操作是：你得在你pr对应的分支上再继续commit，这些commit会自动推送到这个分支开启的pr上，然后你的追加改动就可以成功的被原作者看到了。如果你不了解pr的机制，你可能就会把追加过后的内容再开一个pr，这样子效率十分低下。
Review
这是一个看上去可以被忽视的过程，但实际上，如果你不想被其它的翻译者锤，你最好做这一道流程。
具体该如何做呢？这里放出LWHK的一个pr，来供大家作为讲解例子。
打开pr页面之后，我们点击此处：
进入到如下界面：
在本页面中，本次pr的所有文件更改内容都会显示出来。将鼠标移至每一行前面，可以发现多了一个小加号：
点击这个+，你就可以针对于这一行的内容进行评论，评论完之后，点击start a Review即可，如果你只是单纯的想发表一下对于这一行的一些想法，那么你可以点击Add single comment，如果突然间没意见了，可以点击cancel。
完成了所有文件的查看之后，你可以点击屏幕右上角的这个。如果你觉得有很多地方需要更改，那么就点击Request changes（请求修改），如果你发现没有什么好改的，你就点击approve（批准，赞成），如果你只是来划水或者你觉得你的意见其实不是非常大，你可以点击comment。
有时候你需要特定的人帮助你Review你的pr，这时候你可以在pr里发送@信息，或者在右边的这里指定他帮助你pr（注意，这一操作只有仓库主人才可以进行！如果你没有该仓库的权限，那么你是无法在右边专门指定人为你Review的，此时你只能@他过来）：
这是@的例子：
再次警告：无论你觉得你的实力多强，只要你不是神，你就会犯错误，而且往往是低级的错误，这些时候如果没有人帮助你Review，那么你的错误将会被别人看到，被别的汉化者锤，如果你不想这样，请你一定要找人帮助你Review！！
最后贴上一些例子，都是我自己的：
https://github.com/CFPAOrg/Minecraft-mod-Language-Package/pull/768
https://github.com/CFPAOrg/Minecraft-mod-Language-Package/pull/779
https://github.com/Phylogeny/JEIEnchantmentInfo/pull/1
我在这里再BB多两句。圈子内有一些翻译工因为各种各样的原因而离开了翻译团队，独自一人进行翻译工作。我个人对这些破事情仅保持愉快的吃瓜态度，对于事件的当事人的人品、性格等也不予置评。我想强调的是，如果你很想为中国的模组翻译做出自己的一份贡献，你最好加入一个像样的翻译团队，而不是学习这样的前辈进行单干。CFPA也好，自己组织也好，在GitHub的也好，在weblate也好，一定要有人帮你Review！！那些出来独自干活的，自由是自由，但是这并不意味着他们的翻译文本就是很好的。
前段时间的匠魂事件我就不说了，改动大，可以，你只要把理由给出来，你说的有理由，说的人信服，那我就能同意你修改这些历史遗留的翻译问题。哪怕你全是自造的词，只要你能给出理由说服我，并且把翻译的词典写出来，我都会赞同。但是，如果你的翻译仅仅是保持了一种形式上的美观，而没有考虑到具体的内容，以及玩家对于历史翻译的认知粘性，那么我会认为你就是在乱翻译，瞎翻译。我不是说你翻译得有问题，而是说你这个翻译不是为了大家翻译，是为了自己而翻译。如果你的翻译，在形式上就是为了大众而翻译的，但是这些翻译有没有经过社区、群众的讨论，那么这些翻译就丧失了自己的本质。一份本真的的翻译不仅是字词上的优美，意义上的准确；还应该包括群众的意见，社区的反馈。这一意见和反馈就是Review的所代表的内容，这也是我希望每个做翻译的人都要找人帮助自己Review的原因。
如何优雅（或者说保证眼睛不瞎）地Review
有两种办法：
- 在网页端Review
GitHub的网页端是亮色的，简直就是文本查阅的噩梦环境。在GitHub上保持亮色Review不出10分钟，我就开始意识模糊了。为了保护自己的眼睛，我必须找到一种适合我这种变成外行的方法，来改变GitHub的主题颜色。
我个人的解决方法是使用扩展stylus。教程我就不讲了，自行搜索。目标的主题是material-github，点击链接即可进行安装。安装之后，你就会发现，你的GitHub变成暗色的啦！
在GitHub网页端进行Review，在功能上会比在本地Review要更加丰富。一个是一些复杂的语法，在网页端只需点一点按钮就可以唤出了，另一个是一些扩展，可以更好地帮助你说明Review的内容。譬如这款PR Review Priority，你可以迅速的为你的每一条Review标注你对于这一Review的态度，这里是一个大规模运用的例子：https://github.com/CFPAOrg/Minecraft-Mod-Language-Package/pull/779
在这一例子里，我大量运用了优先度的描述，这样PR递交者就能够明白那些Review是比较重要的，那些Review是可以与我讨论的，不会出现误会的情况。
在遇到更改了大量文件的PR时，你会需要用到Github Turbo PR，安装之后，只要在File changes页面点击扩展进行优化，你就会发现页面的流畅度可以得到大幅提升。然而 这个扩展有一些bug，可以在安装页面上查询到，这里就不复述了。 - 本地Review
需要使用到之前提到的vsc插件（按：或许其它的编辑器也有，但是我没用过）：Github Pull Reguests and Issues
安装了之后，你就可以在本地访问到远程仓库的PR了：
点开All进行PR查看（注意，不仅可以访问到origin仓库的PR，还能访问到upstream仓库的PR）（需要特殊的网络支持）
按下图的顺序点击之后，扩展会专门拉出一条分支，这条分支会与你网页端的PR页面实时同步（虽然会因为网络原因而有一些延迟）。以下是图片：
一些注意事项，如下图：
但是要注意，Review的结束似乎还是要在网页端进行的，你得在网页端声明，这次的Review是comment，Request changes还是approve。
如果网页端有文件的更新，扩展会提示你将这些改动Pull到本地。
与原仓库同步
很多时候，作者更新了仓库，然后你发现他新加入了一些物品，理所当然的，语言文件里也多出了这些新物品的条目。你很快就意识到了这一点：你的仓库落后于作者的仓库，如果你想翻译这些新的内容，那么，你必须把新的内容拉取到你的仓库。最简单的方法就是在你的仓库发起一个反向pr，不是你pr他，而是他pr你。
如果使用是本地操作，就得使用命令行进行fetch + merge了，请参考：
https://www.cnblogs.com/jjliu/p/11775845.html
命令行在本地仓库极为有用，建议认真在网上找教程学习。
原库提交（不推荐新手）
原库提交，指的就是向模组的原仓库提交你的汉化。这一行为无异于宣称你开始负责本模组的汉化，所以不推荐新人这样做，逐步积攒经验之后，才有能力承担一个模组的官中。
官库提交的流程与以上提到的提交流程是一个流程，按着操作即可。
注意，原库提交意味着模组作者不会帮助你Review，你必须自行找人，@他过来帮助你Review才行。
CFPA提交（仅限1.12.2）
自动汉化模组的提交途径是我最推荐新手使用的，因为自动汉化的维护者会帮你Review（逃）。提交手段与上述的并无二致，唯一要注意的是文件存放的位置。
CFPA仓库地址以及项目存放位置
CFPA仓库地址：https://github.com/CFPAOrg/Minecraft-mod-Language-Package
注意，所有的汉化项目 应该被放置到该路径下：
点进这里后，你会发现成吨的已经汉化过了的项目（感谢各位的辛勤付出），你需要将你的文件上传至此处，但你必须适当的存放你的文件。还记得第一节中的模组的压缩包结构吗？即 assets\模组 ID\lang ，你会发现，这里的每个项目也都是这样存放的，你需要手动为你的文件创建一个新的文件夹，并将文件夹命名为模组id，然后在其中再次创建一个名为lang的文件夹，然后再把你的汉化文件放进去。这一操作本质上就是将模组文件夹的结构复刻到仓库里，只不过这一次，多了你新放进去的汉化文件。
注意，你最好把你所翻译的对应英语文本同样放进去，这样会方便后来者查看。其它语言的则不用。
通过GitHub搭建翻译团体，以及进行翻译管理
通过Weblate进行汉化工作
weblate是由业界知名人士酒石酸菌所带领的CFPAorg所搭建的一个翻译平台。上手难度极低，基本没有任何门槛，你只需要在对应的网站登录，选择自己想要翻译的模组，然后就可以开始轻松愉悦的翻译了！模组更新的新条目也会及时的被爬虫爬到库里，非常方便！
但是首先：
其次，请尝试是否可以登上这个网站：https://cfpa.team/
该网站为CFPA的介绍页，你可以在这里获得CFPA的详细信息。如果上不去，可以尝试
实在不行，可以访问QQ群：630943368，在群内下载文件《weblate 使用说明》进行阅读，由于上手难度真的太低了，所以这里不再赘述。
汉化的一些注意事项
考虑到可能看这篇的大部分都是新手翻译者（废话，大佬本来就不多），所以，除了一些硬件上的需求，还得提前说好一些mc翻译圈内的规矩，避免冲塔/自爆卡车，然后怪我在贴内没有说清楚。
每天一个机翻小技巧，有手就能学废
不允许机翻！！！
机翻是一种极为严重的错误行为，任何在模组翻译圈中的机翻行为都必须完全抵制。在这里我要谨慎的区分开我前面谈到的，利用Quicker帮助替换颜色文本和机翻具有本质性区别。我们抵制机翻不是为了证明某种由人翻译所产生的抽象本质的威严性，而是为了抵制由机翻带来的不通顺的，错误的，乃至于离谱的翻译。这种抵制建立在纯粹的实用层面上，而不是在抽象的行为区分上。这里可以引出一个非常明显的悖谬：面对着一个翻译的比人更像人的机器，我们是应该抵制呢？还是支持呢？如果一个人不使用这样的机器生产翻译，而是自己翻译（质量上肯定差于机器翻译），那么，站在用户的角度，我们是应该支持，还是抵制呢？
我个人不愿意从纯粹的行为角度区分机翻和人翻，这样子似乎走入了某种本质性幻觉之中，我们试图在人翻和机翻之间找到某种本质性裂缝，这一裂缝展开了价值上的区分。然而，这样的裂缝真的存在吗？我认为这是需要辩驳的。
抛开纯粹的思辨，如果我们站在实用的立场上，我们就可以发现，在颜色替换这样的例子上，其与机翻有实用层面的本质区别。在这种情境下，人翻和机翻在纯粹语词的层面没有差别，这意味着在纯粹实用的层面也没有区别，你根本无从分辨哪个是机翻哪个是人翻，你只能凭借非实用层面的因素进行区分。但是这样的区分在我看来，构不成价值上的判断，所以无须批判颜色替换的问题，需要批判的是由机翻带来的坏翻译。
可以参考土球的一篇小文章，或许会对你有一些帮助：https://www.mcbbs.net/thread-899249-1-1.html
蝙蝠的文章也很好：https://www.mcbbs.net/thread-899199-1-1.html
意外情况
有时你会发现，你翻译出来的文本出现了奇怪的问题：明明把翻译文件放进了模组文件内，但游戏中不加载；加载了，居然是乱码；又或者只有单独的一些东西没有加载。这些情况我会在本节中为你们梳理一下，避免被坑。
不加载
不加载又分为两种情况：完全不加载和部分不加载。
完全不加载
- 检查文件名是否正确。
一般而言，在1.12.2中，中文文件可能会有两种名字 ，一种为zh_cn.lang，一种为zh_CN.lang，看似只有尾巴的大小写差异，但实际上，如果英语语言文件的尾巴是大写的，然后你放了一个小写尾巴的中文文件进去，它是不会加载的。中文文件的尾巴的大小写必须跟随英文文件尾巴的大小写。
这是一个错误的例子：
这是一个正确例子：
1.12.2以上则不是lang文件，而是.json文件。似乎.json文件没有尾巴大小写的说法，全是小写（至少我没见过）。 - 检查文件位置，这个不用我多说。
部分不加载
部分不加载，则有可能是因为key错误，所谓的key错误，就是语言文件中每一行的左边部分，1.12.2的lang是以 = 为界，1.12.2以上的json文件则为 : 为界，你需要单独检查一下那些有了翻译，但是游戏中没有加载的词条的key。
这是一个修复了key错误的commit：
https://github.com/LWHK/LWHK-Simplified-Chinese-Translation/commit/0c8a8914f5f0124fa31c521997b983d8c556c877#diff-306fabd320470aaa7a1f902a579b1a4a
也有一些情况，那就是根本没有key，作者把文本写进了代码中，这个情况你就需要较高的技术力了。如果你懂代码，那么你就能明白怎么改；如果你不懂代码，在issue界面和作者反馈问题就好了，不必勉强自己。
这是一个issue反馈（@NoName德里奇 的例子）（为了避免误会，提前声明：他本人懂代码）：
https://github.com/Mysticmods/MysticalWorld/issues/126
这个是比较特殊的情况，一般而言，你只需要说清楚哪里没有key，希望作者改进就好了。
如果你确实不精通英语，甚至书面表达都颇为吃力，那么你可以使用这一套模板，填写入相应的信息之后，将中文删掉即可（由德里奇友情提供）：
https://github.com/0999312/Sakura_mod/issues/new
这是一个手动改硬编码的例子（前提是你能看得懂作者是怎么样写的）：
https://github.com/TUsama/Roots/commit/a12922af9aa8b1a17e756444749e4c11bfd6022b
文字乱码
文本都会涉及到一个问题，那就是编码问题。如果你的文本是UTF-8的编码，然而你的游戏使用了GBK的编码方式，那么自然只能出现乱码。详细的可以去网上搜一搜。
在vsc中，下方导航条的右侧会显示出vsc当前是用什么编码打开该文件：
注意，无论是lang还是手册，编码格式一定得是UTF-8，不能是其它的。有些模组自带手册，但是忘记定义了调用Java解码的字符集，此时Java就会调用你的系统默认的字符集进行解码。如果使用UTF-8进入游戏，则会通篇全为乱码。但是这不是你的问题。你要做的就是在他的仓库的issue那里贴上这个pr，作者自然就会明白了。
看着不错，等我系统好了之后咱几个再写一篇《积累》讲讲具体内容吧。
WuzgXY 发表于 2020-8-14 15:18
看着不错，等我系统好了之后咱几个再写一篇《积累》讲讲具体内容吧。
那有点困难
看了帖子 学到了很多
这个条目下的第一张图片裂开了： 相关概念以及工作流程
这个条目下的第一张图片裂开了： 相关概念以及工作流程
喵鱿 发表于 2020-8-14 16:12
看了帖子 学到了很多
这个条目下的第一张图片裂开了： 相关概念以及工作流程 ...
应该是暂时性的网络问题，我这边正常加载。
不过sm.ms时不时抽风，也习惯了。。
学到了，帮助很大，感谢贴主
感谢楼主的分享
哇这个目录这个贴 厉害了 给大佬个赞
想学编程 学不会
泻药，我来捧捧场。
Wuzg大佬的文笔我是很震撼的，我自愧不如。
Wuzg佬说汉化考验的是英语水平，我从我个人的翻译经验来看，有一定道理。
但是我认为模组汉化更关键的东西在于“汉语”的水平。
你不必放出很好的洋屁，但是汉语水平是真的必须过硬。
我们面对的任务毕竟不是四六级的翻译题，“信达雅”的三条标准，在翻译题那里，“信”在第一位。
你要准确无误，不丢失句子的意思。
但是在MC模组翻译汉化这里，我认为“达”是第一位，变成了“达信雅”。
如果你的语言水平真的略微逊色，碰上一个作者在文段里玩梗、用 Urban Dictionary 里面的流行英语词汇，
或者作者被英语自身又臭又长的固有缺陷所限制，用了一段长句描述一个复杂的游戏机制，
类似这样的情况时，你大可以砍掉一些“信”层面的准确无误、“雅”层面的意涵传达，
先把句子通顺地用汉语解释出来，“解释”，不是翻译。
我们做汉化的目的是什么？推广模组。
玩家拿了没翻译的mod不会玩，你没法推广；
玩家拿了翻译得生硬机械、又长又难懂的mod，也不是很会玩，也没法推广。
你今天发现一个mod好玩，没汉化，第一步做什么？把mod里面的外语文本解释一遍，
通顺、简洁、易懂，你就赢了。
准确和优雅怎么办？LWHK小组和CFPA Team人才济济，交给比你牛逼的大佬来写完全可以。
但是你要比这些大佬具有更敏锐的发现值得翻译的有趣mod的眼光，
以及愿意不怕麻烦，提供第一手翻译资料的耐心和决心。
总的来说，我相信具有一定英语水平，而且语文学得还行的佬们，都可以参与到mod汉化的工作中来。
在这里我说两句骚话，我就菜得很，但是交错次元的代码贡献我排在第10，全是提交汉化。
靠的是什么？有耐心，敢于肝；有一定水平，但也敢于挑战自己啃硬骨头翻译；不怕丢人，敢于献丑。
献丑了.jpg
以上。
Wuzg大佬的文笔我是很震撼的，我自愧不如。
Wuzg佬说汉化考验的是英语水平，我从我个人的翻译经验来看，有一定道理。
但是我认为模组汉化更关键的东西在于“汉语”的水平。
你不必放出很好的洋屁，但是汉语水平是真的必须过硬。
我们面对的任务毕竟不是四六级的翻译题，“信达雅”的三条标准，在翻译题那里，“信”在第一位。
你要准确无误，不丢失句子的意思。
但是在MC模组翻译汉化这里，我认为“达”是第一位，变成了“达信雅”。
如果你的语言水平真的略微逊色，碰上一个作者在文段里玩梗、用 Urban Dictionary 里面的流行英语词汇，
或者作者被英语自身又臭又长的固有缺陷所限制，用了一段长句描述一个复杂的游戏机制，
类似这样的情况时，你大可以砍掉一些“信”层面的准确无误、“雅”层面的意涵传达，
先把句子通顺地用汉语解释出来，“解释”，不是翻译。
我们做汉化的目的是什么？推广模组。
玩家拿了没翻译的mod不会玩，你没法推广；
玩家拿了翻译得生硬机械、又长又难懂的mod，也不是很会玩，也没法推广。
你今天发现一个mod好玩，没汉化，第一步做什么？把mod里面的外语文本解释一遍，
通顺、简洁、易懂，你就赢了。
准确和优雅怎么办？LWHK小组和CFPA Team人才济济，交给比你牛逼的大佬来写完全可以。
但是你要比这些大佬具有更敏锐的发现值得翻译的有趣mod的眼光，
以及愿意不怕麻烦，提供第一手翻译资料的耐心和决心。
总的来说，我相信具有一定英语水平，而且语文学得还行的佬们，都可以参与到mod汉化的工作中来。
在这里我说两句骚话，我就菜得很，但是交错次元的代码贡献我排在第10，全是提交汉化。
靠的是什么？有耐心，敢于肝；有一定水平，但也敢于挑战自己啃硬骨头翻译；不怕丢人，敢于献丑。
献丑了.jpg
以上。
谢谢教学，学习一波，冲冲冲
Github页面链接修一下呗，404了。
原来的：
https://github.com/LWHK/Passages ... 5%8F%91/Markdown.md
应改为：
https://github.com/LWHK/Minecraf ... 5%8F%91/Markdown.md
原来的：
https://github.com/LWHK/Passages ... 5%8F%91/Markdown.md
应改为：
https://github.com/LWHK/Minecraf ... 5%8F%91/Markdown.md
墨穷 发表于 2023-1-31 10:43
Github页面链接修一下呗，404了。
原来的：
https://github.com/LWHK/Passages/blob/master/Minecraft%20%E ...
能找到就没什么必要修。