界面未翻译的文案有固定顺序，出错提示排在队尾

摘要：把147个语言版本的界面译文逐条对齐，算出每一条文案被多少门语言翻过，得到一条极稳定的翻译顺序。星期几、上一页、作者这些一个词的标签排在最前面，平均被86.7%的语言翻过；编辑器里那些长句子排在最后，只有50.8%。问题出在中间：读者最需要看懂的出错提示，中位排到了6519条里的第2896位；分页导航那两条给读屏用的标签，排在倒数第110名。所以一个看着已经本地化好了的界面，会在用户填错一次表单的那一刻，整段变回英文。

上一篇量的是一门语言的界面翻了百分之多少。这一篇量的是另一件事：没翻的那部分，是随机的一半，还是有固定顺序的一半。

答案是后者，而且顺序稳定到有点吓人。

稳定到什么程度？把完成度落在两成到七成之间的语言版本单独拉出来，一共44个，它们分布在非洲、南亚、东南亚、高加索和东欧，社区之间没有任何协作关系。这44个版本在各类界面文案上的完成度排序，几乎完全一致。

保哥把147个语言版本的译文全部导出来，逐条对齐——每一条原文在每一门语言里有没有译文，是一个可以精确到条的判断。然后给每一条文案算一个数：它被多少门语言翻过。六千五百多条按这个数排一次序，就得到了这条队伍。

队首是ltr这三个字母，147门里有143门处理过它；队尾是一句关于区块元数据注册的报错，只有13门碰过。中间那六千多条，排得比想象中整齐得多。

界面翻译停在半路的时候，停的是哪一半？

先把这个问题问清楚，因为它跟另一个很像的问题容易混。

没翻和没送去翻是两件事

一句话没有变成本地语言，通常有两种原因。

一种是它压根没被从代码里挑出来，写死在了模板中间，翻译流程根本看不见它。这种情况下，报价单上不会有它，译者也不会见到它。

另一种是它被正常挑出来了、进了翻译池、躺在列表里，只是没有人认领。这一篇讲的全部是第二种。

两种的解法完全不同。第一种要改代码，第二种只要有人坐下来翻。而做站的人常常把两者混成一句“这里没翻译”，结果是找错了人：去催开发，其实该去找译者；或者反过来，翻了半天发现那句话根本不在池子里。

区分它们只要一个动作：拿那句英文原文去翻译列表里搜一下。搜得到，说明它在池子里，是这一篇的问题；搜不到，说明它从来没被送出来过，是另一件事。

为什么可以精确到条

标准的本地化文件里，每一条记录都长成同一个样子：一条原文、一条译文、若干条注释，其中一类注释会写明这句话出现在哪个源文件的第几行。译文那一格是空的，就是没翻。

这个结构让逐条对齐成为可能。同一个版本分支下，所有语言版本的记录条数和顺序完全一致——保哥这次导出的147个语言版本，每一份都是6519条，一条不多一条不少。

于是可以把它们叠成一张表：6519行，147列，每格是一个是或否。这一篇所有的数字都是从这张表上算出来的。

这张矩阵有九十多万个格子，但真正有用的操作只有两种：按行求和，得到每一条文案被多少门语言翻过；按列求和，得到每门语言翻了多少条。前者是这一篇，后者是上一篇。

为什么是147而不是全部208个？因为完成度为100%的语言版本对这个问题没有信息量——它们每一条都翻了，不参与区分谁排在前面。上一篇统计各语言完成度时用的是全部208个，这一篇取的是有区分度的那一批：完成度落在1%到99%之间的全部语言版本，再加18个满分的作对照。

这条顺序为什么值得单独量一遍

因为完成度这个百分比会让人产生一个错觉：以为60%的意思是每一块都翻了六成。

这个错觉在排期会上特别有杀伤力。有人报了一个数，六成，听的人自动脑补成还行、能用、剩下四成慢慢补。没有人会追问那六成落在哪儿。

实际上不是。60%的真实形态是有几块接近满格、有几块几乎为零。而你的用户会不会遇到英文，取决于他走到的是哪一块，跟那个60%没有直接关系。

这跟保哥在拆内容缺口时发现品类词那一格单独塌陷是同一类现象：总量指标把结构差异抹平了，而所有的坑都长在结构里。

处理办法也是同一套：别信总量，把它拆成几个业务上有意义的分组，各报各的。拆分维度选得好，一张表就能替代十次讨论。

这一篇能回答和不能回答的

能回答的是：在人手不够的现实里，各类界面文案实际被处理的先后顺序是什么，以及这个顺序跟读者的实际需要错开了多少。

不能回答的是译文质量。有译文和译得对是两件事，这张表只看有没有。

也不能回答某一个具体站点的情况，因为真实站点还叠着主题和插件。不过后面有一节会给出把这套方法搬到自己站上的做法。

还有一件事这篇不碰：译文什么时候被提交的。理论上可以从提交时间反推出各语言的翻译节奏，但那个字段只精确到整份文件，逐条的时间拿不到。

六千五百条文案分别长在什么地方？

要看顺序，先得给这六千多条分类。分类依据是文件里那条来源注释——每条文案都记录了它出现在哪个源文件里。

按位置拆开之后的样子

一条文案可能同时出现在几个文件里，所以各组之和会大于总数，这里不做互斥切分，只看每一组各自的情况。

还有一批条目落在接口层，也就是程序之间说话用的报错和字段说明，共九百多条。它们既不是读者可见，也不完全属于后台，单独成一类，特点是翻译率一直排在最后几名。

四成的文案只有你自己看得见

最刺眼的一行是第一行。2648条，占全部的四成，全部属于写文章用的那个编辑器界面——按钮、面板标题、提示气泡、快捷键说明。这些字，你的读者一个都看不到。

这不是设计失误，编辑器本来就是复杂的东西。但它对分配翻译人力的意义很大：如果你按条数比例去分配预算，四成的钱会花在只有内部几个人会看的界面上。

而读者真正会遇到的那几组加起来只有四百多条：导航分页121、出错与空状态98、时间词69、评论区69、订阅源9。

四百多条对六千五百条，比例是6%左右。也就是说，把读者能看到的每一个系统文案都变成本地语言，需要动的只是这套系统的十六分之一。

这个比例在做取舍的时候很好用。它把一个听起来要整体投入的事情，变成了一个可以先切一小块出来做的事情。

四百条和两千六百条

这两个数放在一起，是这一篇最有用的一组对比。

四百条是什么概念？一个人一天能翻完。两千六百条是什么概念？一个人要做两三周。

如果你的目标只是让读者看到的每一个字都是本地语言，成本是一天；如果目标是整个后台都不出现英文，成本是三周。这两个目标经常被写在同一行需求里，而它们的成本差了二十倍。

更实际的是，这两件事的收益完全不在一个量级。前者影响的是每一个访客的第一印象和信任判断，后者影响的是内部三五个人的操作效率。

时间词那69条为什么单独拎出来

因为它们是唯一一组出现在每一个页面上的文案。

月份名十二个、月份缩写十二个、星期名七个、星期缩写七个、星期的单字母缩写七个，再加上上午下午、时间格式、数字的千分位和小数点符号。系统把这些东西集中放在一个地方，因为它们不是普通文案，是这门语言的基本写法。

任何一篇文章的日期署名都会用到它们。分类页、归档页、评论时间戳、结构化数据里的日期，全部经过这69条。

结构化数据那一条尤其值得注意。页面里给机器读的那份日期字段用的是标准格式，不受这69条影响；但展示给人看的那个日期用的就是它们。同一个页面上，机器读到的日期正常，人看到的日期是英文，这种情况完全可能发生。

后面会看到，这69条同时也是整条队伍里排得最靠前的一组，而且它可以当一个非常省事的探针用。

人手不够的时候，实际先翻的是哪一批？

把147个语言版本里完成度落在20%到70%之间的挑出来，共44个。这批语言的共同处境是：翻了一些，远没翻完，每一分人力都花在了他们认为最该花的地方。

44门语言给出的排序

这44个语言版本的全局完成度均值是38.5%。如果翻译是随机进行的，每一组的完成度都应该在38.5%上下。实测结果差得很远。

为什么取20%到70%这一段？低于两成的语言样本里几乎每一组都接近零，看不出取舍；高于七成的又快翻完了，同样看不出取舍。中间这一段才是真正在做选择的那批。

这张表是整篇的核心。它说明翻译顺序不是随机的，而且不同人群、不同语言、不同年份做出的选择高度一致。

把它换个说法：如果你只知道一门语言的整体完成度是四成，你其实已经可以相当准确地推断出它的每一块分别翻了多少。四成的语言，时间词几乎满格，导航分页八成多，出错提示不到一半，编辑器两成。

为什么所有人都做了同一个选择

没有人给这44个语言社区发过统一的排序表。他们分布在几十个国家，用不同的语言，多数彼此不认识。

他们收敛到同一个顺序，是因为翻译平台默认按出现频率和使用位置排列待翻列表，而新手天然会从列表最上面开始做。加上一条更朴素的心理——人会先翻自己看得懂在哪儿用的那些词。星期一就是星期一，谁都知道该译成什么；一句关于区块元数据命名空间的报错，多数译者根本不知道它长在哪个屏幕上。

这里的人手结构跟内容那一层很像。保哥在用编辑人数替代内容量估竞争强度时量到过，很多小语种的整片内容背后只有二三十个人。界面翻译的人数只会更少，通常是个位数。

官方的术语表机制其实就是为了解决后半个问题，把高频词的标准译法先固定下来，让新人不用做判断。这个机制越有效，队伍前半段就越整齐。

这也是为什么队伍最前面那几十条几乎不受语言影响。星期一、上一页、作者、分类，这几个词在任何一门语言里都有现成的说法，不需要讨论，不需要查证，翻起来没有心理成本。

负号那一行的意思

编辑器那一组是唯一一个负号，−16.3点。

它占了全部条数的四成，却被系统性地跳过。这解释了一个常见现象：一门语言的完成度停在40%上下不动很久。原因不是社区没在做，是剩下的全是编辑器那两千多条，而那两千多条对社区来说优先级最低。

编辑器这一批还有个额外的门槛：它的文案高度依赖上下文。同一个词在不同面板里意思不一样，不打开那个面板根本不知道该怎么译。对一个业余时间做翻译的人来说，这个成本高得不成比例。

如果你看到一门语言长期卡在35%到45%之间，大概率它的读者可见部分早就翻完了，卡住的是编辑器。这种语言实际可用度比数字看起来高得多。

这条顺序对分工的直接用处

如果你要自己补译，这张表就是现成的优先级。

先补时间词那69条，再补导航与分页那121条，然后是评论区和出错提示。编辑器那两千多条放到最后，甚至可以永远不做——如果你的编辑团队本来就用英文后台。

这里有个容易被忽略的顺序问题：出错提示虽然排在第四位，但它的实际优先级要看你的站有没有表单。有注册、有评论、有结账的站，出错提示应该提到第二位；纯阅读的站可以往后放。

这个顺序跟按文件顺序补、或者按翻译平台默认列表顺序补，效果差别非常大。按这张表补，前400条就能覆盖读者会遇到的绝大部分界面；按默认顺序补，前400条大概有160条落在编辑器里。

读者能看见的那些字，真的排在前面吗？

上面那张表容易给人一个安心的结论：读者可见的排前面，内部使用的排后面，正好合理。

把读者可见那几组拆细之后，这个结论就不成立了。

把6519条排成一队之后的位次

换一个更直接的算法：把6519条按被多少门语言翻过降序排列，第1名是最多人翻的，第6519名是最少人翻的。然后看每一组的中位位次落在哪儿。

时间词的中位位次是241，也就是说这一组的一半排在整个队伍的前4%里。到这里为止都符合预期。

订阅源那9条排第二，中位344。这一组小得可以忽略，但它的位置说明了一件事：早期做本地化的人是从整站的输出口开始梳理的，订阅源属于那一批。

导航与分页中位597，也在前一成里。登录与注册页902，评论区1118，都还算靠前。

队首那二十条到底是什么词

把队伍最前面的一段打印出来，会看到一份很朴素的名单。

第一名是ltr，三个字母，147门里有143门处理过。它不是一句给人看的话，是让系统知道这门语言从左往右还是从右往左排的方向标记。译者第一眼就会遇到它，而且必须处理。

接下来是密码、编辑、标题、搜索、分类、作者、左、右、退出登录、访问站点，全部在136到139之间。然后是七个星期名和十二个月份名，密集地占据了第15名到第40名。

还有一条容易被忽略的排在第4名：控制小数点符号的那一条，138门语言处理过。它和排在118名的千分位符号是一对，两条都不是文案，是这门语言写数字的规矩。

这份名单的性质很统一：要么是一个词就能译完的高频标签，要么是必须处理否则页面会明显不对的格式项。翻译者的第一反应是对的——先把不做不行的做掉。

格式项这一类还藏着一个更细的坑。土耳其语那个不带点的小写字母提醒过一件事：有些语言的基本书写规则跟英语默认值不一样，而系统里管这些规则的位置往往就藏在这类看起来像乱码的条目里。填错和不填的后果同样严重。

出错提示掉到了第2896位

出错与空状态这一组，中位位次2896，落在整条队伍的中后段，比后台管理页面还靠后一倍。

这一组是什么？是表单填错时那句红字，是评论没通过审核时的提示，是密码重置链接过期时的说明，是站点崩了那句请联系管理员。

换句话说，是这个系统里唯一一批只在用户遇到麻烦时才出现的文字。

把它排到后半段，意味着一个完成度60%的语言版本，用户在正常浏览时看到的全是本地语言，一旦操作出错，弹出来的很可能是英文。而出错那一刻，正好是他最需要看懂的一刻。

具体是哪些句子

把读者可见几组里翻译率最低的挑出来，名单相当具体。

评论提交失败那几句：请填写评论内容、评论太长了、你填的网址太长了、你填的名字太长了，这几条的位次都在4100到4600之间。密码重置链接已过期、注册功能当前未开放、两次输入的密码不一致，位次在4800到5100。

还有一句排到了5639名：抱歉，不允许回复尚未通过审核的评论。这句话出现的场景很具体——用户刚发过一条评论，还在审核队列里，他又想回复自己那条。这时候他会收到一句英文。

浏览器不支持Cookie或Cookie被拦截那两条，位次4644和4719。这两条出现的时候，用户连登录都做不到，而给他的解释是英文的。

把这些句子连起来读一遍会有个很直观的感受：它们覆盖的全部是用户已经决定要做点什么、然后失败了的那些时刻。注册、评论、找回密码、登录。这几个动作恰好是一个访客从路人变成用户的全部入口。

为什么偏偏是这一组掉队

三个原因叠在一起。

第一，出错提示句子长。后面会看到长度跟翻译率确实负相关，虽然相关得不算强。

第二，译者看不到它们。翻界面的人多半是照着列表翻，不是照着屏幕翻，而出错提示很难在正常操作里触发一遍。带上下文注释是官方推荐的补救办法，但注释要开发主动写，写的人不多。

第三，也是最现实的一条：做翻译的人多半在测试环境里从来没让它出过错。没见过的屏幕，翻起来永远排在最后。

这三条原因里，第二条和第三条其实是同一条：可见性。后面量长度和复数的时候会看到，可见性对顺序的解释力比其他任何变量都强。

这一层的代价不好算，但方向很清楚。保哥在拆落地页上那几个最像装饰的信任元素时得出过一个结论：用户对一个站的信任判断，靠的不是首页写得多漂亮，是出问题那一刻他有没有被好好对待。出错提示是英文，就是没有被好好对待。

排在倒数一百一十名的那两条是什么？

整条队伍里最值得单独讲的，是并列排在第6409和6410名的两条。

两个词组，各只有46门语言翻过

它们分别是Posts pagination和Comments pagination，直译过来是文章分页和评论分页。

6519条里排第6409和6410名，意思是倒数第111和第110名。147门语言里只有46门翻过它们，其中还包括那18个满分的对照组。

而这两条不是后台的东西。它们是前台分页导航那个区块的无障碍标签，写在页面HTML里，读屏软件会念它，搜索引擎的抓取程序也会读到它。

也就是说，一个使用小语种、完成度中等的站点，它的分页导航在辅助技术那里念出来的是两个英文词，而周围所有内容都是本地语言。

为什么这种东西最容易被漏掉

因为它在屏幕上是看不见的。

分页导航渲染出来的是一排数字和箭头，那个标签只存在于标签属性里，用来告诉辅助技术这一坨东西是干什么用的。无障碍规范里对这类名称的要求写得很明确：它必须是用户能理解的语言，因为它会被直接念出来。

译者对着列表翻的时候，看到Posts pagination这两个词，第一反应是不知道它出现在哪儿。翻了也验证不了，不翻也看不出来。于是它一路排到了队尾——不是因为它不重要，是因为它在整个翻译流程里没有任何一环能被人看见。

看不见的字里还有哪些

同一类的还有几条值得留意。

排在4849名的是一个星号。它是表单里标记必填项的那个符号，在有些语言的排版习惯里要换成别的记号或者加说明。

这个星号还有另一层麻烦：它单独出现在翻译列表里就是一个星号，没有任何上下文。译者看到它多半会直接跳过，因为看不出它是干什么的。

排在5815和5816名的是两条帮助文档的网址。这类条目存在的原因是各语言社区可以把它换成自己语言的文档地址，翻了就是本地文档，不翻用户点过去看到的是英文页面。

还有一条排在4099名的注释性文案，提醒开发者使用更具包容性的措辞。它出现在开发环境的日志里，性质跟前面几条又不同。

这一类的自查怎么做

看不见的字没法靠肉眼走查发现，只能靠两个动作。

一个是直接看页面源码，搜一遍标签属性里的文字，看有没有英文。分页、搜索框、跳过导航的链接、图片的替代文字，这四处最常出问题。

另一个是用读屏软件把关键页面听一遍。这个办法慢，但它能一次性发现所有听得见看不见的问题。做多语言站的团队里，几乎没有人在非英语版本上跑过这一步。

退一步的做法是只听三个位置：分页、搜索框、主导航。这三处的标签属性覆盖了绝大部分辅助技术会念到的系统文案，五分钟能听完。

保哥在写非拉丁文字的图片替代文字时提过一个相似的判断：所有不在正文可视区域里的文字，都天然处于验收流程的盲区，需要单独列一张清单去查。

同一类盲区还有另一种形态。为了排版塞进标题里的那个看不见的字符属于反过来的情况：那里是多了看不见的东西，这里是少了看不见的东西，两者都要靠专门的动作才能发现。

六十九个词能不能当探针用？

逐条导出147个语言版本的译文，跑一遍要十几分钟。有没有更快的办法，只看一小撮字符串就估出这门语言的界面能不能见人？

时间词那69条是最合适的候选，因为它们在任何一个页面上都能看到。

而且它们不需要任何工具就能查。打开一篇文章，看日期，三十秒。这是所有可用探针里门槛最低的一个。

相关系数0.665，但这个数字会骗人

先算相关：时间词那一组的完成度跟全局完成度，相关系数0.665。

中等强度，看起来可以当粗略估计用。但把两端分开看，结论完全不同。

往下看极准，往上看没用

时间词完成度低于50%的语言版本有21个。这21个的全局完成度中位数是3.8%，最高的一个也只有10.6%。换句话说，连星期几都没翻全的语言，界面必然是空的，没有例外。

时间词完成度在95%以上的有114个。这114个的全局完成度中位数是84.2%，听起来不错，可最低的那一个只有3.0%。

那个3.0%的样本是迪维希语。它的时间词翻了97.1%，全局只有3.0%。也就是说，有人认真地把月份和星期全部译完，然后再也没有回来。

这个形态跟保哥在量条目底下有没有出处时抓到的那批空壳一模一样：格式框架搭好了，里面的活没做。区别只是那一次的空壳是参考资料栏，这一次的空壳是六千多条待翻列表。

所以这个探针是单向的：它能确诊坏的，不能确诊好的。测出来低，可以直接排除；测出来高，什么也没证明。

时间词满分而全局不到四成的有25个

这个反例组不小，25个语言版本，包括宿务语、缅甸语、僧伽罗语、亚美尼亚语、冰岛语、阿塞拜疆语、爱尔兰语、鞑靼语、泰卢固语。

它们的共同形态是：读者可见的那几百条早就翻完了，剩下的编辑器和接口层一片空白。前面那条负号规律在这里得到了印证。

这一组里有几个熟面孔。宿务语在上一篇按内容量对照界面完成度时是最刺眼的那个样本，维基条目数全球第二、界面只有两成；在这一篇里它的时间词是满分。两个数放在一起，说明那门语言不是没有人，是人很少而且只做了最要紧的那一小块。

做非洲市场的人还要多看一眼另一组。选非洲语种时先看有没有人写价格和退货政策这条判据，在界面这一层同样成立：斯瓦希里语的核心接近满格，商店插件是零，也就是说读者路径上最要紧的那几屏根本没有译文。

对做内容站的人来说，这25个版本其实是可以用的。对做电商的人来说，就要接着往下查——因为商店流程里那几千条不在这69条的覆盖范围内。

这也是这个探针最容易被误用的地方。它量的是系统核心那一层，不覆盖任何插件。用它给电商站做判断，会系统性地偏乐观。

这69条里最难的是哪几个

有意思的是，这一组内部也有排序。

月份缩写是最容易漏的一批：五月、六月、七月、八月这四个月的缩写，在147门语言里只有120门翻了。原因很好猜——英语里这四个月的缩写跟全称长得一样或者只差一个点，译者容易以为不用动。

这个坑跟保哥在拆缩写在各语言里的本地形式时讲的是同一件事：缩写不是把全称砍短，是一门语言自己的一套约定。英语里恰好相同的那几个，在别的语言里往往完全不同。

还有两条特殊的：一条控制千分位符号，只有118门翻了；一条是时间格式的写法模板。它们看着像乱码，实际上是让译者填入本地写法的占位。不翻的后果是价格显示成英语习惯的写法，这一条会直接落在商品页上。

所以探针要用得准，别只数这69条翻了多少，要专门看月份缩写和那两条格式项。

短句为什么比长句先翻？

把6519条按原文长度分档，再看各档的平均翻译率，得到一条很平缓但方向一致的曲线。

长度跟翻译率的关系没有想象中强

从最短到最长，只差14个百分点，而且200字符以上那一档还回升了。

如果长度是主导因素，这条曲线应该陡得多，最短那一档和最长那一档之间至少差三四十个点。实际上它平得像一条直线。

这个结果本身就是个提醒。长度看起来是最直观的解释，实测它只能解释一小部分——真正决定顺序的不是句子多长，是译者知不知道这句话长在哪个屏幕上。

最长那一档为什么回升

200字符以上只有43条，多数是登录页和注册页上的说明段落，比如收不到邮件时可以怎么排查。

这些段落虽然长，但它们出现在一个译者一定见过的屏幕上，而且位置显眼。见过就会翻，长度只是让它慢一点，不会让它被跳过。

反过来也成立：队尾那些句子里有不少其实很短，比如那两条分页标签各只有两个词。短得不能再短，照样排在倒数一百多名。

这条小小的回升，反过来证明了可见性比长度重要。

复数形式那87条，跟预期完全相反

开工前保哥以为复数条目会明显吃亏。理由很实在：复数规则在不同语言里差别极大，阿拉伯语要填六个格子，斯拉夫语系要填三个，而英语只有两个。格子多、判断难，应该更容易被跳过。

实测复数条目的平均翻译率是59.2%，单数是58.3%。不但没吃亏，还高了0.9个百分点。

回头想原因，应该是复数条目本身就是高频词——多少条评论、多少个分类、多少项已选中，这类计数文案出现在最常用的位置上。可见性再一次盖过了难度。

顺带说一句，复数格子填得对不对是另一回事，这张表只看填没填。一门语言把六个格子全填成同一句话，在这里算翻了。质量那一层要另外查。

这条结论对写代码的人有用

把三条合起来：可见性决定顺序，长度影响很小，语法复杂度基本不影响。

所以想让自己的界面在小语种上更快被翻完，最有效的动作不是把句子写短，是把上下文说清楚。给每一条加一句注释写明它出现在哪个屏幕上，比什么都管用。

这个动作的成本几乎为零，收益是让那批排在四千名之后的句子提前几百个位次。

对自己站的主题和插件同样适用。你写的每一条前台文案，加一句注释说明它出现在哪个模板的哪个位置，翻译的人省下的是来回猜的时间。

这套顺序在主题和插件上一样吗？

核心的翻译队伍有社区在维护，术语表也是现成的。主题和插件那边是另一套生态。

三层的差距比核心内部的差距还大

上一篇量过一组数：完成度达到95%以上的语言版本，核心有63个，官方主题只有29个，商店插件30个，SEO插件28个。

而完全没有译文的语言版本，核心是35个，官方主题是134个。

134对35，差了将近四倍。这个差距不是因为主题的字符串更难翻——它只有357条，是核心的十八分之一。差距全部来自有没有人接手。

同一门语言，核心翻满、主题一条没有，这不是个别现象，是多数情况。

主题那357条几乎全是读者可见的

核心的六千五百条里四成是编辑器，读者可见的只有四百多条。主题不一样——官方主题那357条，绝大部分是模板里直接输出到页面上的文字：继续阅读、发表于、由某某撰写、上一篇、下一篇、没有找到内容。

换句话说，主题这一层的每一条都是读者可见的，而它的语言覆盖面比核心差得多。核心那四百条读者可见文案的高完成度，在主题这一层完全没有对应物。

这个落差解释了一个常见的困惑：为什么后台看着挺本地化，前台一翻页就冒出英文。

而且这个落差在自查时很难被发现，因为团队多半是从后台开始看的。后台是本地语言，就默认前台也是。

插件那一层的顺序还没有形成

插件的情况更零散。一个插件的译文有没有人做，取决于它在那个语言市场有没有被广泛使用，而不是取决于它有多重要。

这意味着核心那条稳定的顺序在插件上并不成立。你没法假设商店插件也会先翻结账页再翻后台设置——很可能它翻的是最先出现在设置页面第一屏的那几条。

所以插件层只能一个一个查，没有捷径。这也是保哥在拆一套模板生成十种语言时反复强调的一点：越是靠近页面输出的那一层，越不能靠推断，只能实地看一遍渲染结果。

要查也不难。每个公开插件的翻译状态都挂在同一个平台上，按项目名找过去就能看到逐语言的完成度，跟核心用的是同一套数据结构。

半小时能查出自己站漏在哪儿吗？

能。这一节是可执行的部分。

第一步：查那69条

随便打开一篇你那门语言版本的文章，看日期显示。月份名是本地语言还是英文，星期名是不是本地语言，缩写形式对不对。

这一步三十秒。如果这里就是英文，后面的都不用查了，这门语言的界面还没到能上线的程度。

顺手再看一眼数字的写法。价格里的千分位和小数点符号也在这69条里，写成英语习惯就说明这一组没翻全。

第二步：走一遍读者路径

按顺序点过去：首页、分类页、翻到第二页、打开一篇文章、看评论区、提交一条评论、故意留空必填项让它报错。

最后那个动作最重要，因为它是唯一能把出错提示逼出来的办法。前面五步都正常、第六步冒英文，是最典型的形态。

做电商的话再加三步：加购、进结账、故意填一个不存在的邮编。

邮编那一步是故意选的。地址校验的报错通常来自商店插件而不是核心，能一次测到另一层。

第三步：看那些看不见的字

在分页导航那里查看页面源码，找标签属性里的文字。再搜一遍图片的替代文字和跳过导航的链接。

这三处是标签属性里最常出现英文残留的地方，而它们都会进HTML，都会被抓取程序读到。

顺便也把页面上的字体渲染看一眼。小语种站的字体文件经常缺字形，缺了之后显示成方框，肉眼上跟没翻译是两回事，排查方向也完全不同。

第四步：把结果写成一张表

查完之后，按前面那张位次表的分组，标出每一组是全本地、部分英文、还是全英文。

然后决定补哪些。补的顺序照那张表来：时间词、导航分页、评论区、出错提示、登录注册，编辑器放最后或者不做。

整个流程熟练之后二十分钟能跑完一门语言。比这个流程更省事的做法是没有的，因为任何一个百分比数字都回答不了你的用户会在哪一步撞上英文。

这套流程还有个副产品：它会顺带把主题和插件那两层一起测掉。你走的是真实页面，页面上的每一个字来自哪一层并不重要，重要的是它是不是本地语言。

如果要把结果留给后面的人用，记得把每一条英文残留的原文抄下来。有了原文才能去翻译列表里搜，才能分清是没人翻还是没送去翻。

我一开始猜错了哪几条？

这一批预期写了七条，跑完对了两条。

以为读者可见的会整块排在前面

错得最有价值的一条。预期是读者可见的几组全部集中在队伍前段，内部使用的全部在后段，界限清楚。

实测是读者可见这一类自己就裂开了：时间词中位241，导航分页597，而出错与空状态掉到2896。三组都是读者可见的，位次差了十倍以上。

这条打脸直接改写了整篇的结构。如果读者可见的真的整块排在前面，这篇文章只有一句话可写；正因为它裂开了，才有那份具体的补译顺序表。

以为长度是主要原因

第二条错的是归因。预期长度跟翻译率强负相关，实测从最短到最长只差14个百分点，最长那一档还回升了。

把长度这条解释掉之后，剩下的解释只有可见性。这个替换让整篇的落地建议从把句子写短变成把上下文写清楚，后者才是真正有效的动作。

以为复数条目会明显吃亏

第三条错在把语法难度当成了障碍。实测复数条目的翻译率反而略高。

这条错误提醒了一件事：在志愿劳动驱动的场景里，难度几乎从来不是瓶颈，注意力才是。愿意做这件事的人本来就愿意查规则，他们缺的是知道该先做哪个。

这条推论对自己团队也成立。补译排不上优先级，多半不是因为难，是因为没有人知道那四百条具体是哪四百条。把清单列出来，事情就变得很小。

猜对的那两条和一条没猜到的

猜对的是编辑器那一组会垫底，以及时间词会排在最前面。

完全没预料到的是那两条分页的无障碍标签能掉到倒数一百一十名。找到它们靠的不是假设，是把读者可见那几组按翻译率从低到高排了一遍，然后一条一条往下看。这个动作花了不到十分钟，产出是整篇里最具体的一个发现。

这条经验值得单独记：有了一张对齐好的矩阵之后，最划算的动作不是再算一个统计量，是把某一列排序之后把两端打印出来看。

哪些相邻的问题不归这一层管？

没被抽出来的那批字

这一篇从头到尾讲的都是已经进了翻译池、只是没人认领的字。还有一类字压根没进池子，被写死在模板里。

那一类的表现看起来一模一样——页面上一段英文——但排查方向完全相反：这一篇讲的要去找译者，那一类要去找开发。区分办法很简单，去翻译列表里搜一下那句话，搜得到就是这一篇的问题，搜不到就是另一件事。

经验上，前台模板里的硬编码比后台多，因为前台改动频繁、临时加一行字的诱惑更大。查的时候从主题文件开始翻，比从核心开始翻效率高很多。

译文的质量不在这里

有译文和译得对是两件事。这张矩阵只看那一格是不是空的，不看填的对不对。

质量这一层要靠母语审校，判据和流程跟这里完全不同，保哥在母语审校的验收清单里写过一套可执行的做法。两件事要分开做，因为它们的失败方式不一样：这一层的失败是空白，那一层的失败是看起来没问题。

内容的语言不归这里

你的文章正文、商品描述、分类名称，都不在这份数据里。它们是你自己写的，跟界面译文不共用同一套供给。

这两层的关系倒是有一条值得注意：页面被机器判成哪门语言时，界面文案是会参与判断的。一个正文是本地语言、界面全英文的页面，在字数少的页面类型上有被判错的风险。

标签页、分页第二页往后、只有几张图的相册页，都属于这种字数少的类型。这几类页面上界面文案占的比重最高，也最容易被判错。

交给谁

补译这件事在多数团队里落不到人头上，因为它既不是内容任务也不是开发任务。

比较可行的做法是把前面那张四百条的清单交给做那个市场的运营，一次性做完；编辑器那两千多条如果确实需要，再单独立项。把两件事写成一个需求，是这一层最常见的排期错误——四百条一天能做完，两千六百条要三周，混在一起就会一起被推迟。

还有一个更省事的路子：把补好的译文提交回上游社区。这样下一个版本发布时它会跟着一起走，不用每次升级重来一遍，也顺带把这门语言的完成度往上抬了一点。

常见问题解答

界面翻译有没有一个固定顺序？

有，而且非常稳定。147个语言版本里完成度在20%到70%之间的那44个，时间词平均翻了97.8%，导航与分页86.3%，评论区70.1%，出错提示只有46.2%，区块编辑器22.2%。这些社区彼此不认识，却收敛到了同一个顺序。

为什么正常浏览都是本地语言，一出错就变英文？

因为出错提示在翻译队伍里的中位位次是2896，落在6519条的中后段，比后台管理页面还靠后。译者按列表翻，很难在正常操作里触发一遍出错场景，没见过的屏幕就一直排在后面。

用什么办法能快速判断一门语言的界面能不能用？

先看日期显示里的月份名和星期名。这69条时间词是整条队伍排最前面的一组，测出来不合格可以直接排除。但它是单向探针，测出来合格什么也不能证明，实测有25个语言版本时间词满分而全局完成度不到40%。

后台看着已经本地化了，前台为什么还有英文？

因为主题是独立的翻译项目。官方主题那357条几乎全部是读者可见的模板文字，而完全没有译文的语言版本，核心是35个，官方主题是134个。核心的高完成度在主题层没有对应物。

自己补译的话，先补哪些？

按位次表来：时间词69条、导航与分页121条、评论区69条、出错与空状态98条、登录与注册134条，加起来四百多条，一个人一天能做完，覆盖读者会遇到的绝大部分界面。区块编辑器那2648条放最后，如果编辑团队本来就用英文后台，可以不做。

句子写短一点会不会更容易被翻？

作用很小。从最短到最长那一档，平均翻译率只差14个百分点，200字符以上那一档还回升了。真正有效的动作是给每一条加一句注释说明它出现在哪个屏幕上，可见性对顺序的影响远大于长度和语法难度。

权威参考资料