Minecraft 模组翻译：从入门到开发
前言
粗略查了查，似乎目前还没有一个当前风行版本（指 1.12.2 及以后）的汉化流程教学。其实很多时候不见得没有人翻译，而是很多人自己试着做了翻译，但完全不合规范；对上了格式的规范，却又质量不高；终于做完了想共享出来，然而找不到门路，还得低效率地找人帮忙扩散（悲）。其实这些都可能是可避免的 —— 如果有足够详细且描述系统的文章能够写明部分规范化处理的流程（也可以说这一流程正是在书写的过程中被规范化了的），那么想要参与到汉化工作之中来的人就能很快地上手并充分输出自身的生产力了。
本文的目的就是写出上述的内容 —— 当前版本下的汉化及提交流程。我们会尽量将我们所知道的流程写清楚，以便后来者查阅和学习。
在此之前还要再说明一点。如果你的英语水平还很差，即使你的热情相当高涨，我们仍然不建议你参与到汉化工作中来。有些人可能觉得翻译工作查一查词典、找一找语法书，或者背一背单词就完事了，然而这么想其实是完全不正确的；如果你有这种想法，你的水平可能还需要提高。我们可以引用本雅明《译作者的任务》中的一个文段来阐明这一点：
……文学作品的基本特性并不是陈述事实或发布信息。然而任何执行传播功能的翻译所传播的只能是信息，也就是说，它传播的只是非本质的东西。
这是拙劣译文的特征。但是人们普遍认为文学作品的实质是信息之外的东西。而即使拙劣的译者也承认，文学作品的精髓是某种深不可测的、神秘的、“诗意的”东西；翻译家若要再现这种东西，自己必须也是一个诗人。
多数模组文本明显不是文学作品，然而对它的翻译追求却能与 Minecraft 翻译界公认应追求的翻译之标准（至少对于绝大多数的文本翻译而言也是如此）进行对照。对于文学作品的翻译而言，其基本特性并不是陈述事实或发布信息，但对于 MC 的翻译，精确描述和准确表达总是最重要的，因为若是缺失了这一要素，这些不够准确的翻译就会严重影响游戏的进程推进。因此在翻译中，“信”总是排在最先的，“达”是我们致力于追求的，“雅”则是力所能及者行之事，不能行则应退而求其次，无需强求。“信”首先要求译者对原版词汇烂熟于心，避免在翻译时使用了错误的翻译而引人发笑；其次要求了解一些约定俗成的词语的翻译，可于 MCW 查到相关资料；此外由于各方机翻小能手整出的机翻中好笑的文本频频出现，机翻相关内容甚至成为了 一个梗。“达”则要求长文本翻译尽可能清新流畅，至少像是人能说出来的，而不是机器翻译的。我们曾经见到过一份文本，这份文本的作者在进行过大量机翻以及其后的阅读后已经不再能清晰地把握中文文字的脉络了，于是他自己原创出的这份文本都被我们误判为了机翻内容。毫无疑问，这种水平较低的译文是经验不足导致的，而这一经验指的远不止英语阅读的经验，更是将英语文本转变为有逻辑脉络的中文句子的经验。也就是说，翻译工作同时考校了你双边的实力。最后的“雅”则是那些有较高的语言素养的人才能够达到的，它要求译本能在艺术层面上被欣赏，鉴于我们自身水平较差，此处就不多在网络上逼逼赖赖了。
然而哔哩吧啦了一大堆，本篇教程和“如何汉化”并无关联。如何翻译一个句子、一个词，这些不在本文的指导范围之内。当今的九年义务教育制度普及效果良好，如果你因为年龄不大而翻译得很烂，你还有很多机会可以接受更好的教育以及自我训练。本文真正希望解决的是那些类似于“如何投交汉化文本”以及“除了自身的翻译水准，成为一个合格的 Minecraft 模组翻译者还需要学会哪些技能”，甚至只是“我对翻译有兴趣，我应该做哪些准备”的问题。
对于那些只是对翻译有兴趣，想看看翻译需要做哪些准备然而有些怕麻烦的人而言，仅看前面两章（找到语言文件 和 搭建工作区域）即可。当然，最后一章的第一小节（关于机翻的部分）也得看，以尽可能避免出问题。在这之后，你可以根据自己的兴趣决定是否继续阅读。
如果你想要认真参与到社区的翻译工作中或已经开始了为社区服务的翻译工作，但仍觉得自己的专业性有待提高，那么你可以看看其他的章节。掌握了 GitHub 的相关技巧，你就可以比较专业地管理你自己的翻译长期项目，甚至与他人合作了。
提问之前，请先阅读《提问的智慧》。如果我们判断你的问题并未遵守此文中的建议，我们将不予回复。
我们默认读者有对 Minecraft 及其 模组 的基本认知。如对模组内容有疑问，可以访问 MC百科。（仍抱有疑问的读者也可查看 百科的模组简介）
话不宜多，我们开始正题。
找到语言文件
右击你的模组文件（扩展名为 .jar 的压缩包），使用压缩软件打开。例如，我（清秋）使用的是 Bandizip（写教程的时候使用的是 360 压缩）（亦可使用 7-Zip），那么右击模组文件之后，会出现如下提示：
单击之后是这个样子的：
依次进入 assets\ModID\lang（有一些模组的文件结构与通常的不同，但是一般情况下语言文件都会位于一个名为 lang 的目录下，如果本文提到的位置并无语言文件，可以使用文件查找功能自行寻找）就能发现：
1 是英文的语言文件，而 2 是中文的语言文件，如果没有 2，就基本说明了这个模组没有中文的翻译（例外：1.12.2 和 1.16 的情况下有可能 CFPA 有而模组本体没有，为了防止撞车，请先阅读底部的 一节），你可以按照其英语文本进行翻译（建议阅读本节 教程；如果这是你的第一份翻译，请先查看其他有汉化的模组的语言文件，对照着中文与英文文件查看具体应该替换的部分，以避免出现失误）。翻译完之后，把文件改名为 2，也就是 zh_cn.lang，然后再将其放进上述的目录。这样，理论上来说你在游戏中就可以读取到翻译了！
顺带一提，在 1.12.2 中，语言文件为 .lang 文件，但在 1.12.2 以上的版本中，则是 .json 文件。
搭建工作区域
如果上面说的都还只是一些人尽皆知的小技巧，那么，接下来的内容就只有翻译工们才会知道了。每位汉化者都有自己的舒服的一些工具，有些工具性能较好，有些工具功能更优，而工具的使用全看个人选择，所以，以下只是我们个人的经验之谈。
在这里，必要的部分只有文本编辑器，在必要的部分之后，我会列出可选的软件，这些软件有一些可以提升你的工作效率，有一些则关乎你接下来提交汉化的方式。
文本编辑器
我们使用的文本编辑器有两个：
-
轻量编辑器：Notepad++（简称 Np++）（不再推荐）
原本我们想着说，如果不谈敏感话题，那么这款软件完全可以推荐，但是后来又发现作者在他的官网上已经到了非常嚣张的地步了，所以我们决定不再推荐。如果想使用轻量编辑器，换一个 Notepad3 可能会好一些。（据传 Sublime 也是一款不错的轻量编辑器，但我们都没有尝试过；如想查看 Np++ 的替代品及各替代品的差异，也可查看这篇 文章）
之所以我们认为你可能需要一款轻量编辑器，是因为有时候其实你根本不需要这么多的功能。你只需要一定的语法高亮来看看排版、查查错误，再了解了解翻译的文本质量，如果这时候再搬出一些庞然大物，那就未免有点杀鸡用牛刀的意味了。
-
主力军：Visual Studio Code（简称 VSC 或 VSCode 甚至 Code）
这是我们汉化工作的主要工作区域。
安装完成后，界面是这样的：
在上面分别标注出了几个需要注意的地方。
现在开始进行工作区的搭建。你需要点进 Extension（扩展）管理，在顶部搜索栏中搜索 “Chinese (Simplified) Language Pack for Visual Studio Code”，单击第一个扩展，再单击 Install，稍待一会你就会发现你的界面已经变成了中文。
你还需要安装以下扩展：
- Minecraft Lang Colorizer（zz5840.minecraft-lang-colorizer）（必装）
- Minecraft JSON Schemas（levertion.mcjson）（可选；目前用处不大）
第一个能使得 VSC 支持 .lang 文件的读取，第二个则还能支持一些 Minecraft 独有的类 .json 文件的显示（譬如 .mcmeta 文件）。这是安装了第一个扩展 Minecraft Lang Colorizer 之后的对比图：
考虑到很难找到一个能同时使 .lang 和 .json 文件的配色合适、文本易阅读的颜色主题，我（轩辕）比较喜欢 Navy and Ivory（evan-siegel.navy-and-ivory），不过它处理 .lua 文件略有一些小问题。后期我们可能会在这里加入更多较好的现成主题。如果你有能力，当然也可以自己制作一个。建议安装 Material Icon Theme（pkief.material-icon-theme），它可以为你任务栏中的文件添加图标。
需要注意的是，如果你安装了这个扩展而 .lang 文件配色等等并没有发生变化，你需要手动将一个 .lang 文件设置为 .lang 文件格式，之后 VSC 就会自动为你设置了。上方的图中圈出的位置就是修改文件读取格式的位置，如果你因为某些原因，想要以纯文本的形式读取 .lang 文件，那么你可以在图中被圈起的相应位置中进行修改。
基本上，安装了这些之后，你就可以
畅通无阻地进行你的汉化工作了！
词典与网站
如果你的词汇量无比丰富，那么你的翻译过程应该是基本顺畅的。但是实际上绝大多数人根本无法完全认得在翻译中见到的全部词汇，更何况还存在一些合成词甚至作者瞎编乱造的词，所以词典软件是必不可少的。
我（清秋）使用的词典是 欧路词典。
个人感觉还是不错的，安装了桌面版之后，打开划词翻译，打开 VSC，只需要选中你想查询的词，即可查出释义，非常好用。
有道词典 的桌面版也不错，然而和我的电脑适配有困难，出现了比较严重的 bug（无法进行文本复制），所以卸载了，但是有道的划词检索很快，不像欧陆词典有时候划词检索不出来，还会偶发地卡住。
如果你是重度开源受害者，或者对于上述两款软件都不满意，那么可以考虑 CopyTranslator，复制即可搜索，方便快捷，不像其他的词典那样过于臃肿（因为对于纯粹的翻译而言，你并不需要例句与发音这些功能）。
长句子翻译非常推荐 DeepL，它拥有着令人惊叹的翻译准度，以至于我的哲学论文有很大一部分的内容都是它帮助我翻译的。
顺带一些其他的在线词典网站推荐：
模组词典（可以查出 MC 一些既定专有名词的翻译）
如果你有苹果移动端设备并且使用方便的话，直接打开设备，在主屏幕下滑打开搜索栏，输入英语词汇即可翻译。苹果支持的词典种类很丰富，甚至部分支持其他几个印欧语系的语言、日语以至汉语本身。似乎需要 iOS 12 及以上。
进阶小技巧
-
替换重复率高的词
汉化时你可能会遇上那种重复率很高，并且已经成为定番（几乎不可能更改）的词，例如 Red，Green 这种颜色词，并且这种词往往一次性出现 16 个（也就是原版的所有颜色）。这种一次性出现很多的重复词语，由人类进行手动翻译不仅浪费时间，还可能导致准确度的降低（例如 PHC 模组，数十种作物如果上下不统一就会闹出笑话来）。
如果你不会代码，就有必要使用一些小工具来代劳了，我们推荐使用 Quicker，它的用处很大，这只是它的众多使用方法之一。如果不了解具体的使用方式可以自行搜索。
这是我（清秋）自己写出来的一个替换颜色的小脚本，你可以将其复制至 Quicker。难度不高，你也可以自己尝试编写一下拥有类似功能的脚本。
-
与同伴一起汉化一个项目
VSC 有个名为 Live Share（ms-vsliveshare.vsliveshare）的扩展，可以通过分享链接来共享工作区。以链接的形式发送给同伴，让同伴单击并接受，就可以实时共享翻译进程了！
装了扩展之后，会在 VSC 的下方显示这个内容：
单击之后就会提示你登录（请 使用自己常用的 GitHub 账号 登录，这样在安装有 git 相关的扩展后就可以以自己的账户来 commit 了），按提示一步步走并在最后单击 OK，右下角就会提示，已经将链接置入剪贴板。
发送给同伴后，同伴点进去，将会是这样的：
注意：你的同伴也需要登录！
然后只需单击“打开 Live Share for VS Code”，就可以完成了！
与同伴一起进行相关工作时请务必注意统一性。统一性十分重要，而保证统一性在大型模组或协作的翻译进程中尤为困难，因此请做好校对工作。
（题外话：我（轩辕）曾在 提问的智慧 一文的翻译中为统一性作了 一点贡献 以保证读者对文章的正常引用，却忽视了上下文标题格式的统一性，导致文中出现了突兀的格式差异，而我在 pull request 被合并后才意识到此问题，更使得重复发起 pull request 成为难为之事，因而进退两难） -
适当地添加空格，使文本更美观
请阅读 中文文案排版指北。
汉化提交途径
模组的汉化提交可以以多种途径进行，但大体上分为以下几种：
- 通过 GitHub
- 通过 Weblate
- 通过 CFPA 工单系统
- 通过 CurseForge 或其他途径
如果你作为一个新手，确实想要参与到翻译工作中，最好直接阅读 通过 Weblate，因为 CFPA 搭建的 Weblate 平台本身就是为新手设计的，使用它可以方便、快捷地进行翻译，不要浪费了 943 的一片良苦用心。
如果你只是想单纯地为自己或周围的人进行汉化，那么提交汉化是完全没有必要的。我们曾见过一个人只为了自己和朋友能看就把一个模组机翻后交给原作者，我认为这种行为相当不妥，首先机翻本身就没有值得赞赏的点，而你甚至在意识到了它不妥的情况下仍然把机翻文本交给作者，这不是什么好的行为。
当前的这一部分只写给那些想要融入模组翻译圈子的人。如果你翻译了一个看上去从未有人翻译的模组，而且你也不介意让更多的人使用到你的翻译，那么请务必将你的翻译通过各种渠道投递至官方仓库或交给 CFPA 的人员。重复造轮子是对资源的浪费，我们相当感谢愿意无私、无偿地将汉化放出来的好心人。
通过 GitHub
如果你想通过 GitHub 来进行汉化，那么首先你得了解 GitHub 是什么，以及它的相关操作。
GitHub 入门
本节将会告诉你如何注册 GitHub 账号，并带你了解 GitHub 的一些常用术语。本节的内容都是重中之重，很多汉化者都被卡在了这一步，所以在这一节里，我们会尽可能的配上图片，这样讲解的更为清晰明了。先申明，本人（清秋）没有编程经验，对于 GitHub 的操作难免也有疏漏的地方，所以也恳请各位看官斧正一二，感激不尽。
对于某些地区的用户来说，GitHub 的速度奇慢无比。这时候必须通过其他手段解决这一问题，具体方法见 下一节。
GitHub 没有国际化支持，不懂英文将寸步难行，因此请英语水平不足的人自行考量是否要请他人协助提交汉化。
这是进入 GitHub 的第一步。首先打开 GitHub。
然后你大概会看见如下的内容：
如果你始终加载不出来且位于中国大陆，那你可能需要通过专线等方式跨境联网，可以依法向设置国际通信出入口局的电信业务经营者租用，具体请见这份《通知》。注意：未经电信主管部门批准，不得自行建立或租用专线（含虚拟专用网络 VPN）等其他信道开展跨境经营活动；如果你因为不听本文的警告建立非法信道而被国家依法惩处，本文作者不负责。信息来源：环球网。或者你也可以通过一些方便的工具，单独对 GitHub 等网站进行加速，例如 dev-sidecar。如果你对此工具的安装根证书行为存有疑虑，那你可以使用 FastGithub。
接着你需要注册一个账号，只需遵循着引导流程，即可注册一个属于你自己的账号了。如果在注册过程中出现了验证等加载不出来的情况，使用上面提到的国际信道进行网页加载可能也是有必要的。
注册完毕后，你的界面将会变成这样的：
可能在一些小细节上有出入，但无伤大雅，大体一致即可。
到了这里，你就拥有一个 GitHub 账号了！
在本节中，我们会先介绍汉化提交的流程，然后再在流程之中抓出相应的概念进行详细讲解。
工作流程大体为找到仓库 → Fork → 修改 fork 过来的仓库 → 发送 pull request（拉取请求）到原仓库。
接下来是详细讲解：
-
在 CurseForge 上找到自己想要汉化的模组，这里随便以一个模组为例：
这里以 JEI 做个例子，点进去之后，我们可以找到这个图标：
点进这个图标，就可以跳转到这个模组对应的源码仓库了。一般情况下这个仓库位于 GitHub，但也有一些开发者会采用 GitLab 或 Gitee 这种其他与 GitHub 相似的代码托管网站。
-
Fork
这是 JEI 的仓库：
我们单击右上角的 fork，将这份仓库 fork 为自己的。如果你不明白为什么需要这样做，你可以在阅读完成后到 下一节 查看解释。
-
修改仓库的内容
到了这一步，你就可以将你之前的汉化提交到 GitHub 上了。
一番查找之后：
记住这个位置，你的文件应该上传到 lang 文件夹里，就和在模组里一样！其中的几个文件夹名字是不固定的，取决于模组的名字，相信你一眼就能明白哪些是不固定的了。
这里换了一个仓库作例子，单击圈内按钮，选择 upload file，就可以上传文件了！
-
拉取请求
你进行修改的这个仓库是你的，然而你的仓库只是原仓库的一个副本，如果你想要把你的修改合并到原仓库，那么你应该怎么做呢？这时候就需要发送 pull request（拉取请求，简称 PR）到原仓库了。
我们先回到原仓库，依次单击：
然后你会在页面的下方看到你和原仓库的对比，浏览且发现没问题之后，单击 create pull request，然后填上一些你想说的就好了。
注意：在 pull request 的信息填写里，不要给国外的作者发中文，他们是看不懂的。你的目的是给他们发送汉化文件，不是使用中文和他们聊天！（不过可以用英文和他们聊.jpg）
遵照上述的流程，你就可以顺利将你的汉化提交至作者那边了！但是你还是需要稍微等待，毕竟作者也不可能一直守着电脑；等到作者有空的时候，他会回复你，并决定是否采用你的汉化文件。
为什么需要 fork？
你应该已经注意到了，你其实对别人的仓库是没有修改权限的。所以 fork 的操作就相当于，你将他的仓库抄了一遍，然后你在这个抄本上进行修改，这是可以的，因为这是你自己的抄本。
我们引一段 资料：
……你 fork 一个仓库，指的是复制它。特别是当你 fork 属于别人的仓库时，你将制作他们仓库的完全一样的副本，之后这个副本便变成你的了。
注意这里的用词，“变成你的”意味着你对于这个仓库有着完全的控制权，包括删除仓库，所以修改你自己的仓库也自然不在话下了。
如果仍然未能理解这部分内容，请务必自行搜索并弄通这部分的概念与含义，因为此后的诸多行为都要以这部分为基础，如果未理解就去接着进行翻译工作很有可能误操作。建议阅读《Git 工作流指南》当中的 fork 与 pull request（见下面的 Pull request）两节。
在你同时参与了多个项目的汉化之后，你会遇到一个严峻的事实：一旦作者们更新勤奋，每天打开浏览器、登上 GitHub 时，你就得开始手忙脚乱的跳网页、找位置了。打开自己的仓库、做好跟进、发 pull request，等等，这有时候要你开四五个页面，才能开到你想要的那个仓库位置。一个仓库还好，如果有十多个乃至更多，那就太累人了；此外 GitHub 网页版在部分地区的加载速度并不快。
这个时候，最好的解决方案就是将你负责的仓库拉取到本地，你只需要在你的本地就能够将一切任务处理完毕，无须上 GitHub 网页版，极为方便。
这里有一份利用 GitHub Desktop 将仓库 clone 到本地的 教程，只要安装了 GitHub 桌面版，执行教程的第二步，就可以将仓库拉取到本地了！接下来的任务就是进一步把你的仓库 clone 到本地，这样就根本无须打开 GitHub 网页版了，完全可以做到本地一站式解决！
但是对于网络环境不好的人而言，这里还有一个极为严重的问题：在将仓库拉取到本地的过程中涉及到 clone 的操作，这一操作的实质就是将你挂载在 GitHub 上的仓库复制到本地上。一般情况下，只有早上八九点的时候才能以很快的速度进行 clone，一旦不在这个时间区域内，clone 的速度就只能听天由命了，而且绝大部分时候都慢得犹如龟爬，速度不高于 10 KiB/s。
这里有一些别人写过的方法，可以用于参考：修改 host 以及使用码云的教程。
在我（清秋）的情况下改 host 时灵时不灵，大部分情况下没什么用；而码云我们尚未尝试过，读者可以自行决定是否使用一下看看效果。
这是一个成功 clone 的仓库在 GitHub 桌面版的样子：
更改之后的操作：
如果你想要完善你的本地 git 操作，那么这两个扩展必不可少：
- GitHub Pull Requests and Issues（github.vscode-pull-request-github）
- GitLens-Git supercharged（eamodio.gitlens）
安装之后，只要你熟悉 GitHub 的操作，你将很快摸索清楚这两个扩展的使用方法。
如果你并不想花时间熟悉 GitHub 桌面版的操作，你可以简单地将需要跟进汉化的仓库添加至浏览器的书签栏，这样也可以在一定程度上提高效率。但是应注意，如果你参与了帕秋莉手册或其他多目录多文本的翻译工作，使用网页端进行翻译是相当不明智的，因为巨量的页面变动将会让你感到手忙脚乱。
什么是 pull request？
这里有一个比较清晰的 介绍。
Pull request 翻译过来就是“拉取请求”。我们在 fork 的仓库里作的修改都只是自己的，和原仓库关系不大。但是如果你想把你的修改合并到原仓库，那么，你需要问一问作者自己能否把自己的修改合并到对方的仓库，而询问这一过程就被成为“拉取请求”。这一过程实质上就是把你作的修改同步到原仓库这一点。但这一过程必须过问仓库主人，因为“未经许可修改仓库”是不被允许的，但向仓库管理申请 write 及以上权限之后，你就可以直接向仓库内写入内容了，这也是你可以修改你自己 fork 出来的仓库的原因，因为对于你自己的仓库，你总有着 admin 的权限。
网上有极多的相关教程，如果觉得我们描述得不够清晰，那么请自行搜索。上述的《Git 工作流指南》当中也有 pull request 一节。
这里还有一个比较清晰的 教程。
在熟练之后，我们很快就能发现在这里涉及的工作流程的实际样貌：Fork → 修改自己的仓库 → 发送 pull request。
有些新手可能会有疑问：我直接试图修改作者仓库里的内容，它也会提示我发起 pull request，那为什么一定要先 fork 再 pull request 呢？
实际上，这样做确实可以发起 pull request，但是这并不意味着你没有 fork 作者的仓库，我们可以看一个例子（保密起见，已隐去作者用户名，但这确实是同一个人）：
这是一个新手对一个原作者仓库连续发起的三个 pull request，可以肯定，这个新手肯定直接修改了原作者的仓库，并且修改了两次，还在自己 fork 来的仓库中修改了一次，最终一共发起了三次 pull request。我们可以看看这三个 pull request 都是从哪里发起的：
可以看到，这位新手对着原作者仓库的分支，连续用三个不同的分支向其发起了 pull request，而这些分支其实都是来源于他 fork 的仓库的：
也就是说，在你打算修改原作者仓库的时候，GitHub 自动为你 fork 了原作者的仓库，并将你的改动应用到你的 fork 仓库的不同分支上，然后再从这些分支发起 pull request 到原作者的仓库那里。这样做实际上没有能够理解 pull request 的本质：对 pull request 的 merge 是实际上是两个分支之间的合并，而非两个仓库之间的合并，即便在同一个仓库，你也完全可以用一个分支对另一个分支发起 pull request。这在在 CFPA 单独翻译某个项目时非常有用，因为你的工作常常不连续，有可能这个模组翻译一点，那个模组翻译一点，此时最好的方法就是创建不同的分支，把你翻译的不同模组分别放入不同的分支内，这样可以目标明确地发起 pull request，而不会在单个 pull request 里塞入无关的内容。你应该在工作开始前就规划好内容分离的工作的提交。
这种连开的 pull request 有什么不好的地方呢？其实从操作层面上来说，没有太多的问题，你爱开多少个 pull request 就能开多少个 pull request，没人管得了你，但事实上这种行为说明其实 pull request 发起者根本就没有理解 pull request 的意义，并且也不了解 GitHub 的 pull request 机制，以及这里谈及的 GitHub 工作流程。一个最显而易见的问题是：如果你根本不能理解 pull request 是如何运作的，那么，你应该如何为你的 pull request 追加新的改动呢？正确的操作是：你得在你 pull request 对应的分支上再继续 commit，这些 commit 会自动推送到这个分支开启的 pull request 上，然后你的追加改动就可以成功的被原作者看到了。如果你不了解 pull request 的机制，你可能就会为追加后的内容再开一个 pull request，这样的效率十分低下，不仅有碍观瞻，且会让仓库的作者搞不清楚你的真正用意。
这是一个看上去可以被忽视的过程，但实际上，如果你不想被其他的翻译者锤石锤，铁锤，钻石锤然后以泪洗面，你最好完成这一道“工序”。
具体该如何做呢？这里放出 LWHK 的一个 pull request，来给大家解释说明。
打开 pull request 页面之后，我们单击此处：
进入到如下界面：
在本页面中，本次 pull request 的所有更改内容都会显示出来。将鼠标移至每一行前面，你将会发现多了一个小加号：
单击这个加号，你就可以针对于这一行的内容进行评论，评论完之后，单击 start a review 即可。如果你只是单纯的想发表一下对于这一行的一些想法，那么你可以单击 add single comment；如果突然间没意见了，可以单击 cancel。如果你想对多行的内容进行评论，按住一个加号并上下拖拽即可选择多行内容。
完成了所有文件的查看之后，你可以单击屏幕右上角的这个。如果你觉得有很多地方需要更改，那么就选择 request changes（请求修改），如果你发现需要改的不多或者基本没得要改，你就选择 approve（赞成修改），如果你只是来划水的或者你觉得你的意见并不很重要，你可以选择 comment。
有时候你需要特定的人帮助你 review 你的 pull request，这时候你可以在 pull request 里发送 @ 信息，或者在右侧指定他帮助你 pull request（注意：这一操作只有仓库主人才可以进行！如果你没有该仓库的权限，那么你是无法在右侧专门指定他人为你 review 的，此时你只能 @ 他过来；@ 的方式即输入 @ 后在后面跟上你要 @ 的人的 GitHub ID 并再在后面空一格）：
这是 @ 的例子：
再次警告：无论你觉得你的实力多强，只要你不是神，你就会犯错误，而且往往是低级的错误，这些时候如果没有人帮助你 review，那么你的错误将会被别人看到，被别的汉化者锤，如果你不想这样，请你一定要找人帮助你 review！！
最后放上一些例子，基本都是我们参与过的：根源魔法丨Crossroads丨JEI 附魔信息丨匠魂 2
需要指出的是，无论你是属于某个翻译团体的合作者，还是单干的独行侠，抑或只是来看一看尝试一下的新手，对于含有大量非定番内容的汉化，你都应该叫人来 review；就算是不考验你能力的定番内容，你也照样有可能在翻译时输入了错别字。因此，除非你对自己的汉化有着完全的信心，或者汉化文本总共只有数行，review 都是必要的。前段时间匠魂的汉化发生了大的改动，我们两位也都去 review 了。我们想说的是，如果不考虑对使用范围极广的错误汉化作出修改可能带来的不便，如果你能给出你自己的完善的解释与说明，让我们搞得明白你作的修改都有什么含义，那就可以改，即使你生造出词来，让我们能理解得了并且有充足的理由支持你的行为，那也都可以改；但是如果你的翻译让人无法信服或是完全看不懂，你将有必要向 review 者作出有关你修改原因的解释。
优雅（或者说保证眼睛不瞎）地 review 有两种办法：
-
在网页端 review
GitHub 网页端的默认主题是亮色的，简直就是文本查阅的噩梦环境。在 GitHub 上保持亮色 review 不出十分钟，我（清秋）就开始意识模糊了。为了保护自己的眼睛，我必须找到一种适合我这种编程外行的方法，来改变 GitHub 的主题颜色。
我个人的解决方法是使用扩展 Stylus（Chrome丨Firefox）。教程我就不放了，如有需要请自行搜索。目标的主题是 Material Dark GitHub，单击链接即可进行安装。安装之后你就会发现，你的 GitHub 变成暗色的啦！
在 GitHub 网页端进行 review，在功能上会比在本地 review 要更加丰富。一个是一些复杂的语法，在网页端只需点一点按钮便可以唤出；另一个是一些扩展，可以更好地帮助你说明 review 的内容。譬如这个 PR Review Priority（Chrome丨Firefox），你可以迅速地为你的每一条 review 标注你对于这一 review 的态度，上文的 对 Crossroads 汉化的 review 就是一个大规模运用的例子。在这一例子里，我大量运用了优先度的描述，这样 pull request 递交者就能够明白哪些 review 是比较重要的，哪些 review 是可以与我讨论而不会出现误会的。遗憾的是，这个扩展一旦安装便不能选择无优先度的设定；此外至少在火狐方面为有多人的、种类不同的 review 添加评论时会出现数据错乱的现象，只能通过编辑功能手动修改。
在遇到了更改大量文件的 pull request 时，你会需要用到 Github Turbo PR（很遗憾，并没有火狐的扩展）安装之后，只要在 file changes 页面单击扩展进行优化，你就会发现页面的流畅度可以得到大幅提升。然而这个扩展有一些问题，可以在安装页面上查询到，这里就不复述了。
但无论如何，在网页端 review 总是有着各种各样的不便的，所以我们更推荐在本地进行 review。
更新：现在 GitHub 已经可以选择 dark mode 了，请前往 设置 选择 theme。
-
本地 review
需要使用到之前提到的 VSC 扩展（按：或许其他的编辑器也有，但是我们都没用过）GitHub Pull Requests and Issues。
安装了之后，你就可以在本地访问到远程仓库的 pull request 了：
单击 all 进行 pull request 查看（注意：不仅可以访问到 origin 仓库的 pull request，还能访问到 upstream 仓库的 pull request；可能需要 注册账号 一节提到的建立国际信道的方法）
按下图的顺序单击之后，扩展会专门拉出一条分支，这条分支会与你网页端的 pull request 页面实时同步（虽然会因为网络原因而有一些延迟）。以下是图片：
一些注意事项，如下图：
想要结束 review，必须得声明这一次的 review 的类型是 comment，request changes 还是 approve。也可以直接点进 pull request 的 description 并在其中进行评论以及确认 review 的操作。
当然，手动前往网页端声明 review 类型也是可以的。
如果网页端有文件的更新，扩展会提示你将这些改动 pull 到本地。
我们很快就能发现，本地编辑器在语法难度上比网页端高了不止一点，比如我们常用的 suggest 语法，在网页端只需点一点按钮即可唤出，但在本地端极为麻烦，因为目前插件还没有推出这种简易输入的功能。
这个时候就要发挥出本地的优势了。你可以借助第三方软件进行快速的为你输出特定的语法，我们个人使用的是 Quicker（在上文中亦有提及），我个人编写出了一个快速添加建议的脚本，只需选中你想要提出建议的行，然后使用动作，带有建议语法的文本就会写入你的剪贴板，你只需在 review 的输入框内粘贴这一文本即可，虽然不似网页端快捷方便，但也算是比较顺手好用的了。
这是 快速添加 suggest 的脚本，选中文本后直接执行动作，相应的带语法的文本会被添加到剪贴板中。
很多时候，作者更新了仓库，然后你发现他新加入了一些物品，理所当然的，语言文件里也多出了这些新物品的条目。你很快就意识到了这一点：你的仓库落后于作者的仓库，如果你想翻译这些新的内容，那么，你必须把新的内容拉取到你的仓库。最简单的方法就是在你的仓库发起一个反向 pull request，不是你 pull request 对方，而是对方 pull request 你。如果你没能了解如何这么做，在保证你的修改已经完全被上交了的情况下，可以删掉自己的仓库再重新 fork。
如果使用是本地操作，就得使用命令行进行 fetch + merge 了，请参考这篇 教程。
命令行在本地仓库的相关控制中极为有用，建议认真在网上找教程学习。但是，首先你得为你的计算机安装上 Git。
向官方仓库提交
原库提交，指的就是向模组的原仓库提交你的汉化。这一行为无异于宣称你开始负责本模组的汉化，所以不推荐新人这样做；只有在逐步积攒经验之后，一个人才有可能有能力承担起一个模组的官中负责者的任务。
官库提交的流程与以上提到的提交流程是一个流程，按着上面的指导操作即可。
注意，原库提交意味着模组作者不会帮助你 review，你必须自行找人，@ 他过来帮助你 review 才行。
向 CFPA 提交
自动汉化更新模组的提交途径是我们最推荐新手使用的，因为这里的维护者会帮你 review（逃）。提交手段与上述的并无二致，唯一要注意的是文件存放的位置。注意：CFPA 仅支持 1.12.2 和 1.16 两个版本。
进入仓库后，你会发现成吨已经汉化过的项目（感谢各位的辛勤付出！），你需要将你的文件上传至此处，但你必须适当的存放你的文件。还记得第一节中的模组的压缩包结构吗？assets\ModID\lang，你会发现这里的每个项目都不是这样存放的，这里文本的存放位置下面有描述。
注意，你最好把你所翻译的对应英语文本同样放进去，这样会方便后来者查看，而英语之外的其他语言文本则不用。
**以上演示的是旧版本的仓库，**在 CFPA 仓库里，主分支名为 “main”（不是 “1.12.2”！），用于存放所有 1.12.2 的汉化文件；1.16 翻译则位于 “1.16” 分支中。以下为演示：
概括可得文件位置为 /projects/1.12.2 或 1.16（勿忘使用正确分支）/assets/CF ID/ModID/lang/zh_cn.lang 或 zh_cn.json。如果模组没有 CF 页面，则应在该处填充 “1UNKNOWN”。
注意：一定要在正确的位置放置你的文件，添加 CF 相关的 ID 目录的这一步是为了之后的爬虫进行最新文本的爬取而进行的额外设置，如果 ID 错误，那么爬虫将无法正常工作！
其余的分支存放的是其他版本的文件，切记不要传错分支！
通过 GitHub 建立翻译团体并进行翻译管理
GitHub 有一个 organization 的设定，单击右上角的加号可以发起组织。组织的功能很多，你可以使用组织来建立仓库，也可以以组织的名义 fork 或发起 pull request。组织本身还有一个 project board，在那里建立的 project 可以由任何组织成员编辑。
通过以组织之名建立中转仓库（我们的 例子）管理需要帮助的汉化会变得轻松许多。你可以 fork 中转仓库至自己的账号下并在 fork 后的仓库中作修改，然后再发起面向中转仓库的 pull request。直接向作者的仓库 pull request 会带来一些问题，比如 review 过长时作者阅读不便、无法 review 完成后立刻 commit、需要控制及压缩 commit 数量、无法不通过 @ 来邀请他人 review 等等，而在中转仓库下这些问题都能得到解决。
除此之外，组织页面还可以作为一个向外界展示自己所在的翻译团体的平台使用。
通过 Weblate
自动汉化更新模组的团队（CFPAOrg）以 Weblate 为基础搭建了一个 翻译平台。上手难度极低，基本没有任何门槛，你只需要在对应的网站登录（账号请找管理员注册），选择自己想要翻译的模组，然后就可以开始轻松愉悦的翻译了！模组更新的新条目也会及时的被爬虫爬到库里，非常方便！
但是首先：
其次，请尝试是否可以登上团队的 官方网站。
该网站为 CFPA 的介绍页，你可以在这里获得 CFPA 的详细信息。如果上不去，可以尝试前往大陆以外的地区或按照 注册账号 一节的内容合法使用国际信道。
可以访问 QQ 群 630943368 进行相关事项的咨询，由于上手难度真的太低了，这里不再赘述。
通过 CurseForge 或其他途径
顾名思义，在作者不开源的情况下，你必须向作者私信汉化文本（注意：最好以文件形式发送！）。如果你的位置在中国大陆以外，你可以使用 Twitter 或 Discord 等内容与作者取得联系；如果你在大陆内而没能找到其他路径向作者发送文件，你将只能使用 CurseForge 自身的私信（又称 PM 或 DM）功能来发送文件。
如果需要以本节提到的内容进行提交，并且你也有一个所属的翻译团体（CFPA 例外），你可以先将汉化文本以 pull request 的形式交至自己团体的库中让大家一起看一眼，顺便弄个 review 再将文件发给作者。这点将会在 通过 GitHub 建立翻译团体并进行翻译管理 一节详细描述。
一些注意事项
考虑到可能看这篇的大部分都是新手翻译者，所以除了一些硬件软件上的需求，还得提前说好一些 MC 翻译圈内的规矩，避免冲塔/自爆卡车，然后还怪我在文章内没说清楚。
每天一个机翻小技巧，有手就能学废
不允许机翻！！！
机翻是一种极为严重的错误行为，任何在模组翻译圈中的机翻行为都必须完全抵制。在这里我要谨慎的区分开我前面谈到的，利用 Quicker 帮助替换颜色文本和机翻具有本质性区别。我们抵制机翻不是为了证明某种由人翻译所产生的抽象本质的威严性，而是为了抵制由机翻带来的不通顺的，错误的，乃至于离谱的翻译。这种抵制建立在纯粹的实用层面上，而不是在抽象的行为区分上。这里可以引出一个非常明显的悖谬：面对着一个翻译的比人更像人的机器，我们是应该抵制呢？还是支持呢？如果一个人不使用这样的机器生产翻译，而是自己翻译（质量上肯定差于机器翻译），那么，站在用户的角度，我们是应该支持，还是抵制呢？ 我个人不愿意从纯粹的行为角度区分机翻和人翻，这样子似乎走入了某种本质性幻觉之中，我们试图在人翻和机翻之间找到某种本质性裂缝，这一裂缝展开了价值上的区分。然而，这样的裂缝真的存在吗？我认为这是需要辩驳的。 抛开纯粹的思辨，如果我们站在实用的立场上，我们就可以发现，在颜色替换这样的例子上，其与机翻有实用层面的本质区别。在这种情境下，人翻和机翻在纯粹语词的层面没有差别，这意味着在纯粹实用的层面也没有区别，你根本无从分辨哪个是机翻哪个是人翻，你只能凭借非实用层面的因素进行区分。但是这样的区分在我看来，构不成价值上的判断，所以无须批判颜色替换的问题，需要批判的是由机翻带来的坏翻译。
以上文本出自清秋，如果你觉得这段话太长了，你可以只看下面这一句话：
我们批判的并不是机翻本身，而是明知机翻会带来差翻译而仍然使用机翻的这种行为。
如果你的翻译当中包含了机翻的内容，请读读土球的一篇 文章，或许会对你有一些帮助；蝙蝠的一篇 文章 也很好。无论如何，机翻都应是被抵制的，除非你时间不足或者能力不够，尽量不要使用机翻。如果实在需要机器的辅助，请使用 DeepL 作为自己的首选工具。
复杂文本格式翻译
你可以在 CFPA 相关教程 内查询到一些有关对部分非 lang 文件夹内的文本翻译的注意事项。
意外情况
有时你会发现，你翻译出来的文本出现了奇怪的问题：明明把翻译文件放进了模组文件内，但游戏中不加载；加载了，居然是乱码；也可能只有个别的一些东西没有加载。这些情况我们会在本节中试着梳理一下，避免被坑。
不加载
不加载又分为两种情况：完全不加载和部分不加载。
-
检查文件名是否正确。
一般而言，在 1.12.2 中，中文文件可能会有两种名字，一种为 zh_cn.lang，一种为 zh_CN.lang。它们看似只有尾巴的大小写差异，但实际上，如果英语语言文件的尾巴是大写的，然后你放了一个小写尾巴的中文文件进去，它是不会加载的。中文文件的尾巴的大小写必须跟随英文文件尾巴的大小写。具体原因请参见 本文。
这是一个错误的例子：
这是一个正确的例子：
1.12.2 以上则不是 .lang 文件，而是 .json 文件。似乎 .json 文件并没有尾巴大小写的说法，全是小写。
-
检查文件位置，这个无需多言。
-
如果你的翻译是给 1.12.2 以上版本提供的，你将需要查看语法。
GitHub 会在 JSON 文件中以红色底色标示出语法错误。语法的错误包含缺少引号、逗号或冒号，多余的逗号以及注释（虽然直至目前注释问题仍然没有好的解决方案，但是添加符合格式的注释并不会影响 JSON 的正常加载）。
如须注释，请添加下面这段文本至你的 JSON 文件中。这一部分还需要考证"_comment": “注释文本”,
部分不加载，则有可能是因为 translation key 发生了错误，所谓的 key，就是语言文件中每一行的左边部分，也即 1.12.2 的 .lang 文件中，每一行条目的 = 的左侧或 1.12.2 以上 .json 的 : 左侧的部分，你需要单独检查一下那些尽管填了翻译，但是游戏中没有加载的词条的 key。
这是一个修复了 key 错误的 commit。
若是根本没有 key，而作者把文本写进了代码中（我们称这种文本为硬编码文本），要想处理这个情况你就需要较高的技术力了。如果你有能力且有时间，并且愿意协助作者进行修改，那么你可以直接进行修改之后发送 pull request 到作者的仓库；如果没能力或者没时间进行协助，在 issue 界面和作者反馈问题就好了，不必勉强自己。
这是一个相关的 issue 反馈（@RisingInIris2017 的例子，MCBBS 用户名 NoName德里奇）。
这个是比较特殊的情况，一般而言，你只需要说清楚哪里没有 key，说希望作者改进就好了。
如果你确实不精通英语，甚至书面表达都颇为吃力，那么你可以使用这一套 issue 模板，填写入相应的信息之后，将中文删掉即可（由德里奇友情提供）。
这是一个手动改硬编码的 例子（前提是你能看得懂作者的写法）。
文字乱码
文本都会涉及到一个问题，那就是编码问题。如果你的文本是 UTF-8 的编码，然而你的游戏使用了 GBK 的编码方式，那么自然只能出现乱码。如想了解详细内容，可以去网上搜一搜“解码错误”。
在 VSC 中，下方导航条的右侧会显示出 VSC 当前打开该文件所使用的编码类型：
注意，无论是语言文件还是手册，编码格式一定得是 UTF-8，不能是其他的编码（这里体现出了记事本的弱点：不仅默认格式不是 UTF-8，就算调整为了 UTF-8 也可能是 with BOM 版本的）。有些模组自带手册，但是忘记定义了调用 Java 解码的字符集，此时 Java 就会调用你的系统默认的字符集进行解码。如果使用 UTF-8 进入游戏，则会通篇全为乱码。但是这不是你的问题。你所要做的就是在他的仓库的 issue 那里放上这个 pull request，并说明乱码问题可能与这个 pull request 相关，作者自然就会明白了。
