Steam 游戏内本地化实战:2021 年 3 月个人项目文本、字体与多语言管线

从文本抽取、Key 命名、字体选择、UI 溢出、翻译交付、Steam 语言设置到 QA 表格,拆解个人游戏本地化开发流程。

本地化要从工程开始

个人游戏准备上 Steam 时,常常先把商店页翻译成英文,再考虑游戏内文本。这样会出现一个尴尬情况:商店页写着支持英语、简体中文和日语,但游戏里还有硬编码中文;或者 UI 能显示英文,却因为德语、俄语文本更长而溢出。玩家不会把这些问题看成“小团队可以理解”,他们只会认为语言支持不可靠。

本地化的核心不是翻译,而是管线。文本能否统一抽取,语言能否随时切换,字体是否覆盖字符,UI 是否能容纳不同长度,翻译是否知道上下文,版本更新后是否能补齐新增文本,这些都属于开发问题。个人项目越小,越不能靠记忆维护。

文本不要硬编码

所有玩家可见文本都应该进入本地化表,包括按钮、提示、设置、错误信息、成就说明、教程、章节名、道具描述、结局文本。调试信息和内部日志可以例外,但不要让它们出现在正式包。

一个基础文本表可以这样设计:

keyzh-CNennote
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 或专门本地化工具。关键是形成固定交付流程:

  1. 开发者新增 Key 和源语言文本。
  2. 每周导出待翻译差异。
  3. 翻译人员填写目标语言和备注。
  4. 开发者导入并跑缺失检查。
  5. 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 获得更多地区的机会,就要把本地化当成开发管线,而不是发布前的一次翻译任务。

翻译成本不足时怎么取舍

如果预算只能覆盖一部分语言,优先翻译直接影响购买和游玩的文本:商店页、主菜单、设置、教程、核心系统、错误提示、结局说明。大量背景书籍、支线闲聊、装饰性文本可以分阶段处理,但不要在商店页把未完成语言写成完整支持。

也可以把文本按风险分层:

层级内容原因
必须准确按键、目标、系统提示、存档错误影响能否继续玩
应该自然对话、道具描述、章节标题影响沉浸感
可后续优化彩蛋、装饰牌、非关键环境文本不阻断主流程

这种取舍比平均翻译所有文本更现实。玩家可以接受少量非关键文本稍后优化,但很难接受教程和设置翻译错误。

本地化计划最后要回到版本表:哪些语言随首发提供,哪些语言在补丁中补齐,哪些语言只做商店页。把边界写清楚,比含糊承诺更能保护玩家预期。

继续阅读

探索更多技术文章

浏览归档,发现更多关于系统设计、工具链和工程实践的内容。

全部文章 返回首页