教程 on September的个人空间

把 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 接管检查清单，人只需要把关翻译质量和最终体验。

Markdown 基本语法指北

Mon, 06 Apr 2026 00:00:00 +0000

几乎所有现代的博客平台和静态网站生成器都完美支持 Markdown。它能让我们在纯文本环境下专注于内容创作，而无需被复杂的排版工具打断思路。

以下是日常写作中最常用的 Markdown 基本语法。

1. 标题 (Headings)

要在文档中创建标题，请在单词或短语前面添加井号 (#)。# 的数量代表了标题的级别。为了兼容性，请务必在 # 和标题文字之间保留一个空格。

1
2
3
4
5
6


# 一级标题
## 二级标题
### 三级标题
#### 四级标题
##### 五级标题
###### 六级标题

2. 段落与换行 (Paragraphs & Line Breaks)

段落： 创建段落非常简单，只需要使用一或多个空白行将连续的文本分隔开即可。不要用空格（spaces）或制表符（tabs）缩进段落。

换行： 如果你想在段落内强行换行（创建 <br>），请在这一行的末尾添加两个或多个空格，然后按回车键。

3. 强调语法 (Emphasis)

通过添加星号或下划线，可以轻松实现加粗和斜体效果。

加粗：在单词或短语的前后各添加两个星号或下划线。
- **加粗文本**
- __加粗文本__
斜体：在单词或短语的前后各添加一个星号或下划线。
- *斜体文本*
- _斜体文本_
加粗斜体：前后各添加三个星号或下划线。
- ***加粗且斜体的文本***

4. 引用 (Blockquotes)

要在段落前添加块引用，请在段落的第一行或者每一行前面添加一个 > 符号。引用不仅支持多段落，还可以嵌套其他 Markdown 元素。

1
2
3
4


> 这是一段引用文本。
> 
> > 这是一个嵌套的引用。
> > 里面还可以使用 **加粗** 等其他语法。

5. 列表 (Lists)

你可以将项目组织成有序列表或无序列表。

有序列表： 在每个列表项前添加数字并紧跟一个英文句点。数字不必按数学顺序排列，但列表应当以数字 1 起始。

1
2
3


1. 第一项
2. 第二项
3. 第三项

无序列表： 在每个列表项前添加破折号 (-)、星号 (*) 或加号 (+)。建议统一使用 -。

1
2
3


- 苹果
- 橘子
- 香蕉

6. 代码 (Code)

行内代码： 如果要把句子中的某个单词或短语标记为代码，请将其包裹在反引号 ( \ `) 中。

示例：使用 print("Hello World") 来输出文本。

代码块： 要创建多行代码块，请将代码包裹在三个反引号 (```) 中。在第一排的反引号后面加上编程语言的名称，就可以实现代码高亮。

1
2


def greet(name):
 print(f"Hello, {name}!")

7. 分隔线 (Horizontal Rules)

要创建一条水平分隔线，请在单独一行上使用三个或多个星号 (***)、破折号 (---) 或下划线 (___)，并且不能包含其他内容。

1

---

8. 链接 (Links)

链接文本放在中括号内，链接地址放在后面的括号内。

语法： [超链接显示名](超链接地址 "可选的提示标题")
示例： 欢迎访问我的 GitHub

如果想直接显示网址并使其可点击，可以用尖括号将网址括起来：<https://example.com>。

示例： https://blog.september.win/

9. 图片 (Images)

插入图片的语法和链接非常相似，只是前面多了一个感叹号 (!)。

语法： ![图片替代文字](图片链接地址 "可选的图片标题")
示例：

1

![美丽的风景图](https://markdown.com.cn/assets/img/philly-magic-garden.9c0b4415.jpg "Magic Gardens")

10. 转义字符 (Escaping Characters)

如果你需要显示原本用于格式化 Markdown 文档的字符（比如你不希望 # 变成标题），可以在该字符前面添加反斜杠 (\) 来转义。

1

\* 这不是一个无序列表项，而是一个普通的星号。

掌握了以上基本语法，你就已经具备了使用 Markdown 撰写结构清晰、排版优雅的博客文章的能力。

Markdown 拓展语法指北

Mon, 06 Apr 2026 00:00:00 +0000

掌握了基本语法后，Markdown 的扩展语法将为你打开新世界的大门。Markdown 官方标准（Basic Syntax）仅包含基础元素，但在实际应用中，许多解析器（如 GitHub Flavored Markdown, Hugo 等）支持更强大的扩展语法。掌握这些进阶技能，能让你轻松处理表格、代码高亮和任务清单。

1. 表格 (Tables)

要在 Markdown 中创建表格，请使用管道符 | 分隔各列，并使用三个或多个连字符 --- 创建表头和内容的分隔线。

对齐方式

通过在分隔线行添加冒号 :，可以控制列的对齐方式：

:---：左对齐（默认）
---:：右对齐
:---:：居中对齐

1
2
3
4


| 语法 | 说明 | 示例 |
| :--- | :---: | ---: |
| 表格 | 居中 | $10 |
| 扩展 | 左对齐 | $20 |

2. 围栏代码块 (Fenced Code Blocks)

扩展语法允许你使用三个反引号（```）或三个波浪号（~~~）来包裹多行代码。最强大的功能是支持语法高亮，只需在开头反引号后指定语言名称（如 python, html, css 等）。

1
2
3
4


{
 "project": "September's Blog",
 "status": "Learning Markdown"
}

3. 脚注 (Footnotes)

脚注用于对正文中的内容添加补充说明，而不会打断读者的阅读流。

用法：在词汇后面使用 [^1]，然后在文档底部定义说明。
示例：这是一个使用了脚注的句子。¹

4. 标题 ID (Heading IDs)

部分解析器支持给标题指定唯一的 ID，方便在文章内部进行跳转（锚点链接）。

1

### 我的目标 {#goals}

5. 定义列表 (Definition Lists)

定义列表允许你列出术语及其对应的定义。

1
2
3
4
5
6


第一项
: 这是第一项的定义。

第二项
: 这是第二项的定义。
: 这是第二项的另一个定义。

6. 删除线 (Strikethrough)

在文字前后各添加两个波浪号 ~~ 来表示已被删除或错误的信息。

示例：~~这件衣服原价 99 元~~，现在只需 19 元。

7. 任务列表 (Task Lists)

任务列表非常适合管理待办事项或项目进度。使用带有空格或 x 的中括号 [ ]。

1
2
3


- [x] 完成基础语法学习
- [x] 掌握扩展语法
- [ ] 发布第一篇技术博客

8. 使用 Emoji 表情

在 Markdown 中添加表情有两种常见方式：

直接从表情库复制并粘贴 Emoji 符号（如 🚀）。
使用“短代码”（需解析器支持），例如输入 :smile: 会被渲染成 😄。

9. 自动网址链接 (Automatic URL Linking)

许多现代解析器会自动将纯文本形式的 URL（如 https://google.com）直接转换为可点击的超链接，而无需额外添加中括号。

通过灵活运用这些扩展语法，你的 Markdown 文档将不仅仅是文字，更是一个具备专业排版水准的数字化作品。

这些扩展语法能显著提升你博客内容的专业度和丰富度。建议在使用前，先确认你所使用的博客主题或编辑器是否已完整开启这些功能支持。

这是在文档末尾自动生成的补充说明。 ↩︎

在安卓手机上搭建个人博客的赛博折腾记录

Sun, 05 Apr 2026 00:00:00 +0000

把一台安卓手机变成全天候运行的服务器，这里记录一下整个博客的底层架构、一键启动脚本以及日常编辑的工作流，作为个人记录用 Desuwa。

1. 核心底层架构（搭建过程）

整个站点的运行不需要去购买云服务器，所有的计算和渲染都在手机里完成。

运行环境：安卓端安装 Termux，提供完整的 Linux 终端环境。
核心引擎：使用 Hugo 生成静态页面，并配置了功能齐全的 Stack 主题。
外网穿透：通过 Cloudflared 建立加密隧道。把本机的 8080 端口映射到公网域名，同时打通了 SSH 通道。
云端编辑器：在 Termux 内运行 code-server，提供网页版的 VS Code 界面。

2. 自动化启动方案

手机重启后，手动敲命令拉起服务效率太低。为了实现“一键复活”，配置了结合 tmux 的自动化脚本。

手机开机打开 Termux 后，直接执行以下代码：

1
2
3
4
5
6


termux-wake-lock
sshd
tmux new-session -d -s blog "cloudflared tunnel run"
tmux new-window -t blog:1 "code-server --auth none --bind-addr 127.0.0.1:8443"
tmux new-window -t blog:2 "cd ~/myblog && hugo server -D -p 8080"
tmux attach -t blog

这段脚本执行了以下操作：

获取唤醒锁，防止安卓杀后台。
启动 SSH 服务，允许电脑远程接入。
创建名为 blog 的虚拟窗口，在后台并行三个任务：内网穿透、VS Code 服务、Hugo 本地实时预览。
随时可以通过快捷键 Ctrl+B 配合数字键 0, 1, 2 切换查看不同服务的实时日志。

3. 跨端编辑流

服务端跑通后，日常编辑不需要在手机屏幕上操作。

在电脑端打开终端，执行端口转发：

1

ssh -L 8443:127.0.0.1:8443 phone

接着，在电脑浏览器里打开 http://localhost:8443/，即可接入完整的 VS Code 界面。工作流如下：

敲击 Ctrl + ~ 呼出终端，使用 hugo new post/文章名.md 创建新文章。
直接在网页编辑器里撰写 Markdown 内容。
按下 Ctrl + S 保存，Hugo 会在毫秒级完成重新编译。
刷新博客对应的公网页面，即可看到最新排版效果。