适合小型团队的 Steam 游戏本地化准备度检查表
作品经历与项目类型相匹配，并不代表本地化项目一定能够交付。文本接入、上下文、字体、构建、LQA、版本管理和决策流程，都会影响小型本地化团队能否把试译真正推进到上线。
在把 Steam 游戏列为可跟进商机，或提出付费试点之前，可以使用下面的检查表。
产品与范围
- 本次范围是商店页、UI、字幕、叙事、成就、营销内容还是完整音频？
- 预计字数和独立资源数量是多少？
- 游戏处于正式发布、抢先体验、试玩还是开发阶段？
- 后续更新、DLC 或平台版本会产生多少维护工作？
- 第一次合作能否切分为小而有用的独立交付？
Steam 允许分别管理商店页与游戏内本地化。Steamworks 本地化指南还区分界面、字幕和完整音频，因此必须先明确层级，再估算工作量。
文本管线
- 文本能否在不修改源代码的情况下导出和回写？
- 使用什么文件格式和编码？
- 字符串 ID 在不同构建之间是否稳定？
- 变量、复数规则、标记和换行是否有说明？
- 是否有足够上下文识别说话人、UI 位置和游戏状态？
- 译者能否看到截图或可运行的构建？
如果开发者无法提供可重复的文本管线，真实项目很可能包含以翻译为主的供应商没有报价、也没有人员承担的工程工作。
简体中文显示支持
- 所选字体是否覆盖所需简体中文字符？
- 每个目标构建是否都包含后备字体？
- UI 容器是否能适应不同长度文本？
- 是否测试换行、标点、数字和输入法行为？
- 图片、视频或纹理中的文字是否计入范围？
- 如游戏涉及搜索、排序和角色命名，引擎是否正确处理中文？
在表格里看起来正常的译文，进入游戏构建后仍可能完全不可用。
构建获取与 LQA
- 谁负责生成本地化构建？
- 本地化团队多久可以拿到一次当前构建？
- 是否提供测试账号、存档、调试菜单或章节选择？
- 截图、复现步骤、严重程度和责任人记录在哪里？
- 谁修复截断、漏字、变量错误和字体问题？
- 修复后是否留有回归测试时间？
当不同语言资源较大时，Steam 支持语言专属 Depot（内容仓库）；较小内容也可以共享 Depot。具体方案由开发者决定，但会直接影响本地化构建如何打包和测试。
角色与沟通
- 开发者侧是否有一位明确的本地化负责人？
- 供应商侧是否有一位项目负责人？
- 谁审批术语、角色语气和敏感内容？
- 遇到阻塞问题时，合理回复时间是多少？
- 供应商能否完成技术问题初步分类，还是每个问题都需要开发者判断？
- 项目是否需要小型团队当前并不具备的专职项目经理？
这一部分经常被低估。一个技术复杂且负责人长期不回应的项目，可能比文本量更大的成熟流程项目风险更高。
版本与术语维护
- 是否有术语表和风格指南？
- 如何识别新增、修改和删除的字符串？
- 旧译文是否能够安全复用？
- 更新公告和社区通知是否也需要本地化？
- 谁维护本体、DLC、商店页和客服内容之间的术语一致性？
- 英文源文本在审批后改变时如何处理？
Steam 除了商店页和游戏内容，也支持本地化社区公告。应把持续沟通视为维护工作流，而不是认为上线后项目就结束。
商务与法律准备
- 买方是否是可以明确识别的工作室、发行商或法律实体？
- 第一阶段是否足够明确，能够避免开放式承诺？
- 计价方式、币种、付款时间和修改次数是否清楚？
- 翻译记忆库、术语和交付文件归谁所有？
- 团队能否在作品集中展示该项目？
- 保密与数据处理要求是否与项目规模相称？
公开信号无法确认所有问题。商机简报应把它们列为下一步核验事项，而不是默认答案有利。
低风险的首次合作结构
对于以翻译为主的小型团队，较合理的第一次合作通常包含：
- 明确的内容切片；
- 带上下文的可导出文本包；
- 一位明确的开发者联系人；
- 一次测试构建和一轮结构化反馈；
- 清楚的技术问题责任归属；
- 扩展到完整游戏之前的决策节点。
具体形式可以是商店页本地化、UI 与教程试点、开场章节、术语审计或 LQA 诊断。目标不是只拿下一次试译，而是确认双方能否走完整个交付链路。
什么时候应降级或放弃商机
出现以下情况时，应继续观察，而不是包装成可立即行动的商机：
- 文本无法导出，而供应商没有工程接入能力；
- 没有人能够提供构建或修复缺陷；
- 项目需要超出供应商能力的持续工程或项目管理；
- 开发者无法定义第一阶段范围；
- 语言缺口存在多年，但没有当前开发或协作信号；
- 推荐供应商无法说明自己经过核验的经验如何对应具体工作。
项目是否具备交付条件，取决于游戏、开发者和本地化团队三方。完整评估三方，可以避免一次看似有希望的引荐最终无法转化为成功交付。