本帖最后由 luzhengwei 于 2022-2-7 17:24 编辑 

DynTranslation
——运行时翻译/替换 介绍
在进行mod国际化的时候,有时会遇到部分文本的硬编码无法简单国际化的问题,导致国际化工作比较困难,通常需要进行对源文件的注入进行修改,一方面对源文件造成了破坏性的改动,而且进行更新后又需要重复工作。
这个mod的对象是mod汉化人员,和对应的使用玩家,主要针对部分国际化不完善的mod,提供流畅的汉化体验。
同时在一些娱乐向方面,我们需要替换游戏内文本来达到一些特殊效果,这时候也需要对游戏内文本进行修改。
DynTranslation通过映射表文件进行运行时文本替换来达到以上效果。
DynTranslation替换的时间节点
通过介绍时间节点来避免不必要的问题产生,动态翻译在进行替换时,需要在Forge完成初始化时才能锁定配置文件位置,所以在初始化完成前无法加载配置文件,同时这样做也是减少CPU空转时间,因为在加载时间点会产生大量动态数字,造成翻译队列阻塞,过高的消耗CPU资源。
所以在初始化完成前,动态翻译本身不能替换加载界面的文本。
前置
对于1.12.2版本不需要安装前置;
对于1.15.2+ 请安装MixinBootstrap (下载不了可以自行搜索)
替换方法
通过简单的文本替换,这里采用了json文件作为载体,对映射文件进行读取;
映射文件信息如下:
父文件夹:位于mod的config文件夹下,并且会创建子文件夹名为dyntranslation
子文件命名:所有子文件,必须以形如 dyntranslation_{name}.json 的规范命名,其中{name}为所有系统文件可用字符。

替换内容:替换内容以 json 的标准格式为准的Map嵌套形式。
复制代码
性能影响
由于是每帧替换,所以其性能影响和帧数也是成正比的,最后的影响结果应该是线性的。其中的IO操作和分词耗时操作放在其他线程中,最终的性能影响来自于:
后两者无法通过人工进行控制,所以我们关注前两者,理论时间复杂度为 O(k) (仅仅考虑map存取,k为小常数,约为1-6),在实测中新增加的内容打开分词后的平均影响如下图:

平均值为3099.375,量纲为纳秒,小于毫秒的数量级,可以认为在稀疏操作下的影响可以忽略不记。
GUI(mc.1.15.2, 1.16.x)

顾名思义~
控制中可以自己修改键位默认打开设置Z, 开始和停止记录屏幕字符V,
开启和关闭聊天栏翻译Y。
命令(mc1.12.2)
复制代码
其中record产生的输出文件如下所示:
复制代码
其中§{char}为格式字符,默认情况下生成两行(如果不产生冲突),上一行为包含格式字符的记录对,下方为清除格式字符的记录对。
因为在minecraft中的Tooltip中会包含格式字符而当其在Highlight显示在游戏界面下方时是不包含格式字符的,同样的在F3+H开启高级调试时会在其后方添加#{id}这里不再记录。对于这些情况都已经做过部分处理可以自动替换,如果你想修改原来的格式显示也可以在此处修改来达到不同的展示效果。
分词
我自己不是做自然语言处理的,这里针对English和中文进行了分词处理,分词和语言检测来自于com.github.houbb.segment和com.optimaize.languagedetector,分词的平均速度采用了最快(准确率最低)的贪心算法,语言检测使用了3种语言的检测:中文,英文和日文,但是对于日文迫于字典太大(其实不加也很大了),就没有添加。
分词主要用于拓展映射表节省搜索耗时,例如:
复制代码
对草进行了翻译替换,这样也会默认对所有含“草”的词组以及句子进行替换(前提是通过一般匹配)。
举个栗子:
如果在你的映射表中没有对“草方块”单独做映射,那么你的“草方块”文本将会被替换为“艹方块”,如下图所示:


如何避免这种情况?
你可以在你的映射文件中添加全匹配标记符@
复制代码
如果你需要@这个字符可以通过@再进行转义,如上图所示。
或者你也可以关闭分词功能,详见章节命令|GUI。
渲染位置微调(v1.2添加)
有时候面临的Gui中出现的居中字符,我们经过翻译/替换后的文本长度和原来的文本长度不同,导致原来mod中的居中计算会造成错位。如下图:


图中的tile在英文表示中较短,而中文表示可能会比较长,导致mod本身计算时讲起始点保持在了英文起始点导致居中失效。
为了解决这个问题,在每个配对右侧翻译部分增加了控制字段来微调渲染位置[x(整数),y(整数),scale(小数)]:
复制代码
这里对附魔进行了位置微调,首先进行一次自动的缩放,这次缩放会按照替换文本“附魔测试”和被替换文本“附魔”的文本长度进行缩放比例调整,这里我们很清楚的可以计算,被替换后长度变成了原来的2倍,所以会对替换文本x,y位移后的位置进行0.5倍的缩放来保持和原来文本的对齐:

同样的控制字符中的x,y除了可以填写相对位置的具体值外,也可以使用值“auto”进行自动位置调整:
当你不填写控制字段(一个或多个)的时候x的默认值位0,y的默认值为0,scale的默认值为1;
当你的文本中本身就以"{","}"开头和闭合时:如
复制代码
你可以在右边的开通插入空的控制字段来防止渲染出错:
复制代码
当然,所有的控制字段必须在替换文本的开头,并以规范形式结束,否则可能会造成不可预料的后果。
对于控制字段,仅仅对非Tooltip(悬浮提示框)中的文字生效,并且不会作为子单词嵌套。
联网翻译聊天栏 (v1.3+)
没什么好说的,默认键位Home键,可以在控制选项里调整,切换是否对聊天栏进行联网翻译,翻译结果根据你所选的当前语言种类确定。
指令 /translation retainOrg true 开启翻译时保留原句。
由于经费不足😂,没钱架设翻译服务器,免费的翻译接口又可能随时gg,所以这个功能的接口申请要靠你们自己搞了,这里我就写了一个百度翻译的接口,有空的小伙伴可以去 百度翻译 申请接口,有免费的,然后将id和key填入到以下的配置文件中(这个文件会在游戏初始化后自动生成)。
游戏内用命令 /translation loadConfig 主动加载配置(为了以后平滑升级到其他版本,没用minecraft自带的配置文件系统,所以修改后麻烦主动加载下配置文件)。
如果是覆盖原文不保留原句,应该大部分时候不会缩放结果,但是如果开启了保留原句,句子太长会进行缩放,可能非满屏下会看不清字,可以考虑使用推荐使用 SmoothFont(也可以在本站搜索)来缓解字体过小的问题,经过测试完全兼容。

不足和缺陷
动态翻译无法完成的事情:
注意事项
在windows平台,所有的json文件请使用ANSI编码。如下图:

使用教程
详细教程请查看Mod百科作者教程。

DynTranslation
——运行时翻译/替换 介绍
在进行mod国际化的时候,有时会遇到部分文本的硬编码无法简单国际化的问题,导致国际化工作比较困难,通常需要进行对源文件的注入进行修改,一方面对源文件造成了破坏性的改动,而且进行更新后又需要重复工作。
这个mod的对象是mod汉化人员,和对应的使用玩家,主要针对部分国际化不完善的mod,提供流畅的汉化体验。
同时在一些娱乐向方面,我们需要替换游戏内文本来达到一些特殊效果,这时候也需要对游戏内文本进行修改。
DynTranslation通过映射表文件进行运行时文本替换来达到以上效果。
置顶更新内容
对应于mc1.16.x mod版本1.3.5 beta 以及之后版本更新物品的提示框联网翻译功能;
使用神经翻译在主流mod的英译中集合上进行训练微调,在minecraft相关语料集上达到主流翻译器水平;
感谢CFPA提供的语料库和参与翻译的所有译者。
在线api使用 CC BY-NC-SA 4.0 协议发布。
现阶段功能处于测试阶段,会对网络访问进行限制(每小时360次的访问),作者不保证翻译服务的稳定性,如有疑问请即时反馈。
更新了新的数字匹配,在避免分词的情况下进行包含变动数字的快速匹配替换。
使用方法
悬浮指针在物品上,按住默认键位Alt以进行联网翻译,改功能无法对创造模式搜索栏进行翻译,因为他拦截了键盘事件。
DynTranslation替换的时间节点
通过介绍时间节点来避免不必要的问题产生,动态翻译在进行替换时,需要在Forge完成初始化时才能锁定配置文件位置,所以在初始化完成前无法加载配置文件,同时这样做也是减少CPU空转时间,因为在加载时间点会产生大量动态数字,造成翻译队列阻塞,过高的消耗CPU资源。
所以在初始化完成前,动态翻译本身不能替换加载界面的文本。
前置
对于1.12.2版本不需要安装前置;
对于1.15.2+ 请安装MixinBootstrap (下载不了可以自行搜索)
替换方法
通过简单的文本替换,这里采用了json文件作为载体,对映射文件进行读取;
映射文件信息如下:
父文件夹:位于mod的config文件夹下,并且会创建子文件夹名为dyntranslation
子文件命名:所有子文件,必须以形如 dyntranslation_{name}.json 的规范命名,其中{name}为所有系统文件可用字符。

替换内容:替换内容以 json 的标准格式为准的Map嵌套形式。
- {
 
-     //容器(GUI)包名,“*”表示没有在任何容器(GUI)中,大部分在Tooltip中
 
-   "*": { 
 
-     "§f腐肉§r": "§d腐肉§r",
 
-     "  盔甲": "",
 
-     "§7穿在腿上时:": "§8穿在腿上时"
 
-   },
 
-     //这里表示字符显示在GuiEnchantment中
 
-   "net.minecraft.client.gui.GuiEnchantment": {
 
-     "附魔": "附魔"
 
-   }
 
- }
性能影响
由于是每帧替换,所以其性能影响和帧数也是成正比的,最后的影响结果应该是线性的。其中的IO操作和分词耗时操作放在其他线程中,最终的性能影响来自于:
- map的存取性能
- map的大小
- 线程的创建销毁时间
- 新词汇的产生速度过快导致的队列阻塞
 
后两者无法通过人工进行控制,所以我们关注前两者,理论时间复杂度为 O(k) (仅仅考虑map存取,k为小常数,约为1-6),在实测中新增加的内容打开分词后的平均影响如下图:

平均值为3099.375,量纲为纳秒,小于毫秒的数量级,可以认为在稀疏操作下的影响可以忽略不记。
GUI(mc.1.15.2, 1.16.x)

顾名思义~
控制中可以自己修改键位默认打开设置Z, 开始和停止记录屏幕字符V,
开启和关闭聊天栏翻译Y。
命令(mc1.12.2)
- /translation loadMap 重新载入文件;
 
 
- /translation startRecord //开始捕捉字符,这个命令会在你指令被接受后再游戏中记录所有出现的字符,并存入缓存,上限为1000;
 
 
- /translation endRecord <-n> 停止记录并保存,这个命令会停止捕捉并存入之前提过的config文件的dyntranslation中,文件名形如record_{mill_time}.json。<可选项-n>用来进行简化输出,删除格式化字符。
 
 
- /translation enable 启用动态翻译
 
 
- /translation disable 关闭动态翻译
 
 
- /translation spilt 启用分词
 
 
- /translation notSpilt 关闭分词
其中record产生的输出文件如下所示:
- {
 
-   "*": {
 
-     "§f腐肉§r": "§f§r",
 
-     "  盔甲": "",
 
-     "§7穿在腿上时:": "§7",
 
-     "穿在腿上时": ""
 
-   },
 
-   "net.minecraft.client.gui.GuiEnchantment": {
 
-     "附魔": "",
 
-     "物品栏": ""
 
-   }
 
- }
其中§{char}为格式字符,默认情况下生成两行(如果不产生冲突),上一行为包含格式字符的记录对,下方为清除格式字符的记录对。
因为在minecraft中的Tooltip中会包含格式字符而当其在Highlight显示在游戏界面下方时是不包含格式字符的,同样的在F3+H开启高级调试时会在其后方添加#{id}这里不再记录。对于这些情况都已经做过部分处理可以自动替换,如果你想修改原来的格式显示也可以在此处修改来达到不同的展示效果。
分词
我自己不是做自然语言处理的,这里针对English和中文进行了分词处理,分词和语言检测来自于com.github.houbb.segment和com.optimaize.languagedetector,分词的平均速度采用了最快(准确率最低)的贪心算法,语言检测使用了3种语言的检测:中文,英文和日文,但是对于日文迫于字典太大(其实不加也很大了),就没有添加。
分词主要用于拓展映射表节省搜索耗时,例如:
- {
 
-   "*" : {
 
-           "金矿石" : "金闪闪",
 
-           "草" : "艹",
 
-           "Grass": "艹"
 
-         },
 
 
-   ... ...
 
 
- }
 
对草进行了翻译替换,这样也会默认对所有含“草”的词组以及句子进行替换(前提是通过一般匹配)。
举个栗子:
如果在你的映射表中没有对“草方块”单独做映射,那么你的“草方块”文本将会被替换为“艹方块”,如下图所示:


如何避免这种情况?
你可以在你的映射文件中添加全匹配标记符@
- ... ...
 
 
- {
 
-     "Iron Ore" : "铁矿",
 
-     "@草" : "艹",
 
-     "@@草" : "@艹"
 
- },
 
 
- ... ...
如果你需要@这个字符可以通过@再进行转义,如上图所示。
或者你也可以关闭分词功能,详见章节命令|GUI。
渲染位置微调(v1.2添加)
有时候面临的Gui中出现的居中字符,我们经过翻译/替换后的文本长度和原来的文本长度不同,导致原来mod中的居中计算会造成错位。如下图:


图中的tile在英文表示中较短,而中文表示可能会比较长,导致mod本身计算时讲起始点保持在了英文起始点导致居中失效。
为了解决这个问题,在每个配对右侧翻译部分增加了控制字段来微调渲染位置[x(整数),y(整数),scale(小数)]:
- {
 
-   "*":{
 
-     "金矿石" : "金闪闪"
 
-   },
 
 
-   "net.minecraft.client.gui.GuiEnchantment": {
 
-     "附魔": "{x=1,y=2,scale=auto}附魔测试"//现在共有3个可用属性,x,y,scale,属性可以为auto这是会自动在指定方向上和原字符串中间对齐;
 
-     //例子: "{x=auto}测试测试" , "{x=auto,y=auto}测试测试2"
 
-   }
 
- }
这里对附魔进行了位置微调,首先进行一次自动的缩放,这次缩放会按照替换文本“附魔测试”和被替换文本“附魔”的文本长度进行缩放比例调整,这里我们很清楚的可以计算,被替换后长度变成了原来的2倍,所以会对替换文本x,y位移后的位置进行0.5倍的缩放来保持和原来文本的对齐:

同样的控制字符中的x,y除了可以填写相对位置的具体值外,也可以使用值“auto”进行自动位置调整:
- 对于x,自动调整会将替换后文本和替换前文本进行居中对齐,即两份文本的中线对齐。
- 对于y,因为字体高度不变,仅仅通过缩放比来做到竖直方向上的垂直居中,同上。
 
当你不填写控制字段(一个或多个)的时候x的默认值位0,y的默认值为0,scale的默认值为1;
当你的文本中本身就以"{","}"开头和闭合时:如
- "公式" : "{[(1-x) * y]} * z"
你可以在右边的开通插入空的控制字段来防止渲染出错:
- "公式" : "{}{[(1-x) * y]} * z"
当然,所有的控制字段必须在替换文本的开头,并以规范形式结束,否则可能会造成不可预料的后果。
对于控制字段,仅仅对非Tooltip(悬浮提示框)中的文字生效,并且不会作为子单词嵌套。
联网翻译聊天栏 (v1.3+)
没什么好说的,默认键位Home键,可以在控制选项里调整,切换是否对聊天栏进行联网翻译,翻译结果根据你所选的当前语言种类确定。
指令 /translation retainOrg true 开启翻译时保留原句。
由于经费不足😂,没钱架设翻译服务器,免费的翻译接口又可能随时gg,所以这个功能的接口申请要靠你们自己搞了,这里我就写了一个百度翻译的接口,有空的小伙伴可以去 百度翻译 申请接口,有免费的,然后将id和key填入到以下的配置文件中(这个文件会在游戏初始化后自动生成)。
游戏内用命令 /translation loadConfig 主动加载配置(为了以后平滑升级到其他版本,没用minecraft自带的配置文件系统,所以修改后麻烦主动加载下配置文件)。
config.json(位于config/dyntranslation/中,同映射文件,请按以下示例填写name,id和key)
复制代码
- {
- "ChatTranslate": true,
- "Enable": true,
- "SpiltWords": true,
- "RetainOrg": false,
- "TranslateApis": [
- {
- "name": "baidu",//现在只支持百度的翻译Api
- "id": "****************",//对于百度翻译,这里填入你的AppId
- "key": "*****************"//这里填入你的SecretKey
- }
- ]
- }
如果是覆盖原文不保留原句,应该大部分时候不会缩放结果,但是如果开启了保留原句,句子太长会进行缩放,可能非满屏下会看不清字,可以考虑使用推荐使用 SmoothFont(也可以在本站搜索)来缓解字体过小的问题,经过测试完全兼容。

不足和缺陷
动态翻译无法完成的事情:
- 非FontRenderer渲染的文字,如材质中的文字,图片中的文字和非Opengl环境下的文本。
- 现在在Tooltip中不会有渲染错误(下图不会发生),但是依然不排除在一些mod的自定义Gui中使用裁剪功能后导致的渲染问题。
- Minecraft自带的一些组件以及Mod中的编辑组件会被错误渲染(比如编辑栏,搜索栏等你自己就需要输入字符的组件),你输入了你定义过的字符,那么在渲染时会被错误映射为你的翻译/替换结果。
- 只支持中英文的分词。
- ... ...
 
注意事项
在windows平台,所有的json文件请使用ANSI编码。如下图:

使用教程
详细教程请查看Mod百科作者教程。
虽然看不懂,但是好像好厉害的样子
虽然我没能理解这个模组的意义是什么,但是请按照版规将字号调整到不大于五号字号落实谢谢。
没糖的葫芦 发表于 2020-4-9 20:01
虽然我没能理解这个模组的意义是什么,但是请按照版规将字号调整到不大于五号字号落实谢谢。 ...
什么不大于五号字。。
luzhengwei 发表于 2020-4-9 20:09
什么不大于五号字。。
标题还真大于5号字了,markdown的标题竟然是6号,我哭了,谢谢提醒
好高级的丫子,但是我没看懂用处?
没糖的葫芦 发表于 2020-4-9 20:01
虽然我没能理解这个模组的意义是什么,但是请按照版规将字号调整到不大于五号字号落实谢谢。 ...
就相当于用于mc的chrome网页翻译
翻译mod 解决了我看不懂的难题
解决了我看不懂的难题
好东西!!!
1.15.2如何使用这个mod
mota 发表于 2020-9-14 10:44
1.15.2如何使用这个mod
和1.12.2一样, 就是指令变成了对应的按钮。因为1.15.2没有客户端的指令了,为了让它只依赖客户端,就只能使用gui或者捕捉所有指令做处理,后者太麻烦了,就干脆用了gui界面。可以看下控制里的对应按钮调出gui界面。
这是模组吗,看不出来
爱了爱了
能提高FPS吗???
前来白嫖~
我看不懂你在说啥啊=-=我可能是个fw
感谢楼主分享 收藏了qwq
很强的模组
来支持一下
感谢楼主分享!
下载链接失效了 /悲
这个 挺实用的就是不太好上手
没有forge下载链接吗
这个可以自动翻译吗
会代码的都是大佬
能不能出个视频讲解还是不懂啊,但是很想用
感觉会很不错下载试试看  谢谢楼主
不错啊好高级的丫子。
很强,嫖了
整合包作者狂喜
终于可以畅玩各种整合包了qwq
优化下贴贴把看不大懂
再也不担心看不懂英文了
这个是什么模组,  很厉害的样子,   想用用