游戏本地化自动化 QA 检查清单:变量、占位符、截断、换行与 RTL 的机器化校验

游戏里最丢人的本地化事故,往往不是译得不好,而是 {player_name} 直接显示成了原文、按钮文字被截成半句、阿拉伯语 UI 整个镜像错位。这些问题和译文水平无关,而是工程性的格式问题——也正因为如此,它们大多可以被机器逐条检查出来。

人工 LQA 应该把精力花在语气、术语、情感这些机器判断不了的地方;而下面这一类"对错分明"的项,完全可以交给自动化在每次构建时跑一遍。这篇就是一份可收藏的、游戏向的自动化 QA 检查清单。

变量与占位符:最高优先级的机器检查项

占位符错误是上线后最常见的问题之一,也最容易被自动拦截。把它们放在清单最前面。

• 占位符数量一致:源串里有几个 {count}、%s、%1$s,译串里就必须有几个,不多不少。漏掉一个,游戏里就会显示一个空洞或崩一行。
• 占位符名称/索引一致:命名占位符 {player} 不能被译者"翻译"成 {玩家};位置参数 %1$s %2$s 的索引不能错配。
• 格式说明符不被破坏:%d、%.2f、{0:N0} 这类带格式的标记,内部字符不能被改动或插入空格。
• 复数与性别变体完整:用了 ICU MessageFormat 的 plural/select 时,目标语言要求的所有分支(如俄语的 one/few/many/other)都要在。
• HTML/富文本标签配对:<b>…</b>、<color=#fff>…</color> 之类的标签必须成对且嵌套正确,顺序可随语序调整,但不能丢标签。

这些规则都能写成正则或基于语法树的断言,在 CI 里对全量字符串跑。关于如何把这类硬性检查和"译文好不好"的软性评分分层处理,可以参考我们对 AI LQA 评分框架的拆解。

截断与溢出:在真实字体和分辨率下才暴露

文本长度是游戏 UI 的天敌。德语、芬兰语、俄语常比英语更长——短串尤其明显,经验上常见 +30% 甚至更多,但具体随语种与字符串长度而异(这是经验值,不是定值),而中日韩单字信息密度又高得多。可机器检查的项包括:

• 长度上限:对带 maxLength 约束的 key,译串超长直接报错。
• 像素宽度预估:结合目标字体度量,估算渲染宽度是否超出控件;比纯字符数更准,尤其对 CJK 与等宽数字。
• 关键 UI 元素白名单:按钮、标签页、货币数字这类"绝不能换行/截断"的位置单独标记,阈值更严。
• 数字与单位格式:千分位、小数点、货币符号位置随地区变化,长度也随之变化,需一并纳入预估。

纯靠人工在每种语言、每个分辨率下逐屏检查并不现实;自动化能先把高风险项筛出来,人再去重点复核。

换行、空格与转义:看不见但会出事

这一类问题在测试机上常常"看起来没事",换个设备或语言就翻车。

检查项	典型问题	机器规则
换行符	译串擅自删/加 \n,导致多行排版错乱	比对源/译串换行符数量与位置语义
不间断空格	CJK 与 RTL 里   被普通空格替换	检测特定 Unicode 空格是否保留
转义序列	\"、\\、\t 被错误转义或反转义	校验转义符在目标格式下合法
首尾空白	译串多出前后空格,拼接时出错	去空白后比对,标记可疑差异
受控字符	出现零宽字符、BOM、控制符	扫描不可见字符并告警

尤其是字符串拼接(把译文片段在运行时拼起来)的场景,首尾空白和换行的不一致几乎必然导致显示问题,值得设为硬性拦截。

字体回退与字符覆盖:别让玩家看到豆腐块

新增一种语言时,最容易被忽略的是:你的字体到底有没有这些字符的字形。缺字形时,引擎会显示成方框(俗称"豆腐块"),严重时整句不可读。

• 字符集覆盖检查:对每条译串的每个码点,验证目标字体(含回退链)是否提供字形。
• 回退链验证:确认 CJK、阿拉伯语、泰语、天城文等需要专门字体的语言,在回退链里有对应字体。
• 组合字符与连字:泰语、印地语等需要正确的字形整形(shaping),要确认渲染管线支持,而不仅是码点存在。
• 表情与符号:活动文案里的 emoji、特殊符号是否在所选字体内有定义。

这一步能在打包前就把"上线才发现满屏方块"的风险消灭掉。

RTL 与双向文本:阿拉伯语、希伯来语的专属雷区

右到左(RTL)语言不只是"文字反过来"。可机器检查的项相对集中,但漏一个就很显眼:

• 方向性标记:在 LTR 与 RTL 混排(如阿拉伯语句子里嵌英文 ID 或数字)时,是否需要 ‎/‏ 等方向控制符来避免乱序。
• 占位符在双向文本中的位置:数字、{var} 嵌入 RTL 文本时的视觉顺序是否正确。
• 镜像友好性:译串本身无法决定 UI 镜像,但可以标记出"含 RTL 字符却被放进未做镜像界面"的高风险组合,提示人工核查。
• 标点方向:括号、引号在 RTL 下的开合方向是否正确。

把清单接进流水线,而不是临上线才想起

这些检查的价值在于早、且每次都跑。建议:

1. 作为 CI 的一道关卡:每次字符串变更或构建触发全量校验,把上面的硬性项设为阻断级,可疑项设为告警级。
2. 分层处理:机器先过格式与一致性,把"对错分明"的拦下;人工和 AI LQA 再专注语气、术语、文化适配等软性维度。
3. 结合运行时兜底:即便如此,仍会有只在真实设备上才暴露的溢出或错位。这时不必等下个版本——参见游戏内实时字符串修复,在运行时定位并改掉问题字符串。

Loxily 的思路正是把这套机器可查的清单,和理解游戏语境的 AI LQA、以及运行时实时修复连成一条线:格式问题让规则去拦,语境与质量交给懂游戏的模型,残留问题用实时修复收尾。

结论

游戏本地化的多数"翻车现场",其实是工程格式问题,而非翻译质量问题——这意味着它们大多可以被自动化逐条拦下。把变量、占位符、截断、换行、转义、字体回退、RTL 这几类做成每次构建都跑的检查清单,你就能在上线前消灭绝大部分低级事故,把宝贵的人力留给机器判断不了的地方。