字符串目录里缺一条 locale 值,构建照样全绿——这类缺口能一路活到提交前。
场景很普通:一个 key 在 zh-Hans 下没有值。构建不报错,因为开发语言直接拿 key 本身当文案渲染,英文界面"看起来正常",中文界面整句回退成英文。真正扎手的是带格式符的字符串:token 不匹配时 String(format:) 直接崩,而崩在哪个人手里,取决于审核员打开的是哪种语言——你自己的测试永远复现不出来。
为什么一直没人看见:那个 key 本身是一整句英文 UI 文案,连引号一起被原样当成了标识符。用英文开发的人看这行"已经写好了"——可值等于 key 的条目,等于什么都没写,只是起了个名。绿构建说明零件没问题,不说明产品在每一种语言下都没问题;发现它的是一道机械的目录对账,不是任何一次人工回归,因为人眼只看自己正在用的那种语言。
修复的顺序是承重的,倒过来就返工: 1. 先修 key 的形状。整句文案做 key,镜像永远补不完——下次改措辞、加个数量词,空间就再分叉一次。换成静态短 key + 格式参数,把变化的部分从 key 里移出去。 2. 再逐条对账:机械地 diff 每个镜像 locale 对源语言,数 diff 找到的条数,不数自己记得加过什么;值仍然等于 key 的条目,一律按"未完成"处理。 3. 把对账固定成提交前的检查。靠人眼维护的多语言目录,缺口是必然,不是意外。
一分钟自检:几行脚本解析 .xcstrings(或逐 locale 加载编译后的 .strings),列出三类条目——在任一 locale 缺值或空值的 key、值等于 key 本身的 key、key 里带转义引号或插值的条目。每一条都指向同一个病根:文案冒充标识符,或者镜像根本没铺平。