语言包完成度实测：208个版本里曾经翻满的四成已掉队

摘要：把WordPress 6.7的6519条界面文案，在208个语言版本上逐条对了一遍。第一，完成度不是一个勾，是一条会往回掉的曲线——历史上曾经翻满过的106门语言，到这一版还满着的只剩63门。第二，界面翻得好不好跟这门语言有多少网上内容确实相关，但真正有用的是对不上的那部分：宿务语的维基条目数排全球第二，界面只翻了两成；老挝语维基只有5597条，界面满分。第三，核心翻满不等于你的站能用，斯瓦希里语核心99%、商店插件0%、主题0%、SEO插件0%。

决定要不要开一门语言的那天，多半是这么过的：打开后台的语言下拉，找到那门语言，看到它在列表里，松一口气，把它写进排期表。

这个动作里藏着一个默认假设——列表里有，就等于能用。

上个月WordPress 6.7发布，保哥顺手把它的语言包数据整个拉了一遍，想看看这个假设离事实有多远。结果是：那个下拉列表有208项，而这208项背后的实际状态，从一条译文都没有到六千五百条全部译完，中间铺开了一条完整的连续带。列表这个界面，把一条连续带压成了一个二值的勾。

更麻烦的是，这条带子还会往回走。一门语言今年翻满了，明年可能就不满了，而且不需要任何人去删掉译文——只要软件自己长大就够。

这件事对做出海站的人有直接影响，因为语言这一栏通常是在立项会上被一句话带过的。有没有？有。那就排上。真正的成本要等上线前两周，测试同学截图问一句这些英文是什么情况，才第一次被人看见。

下面这些数字是为了让那一刻提前到立项会上。

那个写着支持的勾选框，底下到底是什么？

先把这条带子的形状摆出来。数据是WordPress 6.7这一版的核心界面文案，共6519条，覆盖208个语言版本。所谓语言版本，指的是一个可以被单独选中、单独维护译文的条目，比如简体中文是一个，繁体中文是另一个。

208个语言版本的完成度长什么样

按完成度分档之后，分布是这样的。

两头各占约六分之一，中间那一大片占了三分之二。这个形状值得多看两眼，因为它跟大多数人心里的图不一样。

心里那张图通常是两根柱子：大语言在右边顶格，小语言在左边贴地。真实的图是一条从右到左缓慢下沉的坡，坡上站满了人。落在30%–89%这个区间的有53个语言版本，超过总数的四分之一——它们既不能说不支持，也绝对不能说支持。

这四分之一才是做决策时最容易踩空的地方。你查到它在列表里，它确实在；你上线之后发现三分之一的界面是英文，它也确实是。

满分那34门和零分那35门分别是谁

满分那一组里有德语、法语、俄语、日语、波兰语这些意料之中的名字，也有一批意料之外的：格鲁吉亚语、老挝语、他加禄语、威尔士语、库尔德索拉尼语、维吾尔语。这几门语言的共同点是使用者规模都不大，网上的文本量也谈不上丰富。

零分那一组里则有祖鲁语、科萨语、伊博语、沃洛夫语、斯瓦蒂语、马耳他语、拉丁语。祖鲁语和科萨语加起来是南非上千万人的母语，伊博语在尼日利亚同样是几千万人的日常用语。

祖鲁语这一行尤其值得记住。南非是非洲电商渗透率最高的市场之一，祖鲁语是那里的第一大母语，而在这份名单上它的已翻条数是零，从建立到现在没有人提交过一次。

把这两组并排看，第一个反应通常是想找一条人口线或者一条经济线去解释它。找不到的。后面会用相关系数把这件事说死，这里先记住一个粗浅但可靠的印象：这张表上语言的位置，跟这门语言有多少人说、有多少钱，关系比想象中弱得多。

零分里有21门其实有人开过头

零分那35门里，有21门的已翻条数并不是零，只是不到1%被四舍五入成了零。把已翻条数拉出来，会看到一组很有意思的数字。

威尼斯语翻了60条，土库曼语49条，伊博语40条，帕皮阿门托语38条，富拉语32条，新加坡中文27条，丰语20条，格陵兰语15条，夏威夷语9条，毛利语6条。最后三个更极端：瓦伦西亚加泰罗尼亚语、卢旺达语、毛里求斯克里奥尔语各翻了1条。

再把最后一次提交的时间贴上去：富拉语停在2014年12月，卢旺达语停在2014年12月，毛利语停在2015年7月，格陵兰语停在2016年2月，土库曼语停在2017年1月。

六千五百条里翻了一条，然后停了十年。这不是一门语言没人管的样子，这是一个人来过、试了几分钟、走了的样子。

这个形态在做市场调研的时候特别容易骗人，因为大多数工具展示的是有没有这门语言，而不是有多少。列表里那一行看起来跟满格的德语没有任何区别。

做小语种内容的人对这个形态应该不陌生。翻开维基百科上那些条目会看到同样的东西：一个标题、一句正文、一个空的参考资料栏。保哥在拆条目底下垫没垫可核查的出处时量到过一个更极端的版本——约鲁巴语的条目里，有参考资料栏的占了八成，而这些栏里一条出处都没有。格式被复制过去了，动作没有发生。

界面翻译这一层的表现完全一致。开一个坑和填一个坑之间，隔着的不是技术门槛，是有没有人愿意连续做上几十个小时。

为什么这条曲线跟你想的形状不一样

一条正常的能力曲线，比如各语言的网页总量、各语言的搜索量，通常是长尾形状：头部几门语言占掉绝大部分，后面拖一条很长很薄的尾巴。界面翻译这条不是长尾，它两头厚中间实，更像一条被拉平的坡。

原因在于这件事的总量是封闭的。写内容没有终点，能一直写下去，所以头部可以无限拉高；翻界面有终点，六千五百条译完就是译完了，再多的人力也变不出第6520条。

这个封闭性带来两个后果。好的一面是，任何一门语言理论上都能走到100%，这是内容层永远做不到的事；坏的一面是，终点每年都在往后挪。

后面这句话是整篇文章的主线。

顺带说一句读图的经验。看到这种两头厚中间实的分布，第一反应不该是找平均值，因为平均值落在中间那一段，而中间那一段恰好是最没有代表性的位置。这份数据的平均完成度是52.9%，中位数57%，可整个208项里真正落在50%到60%之间的只有8项。

要用的是分位数和两端的名单。这条经验对任何长得像这个形状的指标都适用。

完成度为什么会往回掉？

先看一组分母。

十二年里字符串从1709条涨到6519条

WordPress每个大版本都有一条独立的翻译分支，每条分支有自己的字符串总数。把几条分支的分母顺着时间排开：3.5版是1709条，4.0版1544条，4.9版2669条，5.5版4062条，6.0版5357条，到6.7版是6519条。

中间有过一次收缩，4.0那一版比3.5少了一百多条，说明这个数字不是只涨不跌的，重构和精简也会发生。但从4.0到6.7，十年多一点的时间里翻了4.2倍。

同一段时间里，有译文的语言版本数从114个涨到208个。参与的人变多了，每个人要追的东西也变多了，而后者涨得更快。

软件长大的方式是加功能，加功能的方式是加界面，加界面的方式是加文案。代码里每一句要给用户看的话都得被单独标记出来，标记完就自动进了翻译池。这条链条上没有任何一环会主动去关心某门语言的译者今年还在不在。

这就是这一层跟内容层最不一样的地方。你的文章不会因为别人写了新文章而变得不完整，界面译文会。

曾经翻满的106门，今天还满的63门

把判据定死：一个语言版本只要在3.5、4.0、4.9、5.5、6.0这五条分支中的任意一条上达到过95%，就算它翻满过。符合这个条件的有106个语言版本。

这106个里，在6.7分支上仍然保持95%以上的，是63个。

也就是说，历史上曾经把界面翻完的语言，四成已经掉队了，而且没有任何一门是因为译文被删掉。

这条数据是整份数据里保哥最看重的一条。它把一件通常被描述成静态状态的事情——这门语言支持不支持——改写成了一件动态的事：这门语言的翻译供给速度，跟不跟得上软件的增长速度。

掉得最狠的十八门，轨迹长什么样

把判据收紧到峰值95%以上、6.7分支跌破70%，得到18个语言版本。挑几条轨迹出来看。

这些曲线的形状高度一致：先陡峭爬升到接近满格，保持一到两个版本，然后开始匀速下滑，一路滑到今天。

它们不是没做好，是做完过一次，然后停手了。停手那一刻的完成度是99%，此后每个版本新增的一千多条没人接，分母涨、分子不动，百分比就自己往下走。

亚美尼亚语那一行的形状稍微不同，它的峰值出现在4.0而不是最早的分支，说明社区是中途接手的，接完一版之后同样没有再续。乌尔都语则是滑得最慢的一条，从99%到61%用了四个版本，说明它一直有零星的提交，只是速度追不上新增量。

把这两种形状分开有实际意义：前一种是社区解散了，后一种是社区还在但人手不够。前者基本不可能自己回来，后者只要有人赞助几十个工时就能拉回去。

停手不等于停在原地，等于往回退

这句话听着像绕口令，但它是这一层最反直觉的地方，也是最容易在排期会上被说漏的地方。

做内容的人对停更有一套成熟的直觉：停更了，老内容还在，排名会慢慢掉但不会归零。做界面翻译的人如果把这套直觉搬过来，会得出一个错误的结论——译文又不会消失，停一年能有多大事。

实际上，从6.0到6.7这三年，核心新增了1162条文案。一门停手三年的语言，光是这三年就会白掉17.8个百分点，而这三年里它一条译文都没有丢。

把这件事翻译成运营语言：界面本地化不是一个项目，是一条订阅。你可以不续费，但不续费的代价不是维持现状，是每年往回退五到六个点。

这跟保哥之前在用编辑人数替代内容量来估竞争强度时的发现是同一个道理：一个看起来在描述存量的数字，实际上被一个流量型的变量控制着。存量指标读起来安稳，安稳是假的。

掉下去的语言还爬得回来吗？

能。而且爬回来的速度比掉下去快得多，这是这份数据里唯一让人高兴的一条。

十三门从很低爬到九成以上的语言

把判据反过来定：在3.5或4.0分支上不到30%，而在6.7分支上达到90%以上。符合的有13个语言版本。

幅度最大的几门是这样的：斯瓦希里语从1%到99%，阿富汗波斯语从2%到99%，古吉拉特语和卡纳达语都是从6%到99%，波斯语从8%到100%，马拉雅拉姆语从7%到91%，马拉地语从11%到99%。剩下几门起点稍高：斯洛伐克语16%、威尔士语17%、越南语21%、他加禄语27%，现在全部在99%以上。

波斯语的轨迹尤其干净：3.5分支8%，到4.0分支直接100%，此后五条分支全部保持100%。斯洛伐克语和威尔士语的形状完全一样，都是在某一个版本上一次性补完，然后再也没掉过。

他加禄语的形状则是另一种：27%、53%、81%、56%、55%、100%，中间掉过两次又爬回来。这种锯齿形通常说明社区人手不稳定，某个版本有人集中做了一批，下个版本没跟上，再下一个版本又有人回来。

这几条曲线在说同一件事：六千多条文案对一个认真的团队来说不是一个不可逾越的量，难的从来不是第一次翻完，是接下来每年都补上新增的那一千条。

缅甸语在两个分支上差了七十七个百分点

缅甸语值得单独说，因为它同时是掉队最狠的样本和回来最猛的样本。

它在6.7分支上是22%。但如果去看正在开发中的下一个大版本分支，缅甸语是99%。

同一门语言，同一批人，两个分支差了77个百分点。这不是数据错了，这是WordPress翻译平台的一条规则在起作用：每个版本分支的译文是独立的，新提交的译文只进当前正在开发的那条分支，不会自动回填到已经发布的旧分支上。

翻译成人话就是：缅甸语社区回来了，而且几乎是把六千多条重新翻了一遍，但这批劳动只对以后的版本生效。今天还在跑6.7的缅甸语站点，界面仍然是七成八的英文。

这条规则对做站的人有一个直接后果——你查到的完成度，取决于你查的是哪个版本分支；查开发分支会系统性地高估你今天能拿到的东西。后面讲方法的时候会把这条口径说清楚。

回来的人先补哪一段

这份数据回答不了这个问题，但它的姊妹数据可以。把同一批语言的译文逐条拆开、按界面位置分类之后，能看到一条极其稳定的顺序——先补的永远是读者天天看见的那几十个词，最后补的永远是编辑器里那些长句子。这条顺序的完整证据和它带来的坑，保哥放在下一篇里讲。

这里只留一个结论：一门语言从20%回到90%，中间那段路上用户能感觉到的变化，远小于百分比的变化。因为最影响观感的那几百条，在20%的时候就已经翻好了。

一个人到底能不能翻完六千条

做排期的时候这个数要能估出来。按每条平均八到十二个词、一个熟练译者每小时处理三十到五十条算，六千五百条大约是一百三十到两百个工时。

这个量对一家公司来说是四五周的一个人力，对一个志愿社区来说是三五个人利用业余时间做上一个季度。官方的翻译者上手指引里对新人的期望写得很直白，先从最常用的那一批开始，不追求一次做完。

真正的问题从来不在这一百多个工时。真正的问题是明年的一千条谁来做，后年的一千条谁来做。把这件事写进预算表的时候，写成一次性项目的公司，三年后一定会回到这份数据的下半区。

内容多的语言，界面就翻得好吗？

开工前保哥的假设是没有关系。理由听起来很顺：写内容是无数人各写各的，翻界面是少数人集中做一件事，两件事的供给结构完全不同。

实测结果是这个假设错了，但错得很有价值。

相关系数是0.618，比我以为的高

拿147门语言的维基百科条目数取对数，跟6.7分支的界面完成度做相关：皮尔逊相关系数0.618，秩相关0.659。

这是一个中等偏强的正相关。也就是说，内容量确实能解释界面完成度的一部分变化，大概四成上下。这个结果本身不奇怪——两件事共享同一个底层变量，就是这门语言在互联网上有多少人在为它做无偿劳动。

但相关系数只有0.618，意味着还有六成的变化跟内容量无关。做决策时真正有用的不是这条相关线，是离这条线最远的那些点。

这也是保哥这几年反复撞到的一个模式。跨语言的指标之间几乎总能测出中等强度的正相关，因为它们背后共享一个笼统的语言活跃度；但只要相关系数不到0.8，用一个去替代另一个就一定会在某几门语言上翻车，而那几门往往正是你在犹豫要不要做的。

宿务语的维基排全球第二，界面只有两成

先看线下面的那一批。

宿务语这一行是整张表最刺眼的。六百一十一万条，在所有语言的维基百科里排第二，仅次于英语。界面完成度20%。

熟悉这门语言的人知道原因：那六百多万条里绝大部分是程序批量生成的。保哥在量随机一个页面一年有多少人打开时，宿务语的中位数是1次，接近一半的页面全年零次；在拆访问量里有多少来自机器时，宿务语的爬虫占比是92.07%，48门语言里最高。

三份完全独立的数据在同一门语言上指向同一个判断：那六百万条页面没有对应的人。而界面翻译这把尺子的好处是，它量的是人干的活，程序刷不出来。

老挝语条目五千多，界面满分

再看线上面那一批，也就是内容量很小、界面却接近满格的。老挝语的维基是5597条，界面100%；维吾尔语9724条，界面99%；阿萨姆语24871条，界面100%；古吉拉特语30897条，界面99%；卡纳达语35284条，界面99%；他加禄语49169条，界面100%；吉尔吉斯语76509条，界面99%；库尔德索拉尼语83732条，界面99%。

这八门语言的维基规模加起来还不到宿务语的5%，界面完成度却全部在99%以上。

老挝语的维基只有5597条，比宿务语少三个数量级，界面却是满分。这门语言在保哥之前的几次实验里一直是最惨的那一档——同一段内容送进模型的成本是英语的八倍，关键词工具上更是连一条有效搜索量都拿不到。

可是在界面这一层，老挝语站在最上面。

这两张表放在一起，才是这条相关性的正确读法：内容量告诉你这门语言的网上有多少字，界面完成度告诉你这门语言有没有一批人愿意做没有回报的细活。这两件事经常一致，不一致的时候，后者对你更有用。

这条相关性里真正有用的是残差

把上面两张表合起来，可以整理成一个很实用的读法。

内容量高、界面低的那一批，多半是被批量生成的内容撑起来的规模，要提防的是拿内容量排优先级会把它们排到前面。保哥在拆内容体裁成分时量到过一个配套指标，名录型条目的占比跟内容总量正相关，规模越大的语言水分越大。

内容量低、界面高的那一批，说明这门语言有一个活跃的技术社群。这批语言开起来阻力最小：你会拿到一个完整的后台、一套可用的日期与数字格式，剩下的只是内容本身。

两者都低的那一批，就是字面意思上的从零开始，成本要按重新造一遍来估。

而两者都高，才是唯一可以按常规市场做的情况——这份147门语言的样本里，符合的不到三十门。

做优先级排序的时候，这个四象限比单一排行榜好用。排行榜逼你在一条线上比较不可比的东西，四象限直接告诉你每一类要花的是什么钱：内容钱、工程钱、还是两样都要。

顺便提醒一句，这里用维基条目数只是因为它对所有语言都可得、口径统一。真正做决策时，把它换成你自己那个品类在这门语言下的搜索量、竞品数量、或者你已有的自然流量，得到的四象限更贴身。换指标不影响读法，因为读法本来就在残差上，不在绝对值上。

同一门语言被切成十四个版本，选错一个的代价

前面一直在说语言版本而不是语言，因为这两个词在这一层不是同义词。西班牙语在这份名单上占了14个位置。

西班牙语从满分一路排到2%

把这张表跟做市场的直觉对一下就会发现问题。西班牙语在你的排期表上大概率是一行，写着高优先级；它在系统里是14行，其中5行满格、4行残缺、1行几乎是空的。

洪都拉斯那一行2%，意思是选中它的站点会拿到一个几乎全英文的后台，而站长以为自己选的是西班牙语。

葡语的非正式版只有13%

葡萄牙语这一族5个版本，葡萄牙100%、正字法协议版99%、巴西99%、安哥拉84%，而葡萄牙语的非正式称呼版只有13%。

非正式版这种东西在德语、荷兰语、葡语里都有，用来区分对用户用敬称还是用平称。它是语言层面一个真实存在的分叉——保哥在拆日语敬语层级对转化的影响时讲过同一件事，称呼层级会直接改变落地页的语气与信任感。

但在这一层，非正式版不是一个开关，是一份需要重新翻六千五百条的独立工作量。德语的非正式版本做到了100%，葡语的停在13%，瑞士德语的非正式版反倒有99%。这里面没有规律，只有各自社区当年有没有人接手。

中文那四个版本的差距

中文有4个版本：中国大陆100%、台湾99%、香港75%、新加坡0%。

新加坡中文的已翻条数是27条，最后一次提交在2022年。这对做东南亚市场的独立站是一条实际信息：如果你按地区精细化去选了新加坡中文，拿到的是一个空壳；正确做法是选大陆或台湾版本，再在内容层处理用词差异。

这跟保哥反复讲的西语两个市场用词分叉、葡语巴西和葡萄牙的取舍是同一类判断，只是这次的判断依据不在关键词表上，在语言包的完成度上。

选locale时该按什么顺序看

把上面几族合起来，可以固化成一个很短的动作。

先看这门语言一共有几个可选版本。只有一个，直接用。有多个，把每个版本的完成度拉出来排一次序。

然后问一句：地区差异体现在界面文案上的部分，值不值得用完成度换。多数情况下不值得——界面上那几百个高频词在各地区版本之间几乎没有差别，你用地区版本换来的语言学精度是零点几个百分点，付出的是几十个百分点的完成度。

只有一种情况例外：这个地区版本本身也是满格的。西班牙语的墨西哥版和哥伦比亚版就属于这一类，选它们不用付代价。

核心翻满了，你的站就能用了吗？

到这里为止，所有数字量的都是WordPress核心。但没有一个真实站点是只跑核心的。

主题、商店、SEO插件是三条独立的曲线

保哥把同一批208个语言版本，在另外四个项目上重新量了一遍：官方主题Twenty Twenty-Four、电商插件WooCommerce、SEO插件Yoast SEO、表单插件Contact Form 7。

这张表比前面所有表都重要，因为它把结论从软件话题拉回了生意话题。

核心有63个语言版本翻到95%以上，到了商店那一层只剩30个，到了主题那一层只剩29个。而完全没有译文的版本数，核心是35个，主题是134个。

商店那一层的分母是核心的2.3倍

WooCommerce有15114条文案，是核心的2.3倍。

这个数字第一眼看着不合理——一个插件怎么会比整个系统还多。想一想就通了：核心管的是发文章，商店管的是商品、库存、税率、运费、支付、退款、订单状态、发票、优惠券、会员等级，每一样都是一整套流程，每一步都要给用户一句话。

而这一整套文案，正好是你的买家从加购到付款要一路读过去的那些字。它们不在后台，它们在结账页上。

这个位置上的英文和后台的英文不是一个量级的问题。后台的英文只影响你自己的运营效率，结账页的英文直接落在转化率上，而且落在漏斗最窄的那一段。

更麻烦的是它很难被自查发现。团队里做这个市场的人多半英文没问题，走一遍流程不会觉得有任何异常，甚至会因为看得懂而觉得更顺。真正卡住的是那些只会本地语言的用户，他们不会来告诉你。

十三门语言：后台能用，商店一个字都没有

把两层交叉，筛出核心完成度99%以上、而商店插件不到50%的语言版本，得到13个。

斯瓦希里语这一行值得停一下。保哥在讲非洲市场选语种时说过一句话，别先看人口，先看有没有人拿这门语言写价格和退货政策。这份数据把那句话变成了可查的数字：斯瓦希里语的后台是本地话，结账页从头到尾是英文。

相关系数0.711的意思不是可以替代

核心完成度跟各层的相关系数分别是：商店0.711、表单插件0.752、SEO插件0.638、官方主题0.549。

都是中强正相关，所以拿核心当粗筛是成立的——核心为零的语言，其他层基本不用查了。

但反过来不成立：核心满格只能把可能性从必然为零抬到大概一半，它不能替你回答结账页有没有译文。上面那13门就是这半边的具体样子。

所以正确的动作是分层查，而不是查一层推四层。查法在后面那节写成了清单。

最后一次有人动这门语言，是什么时候？

百分比是一个结果，它告诉你现在到了哪一步，但不告诉你还会不会往前走。时间戳补上了这一半。

十四个语言版本从来没有人提交过一条译文

208个版本里，有14个的提交记录是空的。不是翻了一点点，是从这个位置被建出来到今天，一条都没有。

祖鲁语、科萨语、斯瓦蒂语、埃维语、沃洛夫语、博多语、巴什基尔语、西西里语、皮卡第语、拉丁语、伊多语都在这一组里。

这个数字的意思不是这些语言不重要，是这条链上没有人把它接起来。一个语言版本能被建出来通常只需要有人提一次申请，接下来的六千五百条才是真正的门槛。

值得注意的是，这14个空版本照样会出现在语言下拉列表里。系统不会因为一条译文都没有就把它藏起来，选中它的结果是整个界面回落到英文，而且不报任何错。

如果你的选型清单是从下拉列表里抄下来的，这14项就会原样进入排期表。这也是为什么这一节要单独讲时间戳——它是唯一能把空版本和活版本区分开的字段。

停在2019年或更早的那二十六个

再看有提交记录但已经很久没动的。把最后一次提交落在2019年及以前的挑出来，有26个语言版本，其中5个停在2015年，3个停在2014年。

富拉语最后一次提交是2014年12月，萨哈语是2017年5月，塔希提语是2016年3月，哈扎拉吉语是2017年2月。

一个停在2014年的语言版本，意味着它错过了此后所有版本新增的四千九百多条文案。它的完成度在数学上不可能超过24%，跟这门语言本身没有任何关系。

时间戳比百分比更早给出信号

这两个指标的时序不一样，这一点在做决策时很有用。

百分比是滞后的。一个社区今天停手，完成度不会立刻掉，要等下一个大版本发布、分母变大，数字才开始难看。这中间通常隔着半年到一年。

时间戳是即时的。今天停手，最后一次提交的日期今天就不再往前走。

所以做尽调的时候，正确顺序是先看时间戳再看百分比。一个完成度96%但最后一次提交在两年前的语言版本，比一个完成度78%但上个月还有人提交的更危险——前者正走在下坡的起点上，后者在上坡。

这个读法保哥在别的层面上用过。判断一个开源组件还能不能依赖，看的从来不是它的星标数，是最近一次提交离今天多久。语言包完全是一回事。

怎么判断这门语言还有没有人在管

三个信号一起看，基本不会误判。

第一个是最后一次提交距今多久。半年以内算活跃，一到两年算观望，两年以上按停更处理。

第二个是最近一个大版本发布后完成度有没有回升。回升说明有人在追新增的那一批。

第三个是这门语言在核心以外的项目上有没有动静。只有核心在动、插件全零，通常说明只有一两个人在做，而且他们只做核心。

这些数字是怎么量出来的？

方法这一节写详细一点，因为这套东西可以直接搬到别的系统上，而且中间有一个口径不说清楚就会得出错误结论。

取哪一版，为什么不取开发分支

数据取的是6.7这条已发布分支，不是正在开发的那条。

原因在前面缅甸语那一段已经露过头：新提交的译文只进开发分支。如果拿开发分支的数字去做决策，你看到的是这门语言社区最近的活跃度，不是你今天装上系统能拿到的东西。

缅甸语开发分支99%、6.7分支22%，两个数都对，回答的是两个问题。做上线决策要用已发布分支的数；做长期投入判断可以参考开发分支。

旧分支不会自动继承新译文

这条规则还有一个副作用要说明。已发布分支上的数字并不是完全冻结的——社区偶尔会回头补一批旧版本的译文，所以这些百分比会随时间缓慢上升。

因此这篇里所有的百分比，更稳妥的读法是当作上界。真实站点在这一版发布当天能拿到的译文，只会比这些数字更少，不会更多。

这个口径对结论方向没有影响，因为文章的两条主结论——四成掉队、核心翻满不等于全站可用——都是在说数字不够高，用上界去论证只会让结论更保守。

一个人可以复现的三十分钟

整套采集其实只有三步。

第一步，从翻译平台的公开接口拉某个版本分支下所有语言版本的状态，一次请求拿到全部，包含已翻条数、未翻条数、完成度和最后一次提交时间。各版本分支的翻译状态都挂在同一个位置，换个版本号就是另一条分支。

第二步，对要细看的语言逐个导出译文文件。这一步慢一些，一个语言版本一兆左右，几十门语言跑一遍要十几分钟。

第三步，把外部指标接上去做对照。这篇用的是维基百科的条目数，也可以换成你自己的流量数据、订单数据。

难点不在技术，在别把三件事搞混：语言版本不等于语言，已发布分支不等于开发分支，核心不等于全站。

这套方法能不能搬到别的系统上

能，条件是那个系统的译文是公开的。

用同一套逻辑可以量的东西不止一个。任何采用标准本地化文件格式的项目，都能导出同样结构的数据——这类文件的结构几十年没变过，一条原文、一条译文、若干条注释，译文为空就是没翻。

闭源的系统没法这么查，只能退回到人工抽样：找一个能切到那门语言的演示站，把结账流程走一遍，逐屏截图数英文。这个办法笨，但对判断一个具体平台够用了。

决定做不做一门语言之前，该看哪几个数？

把前面所有东西压成可以执行的动作。

四个数，二十分钟

第一个数，这门语言在你的系统上有几个可选版本，各自完成度多少。多个版本时不要凭地区直觉选，按完成度选。

第二个数，你选中那个版本的最后一次提交距今多久。超过两年，后面三个数都不用查了。

第三个数，你实际要装的那几个插件在这门语言上各是多少。做电商就查商店插件，做内容站就查主题和SEO插件。

第四个数，最近两个大版本之间这门语言掉了几个点。这个数决定你要不要在预算里留一条持续投入的线。

三档判读线

核心和关键插件都在90%以上、且半年内有提交：按正常市场做，界面这一层不用管。

核心在90%以上但插件低于50%：可以做，但要提前决定那几千条商店文案谁来翻。预算里必须有这一项，否则上线那天你会发现结账页是英文的，而这时候改已经来不及了。

核心低于50%，或者两年以上没人提交：这门语言的界面要按从零开始算。这不代表不能做，代表成本模型要换一套——保哥在拆语种优先级的成本模型时把这类固定投入单独列过一栏，它跟内容成本不同源，不能混在一起摊。

查完之后的三种处置

第一种，换一个版本。同一门语言里换一个完成度更高的地区版本，零成本，最常用。

第二种，自己补。补的时候不要按文件顺序补，按用户看得见的顺序补，这个顺序下一篇会给出实测排序。

第三种，先上英文界面加本地语言内容。这个组合听起来别扭，但对纯内容站是完全成立的——搜索引擎抓的是你的正文，不是你后台的按钮。能不能这么干，取决于你的转化动作发生在页面上还是发生在系统里。

什么情况下这条线可以放宽

有三种情况可以不管界面完成度。

纯落地页站，所有文案都是自己写的，系统只负责渲染，那么系统翻没翻都不影响读者。

用无头架构，前端完全自己实现，后台只有自己人用。这时候界面是英文反而省事。

只做内容不做交易，用户在你的站上没有任何表单动作。这一条要谨慎用，因为搜索框、分页、评论都算表单动作。

我一开始想错了哪几条？

开工前保哥按老习惯先把预期写下来，一共八条，跑完对了三条。错的那五条里有两条直接改写了整篇的结构。

以为完成度跟内容量没关系

这是错得最彻底的一条。预期是相关系数接近零，实测0.618，秩相关0.659。

错在哪里？错在把两件事的执行者想成了两批人。写维基条目和翻界面文案确实是不同的活，但愿意为一门语言做无偿劳动的人，在很多语言里就是同一批人，甚至是同一个社群里的同一批账号。

这条打脸带来的收益是，它逼着保哥去看残差，而残差比相关性有用得多。如果实测真的接近零，这篇文章就只能写成两条互不相干的曲线；正因为有相关，偏离这条线的那些点才成为信号。

以为分布是二值的

第二条错的是形状。预期是双峰，一头挤满100%，一头挤满0%，中间很空。

实测是两头各占约六分之一，中间的三分之二铺得很开。在开发中的那条分支上双峰确实更明显一些，但已发布分支上不是。

这条错误如果不纠正，会得出一个很糟的操作建议：只需要判断这门语言在不在满格那一档。实际要判断的是它落在哪一段，以及它正在往哪个方向走。

以为掉队的都是小语言

第三条错的是掉队名单的构成。预期里掉队的应该是使用者最少的那批语言。

实测掉队最狠的18个语言版本里，有马来语、乌尔都语、南非荷兰语、阿塞拜疆语——这几门的母语者都是几千万起步。而满格那一组里躺着老挝语、维吾尔语、阿萨姆语这些使用者规模小得多的。

决定一门语言在这张表上位置的，不是有多少人说它，是有没有那么两三个人，连续几年在每个版本发布后把新增的那一千条补上。

猜对的那三条

猜对的是：核心完成度跟插件完成度相关但不能替代；同一门语言的地区版本之间差距会很大；零分那一组里会有相当比例其实是开过头就走了的。

第三条猜对的过程还有个小插曲。第一版脚本只取了完成度这一个字段，35个零分版本看起来完全一样。把已翻条数拉出来才发现其中21个不是真零。四舍五入到整数百分比的那一步，把一个很有意思的形态整个抹平了。

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

这一节划边界，免得把不同层的东西混在一起做决策。

内容的语言和界面的语言是两件事

这篇量的全部是界面文案，也就是系统自己吐出来的那些字。你写的文章、你的商品描述、你的分类名，都不在这份数据里。

这两件事的成本结构完全不同：内容是你花钱买的，界面是别人做好放在那儿的。所以界面这一层的正确态度是先查后决策，而不是先决策后填坑。

至于内容那一层怎么估、要不要机器翻译打底，保哥在机器翻译直接发布的质量线和母语审校的验收清单里分别写过，跟这一层不共用同一套判据。

语言标签和语言包不是一回事

选一个语言版本会同时决定两件事：加载哪份译文，以及页面上声明的语言标签是什么。

前者是这篇的主题，后者归架构层。你选了西班牙语的墨西哥版本，页面上的语言声明就会带上地区，这会影响搜索引擎对页面的地区判断，也会影响读屏软件的发音。这两件事的取舍规则不一样，架构层那一套在结构化数据里的语言与地区字段那篇里，标准侧的定义则可以直接查W3C关于页面语言声明的说明。

常见的错是拿完成度去定语言标签：因为墨西哥版翻得全，就把整站声明成墨西哥西班牙语。这是两个决策被一个下拉框绑在了一起，得手动拆开。

搜索引擎那半边不归这里

界面翻没翻，跟这门语言在搜索引擎里的收录、排名机制没有关系。后者归引擎层，跟语言层是两个话题。

唯一的交叉点是前台可见的那几百条文案会进页面正文，会被抓取。这个交叉点有多大、值多少钱，是下一篇要回答的问题。

交给谁

界面完成度这件事，在多数团队里没有明确的责任人。它不属于内容，不属于设计，通常也不属于开发——开发只负责让文案能被替换，替换成什么不归他管。

比较务实的做法是把它挂在负责开新市场的那个人名下，跟支付通道、物流方案放在同一张开市场检查表上。它跟支付通道的性质其实一样：不查会一直没人发现，发现的时候通常是用户已经走到最后一步了。

常见问题解答

完成度多少算可以上线？

核心和你要用的关键插件都在90%以上，可以按正常流程上线。80%到90%之间要先人工走一遍关键流程，重点看结账、表单和出错提示。低于80%就要把补译的工时算进上线预算，不能当成上线之后再说的事。

为什么同一门语言查出来的完成度不一样？

大概率是查了不同的版本分支。已发布分支和正在开发的分支是两套独立的译文，新提交只进开发分支。做上线决策要看你实际要装的那一版，缅甸语在这两条分支上的差距是77个百分点。

选地区版本还是选通用版本？

先比完成度。界面上那几百个高频词在同一门语言的各地区版本之间几乎没有差别，用几十个百分点的完成度去换零点几个百分点的地区精度不划算。只有当那个地区版本本身也是满格时，选它才没有代价。

核心翻满了，插件为什么还是英文？

因为它们是各自独立的翻译项目，由不同的人维护。实测有13个语言版本核心在99%以上而商店插件不到50%，其中斯瓦希里语、他加禄语、卡纳达语的商店插件是零。核心的完成度只能当粗筛用，不能推断其他层。

自己补译的话，六千多条要多久？

按熟练译者每小时三十到五十条估，核心六千五百条大约是一百三十到两百个工时。真正的成本不在这一次，在此后每个大版本新增的一千条上——从6.0到6.7这三年新增了1162条，停手三年就会白掉17.8个百分点。

怎么知道这门语言还有没有人在维护？

看最后一次提交距今多久，这个信号比完成度更早。完成度要等下一个大版本发布才开始难看，中间隔着半年到一年；提交时间戳今天停手今天就不动了。两年以上没有提交，按停更处理。

权威参考资料