AI 翻译 + 人工润色，怎么做才没有「机翻味」
方法论约 4 分钟阅读
机翻最容易被玩家一眼看穿的地方，往往不是单词错了，而是语序、语气和信息取舍。中文习惯先铺陈再落点，英文习惯先给结论；中文的「你确定要放弃当前进度吗？」直译成英文会变成一句沉重的审判，而海外玩家熟悉的说法是一句轻得多的「Discard progress?」。
我们把一段游戏文本拆成三步处理：
- 先定场景与角色。同一句「获得道具」，写在系统飘字里是中性播报，写在 NPC 口中就该带人称和情绪。开翻之前先给每个说话者建立语气档案：性别、年龄感、礼貌层级、是否使用俚语。
- 再改语序与句长。英文对白要短，日文对白可以留敬语尾巴。中文一个逗号串三句的长句，在英文里通常要拆成两句，否则读起来像说明书。
- 最后做去 AI 痕迹的替换。把「very important」「utilize」「commence」这类机器偏爱的词换掉，把过度完整的语法改成口语省略。润色的目标不是更正确，而是更像人写的。
文化梗要单独处理。中文的谐音、成语、网络热词，直译过去通常只剩困惑。我们的做法是保留功能、替换载体：如果原句靠谐音制造笑点，就在目标语里找一个同类型的小笑话；如果实在没有对应物，宁可改写成一句朴素但通顺的台词，也不硬塞注释。
一个具体的判断标准：把译文交给一个没玩过这款游戏的母语玩家读，如果他需要停下来想一下才明白，这句就得重写。
英日西语文本膨胀率与界面溢出规避
UI 文本约 3 分钟阅读
UI 本地化最常见的翻车现场，不是译错，而是按钮放不下。中文是表意文字，两个汉字能表达的意思，英文往往需要两个单词。行业里常用的经验值是：以中文为基准，英文字符数约为 1.3 倍，日文约 1.1 倍，西班牙语约 1.4 倍，德语可能到 1.6 倍。
所以我们在处理 UI 文本时，会做三件事：
- 先看容器，再动笔。如果客户能提供截图或引擎文件，我们按实际控件宽度反推可用字符数，而不是译完再让程序去缩字号。
- 给出超长标注。确实压不下来的字段（例如成就名、道具描述），在交付表里单独标出「建议控件宽度 +30%」或「建议允许两行」，让开发提前评估，而不是上线后才发现。
- 优先换词，其次换结构。「立即购买」译成「Buy Now」比「Purchase Immediately」省一半字符；按钮类文案优先用动词短语，说明类文案才允许完整句。
还有一个容易被忽略的点：不要把换行写死在译文里。很多引擎会按控件宽度自动折行，如果译文中带手动换行符，换到另一种分辨率就会断得很难看。我们默认交付不带手动换行的单行文本，需要强制换行的位置用注释标注。
术语表怎么建：道具、技能、专有名词的一致性
术语管理约 3 分钟阅读
同一个道具在商店叫「疾风靴」、在背包叫「风之靴」、在任务提示里叫「迅捷之靴」，玩家不会觉得丰富，只会觉得这游戏没做完。术语混乱是独立游戏出海时最伤质感的问题之一，也是最容易提前解决的问题。
一份最小可用的术语表，至少包含四列：原文、译文、词性 / 类别、备注。备注里写清这个词出现的场景和禁用译法，比如「Boost：加速道具，统一译作 Speed Boost，不要用 Acceleration」。
建表顺序建议这样走：
- 先抽高频词。货币、核心资源、主要玩法动词，这些词出现次数最多，错了影响最大。
- 再定专有名词。角色名、地名、组织名。人名建议统一音译规则，不要一半音译一半意译。
- 最后处理近义词群。比如「强化 / 升级 / 进阶」三个中文词，在英文里可能都指向 Upgrade，这时候要在表里明确区分使用场景，而不是让译员每次自行判断。
术语表不是一次性文档。定稿时我们会把最终版本一并交付，之后客户自己新增文本，或者换人接手，都可以直接复用。这也是我们坚持每个项目都建表的原因：它让后续维护成本降下来。