把 Ren'Py 游戏翻译流程写成一个可复用 Skill

Sat, 23 May 2026 00:00:00 +0000

最近把一套 Ren’Py 游戏翻译流程整理成了一个 Codex Skill。它的作用不是“教 AI 怎么随便翻译几句文本”，而是把 Ren’Py 汉化里那些很容易被忽略的规则，变成一份可以反复执行的检查清单。

Ren’Py 游戏翻译看起来很简单：找到文本，翻成中文，保存。但真正做起来会发现，问题经常不在“这句话怎么翻”，而在“这句话到底会不会被 Ren’Py 正确匹配、正确加载、正确显示”。

所以这个 Skill 的核心思路是：不要把翻译当成纯文本替换，而要把它当成一个小型补丁工程。

为什么要写成 Skill

单次翻译靠经验可以做完，但下一次换一个游戏，很多坑还会再踩一遍。

比如：

old 字符串被改了一个空格，导致翻译完全匹配不上
菜单选项带了文字标签或状态后缀，生成的翻译没有覆盖真实显示内容
变量插值里的人名、阵营名仍然显示英文
字体不支持中文，结果游戏里全是方块
直接改原脚本，更新游戏后补丁很难迁移
批量脚本写文件时编码错了，中文变成乱码或问号

这些不是“翻译水平”问题，而是流程问题。Skill 适合处理的正是这种流程：每次遇到 Ren’Py 项目，都按同一套顺序检查、修改和验证。

工作区应该放在哪里

Ren’Py 翻译最重要的目录是：

1

game/tl/<language>/

Skill 里的第一条规则就是：优先在翻译目录里工作，能不改原始脚本就不改原始脚本。

原因很现实。原脚本是游戏本体的一部分，直接改它虽然快，但后续更新、分发、回滚都会变麻烦。更稳的方式是把翻译、字体、界面覆盖、语言按钮、默认语言设置等内容尽量放进 game/tl/<language>/。

这样做的好处是：

删除语言文件夹就能恢复原版
游戏更新时更容易迁移
补丁边界清楚
不容易误伤原游戏逻辑

如果原游戏没有 .rpy，只有 .rpyc 或资源包，那就先处理解包、反编译或生成翻译文件的问题，而不是直接乱改。

old/new 不能乱动

Ren’Py 里常见的翻译形式有两种。

一种是对话块：

1
2


translate chinese start_abc123:
 "这里写翻译后的台词"

另一种是字符串表：

1
2
3


translate chinese strings:
 old "Start"
 new "开始"

这里最容易犯的错是改 old。
old 不是给你润色的原文，它是 Ren’Py 用来匹配原始文本的钥匙。空格、标点、文本标签、大小写、换行都可能影响匹配。

所以规则很简单：

1
2


old 保持原样
new 写翻译

如果一个 old 看起来有点怪，比如带着 {size=}、颜色标签、状态后缀，也不要顺手清理。真实运行时显示出来的字符串很可能就是这么匹配的。

菜单和 UI 要单独查

Ren’Py 自动生成翻译文件很有用，但它不一定能覆盖所有运行时可见文本。

除了对话，还要主动搜索这些位置：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


Character("...")
text "..."
textbutton "..."
tooltip "..."
renpy.input("...")
renpy.notify(...)
default xxx = "..."
define xxx = "..."
$ xxx = "..."
menu:

尤其是菜单选项。它们经常带条件、标签、样式或自定义 screen 处理。你在翻译文件里看到的 old "Yes"，不一定覆盖了运行时真正显示的 {color=#fff}Yes{/color}。

如果某个选项死活不翻译，别先怀疑 Ren’Py。先把运行时原文和 old 逐字节对一下，包括空格和标签。

变量插值是隐藏大坑

这次整理 Skill 时，最值得单独记下的是变量插值。

Ren’Py 里常见写法是：

1

"Welcome to [tribe_name], [player_name]."

如果 tribe_name 的值是 "Wartribe"，即使你在字符串表里写了：

1
2


old "Wartribe"
new "战族"

最终显示时也不一定会自动变成中文。因为普通的 [tribe_name] 插值只是把变量当前值拿出来显示，不会必然再走一遍翻译表。

这种情况下要用翻译感知插值：

1

"欢迎来到 [tribe_name!t]，[player_name!t]。"

如果变量翻译后还需要继续插值，可以看情况用：

1

[variable!ti]

这个坑很隐蔽，因为外面的句子已经翻译了，只有嵌进去的人名、地名、阵营名还保留英文。看起来像漏翻，其实是插值方式不对。

高级补丁放 zzz.rpy

有些问题不是一句 old/new 能解决的，比如：

添加语言切换按钮
设置默认语言
替换字体
调整中文 UI 样式
覆盖 screen
修正少量源代码层面的文本

这类内容可以放到翻译目录里的补丁文件，例如：

1

game/tl/chinese/zzz.rpy

常见做法是加：

1

init offset = 1

让补丁比原定义更晚加载。这样可以覆盖 screen、style、define 等内容，又不会直接动原文件。

默认语言也要分清：

1

define config.default_language = "chinese"

这更适合“首次启动默认中文”。
如果用 config.language 强行指定语言，就可能变成每次启动都锁死语言，不一定符合玩家预期。

字体不是最后再想的事

中文翻译里，字体问题经常到最后才暴露：文本已经翻好了，进游戏一看全是方块。

Skill 里把字体和样式也放进检查范围。一般有几种处理方式：

在 translate <language> style 里覆盖样式
在 translate <language> python 里设置 GUI 变量
在 game/tl/<language>/ 下镜像放置字体资源
用 zzz.rpy 做语言限定的字体覆盖

关键是尽量让字体修复只影响目标语言，不要全局改坏原版 UI。

不要信任批量替换

批量脚本很诱人，尤其是翻译量大的时候。但 Ren’Py 文件里有很多结构性内容：

缩进
引号
转义符
文本标签
插值变量
%、\、/ 这类特殊符号

如果脚本没有严格按 UTF-8 读写，中文很容易变成乱码、问号或损坏标签。

所以 Skill 里明确写了：在 Windows 上做批量编辑时，要使用明确的 UTF-8 读写方式。改完后要扫一遍：

1
2
3
4
5


乱码
???? 
� 
损坏的 {tag}
损坏的 [variable]

翻译文件不是普通 Markdown，不能只看文本大概对不对。

验证要看三个文件

改完之后，不要只打开一两句台词看看。至少要检查：

1
2
3


errors.txt
traceback.txt
text_overflow.txt

它们分别对应不同问题：

errors.txt：生成或启动阶段的问题
traceback.txt：运行时崩溃
text_overflow.txt：文本溢出、排版放不下

还要实际测试：

主菜单
设置界面
语言切换
存档读档
代表性对话
选项菜单
字体显示
被覆盖的 label 或 screen

Ren’Py 翻译不是“文件能保存就完成”，而是“游戏运行时每条路径都能正确显示”。

这个 Skill 最有用的地方

我觉得它最有用的不是告诉 AI “请翻译成中文”，而是强迫 AI 先尊重 Ren’Py 的工程规则。

它会提醒我：

不要乱改 old
不要直接动原脚本
不要忽略菜单和 UI
不要忘记变量插值的 !t
不要把字体和排版当成收尾小事
不要跳过运行验证

这比单纯提高翻译文风重要得多。

总结

Ren’Py 游戏汉化本质上不是文本替换，而是一套围绕运行时匹配、语言加载、界面覆盖和补丁分发的工程流程。

把这套流程写成 Skill 之后，AI 就不只是“会翻译”，而是会按固定步骤处理项目结构、翻译文件、UI 字符串、变量插值、字体、补丁和验证。

下一次再做 Ren’Py 游戏翻译时，就不用从零回忆哪些坑要避开。直接让 Skill 接管检查清单，人只需要把关翻译质量和最终体验。

游戏汉化 on September的个人空间