翻译如何冲破应用商店的字符限制
你写了一个简洁的 28 字符应用名称、一句有力的 29 字符副标题，以及一个用满 100 字符的关键词字段。然后你把上架信息本地化，结果 App Store Connect 开始拒绝这些字段——德语副标题变成了 41 个字符，法语版是 36 个。英文版从来都不是问题所在。每种语言都有自己独立的一份字段文案，而每一份都必须自己达标同一条限制。
本文是关于这些限制具体是多少、翻译为何会超出限制，以及如何让上架信息在每种语言里都保持可读，而不是把单词从中间截断的参考指南。
两大应用商店的字符限制
下面每个数字都是按语言分别计算的。当你本地化成法语、德语、日语等语言时，每种语言都有自己独立的一份字段文案，提交时都会按同一条上限逐一检查。
有两点值得单独说明。App Store 的关键词字段是一个隐藏的、以逗号分隔的 100 字符位——不会出现在产品页面上，但你很大一部分收录效果都靠它，所以每个字符都很关键。而最紧张的字段——30 字符的名称和副标题——恰恰是翻译最容易冲击的地方。
为什么翻译后会超限
同样的意思在不同语言里占用的空间不一样。从英语出发翻译，大致的变化方向足够稳定，可以据此提前规划：
- 德语：通常 +30-40%。复合名词会把几个英文单词融合成一个长词，而且往往没有更短的同义词可用。这是最容易冲破 30 字符字段的语言。
- 法语、西班牙语、意大利语、葡萄牙语：大约 +15-25%。膨胀幅度稳定、适中。一个在英文里舒舒服服放在 24 字符的名称，翻过去往往逼近甚至超过 30 字符。
- 中文、日语、韩语：字符数通常会缩短约 50%。CJK 文字每个字符承载的信息量更多，所以字段上限很少是真正的约束——可读性和用词选择才是关键。
- 阿拉伯语、希伯来语及其他 RTL 文字：预计膨胀 +15-30%，外加书写方向的翻转。这些语言需要人工审校，绝不能只靠机器翻译——双向文字和非拉丁字符的关键词字段，正是自动化翻译最容易悄悄出错的地方。
把这些数字当作规划区间，而不是绝对保证。重点在于方向：如果某个字段在英文里已经接近上限，那么欧洲语言的翻译很可能会超出去，而 CJK 语言则会变短。在英文原文里预留几个字符的余量，膨胀空间就有地方去。
超出限制到底会发生什么
苹果和谷歌都在提交环节强制执行这些上限。实际操作中，你会遇到两种失败情况之一。要么商店表单直接拒绝多出来的字符——你根本无法打字超过限制，于是粘贴进去的翻译会在边界处被静默截断，截在单词中间。要么字段接受了这段文字，结果上架信息在审核时被拒。不管哪种情况，翻译后的名称或副标题最终都会被截断、因截断而拼写错误，或者在那个市场里干脆完全消失。
这些问题在英文版上架信息里完全看不出来。它们是按语言逐个浮现的，通常是在你以为上架信息已经完成之后才冒出来。
解决办法：创译，而不是截断
把德语副标题在第 30 个字符处硬生生切断，只会得到一个断掉的半个词，在母语者看来就像被机器搅乱了一样。正确的做法是按语言分别重写名称和副标题，让它们在限制内依然传达同样的意图。
- 先把原文缩短。一句 22 字符的英文副标题能扛住 35% 的膨胀；一句 29 字符的就扛不住。在英文里留出余量，是最省事的解决办法。
- 对紧张字段做创译。对于名称和副标题，在目标语言里挑一个更短的同义词，或者去掉一个填充词，而不是逐字翻译。目标是一句既能放得下、又读起来自然的短语，而不是字面上的对应。
- 对 RTL 和非拉丁字段做人工审校。阿拉伯语、希伯来语以及非拉丁的关键词列表，正是机器翻译最容易出错、而你如果不认识那种文字就发现不了的地方。
- 用目标语言的文字来计数，而不是用英文。商店衡量的是字符数，而字符数因语言而异——所以必须在翻译之后、按每个字段分别测量。
Mokbi 能帮上什么忙
Mokbi 会把你整套上架信息——名称、副标题、关键词、描述——翻译成 50 种语言，并且在翻译过程中实时显示每个字段按语言计算的字符数。超限情况会直接在编辑器里显现出来，在你把内容粘贴进 App Store Connect 或 Play Console 之前就能发现，这样你就能在还能缩短的时候抓到那个 41 字符的德语副标题，而不是等到被拒之后。
这只是第一遍处理，不是最终定稿。它能让每个字段都回到限制以内，并标记出膨胀的字段，这已经完成了大部分工作。但你最重要的市场仍然值得让真人再读一遍——请母语者确认创译后的名称读起来是否得体，以及从右到左的字段是否正确。工具能替你排除“哪些字段出了问题”的猜测；而人来确认最重要的那些字段是否读起来顺畅。