如何将 Godot 游戏翻译成英语

RuneTranslate 现在能翻译基于 Godot 构建的游戏 —— 那个免费、开源的引擎已悄然成为发布独立或同人游戏最流行的方式之一。Godot 历来是从外部最难翻译的引擎之一，因为一个已发布的 Godot 游戏是一个密封的盒子：一切都住在单一的 .pck 归档里（常常粘在 .exe 本身的末尾），脚本被编译成 GDScript 字节码，场景被存为二进制。RuneTranslate 打开那个盒子、读出文本，并把你的译文打包回去。

这是一个新加入的引擎，所以首先要说：如果你把 RuneTranslate 指向一个 Godot 游戏，而它检测不到、打不开，或导出的副本无法运行，请告诉我们。文末有更多说明。

Godot 究竟是什么

Godot 是一个免费、MIT 许可、开源的游戏引擎，已成为 2D 和 3D 独立游戏的主流选择，越来越多的日本同人作品也发布在它上面。游戏通常用 GDScript（Godot 自己的类 Python 语言）编写，并布局为场景 —— 存为资源的节点树。当一个游戏被导出时，全部内容 —— 脚本、场景、图像、音频 —— 都被打进一个 .pck 包文件里，它要么放在可执行文件旁边，要么非常常见地粘在 .exe 本身的末尾。正是那种打包方式让 Godot 游戏看起来密不可破。

Godot 游戏为何一直难翻译

与像 Ren'Py 那样脚本驱动的引擎不同，一个已发布的 Godot 游戏几乎不以纯文本暴露任何东西：

• 一切都在 `.pck` 里。 没有松散的脚本或文本文件可编辑 —— 而当包嵌在 .exe 里时，甚至没有一个可见的 .pck 供工具去指向。
• 脚本是编译过的。 GDScript 以编译过的字节码（.gdc）发布 —— 而在现代 Godot 4 中该字节码还被额外压缩 —— 所以烘焙进代码里的对话不是你能用 grep 找、或用文本编辑器打开的东西。
• 场景是二进制的。 UI 标签和菜单文本住在以 Godot 二进制资源格式（.scn）保存的场景文件里，而非你在编辑器里看到的、人类可读的 .tscn。
• 大多数游戏不用翻译文件。 Godot 有一个一等公民的本地化系统（CSV / .po → .translation），但很多游戏 —— 尤其是较小的同人作品 —— 从不使用它，而只是把日语硬编码进脚本和场景里。RuneTranslate 正是针对那些硬编码字符串（在 .gd、.tscn、.tres、.cfg 和 project.godot 里）；它尚不读取 .csv / .po / .translation 本地化表，所以一个确实使用它们的游戏目前不在支持范围内。

RuneTranslate 现在能做什么

RuneTranslate 把 Godot 当作一等公民的引擎，替你重建可读的项目。在底层，它捆绑了一份 GDRE Tools（开源的 Godot 逆向工程工具包），并用它来：

• 拆包 `.pck` —— 独立的、data.pck，或粘在 .exe 末尾的包（RuneTranslate 会自动检测嵌入包的签名）。
• 反编译编译过的 GDScript（.gdc → .gd），让代码里的对话和旁白重新变得可读。
• 转换二进制场景（.scn → .tscn），让上面的标签和 UI 文本能被抠出来。

然后它扫描恢复出的项目，在编辑器里按文件分组列出每一条可翻译的字符串 —— 脚本对话和场景/UI 文本 —— 引擎标记被屏蔽在占位符之后，让翻译服务永远不会弄乱它。导出时它把你的译文拼接回恢复出的源代码，并重新打包一个可运行的游戏副本（下面详述具体做法）。

你需要准备什么

• Windows 版 RuneTranslate —— 免费，每一种引擎和翻译服务都已解锁。
• 一个 Godot 游戏文件夹 —— 通常只是游戏的 .exe（包嵌在里面），或一个 .exe 加一个 .pck / data.pck 在旁边。Godot 3.x 和 4.x 都支持。
• 一个目标语言 —— 英语、西班牙语、法语、德语、葡萄牙语、俄语、中文、意大利语、土耳其语、越南语，以及 20 多种其他语言。
• 一个翻译服务。免费的 Google Translate 开箱即用；DeepL 有免费档位；OpenAI、Anthropic、一个本地模型（Ollama / LM Studio），以及任意 OpenAI 兼容 API 都需要自备密钥。Godot 游戏通常对话量大，所以 LLM（OpenAI / Anthropic）或 DeepL 对故事文本读起来最好。

第 1 步：打开游戏文件夹

启动 RuneTranslate，点击 新建项目，把它指向 Godot 游戏目录 —— 含有游戏 .exe（以及一个 .pck，如果它单独发布）的文件夹。引擎检测会自动运行：它会识别可执行文件末尾的嵌入包签名、一个松散的 .pck，或一个 Godot 项目。你的原始文件永远不会被修改。

第 2 步：拆包并恢复项目

RuneTranslate 会运行它捆绑的 GDRE Tools 附属程序来拆包、反编译编译过的 GDScript，并把二进制场景转换成可读源代码。然后它扫描那个恢复出的项目，按文件分组列出每一条可翻译的行 —— 脚本里的对话和旁白，加上场景里的标签和 UI 文本。资源路径、节点名和其他代码标识符会被过滤掉，于是你只翻译玩家真正看得到的字符串。

第 3 步：翻译

选一个翻译服务并运行。对于故事驱动的游戏，LLM（OpenAI / Anthropic）最适合角色声线，DeepL 对旁白又快又干净，而免费的 Google Translate 对短 UI 字符串够用。Godot 游戏常常把对话作为长的行数组保存在单一脚本里 —— 一个"故事数据库" —— 所以同一个角色名或地名会出现数百次。事先给你的角色阵容和关键术语建好术语表，让它们处处渲染得一模一样；参见 术语表 101。用 AI 润色器 做可选的一遍处理，收紧机器翻译往往留下的生硬措辞。

第 4 步：导出译好的构建

点击 导出。因为原始脚本是编译过的字节码，RuneTranslate 采用源代码覆盖的做法：它把你的译文写进恢复出的 .gd / .tscn 源代码、丢弃编译过的 .gdc / 二进制 .scn（让引擎回退到松散的译好源代码）、重新打包一个全新的 .pck，并把它重新嵌进 .exe 的一个副本里。你的原始游戏保持不动；你得到一个独立、可运行、译好的副本。

导出范围，请留意：导出目前适用于其包嵌在 `.exe` 里、且建立在 Godot 4 上的游戏（纯 TS 重打包器只写 Godot 4 包格式）。一个在可执行文件旁边发布独立 .pck 的游戏，或一个建立在 Godot 3 上的游戏，仍然会检测、提取并翻译 —— 你可以完成整个翻译处理并把它用作术语表或参考 —— 但 RuneTranslate 还不能为那些游戏重打包一个可玩的构建。嵌入包的 Godot 4 游戏（最常见的同人情形）能端到端地导出。

第 5 步：验证副本能运行

导出的构建依赖 Godot 运行时在加载时编译松散的译好脚本源代码，所以 —— 和任何新引擎一样 —— 在分享之前先启动一次导出的游戏，确认对话和菜单显示你的语言。如果一个脚本加载不了，那正是能帮我们加固它的那种报告（见下文）。

已知的局限

• 尽力而为。 在重新分发之前，先验证导出的游戏能正确启动和阅读。
• 导出仅限嵌入包 + Godot 4。 独立 .pck 游戏和 Godot 3 游戏能检测、提取并翻译，但还不能被重打包成一个可玩的构建。
• 仅硬编码字符串。 RuneTranslate 读取烘焙进脚本和场景里的日语，而非少数游戏使用的 .csv / .po / .translation 本地化表。
• 加密包。 一些游戏发布用一个烘焙进二进制的密钥加密的 .pck；那些还打不开。
• C# / .NET（Mono）游戏。 RuneTranslate 专注于 GDScript；编译进一个 C# Godot 游戏逻辑里的文本不在支持范围内。
• 绘进图像里的文本。 一个作为艺术品渲染的标题或标志是像素，不是字符串 —— 那是 图片文字翻译 的活儿，不是脚本提取。
• 非拉丁目标语言取决于游戏是否发布了一个真正能渲染它们的字体。

告诉我们哪里坏了

Godot 横跨许多引擎版本和打包风格，我们并未全部见过。如果一个游戏检测不到、拆不开包，或导出了无法启动的东西，请报告 —— 游戏名、它的 Godot 版本，以及它的打包方式（嵌入包对一个松散的 .pck）正是最能帮我们最快加固它的东西。

下载 RuneTranslate，把它指向你一直想读的那个 Godot 游戏，试一试。想看另一个现代引擎，接着看 Unity 教程。