本地化要从工程开始
个人游戏准备上 Steam 时,常常先把商店页翻译成英文,再考虑游戏内文本。这样会出现一个尴尬情况:商店页写着支持英语、简体中文和日语,但游戏里还有硬编码中文;或者 UI 能显示英文,却因为德语、俄语文本更长而溢出。玩家不会把这些问题看成“小团队可以理解”,他们只会认为语言支持不可靠。
本地化的核心不是翻译,而是管线。文本能否统一抽取,语言能否随时切换,字体是否覆盖字符,UI 是否能容纳不同长度,翻译是否知道上下文,版本更新后是否能补齐新增文本,这些都属于开发问题。个人项目越小,越不能靠记忆维护。
文本不要硬编码
所有玩家可见文本都应该进入本地化表,包括按钮、提示、设置、错误信息、成就说明、教程、章节名、道具描述、结局文本。调试信息和内部日志可以例外,但不要让它们出现在正式包。
一个基础文本表可以这样设计:
| key | zh-CN | en | note |
|---|---|---|---|
menu.start | 开始游戏 | Start Game | 主菜单按钮 |
tutorial.interact | 按 {key} 互动 | Press {key} to interact | {key} 来自输入系统 |
item.clock.desc | 一只停在午夜的旧钟。 | An old clock stopped at midnight. | 道具描述 |
error.save_failed | 存档失败,请检查磁盘空间。 | Save failed. Please check disk space. | 系统提示 |
Key 命名要稳定,不要用中文原文当 Key。原文会改,Key 应该服务代码引用。命名方式可以按界面或系统分组:menu.*、settings.*、chapter01.*、item.*、achievement.*。
文本抽取和交付
如果项目文本少,可以用 CSV 或 Google Sheets;如果文本多,建议用 JSON、YAML 或专门本地化工具。关键是形成固定交付流程:
- 开发者新增 Key 和源语言文本。
- 每周导出待翻译差异。
- 翻译人员填写目标语言和备注。
- 开发者导入并跑缺失检查。
- QA 在游戏内截图或记录问题。
不要把翻译放在聊天记录里,也不要让译者直接改代码文件。个人项目协作资源少,更要减少来回确认。
占位符要有上下文
很多翻译问题来自占位符。比如 {count}、{item}、{key} 在不同语言里语序不同,复数规则也不同。表格里要给译者说明占位符含义:
| 文本 | 备注 |
|---|---|
你获得了 {count} 个碎片 | {count} 是整数,可能为 1、2、10 |
按 {key} 打开背包 | {key} 是输入图标或按键名 |
{name} 已加入队伍 | {name} 是 NPC 名称 |
如果引擎支持复数和性别规则,要尽早使用;如果不支持,至少避免写出强依赖中文语序的句子。比如“获得:{item} x {count}”比“你获得了 {count} 个 {item}”更容易跨语言处理。
字体和字符覆盖
字体是本地化里非常容易被低估的部分。中文、日文、韩文、俄文、越南文、土耳其文都可能有不同字符需求。一个字体在你的开发机上显示正常,不代表发行包里包含了对应字形。
检查字体时要列语言表:
| 语言 | 字符需求 | 字体策略 |
|---|---|---|
| 简体中文 | CJK 大字符集 | 使用子集或动态字体 |
| 英文 | 拉丁字符 | 可使用主 UI 字体 |
| 日文 | 假名、汉字 | 检查缺字 |
| 俄文 | 西里尔字母 | 选择覆盖字体 |
| 德文 | 长单词和变音符号 | 检查 UI 宽度 |
CJK 字体文件很大,直接打包完整字体会增加体积。可以根据文本生成字体子集,但要注意玩家输入、用户名、存档名等动态文本可能需要更多字符。不要为了省体积导致缺字方块。
UI 溢出要作为功能测试
英文通常比中文长,德语可能更长。按钮、设置项、任务描述、字幕都要测试文本长度。解决方式包括:
- 使用自适应宽度。
- 允许多行换行。
- 给按钮文本设置较小字号上限。
- 为不同语言准备短文案。
- 避免把文本嵌进不可伸缩图片。
不要把所有溢出都交给自动缩小字号。字号过小会影响可读性。更合理的是在 UI 设计时留出伸缩空间,并给翻译提供最大长度参考。
语言切换和 Steam 语言
游戏可以读取 Steam 客户端语言作为默认语言,但玩家仍应该能在游戏内修改。语言设置要保存,并明确优先级:
| 来源 | 优先级 |
|---|---|
| 游戏内玩家选择 | 高 |
| Steam 客户端语言 | 中 |
| 系统语言 | 低 |
| 默认语言 | 兜底 |
切换语言时,要检查菜单、游戏内提示、字幕、成就名称、设置页是否同步刷新。有些系统只在场景加载时读取文本,语言切换后会混合显示两种语言。上线前要专门测这个场景。
本地化和商店页承诺一致
Steam 商店页的语言支持标签要和游戏实际支持一致。不要因为商店短描述翻译了某种语言,就勾选完整界面和字幕支持。如果游戏只有商店页翻译,没有游戏内翻译,应谨慎描述。
还要注意 Demo 和正式版的语言状态。如果 Demo 只支持中英,正式版计划支持更多语言,就在页面和公告中说清楚。玩家下载 Demo 后发现语言缺失,会影响信任。
QA 表格怎么做
本地化 QA 不只是检查错别字。建议按场景记录:
| 场景 | 检查内容 |
|---|---|
| 主菜单 | 按钮是否溢出,语言切换是否刷新 |
| 设置页 | 分辨率、音量、键位文本是否一致 |
| 教程 | 输入图标和文本是否匹配 |
| 对话 | 换行、说话人、语气是否正确 |
| 道具栏 | 名称和描述是否被截断 |
| 结算页 | 数字、时间、单位格式是否正确 |
| 存档页 | 日期时间格式是否清楚 |
每条问题要包含语言、场景、截图、Key、建议修改。只写“英文有问题”没有用,开发者很难定位。
更新后的文本维护
游戏发售后会继续更新,文本也会变化。每次新增内容时,都要跑缺失检查:
- 新 Key 是否有所有目标语言。
- 删除 Key 是否仍被代码引用。
- 修改源语言后是否通知翻译。
- 字体子集是否需要重新生成。
- 成就和商店公告是否同步翻译。
个人开发者容易在补丁中只改中文,忘记英文和其他语言。长期看,这会让非中文玩家觉得游戏被放弃。即使暂时没有预算翻译全部补丁,也要在公告中诚实说明语言更新时间。
最终检查清单
- 所有玩家可见文本从本地化表读取。
- Key 稳定,备注包含上下文。
- 占位符含义清楚,避免固定中文语序。
- 字体覆盖目标语言字符。
- UI 按长文本测试,不依赖临时缩小。
- 游戏内语言选择和 Steam 语言优先级明确。
- 商店页语言承诺和游戏内容一致。
- 本地化 QA 有截图、Key 和场景记录。
本地化做得自然,玩家不会专门提起;做得粗糙,玩家很快会退出。个人游戏想在 Steam 获得更多地区的机会,就要把本地化当成开发管线,而不是发布前的一次翻译任务。
翻译成本不足时怎么取舍
如果预算只能覆盖一部分语言,优先翻译直接影响购买和游玩的文本:商店页、主菜单、设置、教程、核心系统、错误提示、结局说明。大量背景书籍、支线闲聊、装饰性文本可以分阶段处理,但不要在商店页把未完成语言写成完整支持。
也可以把文本按风险分层:
| 层级 | 内容 | 原因 |
|---|---|---|
| 必须准确 | 按键、目标、系统提示、存档错误 | 影响能否继续玩 |
| 应该自然 | 对话、道具描述、章节标题 | 影响沉浸感 |
| 可后续优化 | 彩蛋、装饰牌、非关键环境文本 | 不阻断主流程 |
这种取舍比平均翻译所有文本更现实。玩家可以接受少量非关键文本稍后优化,但很难接受教程和设置翻译错误。
本地化计划最后要回到版本表:哪些语言随首发提供,哪些语言在补丁中补齐,哪些语言只做商店页。把边界写清楚,比含糊承诺更能保护玩家预期。
继续阅读
探索更多技术文章
浏览归档,发现更多关于系统设计、工具链和工程实践的内容。