Steam 本地化商店页检查：2021 年 2 月个人游戏多语言上架流程

本地化先从承诺开始

个人开发者做 Steam 本地化时，常把重点放在翻译文本本身：短描述怎么翻、长描述怎么翻、公告怎么翻。但真正关键的是承诺。你在某个语言页面上说支持什么，玩家就会按这个承诺购买。页面翻译得漂亮，但游戏内文本不完整、截图语言不一致、客服无法处理对应语言反馈，都会造成落差。

2021 年 2 月如果准备上架或发售，尤其要检查本地化页面是否和真实构建一致。春节期间中文玩家活跃，海外玩家也可能通过英文页面进入。如果不同语言页面说法不一致，后续客服会很麻烦。

先列语言状态表

不要直接在后台勾语言。先做表：

这张表能避免“页面写得比游戏快”。如果英文剧情还在校对，不要在页面上给出完整英文体验的暗示。可以说明当前支持范围，但不要过度承诺。

短描述要重新写，不要直译

短描述最怕机器直译或逐字翻译。它要在目标语言里自然说明类型、动作和差异。中文里能接受的长句，英文可能显得臃肿；英文里的类型词，中文也未必直接对应。

写法步骤：

1. 先用目标语言写一句玩法说明。
2. 检查类型词是否是当地玩家常用说法。
3. 保留核心动词，不要只翻氛围。
4. 让目标语言玩家复述玩法。

如果复述不准，说明翻译没有完成任务。商店页本地化不是语言考试，而是销售沟通。

截图语言要匹配页面

很多页面翻译了文字，截图却仍然是另一种语言。玩家会怀疑本地化质量。至少第一批核心截图要匹配主要页面语言：首图、核心机制、UI、对话或教程。文字量大的游戏更要注意，因为截图就是语言质量证据。

截图检查：

如果暂时无法准备全套截图，至少前 3 张要匹配目标语言。

建术语表

术语表是低成本高收益工具。个人项目常见问题是一个系统在页面叫“模块”，游戏内叫“零件”，公告又叫“组件”。多语言后更乱。

术语表示例：

术语表要给翻译、截图、公告、客服都用。这样玩家从商店页到游戏内不会换一套词。

Demo 和正式版语言要说清

如果 Demo 语言状态和正式版不同，要写清楚。比如 Demo 只有中文，正式版有英文；或者 Demo 英文未校对，正式版会改善。不要让玩家通过 Demo 判断错正式版，也不要让页面承诺超出 Demo 实际。

FAQ 可以写：

当前 Demo 支持简体中文界面。正式版计划包含简体中文和英文界面，英文剧情文本仍在校对中。语言状态确认后会更新商店页。

这种写法比含糊说“支持多语言”更可信。

客服入口也要本地化

如果你开放英文页面，就要至少能处理英文基础反馈。模板可以不复杂，但要能问清日志、系统和问题位置。否则海外玩家反馈了问题，你看不懂或回复很慢，会影响评价。

英文客服模板可以提前准备，中文页面也要写清：

本地化不是只到购买前，也包括购买后的支持。

发售后修正文案

本地化页面上线后，要看玩家是否仍然问同样问题。如果英文玩家问“Is this turn-based?”，说明页面没讲清回合制或即时制；如果中文玩家问“有没有完整中文”，说明语言列表或截图不够明确；如果玩家反馈术语不一致，就更新术语表和页面。

本地化不要只看语言，也要看文化语境

有些中文表达直译后会显得夸张或含糊，例如“硬核烧脑”“治愈神作”“沉浸体验”。英文玩家可能更需要具体机制、时长和内容范围。反过来，英文页面常见的简短类型表达，翻成中文后也可能不够自然。每个语言页面都应该像本地玩家写出来的页面，而不是原文的影子。

可以找目标语言玩家做 10 分钟检查，让他只回答两个问题：他以为这是什么游戏，他觉得哪里像机器翻译。这个反馈通常很直接，也很有价值。

低预算本地化的优先顺序

如果预算有限，不要一开始追求很多语言。优先顺序可以是：先把主语言页面和游戏内文本完全对齐；再做好英文商店页和核心截图；然后根据 Demo 下载和愿望单来源判断下一种语言。文本量大的游戏尤其要谨慎，商店页翻译容易，游戏内剧情和 UI 校对才是真成本。

对个人开发者来说，一个高质量双语页面，通常比六个机器翻译页面更可靠。玩家宁愿看到语言支持有限，也不愿购买后发现翻译粗糙。

最终清单

本地化 QA 清单

上架前做一次小型本地化 QA：

很多本地化问题不是翻译错误，而是 UI 容器太窄、字体缺字、变量顺序不适合目标语言。只读文本表发现不了这些问题，必须在游戏里看。

本地化反馈要能定位

让玩家反馈翻译问题时，要求截图、语言、位置和建议文本。不要只收“翻译怪”。可以在公告里写：如果发现文本问题，请附上截图和所在菜单或任务名。这样你才能快速定位到文本表，而不是在工程里搜索半天。

Steam 本地化的目标不是覆盖最多语言，而是让已覆盖语言可信。个人开发者宁可少支持几种语言，也要把承诺、截图、游戏内体验和客服连起来。这样本地化才会提升转化，而不是制造新问题。

术语变更要统一更新

如果发售前修改了核心术语，例如把“队员”改成“工程师”，要同时更新商店页、截图、教程、公告和客服模板。术语不一致会让玩家以为是不同系统，也会让翻译反馈难以定位。个人项目可以用一个共享表格维护术语，每次改动都标记影响位置。

重要公告也要考虑语言承诺。如果英文页面已经公开，发售日期、已知问题和反馈入口至少要有英文摘要。多语言承诺一旦写在商店页，就应该延伸到关键沟通，而不是只停留在购买前页面。

本地化还要检查商店关键词和玩家搜索习惯。有些中文类型词翻成英文后并不是玩家常用词，反过来也一样。翻译完成后，用目标语言搜索同类游戏，看看它们如何描述机制和类型。商店页要使用玩家熟悉的词，再在正文里解释你的差异。

同类页面还可以帮助你检查语气。某些市场更习惯直接列内容和系统，某些市场更接受氛围表达。不要照搬，但要知道玩家熟悉的信息顺序。先讲清类型和动作，再补气质，通常比先讲世界观更稳。

本地化页面发布后，也要保存每次改动记录，方便回溯哪次文案调整减少了误解。

记录里写清修改语言、修改位置和触发原因，后续找译者协作时也更容易交接。

如果某个翻译问题被多名玩家指出，就把它升级成术语问题，而不是只修单句。术语统一后，后续公告、补丁和 DLC 页面都会更省力。