界面翻译顺序实测：147门语言里出错提示排到中后段

摘要：把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。出现这两条提示时，用户连登录都无法完成，而系统给出的解释是英文。

把这些句子连起来读，能直观看出：它们覆盖的都是用户已经决定做某件事、然后失败的时刻，即注册、评论、找回密码和登录。这几个动作正好构成访客转为用户的全部入口。

为什么偏偏是这一组掉队

有三个原因叠加。

第一，出错提示的句子长。后文会看到长度和翻译率确实负相关，只是相关性不强。

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

第三条最现实：做翻译的人多半从没在测试环境里触发过这些错误。没见过的界面，翻译时总是排在最后。

这三条原因里，第二条和第三条可以归为同一个因素：可见性。后文测长度和复数时会看到，可见性对顺序的解释力比其他任何变量都强。

这一层的损失不好量化，但方向很明确。此前一篇拆落地页上那几个最像装饰的信任元素的文章得出过一个结论：用户对一个站的信任，主要取决于出问题时他有没有被妥善对待，首页写得多漂亮影响有限。出错提示是英文，就属于没有被妥善对待。

为什么分页导航的两条无障碍标签排到倒数第110名？

整条队伍里最需要单独讨论的，是并列排在第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字符以上那一档还有回升。有效的做法是给每条文案加一句注释，说明它出现在哪个界面上。可见性对顺序的影响远大于长度和语法难度。

权威参考资料