# 保哥笔记 — 小语种SEO

> 本分片含 35 篇文章，按发布日期倒序。全部分片索引见 https://zhangwenbao.com/llms-full.md

**站点**：https://zhangwenbao.com/  
**分类**：小语种SEO  
**生成**：2026-09-12 13:06:31 CST

---

## 语言代码申请被驳回，187份裁决书里提到政治的只有1份

- URL：https://zhangwenbao.com/minor-language-code-request-rejection.html
- 分类：小语种SEO
- 发布：2024-12-26  |  更新：2024-12-26
- 摘要：ISO语言代码申请驳回率实测：总体16.0%，拆分与新建约25%而修改仅6.5%；东欧57.1%对南美5.0%，187份裁决书提到政治的只有1份。
- 关键词：多语言SEO,小语种SEO,网站本地化,建站选型

> **TLDR**：摘要：把ISO语言代码从2006年到2024年的全部变更申请翻了一遍，2250行变更里被驳回359行，总驳回率16.0%。按类型拆，想把一门语言立起来（新建25.3%、拆分25.9%）被驳的概率是想改它属性（6.5%）的四倍。按地区拆，东欧57.1%、东亚29.9%，而南美只有5.0%、太平洋10.7%。更值得看的是理由：驳回的申请94%附了公开裁决书，通过的只有2%，这个库里被完整记录下来的只有拒绝的理由。而187份可分析的驳回裁决书里，写到政治的只有1份。它们只说证据不够。

> 摘要：把ISO语言代码从2006年到2024年的全部变更申请翻了一遍，2250行变更里被驳回359行，总驳回率16.0%。按类型拆，想把一门语言立起来（新建25.3%、拆分25.9%）被驳的概率是想改它属性（6.5%）的四倍。按地区拆，东欧57.1%、东亚29.9%，而南美只有5.0%、太平洋10.7%。更值得看的是理由：驳回的申请94%附了公开裁决书，通过的只有2%，这个库里被完整记录下来的只有拒绝的理由。而187份可分析的驳回裁决书里，写到政治的只有1份。它们只说证据不够。

假设你要给一个地区变体单独做一套内容。第一个技术问题不是翻译，也不是选词，而是：这个变体在你的系统里能不能被表示成一个独立的东西。

答案取决于它有没有自己的语言代码。有，那它在hreflang里、在数据源里、在报表维度里都能单独占一格；没有，那你只能把它塞进上级语言里，或者拼一个地区后缀凑合。

于是就有了一个几乎没人问的问题：这个代码是谁发的，凭什么发，不发的时候会说什么。

上一篇把这份清单的生老病死数了一遍 (https://zhangwenbao.com/minor-language-code-retirement-macrolanguage.html)，这一篇换个方向，去看那些没进去的。因为这个库有一个很特别的性质：它只在拒绝的时候写下理由。

下面的数字全部截到2024年12月31日，按结果生效日期算。1423条申请、2250行变更、359行被驳回。

## 一门语言想拿到自己的代码要过几道关？

先把流程说清楚，后面的数字才有意义。

## 任何人都能提交，这一点比想象中开放

提交申请不需要什么资质。填一份表，说明你想做什么变更，附上你的依据，发给注册机构就行。申请人可以是语言学家、可以是当地的语言委员会，也可以是一个热心的使用者。

提交之后进入公开评议，任何人都可以发表意见，这些意见会被留档并编号。最后由注册机构写一份裁决，说明采纳还是驳回。

这套流程的开放程度，比多数人对国际标准的想象要高得多。门槛不在提交这一步，在举证这一步。

评议阶段留下的东西比结论本身有意思。一份争议大的申请能收到几十条意见，正反两方各自摆证据，全部按编号存档，十几年后还能逐条调出来看。

顺带一提，评议意见是这个库里唯一能看到使用者自己怎么说的地方。裁决书里的声音全是注册机构的。

## 五种动作，通过难度完全不同

这套体系要回答的问题，本质上跟印尼语和马来语算不算一门语言 (https://zhangwenbao.com/indonesian-malay-seo-two-markets-vocabulary-split.html)那一篇里的问题是同一个，只是那里用市场判据回答，这里用语言学判据回答。

能申请的动作一共五种：创建一个新代码、修改一个已有代码的属性、把一个代码合并进另一个、把一个代码拆开、直接注销一个代码。

截到2024年底已生效的2250行变更里，创建944行、修改862行、合并193行、拆分139行、注销110行。

这五种动作在你眼里可能差不多，在这套体系里的分量完全不同。下一节的数字会说明这一点。

还有一个隐藏的第六种：一份申请可以在受理过程中被注册机构修改。修改要经过申请人同意，改完之后走的是新方案而不是原方案。这种情况在争议大的申请里出现过好几次。

## 结果一年只出一到两次

申请提交之后要等多久？中位数大约一年。慢的能拖很久：2021年提交的那份闽南语拆分申请，结果2024年10月15日才下来。

更极端的例子是2006年提交的一份关于中古希腊语的申请，2023年12月15日才有结果，等了十七年。

2024年提交的十九条申请，到这一年年底一条都还没生效。所以如果你在等某个变体的代码，时间尺度是年，不是月。

等待时间长的原因不全是排队。有几份申请是被主动挂起的，挂起的理由是它涉及一个还没有先例的问题，而这个问题要等标准本身修订完才有答案。

## 为什么做SEO的人该看这个库

因为它回答了一个别处回答不了的问题：这个市场的语言边界，是不是有争议的。

一个地区的申请驳回率高，意味着这一带反复有人试图把某个变体立成独立语言，而每一次都没能拿出足够的证据。这件事在你的关键词数据里会以另一种形式出现——用户在搜索框里用哪套说法，往往正好卡在这条争议线上。

这比看人口数据有用得多。按母语人口给语种排优先级 (https://zhangwenbao.com/minor-language-seo-priority-language-cost-model.html)那一层看不见这条线，而它恰恰决定了你的词表要建一套还是两套。

还有一个用法更直接：查一下你要做的那门语言最近十年有没有出现在申请里。出现过，说明它的边界或者名称最近被动过，你手上那份词表的口径可能已经旧了。

没出现过反而是好消息，意味着这门语言的登记信息稳定，你按现有代码建的一切都不会突然失效。

## 哪一类申请最容易被驳回？

把359行驳回按动作类型拆开，差距大得有点吓人。

## 四倍的落差

逐条数：拆分25.9%（36行被驳，共139行）、创建25.3%（239行被驳，共944行）；另一头，合并9.8%、注销8.4%、修改只有6.5%。

想把一门语言立起来，被驳回的概率是想改它属性的四倍。

这个落差不是随机波动，它稳定地贯穿了这十八年。早期和近期分开算，比例几乎一样。

把绝对数摆出来更直观：创建类一共944行，被驳239行；修改类862行，只被驳56行。两类的体量几乎一样，被驳的数量差了四倍多。

## 为什么增加比减少难

理由其实很务实。增加一个代码是一笔永久成本：所有下游系统都要跟着加一行，所有历史数据都要考虑要不要重新分类，所有已经在用上级代码的应用都得回答一句这批内容现在归谁。

减少一个代码相对轻松：合并有唯一去向，注销可以直接删。风险是可控的。

所以这套体系天然是保守的。它对新增的举证要求，明显高于对合并和注销的要求。

这条保守性还有一个副作用：这套体系天然滞后于语言的实际变化。一门语言在现实中已经分化很久了，标准里可能还是一个代码；而标准里的划分一旦定下来，改起来又很慢。

## 这对你的实际含义

如果你正在等某个地区变体拿到独立代码，先把预期调低：历史通过率四分之三，而且等待时间以年计。

与其等，不如换个思路：用地区子标签或文字子标签把这个变体表示出来。这条路不需要谁批准，也不需要等。

反过来，如果你的表里有某个代码，你觉得它早晚会被合并掉——那这个判断的成功率反而高得多，因为合并的通过率超过九成。

有个例外情形值得注意：如果你要的那个变体在标准里从来没被登记过，也不属于任何已有代码的范围，那走创建这条路的成功率会明显高于走拆分。空白比划界容易，这条规律在地区数据里也成立。

## 拆分为什么和创建一样难

拆分表面上是把一个代码变成几个，实质上是同时做两件事：注销原代码，创建若干新代码。所以它继承了创建那一侧的高举证要求。

更麻烦的是，拆分要求申请人对原代码的全部范围负责。你不能只说甲和乙应该分开，你得说清楚原来那个代码涵盖的所有变体，拆完之后各自归到哪里。

这一条卡死过很多份申请，包括闽南语的第一次申请。后面会详细讲那一份。

换个角度说，拆分申请的举证工作量是创建的好几倍：创建只需要证明这一门语言存在且独立，拆分要证明原代码涵盖的每一块分别归到哪里。

所以实操上有个取巧的办法：如果你只关心其中一个变体，与其申请把上级代码拆开，不如论证这个变体本来就不在上级代码的范围内，改走创建。

## 修改类为什么这么容易过

修改改的是名字、别名、指称范围、成员关系这些属性，代码本身不动。下游系统不需要做任何迁移，成本几乎为零。

成本低，举证要求自然也低。一份修改申请常常只是一句这门语言在当地的正式名称是某某，附一份官方文件就够了。

所以有个很实用的推论：如果你的诉求可以被表述成改属性而不是立新码，成功率会高一个数量级。2016年有一份被驳的拆分申请，裁决书里直接给了这条路：如果这个变体确实不属于任何已有代码，可以改成申请创建而不是申请拆分，重新提交。

顺便说，修改类里占比最大的两项是参考名和指称范围。指称范围那一项虽然属于修改，但它改的是这个代码管哪些人，实际影响不比拆分小，只是没有人需要迁移数据。

## 为什么东欧的申请几乎过不去？

按地区拆驳回率，是这批数据里最刺眼的一张表。

## 从57.1%到5.0%

样本三十行以上的地区，逐条列：东欧57.1%（20行被驳，共35行）、东亚29.9%（84/281）、西亚28.6%（10/35）、西欧27.9%（12/43）。

另一头：南美5.0%（5/100）、南亚6.7%（11/165）、东南亚8.2%（30/365）、太平洋10.7%（53/494）。

最高和最低差了十一倍。太平洋地区494行申请几乎照单全收，而东欧35行里有20行被驳。

有个细节能帮你理解这张表：太平洋那494行申请里，绝大多数是给一门此前没有代码的语言编号，或者把一个粗糙的登记拆细。这类申请没人反对，因为没有人的既有权益被动到。

## 不是少数语言反复申请

看到东欧那个数字，第一反应通常是：肯定是某几门语言反复提，把比例拉高了。

逐条数了一遍：东欧那20行驳回涉及18个不同的语言代码。不是少数几门语言反复申请，是普遍难过。

这条猜错得挺彻底，但也因此更有价值——它说明问题不在申请人的水平，在这一带的语言边界本身。

顺带说，全库里被反复申请且始终没过的只有两组，这个数字比预期低得多。反复申请这件事本身就很罕见。

## 名单本身就是结论

把那18个代码的名字列出来，你不需要任何解释就能看出规律：波德拉谢语、跨斯拉夫语、教会希腊语、标准立陶宛语、斯堪尼亚语、普雷克穆列语、哈纳克语、卡伊方言、马祖里语、波马克语、卢森尼亚语。

全是想从某个大语言里独立出来的地方变体。捷克语和斯洛伐克语在1993年分家 (https://zhangwenbao.com/czech-slovak-seo-content-reuse-decision.html)之后各自成立，是这类诉求少见的成功样本，而它靠的是国家层面的分立，不是一份申请。每一个背后都有一段关于这里的人到底说的是不是另一门语言的争论。

而太平洋那边的申请长什么样呢？绝大多数是给一门此前没被登记过的语言创建代码，或者把一个登记得太粗的代码拆细。那边在填空白，这边在划边界。填空白容易，划边界难。

还有一层值得注意：这批申请里有好几份是在同一年集中出现的。2012年2月那一批和2020年1月那一批各有三到五份，都是相邻区域的地方变体。这种同步性不太可能是巧合。

对做欧洲市场的人，这份名单可以当成一张风险提示：名单上这些地方的用户，在语言身份上是有强烈自我意识的，而你的站按上级语言一套内容打过去，那种别扭感他们会感觉到。

## 语系维度更极端

换个切法，按语系看驳回率，样本二十五行以上的：汉藏语系83.3%（30/36）全表最高，人造语66.7%（20/30），日耳曼语族相关的也偏高。

另一头，跨新几内亚语系12.5%、沃尔特-刚果语族12.5%、孟高棉语族11.8%。

汉藏那个数字之所以这么高，原因跟东欧同构：申请集中在汉语内部各变体要不要独立成语言这件事上，而这件事是这个库里被反复争论最多的话题。

人造语那66.7%的成因跟前两者都不同，它是判据本身的问题——2017年之前这一类根本没有可依据的标准。这条下面有一整节。

## 这条判据怎么用

实操上可以这样用：查一下你的目标市场所在地区的驳回率。

驳回率低的地区，语言边界相对清晰，代码跟实际语言基本对得上，你按代码建词表问题不大。驳回率高的地区，代码是妥协的产物，你按代码建的词表会漏掉一大块用户实际在用的说法。

非洲市场选语种 (https://zhangwenbao.com/africa-market-language-selection-swahili-hausa-francophone.html)和东南亚那一层语言差异 (https://zhangwenbao.com/southeast-asia-seo-vietnam-thailand-indonesia-language-layer.html)属于前者，欧洲东部和东亚属于后者。这个判断只需要看一眼这张表。

更细的用法是按语系查而不是按地区查。同一个地区内部，不同语系的申请命运可能完全不同，而语系跟语言之间的真实关系更接近。

## 187份驳回裁决书里到底写了什么？

把能抽出文本的驳回裁决书逐份过一遍，数关键词出现在多少份文件里。

## 四个词占了大半

出现频率最高的是证据，105份，56.1%。第二是可懂度相关的词，75份，40.1%。第三是方言，54份，28.9%。第四是语言学，49份，26.2%。

这四个词几乎就是这套体系的全部判据。一份驳回书的典型写法是：你说这两个变体互不相通，但你没有提供证据；现有的语言学文献把它们当作同一门语言的方言。

其余的词都是零头：书写系统7份、人口数据7份、族群身份3份。

这四个词的组合方式也很固定。方言和语言学这两个词几乎总是一起出现，用来说明现有文献的立场；证据和可懂度则是一对，用来说明申请缺了什么。

## 提到政治的只有一份

这是整批数据里打脸最响的一条。翻这个库之前的预期是，考虑到东欧和东亚那个驳回率，总该有那么五到十五份裁决书明写这是政治问题不是语言学问题。

实测：187份里，出现政治这个词的只有1份。0.5%。

这不是说政治不存在。而是说，这套体系处理政治的方式是完全不提它，只谈证据。一份关于某个地区变体的申请被驳回，理由永远是没有提供互不相通的证据，不会是这件事太敏感。

这种处理方式有它的道理。一旦裁决书开始谈政治，这个机构就必须对每一个类似的案子表态，而它既没有这个授权也没有这个能力。只谈证据是它唯一能长期站得住的位置。

副作用是：一份申请被驳回之后，申请人拿到的是一句你的证据不够，而不是一句这件事不归我们判。前者听起来像可以再努力，后者才是实情。

## 也不怎么引学术来源

另一条预期也错了。原以为裁决书会大量引用现成的语言数据库当依据，也就是说判定标准是学界主流怎么说。

实测引用某个全球语言数据库的有13份，7.0%；引用另一个语系数据库的只有2.9%。绝大多数裁决书不引任何具名来源。

它们的写法是直接判断：现有文献把这两者当作方言、申请没有给出足够的证据。判断的依据在注册机构的专业判断里，不在某一份可查的清单里。这一点后面那节会展开，它比看上去要紧得多。

真正被反复援引的其实是两本工具书和一份语言地图集，而它们本身也不是随手可查的公开资源。小语种内容里参考资料那一栏的实测 (https://zhangwenbao.com/minor-language-content-citation-density.html)说过一个类似的现象：看起来有出处，点进去往往什么都没有。

## 一成的驳回书会告诉你怎么改

还有一个数字值得记住：20份驳回书里提到了重新提交，占10.7%。

这些裁决书不只说不行，还说了怎样才行。有的写着补上互不相通的证据、有的写着改成申请创建而不是申请拆分、有的写着如果这门语言继续发展并出现代际传承，可以再来。

这意味着被驳回不是终点。后面那节讲的三个反复申请的案例里，有两个最后过了。

2016年那份关于一门柏柏尔语变体的裁决书是个很完整的例子。它先说没有任何一句话证实这两个变体互不相通，接着挑出申请里的一处自相矛盾——如果新语言有八万人而原语言只有一万一千人，且拆分后原语言人口不变，那说明这八万人本来就不在原代码的范围里，那就不需要拆分。

然后它给了路：如果这个变体确实不属于任何已有代码，可以改成申请创建重新提交。这份裁决书驳回了申请，同时把正确的做法讲了一遍。

## 没提的那些同样是信息

反过来看没出现的东西也有价值。使用人口这个词只出现在7份里，而且都不是当作主要依据。

换句话说，一门语言有多少人说，跟它能不能拿到代码基本无关。这跟绝大多数人的直觉相反，也跟做市场的人的本能相反。

做小语种竞争强度评估 (https://zhangwenbao.com/minor-language-content-volume-editor-count.html)的时候常犯的一个错，就是把标准里的地位当成市场规模的代理指标。这两件事在这个库里几乎正交。

另一个几乎不出现的词是官方地位。一门语言是不是某个国家的官方语言，在这套判据里同样不产生效力。在非洲选语种 (https://zhangwenbao.com/africa-market-language-selection-swahili-hausa-francophone.html)那一层看重的官方地位，到这一层完全失效。

## 为什么只有被拒的时候才留下理由？

这一节讲的是一个结构性的发现，跟具体哪门语言无关。

## 94%对2%

把有驳回行的申请和全部通过的申请分开数，再去看各自有没有附公开的裁决文档。

有驳回的申请200条，其中187条有公开裁决书，94%。全部通过的申请1223条，其中只有23条有，2%。

这个库里被完整记录下来的，只有拒绝的理由。

这个比例还有一个技术含义：如果你想统计这套体系的判据，样本量只有一百八十几份，而且全部偏向被拒的那一侧。这个样本讲不了通过的原因，只能讲被拒的原因。

## 这不是疏忽，是必然

为什么会这样？因为通过不需要解释。申请人提了一个诉求，注册机构同意了，结果就是那个代码出现在表里，没有第三方需要被说服。

拒绝就不同了。有人提了诉求被驳回，这个人和支持他的社群需要一个交代，而且很可能会再来一次。所以理由必须写清楚，写不清楚下次还得重来。

这个规律不只适用于这个库。任何一个把决定过程公开归档的机构，你能读到的都是它拒绝的那部分。通过的那些，只留下一行结果。

反过来想，如果一个机构连通过的理由也详细记录，那多半说明它面对的是一个通过本身需要被质疑的领域，比如药品审批或者专利授予。语言代码显然不属于那一类。

## 对你的两个用处

第一个用处是研究性的：想知道一套体系的真实判据，去读它的驳回记录，不要读它的通过记录。通过记录里什么都没有。

第二个用处更实际：如果你在做的事需要说服某个平台或某个机构，被拒之后拿到的那份说明，价值远高于成功案例。因为成功案例里没有判据，只有结果。

这条对做平台申诉的人应该很熟悉。驳回信是唯一一份会告诉你规则长什么样的文件。

第三个用处偏研究：想快速摸清一个陌生领域的判据，找它的驳回记录读二十份，比读一百份成功案例有效。这条方法在竞品分析里也成立，只是驳回记录通常没那么好找。

## 一个副作用：这个库看起来比实际更严格

还有一个观察角度值得提。因为拒绝有长文档、通过只有一行，你翻这个库的第一印象一定是它非常难过。

但实际数字是84%的变更行通过了。绝大多数申请安安静静地过了，什么都没留下。

感知和实际的落差，全部来自记录方式。记录方式会改变一个体系在外人眼里的样子，而它自己毫不知情。

这个现象在别处也有对应。界面翻译完成度的那次实测 (https://zhangwenbao.com/minor-language-interface-translation-coverage.html)里也出现过类似的偏差：能被看见的永远是没完成的那部分，完成的那部分静悄悄的。

## 互不相通是不是唯一的判据？

这一节回答一个很多人以为已经知道答案的问题。

## 主判据确实是它

标准里的主判据是：两个话语变体之间的差别，是不是大到无法互相理解。是，就是两门语言；不是，就是一门语言的两个方言。

可懂度这个词出现在40.1%的驳回书里，是仅次于证据的第二高频词，位置摆得很清楚。

这条判据有个很干脆的好处：它是可测的。找两地的人互相听录音、做理解测试，能给出数字。而绝大多数被驳回的申请，恰恰是连这个测试都没做。

还有一点容易被忽略：可懂度是有方向的。甲地的人能听懂乙地的话，不代表反过来也成立，这种单向可懂在方言连续体里非常普遍。而标准的表述并没有细分方向。

## 两份申请自己写死了自己

有两个案例特别能说明问题。

2019年那份卢森尼亚语的拆分申请，申请书自己写着两个地区的卢森尼亚语之间存在足够的可懂度以便沟通。裁决书直接引用了这句话，然后说：那么授予独立代码的主要判据就不满足。

同一年波马克语那份申请 (https://iso639-3.sil.org/request/2019-004)更直接，申请书里写着波马克人、马其顿斯拉夫人和说标准保加利亚语的人可以在很大程度上互相理解。同样被原句引用，同样被判不满足。

写申请的人把最有力的反证自己写进了申请书。这不是水平问题，是因为申请人真正想论证的是身份，而身份这件事在这套判据里不算数。

这类错误在申请书里出现得如此频繁，说明它不是偶然。写申请的人默认审阅者关心的是我们是不是一个独立的群体，于是把可以沟通当成了一个中性的事实描述顺手写了进去。

## 但还有一条备用通道

波马克语那份裁决书里，还写了一段更有价值的东西。它引用了标准的另一条判据：在变体之间的可懂度足以沟通的情况下，如果存在长期以来有独立名称的族群语言身份，并且伴随着各自发达的标准化和文献，那也可以被当作应该视为不同语言的依据。

也就是说，互不相通不是唯一的门。还有第二道门：独立身份加上成熟的书面标准和文献。

这条备用通道在187份驳回书里只被明确引用了2次。但它的重要性远远超过这个频率，因为它解释了一整批看起来自相矛盾的现有代码。

这条判据的措辞里还藏着一个细节：它说的是可以被当作一个指标，不是必然成立。也就是说即使两个条件都满足，也还是注册机构判断。

## 塞尔维亚语、克罗地亚语、波斯尼亚语靠的就是这条

波马克语那份申请的论据之一是：塞尔维亚人、波斯尼亚人和克罗地亚人明明互相听得懂，却各有各的代码，那我们凭什么不行。

裁决书承认了这个事实，然后指出那三门语言拿到独立代码用的正是第二条判据，而不是第一条。接着话锋一转：所以一份成功的波马克语申请，需要证明存在发达的标准化并由此产生了相当数量的文献。

然后是那句最狠的：申请里描述的标准化工作听起来还很初步，提供的文献清单只列出两本用波马克语写的书，而且它们是用第二语言写的。

这三门语言在标准里还有一个更早的宏语言代码兜着，两位码是sh，今天在语言标签的登记表里已经被标为不推荐使用。这是个很典型的组合：上层留了兼容代码，下层各自独立。

## 前半句人人都有，后半句才是闸门

这条判据的两半，难度完全不对称。

长期存在的、有独立名称的族群身份——这个几乎每个申请这类代码的社群都有，否则也不会有人去写申请。

发达的标准化加上成规模的文献——这个要靠几十年的语法书、词典、教材、报纸和出版物堆出来。第一半是申请的动机，第二半才是判据。

这一条对做小语种市场的人有直接的映射意义：保加利亚语和塞尔维亚语 (https://zhangwenbao.com/bulgarian-serbian-seo-cyrillic-latin-dual-script.html)、克罗地亚语和斯洛文尼亚语 (https://zhangwenbao.com/croatian-slovenian-seo-two-small-markets-decision.html)这几门在标准里之所以各自独立，靠的是文献存量而不是语言距离。而文献存量，恰好也是决定这门语言的搜索内容供给有多厚的那个变量。

把这条判据翻译成做内容的话就是：一门语言在标准里的地位，跟它有多少人认同关系不大，跟它积累了多少书面材料关系很大。而书面材料的多少，正好也决定了你在这门语言上能不能找到可用的语料和可靠的审校。

## 两种文字算不算两门语言？

这个问题在小语种市场里出现的频率很高，标准里的答案非常明确。

## 亚美尼亚语那份申请给了答案

2011年有一份申请，请求把亚美尼亚语升格成宏语言，底下分出东部亚美尼亚语和西部亚美尼亚语两门。

申请的理由是东部那一支在二十世纪二十年代经历过一次重大改革，西部没有跟进。

裁决书 (https://iso639-3.sil.org/request/2011-176)的回答是：主要的参考文献都注意到了两者的差别，但明确指出它们仍然互相可懂；两者之间的主要差别是书写系统不同，没有清晰的语言学证据把两者分开。因此驳回。

值得一提的是，东西亚美尼亚语在实际使用中的差别相当明显，词汇、拼写规范、甚至部分语法都有分歧。裁决书并不否认这些，它否认的是这些差别到了语言的层面。

## 文字是表层，可懂度是判据

这条结论可以直接抄走：在这套体系里，用两套文字写同一门语言，不构成两门语言。

被这条判据挡住的申请不止一份。书写系统这个词出现在7份驳回书里，占3.7%，每一次都是同样的处理方式——承认差别存在，但认定它不到语言层面。

这跟很多人的直觉相反。对使用者来说，看不懂对方写的字，比听不懂对方说的话感受强烈得多。但这套判据只认后者。

同样的错位在语言名上也有一份：菲律宾那种都叫英语却不是同一个英语 (https://zhangwenbao.com/philippine-english-taglish-mixed-language-keyword-research.html)的情况，在标准里连一个变体子标签都没有，因为混用不构成一门语言。

如果反过来想，这条规则其实是自洽的：可懂度测的是口语，而文字是后来附加上去的一层。一门语言换一套字母，说的话一个音都没变。

只是对做站的人来说，口语这一层几乎接触不到，你能看到的全是文字这一层。判据和你的观测面正好错开，这才是别扭感的来源。

## 那双文字市场怎么表示

标准不给新代码，不代表你在技术上表示不出来。语言标签里有一个专门的文字子标签，写法是在语言代码后面加上文字的四字母代码。

比如塞尔维亚语的拉丁字母版和西里尔字母版，就是靠这个子标签区分的。这条路不需要任何人批准。

做波斯语这类跟阿拉伯语共用字母的市场 (https://zhangwenbao.com/persian-seo-iran-market-letters-digits-zwnj.html)，方向正好反过来：字母一样，语言不同。这时候需要区分的不是文字子标签，是语言代码本身。

这条路上有个容易被忽略的连带决定：地址栏那一截要不要跟着换。URL用本地字母还是拉丁转写 (https://zhangwenbao.com/minor-language-url-native-script-vs-latin-transliteration.html)那一层的取舍跟文字子标签是两回事，但它们经常被当成同一个决定一起拍板，结果是标签写对了、地址却拼不出来。

## 顺便说一个容易搞混的点

语言代码和文字代码是两套独立的标准，各有各的注册机构和更新节奏。

它们在语言标签里被拼在一起用，看起来像一个整体，其实一个变了另一个不会跟着变。做语言选择器 (https://zhangwenbao.com/minor-language-endonym-language-picker-sort.html)的时候如果要按文字分组，那份分组依据来自另一张表，不在本文讲的这个库里。

这两套代码的写法也不一样：语言代码是两位或三位小写字母，文字代码是四位首字母大写。看到一段标签认不出哪一截是什么，看大小写就行。

## 这套判据是什么时候才写下来的？

这一节是翻这个库最意外的一个发现，而它是从一门人造语身上翻出来的。

## 2007年的驳回理由是一句主观判断

2007年有人为一门叫做Toki Pona的极简人造语申请代码。裁决书的措辞今天读起来相当直白：注册机构认为这个申请为时过早；一门人造语的传播往往是短暂的、范围有限的兴趣，很少有人造语能在世界语言社群里留下持久影响而不只是个新鲜玩意儿；这门语言看起来属于新鲜玩意儿那一类。

然后它给了一句话：如果这门语言能挺过接下来这几年并持续发展，无论是应用还是使用者规模，注册机构愿意重新考虑。

注意这份裁决里没有任何可核对的判据。它是一个专业判断，不是一次规则适用。

有意思的是这句判断后来被证明是错的。这门语言不但挺过来了，还在十几年后拿到了代码。但这不妨碍当年那份裁决在当时是合理的。

## 2017年的驳回理由暴露了一件事

十年后同一门语言又申请了一次。这一次的裁决书 (https://iso639-3.sil.org/request/2017-035)写了一段完全不同的话。

大意是：鉴于越来越多看起来处在边缘的语言提交申请，同时标准的正文并没有规定什么样的语言才够格获得一个代码，注册机构一直在国际标准化组织相关技术委员会修订这一族标准的框架下起草这样一套判据；现在网站上已经有一份草案；这份草案在2017年第一次被用作创建语言代码的决策依据，并在同年六月的技术委员会会议上获得认可。

然后才是结论：按这套判据，这门语言看起来没有被用于多种场合，使用社群也不包含各个年龄段，因此驳回。

这段话里最值得注意的是它的坦率程度。一个运行了十一年的注册机构，在一份公开文件里承认自己一直没有成文的准入判据，这种坦率在标准文件里并不常见。

## 运行十一年之后才有成文的判据

把这两段并排读，结论就出来了：这个库从2006年开始受理申请，到2017年才第一次有一套成文的、被上级委员会认可的判据。

中间那十一年里，一千多条申请是怎么裁的？靠注册机构的专业判断。裁决书写得很认真、理由也讲得通，但那不是规则适用，是判断。

这一条把前面那节的结论又推进了一层。前面说这个库里被完整记录的只有拒绝的理由。现在要补一句：有理由不等于有规则。

这条还有一个推论：2017年之前的那些裁决，今天读起来仍然言之成理，但它们没法被用作先例——因为当时并不存在一条可以被援引的规则。而2017年之后的裁决可以。

## 2017年那一天很好认

判据成文之后立刻见效。2018年1月23日那一天生效的变更里，一口气驳回了七门人造语的申请：Sambahsa、Uropi、Lingwa de Planeta、Solresol、现代高卢语、一个国际辅助语的变体，还有Toki Pona。

人造语这一类的总驳回率是66.7%，全表第二高，仅次于汉藏语系。

但故事还有后半段：2021年提交的第三次申请通过了，2022年1月20日生效。同一套判据，同一门语言，第三次过了。变的不是规则，是这门语言自己。

这一天还有一个特点：七份驳回用的是同一套论证结构，几乎是同一个模板填不同的名字。判据成文之后，裁决书也跟着模板化了。

## 这条对你意味着什么

不只是个掌故。它给了一个可迁移的判断方法：任何一份看起来很权威的裁决，先问它适用的规则是什么时候写下来的。

写在裁决之前的，是规则适用；写在裁决之后的，是把过去的判断追认成规则。两者的可预测性完全不同。

这个方法在别的地方也管用。搜索引擎的各种指南、平台的各种政策，都值得问一句它是先有条文还是先有处置。小语种内容里那些看起来言之凿凿的本地规矩 (https://zhangwenbao.com/low-resource-language-ai-hallucination-rate-content-risk.html)，栽的往往就是这一条。

落到具体动作上：遇到一条你打算长期遵守的规则，先花五分钟查一下它的发布时间和最近一次修改时间。这一步能省掉很多按老规矩办事却被新规矩判罚的情况。

## 同一个代码被申请三次是什么下场？

整个库里被反复申请拆分且始终没能拆开的，只有两组。其中一组跨了十六年。

## 第一次：申请不完整

2008年有一份申请，请求把闽南语这个代码注销，拆成厦门话和潮州话两门。

裁决书的态度出人意料地正面：注册机构同意申请人的看法，根据提交的证据，这两者应该被赋予两个独立的代码。

但它接着说：这份申请完全没有处理同样属于闽南语指称范围的其他变体，比如海南和龙岩那几支；注册机构在考虑注销一个代码时必须顾及它指称范围的全部广度，而填补申请里这么大的空缺，不是注册机构的工作。因此驳回，并邀请申请人重新提交一份把全部闽南变体都考虑进去的申请。

这份裁决书的价值在于它把一条隐含规则说破了：注册机构只做裁判，不做补全。申请里缺的部分，它不会替你想，也不会只挑你写全的那部分批准。

## 第二次：论证跑题了

2019年的第二次申请把范围扩大了，一次提出五门。裁决书 (https://iso639-3.sil.org/request/2019-062)的评价相当不客气。

大意是：这份申请以这些变体互不相通这个论断开场，但接下来论证的却是中国的一般性问题，而不是具体的证据。学界的共识倾向于把它们当作一门语言的方言；某本关于中国语言的百科全书也把闽南语当作汉语族的一个方言，把这几个变体当作次方言。

于是注册机构选择遵从学术界的多数意见，保持现状。

这句评语值得任何写论证材料的人抄下来。一份材料一旦从具体证据滑向一般性议题，读的人立刻就知道具体证据是拿不出来的。

## 第三次：过了两门，但不是按申请人想的那样过的

2021年提交的第三份申请一口气提了十一门，结果2024年10月15日才下来。表面看是部分通过：两门通过，九门被驳。

但通过的那两门是怎么过的，才是这个案例真正的价值。裁决书 (https://iso639-3.sil.org/request/2021-045)写着：雷州话和海南话被学者明确认定为不是闽南语的下级分支，而是跟闽南语同一层级的独立闽语分支。

换句话说，这两门语言不是被从闽南语里拆出来的，是被认定为本来就不在里面。而闽南语这个代码本身的拆分申请，第三次仍然是被驳回的。

同一天生效的还有一项变更：中文这个宏语言的成员清单被更新，把这两个新代码加了进去。所以从数据结构上看，这两门语言并没有离开中文这个口袋，只是在口袋里换了一层。

## 顺手还翻了一份五年前的旧案

同一天生效的还有一件事：2019年一份关于邵将话的申请被通过了，而那份申请当年是以为时过早为由被驳回过的。

裁决书解释得很清楚：这三门语言按同一个理由成立，也就是学者把它们列为八个闽语分支中的三个，其中五个已经有代码了。

这是个很好的例子：同一份主张，五年前被判为时过早，五年后按完全相同的理由被通过。变的不是证据，是它排在了谁后面。

为时过早这个理由在这个库里出现过十二次。它是个很特别的驳回理由——它不否认申请的实质，只说时候未到，而时候到没到没有客观标准。

## 反复申请到底值不值

把三个反复申请的案例并排看：Toki Pona三次，第三次过了；跨斯拉夫语三次，2012年和2014年被驳，第三次在2024年4月3日通过了；闽南语三次，三次都没能把那个代码拆开。

三分之二的成功率，说明反复申请不是徒劳。但看通过的那两个，共同点很明显：过的那一次，主张变了。

Toki Pona第三次的时候，它的使用者规模和使用场合已经跟2007年不是一回事。跨斯拉夫语第三次的时候，它已经攒出了文献和社群。而闽南语三次申请的主张始终是同一个：这些变体互不相通，应该拆开。

这条判断可以推广：面对一个有成文判据的评审体系，重复提交同一份主张几乎没有意义；有意义的是把主张改成判据能接住的那个形状。

## 这件事怎么落到你的词表和链路上？

前面全是在读别人的档案，这一节说自己能做什么。

## 先分清有代码和没代码这两种情况

你要做的那个变体，去码表里查一下有没有独立代码。有，那它在链路上可以是一个完整的维度；没有，那它只能靠子标签表示，或者干脆并到上级语言里。

保哥的习惯是把这一步放进建词表的第一天，不是之后。因为它决定的不只是标签怎么写，还决定了你的报表能不能把这批用户单独看出来。

顺序错了的典型后果是：内容做了两套，数据只有一套，然后没人能证明第二套值不值。

还有一处要一起查：用户的设备和浏览器能不能选到这门语言 (https://zhangwenbao.com/minor-language-ui-locale-list-coverage.html)。标准里有代码只是第一关，用户设不成，你的语言协商照样接不住他。

查的时候有个坑：中文世界里流传的语言代码对照表，有相当一部分是从十几年前的资料抄来的，里面躺着已经注销的代码。以官方码表为准，别信二手表。

## 没有代码不等于没有办法

语言标签体系里，除了语言代码还有地区子标签、文字子标签和变体子标签三种补充手段。

瓦伦西亚语就是个现成的例子：它没有拿到独立的语言代码，但拿到了一个变体子标签，可以写成加泰罗尼亚语代码加上瓦伦西亚这个后缀。

Unicode那边关于怎么挑一个合适的语言标识 (https://cldr.unicode.org/index/cldr-spec/picking-the-right-language-code)的说明写得比标准原文好懂，遇到拿不准的组合可以直接对着它挑。这条路唯一的代价是有些老系统不认这么长的标签，需要先测一遍。

变体子标签这一类通常最长也最容易出问题，因为它在语言标签里排在最后，一些实现只解析前两段就停了。上线前找几个主流工具各测一遍，比事后排查省事。

## 驳回率高的市场，词表要按用词建

回到第三节那张地区表。如果你的市场落在驳回率高的那几块，说明当地对语言边界有持续争议。

争议在搜索行为上的表现是：同一个东西存在两套或更多说法，各有一批人在用，而没有任何一套能算作官方的唯一写法。

这种情况下按代码建词表必然漏。正确的做法是先按实际用词把两套都收进来，再决定内容做几套。双语市场那种内容拆分决策 (https://zhangwenbao.com/ukrainian-russian-seo-bilingual-market-content-split.html)本质上就是在处理这件事。

还有一个信号可以配合着看：同一个商品品类在两套说法下的搜索量是不是接近。接近说明两套都活着，必须都收；相差一个数量级说明其中一套只在书面场合出现，词表里留一条就够。

## hreflang这一层的三条底线

第一，别自己发明代码。语言标签的取值有一份权威登记表，不在里面的写法搜索引擎会直接忽略。

第二，别用宏语言代码去表示一个具体的地区变体。荷兰语和佛兰芒语是个好例子——这两个市场在标准里共用一个语言代码 (https://zhangwenbao.com/dutch-seo-netherlands-belgium-flemish-two-markets.html)，要分开只能靠地区后缀。写成宏语言加地区后缀，比生造一个代码稳妥得多。

第三，页面上的语言声明和hreflang里的值要一致。hreflang的完整用法 (https://zhangwenbao.com/international-seo-hreflang-complete-guide.html)那一层讲了各种互指规则，而这一层要保证的是被互指的那串字符本身合法。

第四条不算底线但值得说：别用国旗代替语言。这条跟本文的主题是同一件事的两面——语言和国家在标准里就是两个维度，混成一个迟早出问题。

## 一个五分钟的自查

保哥给几个团队做过这件事，动作很简单：把站上所有语言标签的取值导出来，逐个去登记表里查两件事：这个子标签存不存在，以及它有没有被标为不推荐使用。

不推荐使用那一类最值得看，因为它通常伴随一个官方推荐的替代值，而这个替代值就是你该改成的东西。

做过一次之后，把这个动作挂到每年一次的检查清单里。这件事的成本极低，而它挡住的是那种查一整天都查不出来的问题。

顺手可以一起查的还有一样：你的分析工具里语言维度的取值清单，跟你站上实际输出的标签对不对得上。这两处对不上的时候，报表会安静地把一批用户归到其他一栏。

## 我一开始猜错了哪几条？

翻这个库之前写了一份预期清单，翻完之后逐条对账。

## 猜错一：以为有一批裁决书会明写政治

预计五到十五份，实测1份。错得最彻底的一条。

猜错的根源是把驳回率的地区分布和裁决书的措辞当成了同一件事。地区分布确实反映了争议的位置，但措辞层面完全不提。

修正后的判断是：争议会体现在申请量和驳回率上，不会体现在措辞上。想找争议，看统计，不要看文本。

这条猜错还有一个更一般的形式：一个机构越是被卷进敏感议题，它的公开文本就越会收敛到技术语言。文本越干净，通常说明外部压力越大，而不是越小。

## 猜错二：以为裁决会大量引学术来源

实测引用具名语言数据库的只有7.0%和2.9%。

这条猜错的后果比看上去大。如果裁决大量引用可查的来源，那这套判据就是可预测的——你能提前查一遍那些来源，估计自己的申请能不能过。

实际上不能。判据在专业判断里，而专业判断没有公开的索引。这也是2017年那份草案为什么重要。

顺带修正一个相关的印象：这个库并不是学术共同体在投票，它是一个机构在做行政裁量，只不过裁量的依据是语言学。这两者的可预测性差别很大。

## 猜错三：以为东欧的高驳回率来自少数语言反复申请

实测20行驳回涉及18个不同代码。

这条猜错改变了一个结论的方向：如果是少数语言反复申请，那高驳回率说的是那几门语言的问题；实际是普遍难过，那高驳回率说的是这一带的语言边界本身在移动。

后一个结论对做市场的人有用得多，因为它可以直接推出词表策略。

这条也提醒了一个统计上的常见陷阱：看到一个比例异常，先去数分子里有多少个不同的个体。个体少说明是特例，个体多说明是结构。

## 猜错四：以为反复申请全被驳的案例有五到十二组

实测只有两组：闽南语和一门西非语言。

这条猜错也是有价值的。它说明反复申请这件事本身很少见，而少见的原因不难猜——写一份申请要花的力气不小，被驳一次之后大多数人不会再来。

能来第三次的，要么背后有个持续存在的组织，要么这门语言本身在这十几年里真的变了。

另外还有一个观察：反复申请之间的间隔往往是十年左右，而不是两三年。这个间隔大概就是一个社群攒够新材料所需要的时间。

## 猜对的那一条

猜对的是汉语变体的驳回率会显著高于全局。预计超过六成，实测汉藏语系83.3%，是全表最高。

但猜对的过程里冒出了一个原本没想到的东西：这个数字之所以这么高，不是因为申请质量差，而是因为这一带的申请全部集中在同一个争议上，而这个争议在这套判据下无解。

无解的意思是：主判据要求互不相通的证据，而提交者真正想论证的是身份。这两件事在这套体系里不通约，提多少次都一样。

把这条推广开：当一个体系的判据和申请人的诉求不在同一个维度上时，提交次数不产生任何进展。要么换判据，要么换诉求，没有第三条路。

这也是本文最想留下的一句话。一门语言算不算数，在这套体系里是一件有人受理、有判据、有驳回率的行政事务；而决定它的，是这门语言的边界有没有人在争，以及争的那一方拿不拿得出互不相通的证据。

## 常见问题解答

## 我怎么知道一个语言变体有没有独立的代码？

去注册机构的码表下载页拿在册表，是个制表符分隔的纯文本文件，用表格软件打开搜名字就行。要注意搜索的时候别只搜中文名，官方表里用的是英文参考名和当地名称，中文名往往对不上。搜不到的时候再查一下宏语言成员表，有可能它是作为某个宏语言的成员登记的。

## 没有独立代码的变体，在hreflang里该怎么写？

用上级语言代码加子标签。地区差异用地区子标签，比如同一门语言的两个国家版本；文字差异用文字子标签；两者都不合适的时候还有变体子标签，瓦伦西亚语用的就是这一种。关键是取值必须来自语言标签的官方登记表，不能自己拼。写完之后建议在一两个老一点的系统里测一下，超过两段的标签不是所有地方都认。

## 申请一个新的语言代码难不难，值不值得试？

从数据看，创建类申请的历史通过率是四分之三左右，等待时间中位数一年，慢的能到三年以上。对绝大多数做内容和做站的团队来说不值得——因为你需要的效果用子标签就能达到，而子标签不需要等任何人。真正需要走这条路的，是那些确实要把一门语言写进各种标准链路的语言机构。

## 为什么两门明明互相听不懂的话，只有一个代码？

最常见的原因是从来没有人提出过申请。这套体系是被动的，它只处理收到的申请，不会主动去审视现有的划分。第二个原因是提过但没能拿出可核对的可懂度证据。第三个原因是它们被登记在同一个宏语言底下，各自其实有代码，只是你查的时候用的是那个宏语言的代码。

## 用两套文字写的同一门语言，要不要做成两套内容？

标准这一层的答案是它们是同一门语言，但这个答案不解决你的问题。实际决策要看两点：一是用户在搜索框里用哪套文字打字，这个可以直接量；二是两套文字的内容会不会互相稀释。多数情况下正确的做法是内容一套、呈现两套，用文字子标签区分，而不是做成两个完全独立的站点分支。

## 这些驳回记录，除了长见识还有什么实际用处？

最实际的用处是判断一个市场的语言边界稳不稳。查一下你目标市场所在地区的驳回率，高的说明当地对说的到底是不是同一门语言长期有争议，那你的关键词表必须按实际用词建、按两套甚至三套收；低的说明边界清晰，按代码建词表基本够用。这个判断只需要看一张表，比做用户调研快得多。



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

- URL：https://zhangwenbao.com/minor-language-untranslated-string-order.html
- 分类：小语种SEO
- 发布：2024-12-24  |  更新：2024-12-24
- 摘要：147个语言版本逐条对齐6519条界面文案：时间词平均翻译率86.7%、编辑器50.8%，出错提示中位位次2896，分页无障碍标签排倒数110名。
- 关键词：用户体验,多语言SEO,小语种SEO,网站本地化

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

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

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

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

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

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

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

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

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

## 没翻和没送去翻是两件事

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

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

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

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

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

## 为什么可以精确到条

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

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

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

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

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

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

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

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

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

这跟保哥在拆内容缺口时发现品类词那一格单独塌陷 (https://zhangwenbao.com/minor-language-content-gap-category-words.html)是同一类现象：总量指标把结构差异抹平了，而所有的坑都长在结构里。

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

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

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

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

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

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

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

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

## 按位置拆开之后的样子

位置 | 条数 | 谁会看到 | 

区块编辑器界面 | 2648 | 只有登录后写文章的人 | 

后台管理页面 | 463 | 只有运营团队 | 

登录与注册页 | 134 | 所有注册用户 | 

导航与分页 | 121 | 所有访客，进正文HTML | 

出错与空状态 | 98 | 操作失败的那批访客 | 

时间词（月份、星期、上下午） | 69 | 所有访客，出现在每一篇文章上 | 

评论区 | 69 | 所有访客 | 

订阅源 | 9 | 抓取程序与订阅用户 | 

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

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

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

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

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

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

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

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

## 四百条和两千六百条

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

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

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

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

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

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

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

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

结构化数据那一条尤其值得注意。页面里给机器读的那份日期字段 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)用的是标准格式，不受这69条影响；但展示给人看的那个日期用的就是它们。同一个页面上，机器读到的日期正常，人看到的日期是英文，这种情况完全可能发生。

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

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

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

## 44门语言给出的排序

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

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

位置 | 该组完成度 | 相对全局 | 

时间词 | 97.8% | +59.2点 | 

导航与分页 | 86.3% | +47.8点 | 

评论区 | 70.1% | +31.6点 | 

登录与注册页 | 69.9% | +31.3点 | 

后台管理页面 | 67.1% | +28.6点 | 

出错与空状态 | 46.2% | +7.7点 | 

区块编辑器界面 | 22.2% | −16.3点 | 

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

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

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

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

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

这里的人手结构跟内容那一层很像。保哥在用编辑人数替代内容量估竞争强度 (https://zhangwenbao.com/minor-language-content-volume-editor-count.html)时量到过，很多小语种的整片内容背后只有二三十个人。界面翻译的人数只会更少，通常是个位数。

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

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

## 负号那一行的意思

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

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

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

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

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

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

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

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

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

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

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

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

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

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

位置 | 中位位次 | 最靠前 | 最靠后 | 

时间词 | 241 | 1 | 860 | 

订阅源 | 344 | 147 | 2149 | 

导航与分页 | 597 | 2 | 6410 | 

登录与注册页 | 902 | 2 | 5816 | 

评论区 | 1118 | 12 | 5639 | 

后台管理页面 | 1338 | 2 | 6518 | 

出错与空状态 | 2896 | 159 | 6510 | 

区块编辑器界面 | 4403 | 1 | 6516 | 

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

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

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

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

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

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

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

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

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

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

## 出错提示掉到了第2896位

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

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

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

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

## 具体是哪些句子

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

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

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

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

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

## 为什么偏偏是这一组掉队

三个原因叠在一起。

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

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

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

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

这一层的代价不好算，但方向很清楚。保哥在拆落地页上那几个最像装饰的信任元素 (https://zhangwenbao.com/minor-language-landing-page-trust-signals-payment-address-support.html)时得出过一个结论：用户对一个站的信任判断，靠的不是首页写得多漂亮，是出问题那一刻他有没有被好好对待。出错提示是英文，就是没有被好好对待。

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

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

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

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

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

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

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

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

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

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

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

## 看不见的字里还有哪些

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

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

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

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

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

## 这一类的自查怎么做

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

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

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

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

保哥在写非拉丁文字的图片替代文字 (https://zhangwenbao.com/minor-language-image-alt-text-non-latin-script-search.html)时提过一个相似的判断：所有不在正文可视区域里的文字，都天然处于验收流程的盲区，需要单独列一张清单去查。

同一类盲区还有另一种形态。为了排版塞进标题里的那个看不见的字符 (https://zhangwenbao.com/minor-language-line-break-soft-hyphen-invisible-character.html)属于反过来的情况：那里是多了看不见的东西，这里是少了看不见的东西，两者都要靠专门的动作才能发现。

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

逐条导出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%。也就是说，有人认真地把月份和星期全部译完，然后再也没有回来。

这个形态跟保哥在量条目底下有没有出处 (https://zhangwenbao.com/minor-language-content-citation-density.html)时抓到的那批空壳一模一样：格式框架搭好了，里面的活没做。区别只是那一次的空壳是参考资料栏，这一次的空壳是六千多条待翻列表。

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

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

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

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

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

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

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

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

## 这69条里最难的是哪几个

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

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

这个坑跟保哥在拆缩写在各语言里的本地形式 (https://zhangwenbao.com/minor-language-acronym-initialism-local-forms-inflection.html)时讲的是同一件事：缩写不是把全称砍短，是一门语言自己的一套约定。英语里恰好相同的那几个，在别的语言里往往完全不同。

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

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

## 短句为什么比长句先翻？

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

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

原文长度 | 条数 | 平均被多少语言翻过 | 

1–10个字符 | 1550 | 64.7% | 

11–25 | 2296 | 58.8% | 

26–50 | 1382 | 55.4% | 

51–100 | 985 | 53.5% | 

101–200 | 263 | 50.7% | 

200以上 | 43 | 53.7% | 

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

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

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

## 最长那一档为什么回升

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

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

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

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

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

开工前保哥以为复数条目会明显吃亏。理由很实在：复数规则在不同语言里差别极大 (https://www.gnu.org/software/gettext/manual/html_node/Plural-forms.html)，阿拉伯语要填六个格子，斯拉夫语系要填三个，而英语只有两个。格子多、判断难，应该更容易被跳过。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

所以插件层只能一个一个查，没有捷径。这也是保哥在拆一套模板生成十种语言 (https://zhangwenbao.com/multilingual-template-ten-languages-duplicate-content-risk.html)时反复强调的一点：越是靠近页面输出的那一层，越不能靠推断，只能实地看一遍渲染结果。

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

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

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

## 第一步：查那69条

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

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

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

## 第二步：走一遍读者路径

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

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

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

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

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

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

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

顺便也把页面上的字体渲染看一眼。小语种站的字体文件 (https://zhangwenbao.com/minor-language-web-font-glyph-set-first-screen-cost.html)经常缺字形，缺了之后显示成方框，肉眼上跟没翻译是两回事，排查方向也完全不同。

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

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

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

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

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

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

## 我一开始猜错了哪几条？

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

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

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

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

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

## 以为长度是主要原因

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

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

## 以为复数条目会明显吃亏

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

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

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

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

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

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

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

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

## 没被抽出来的那批字

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

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

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

## 译文的质量不在这里

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

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

## 内容的语言不归这里

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

这两层的关系倒是有一条值得注意：页面被机器判成哪门语言 (https://zhangwenbao.com/minor-language-page-language-detection-misidentification-short-text.html)时，界面文案是会参与判断的。一个正文是本地语言、界面全英文的页面，在字数少的页面类型上有被判错的风险。

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

## 交给谁

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

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

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

## 常见问题解答

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

有，而且非常稳定。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字符以上那一档还回升了。真正有效的动作是给每一条加一句注释说明它出现在哪个屏幕上，可见性对顺序的影响远大于长度和语法难度。

## 权威参考资料



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

- URL：https://zhangwenbao.com/minor-language-interface-translation-coverage.html
- 分类：小语种SEO
- 发布：2024-12-13  |  更新：2024-12-13
- 摘要：208个语言版本实测界面完成度：满分34个、零分35个，曾经翻满的106门只剩63门仍满，核心翻满也不代表商店插件能用。
- 关键词：多语言SEO,小语种SEO,网站本地化,建站选型

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

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

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

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

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

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

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

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

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

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

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

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

完成度区间 | 语言版本数 | 占比 | 

100% | 34 | 16.3% | 

90%–99% | 38 | 18.3% | 

70%–89% | 25 | 12.0% | 

50%–69% | 13 | 6.2% | 

30%–49% | 15 | 7.2% | 

10%–29% | 22 | 10.6% | 

1%–9% | 26 | 12.5% | 

0% | 35 | 16.8% | 

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

心里那张图通常是两根柱子：大语言在右边顶格，小语言在左边贴地。真实的图是一条从右到左缓慢下沉的坡，坡上站满了人。落在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月。

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

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

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

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

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

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

原因在于这件事的总量是封闭的。写内容没有终点，能一直写下去，所以头部可以无限拉高；翻界面有终点，六千五百条译完就是译完了，再多的人力也变不出第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个。参与的人变多了，每个人要追的东西也变多了，而后者涨得更快。

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

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

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

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

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

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

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

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

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

语言版本 | 3.5 | 4.0 | 4.9 | 5.5 | 6.0 | 6.7 | 

黑山语 | 100 | 74 | 56 | 33 | 24 | 20 | 

缅甸语 | 100 | 99 | 53 | 38 | 27 | 22 | 

普什图语 | — | 99 | 64 | 39 | 28 | 22 | 

苏格兰盖尔语 | 99 | 99 | 69 | 41 | 35 | 28 | 

阿塞拜疆语 | 100 | 99 | 78 | 50 | 38 | 31 | 

亚美尼亚语 | 69 | 95 | 65 | 38 | 28 | 27 | 

冰岛语 | 95 | 99 | 93 | 63 | 45 | 36 | 

高棉语 | 3 | 99 | 88 | 73 | 50 | 40 | 

乌尔都语 | 10 | 98 | 99 | 89 | 81 | 61 | 

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

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

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

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

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

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

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

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

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

这跟保哥之前在用编辑人数替代内容量来估竞争强度 (https://zhangwenbao.com/minor-language-content-volume-editor-count.html)时的发现是同一个道理：一个看起来在描述存量的数字，实际上被一个流量型的变量控制着。存量指标读起来安稳，安稳是假的。

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

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

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

把判据反过来定：在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%的时候就已经翻好了。

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

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

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

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

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

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

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

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

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

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

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

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

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

先看线下面的那一批。

语言 | 维基条目数 | 界面完成度 | 

宿务语 | 6115371 | 20% | 

鞑靼语 | 708969 | 27% | 

亚美尼亚语 | 330392 | 27% | 

白俄罗斯语 | 265245 | 35% | 

阿塞拜疆语 | 216457 | 31% | 

拉丁语 | 142075 | 0% | 

泰卢固语 | 126961 | 36% | 

塔吉克语 | 118819 | 3% | 

缅甸语 | 111574 | 22% | 

豪萨语 | 106851 | 4% | 

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

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

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

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

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

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

老挝语的维基只有5597条，比宿务语少三个数量级，界面却是满分。这门语言在保哥之前的几次实验里一直是最惨的那一档——同一段内容送进模型的成本是英语的八倍 (https://zhangwenbao.com/minor-language-llm-token-inflation-cost.html)，关键词工具上更是连一条有效搜索量都拿不到 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)。

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

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

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

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

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

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

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

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

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

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

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

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

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

语言版本 | 完成度 | 最后一次提交 | 

西班牙语（西班牙） | 100% | 仍在更新 | 

西班牙语（墨西哥） | 100% | 仍在更新 | 

西班牙语（哥伦比亚） | 100% | 仍在更新 | 

西班牙语（阿根廷） | 99% | 仍在更新 | 

西班牙语（智利） | 99% | 仍在更新 | 

西班牙语（哥斯达黎加） | 96% | 仍在更新 | 

西班牙语（秘鲁） | 96% | 2024年10月 | 

西班牙语（委内瑞拉） | 84% | 2023年10月 | 

西班牙语（厄瓜多尔） | 76% | 2024年7月 | 

西班牙语（多米尼加） | 63% | 2023年9月 | 

西班牙语（乌拉圭） | 55% | 2021年3月 | 

西班牙语（波多黎各） | 47% | 2023年8月 | 

西班牙语（危地马拉） | 39% | 2019年3月 | 

西班牙语（洪都拉斯） | 2% | 2020年5月 | 

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

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

## 葡语的非正式版只有13%

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

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

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

## 中文那四个版本的差距

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

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

这跟保哥反复讲的西语两个市场用词分叉 (https://zhangwenbao.com/spanish-seo-es-es-latam-keyword-divergence.html)、葡语巴西和葡萄牙的取舍 (https://zhangwenbao.com/portuguese-seo-brazil-portugal-two-markets-keyword.html)是同一类判断，只是这次的判断依据不在关键词表上，在语言包的完成度上。

## 选locale时该按什么顺序看

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

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

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

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

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

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

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

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

项目 | 字符串条数 | 完成度 ≥95%的版本数 | 完成度为0的版本数 | 

WordPress核心6.7 | 6519 | 63 | 35 | 

官方主题Twenty Twenty-Four | 357 | 29 | 134 | 

WooCommerce | 15114 | 30 | 103 | 

Yoast SEO | 2531 | 28 | 114 | 

Contact Form 7 | 445 | 25 | 95 | 

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

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

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

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

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

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

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

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

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

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

语言版本 | 核心 | 商店 | SEO插件 | 官方主题 | 

斯瓦希里语 | 99% | 0% | 0% | 0% | 

他加禄语 | 100% | 0% | 0% | 0% | 

卡纳达语 | 99% | 0% | 0% | 0% | 

维吾尔语 | 99% | 0% | 29% | 87% | 

吉尔吉斯语 | 99% | 0% | 4% | 3% | 

阿萨姆语 | 100% | 1% | 2% | 95% | 

威尔士语 | 100% | 14% | 6% | 100% | 

马拉地语 | 99% | 15% | 7% | 92% | 

拉脱维亚语 | 99% | 38% | 6% | 22% | 

格鲁吉亚语 | 100% | 40% | 0% | 0% | 

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

## 相关系数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%，两个数都对，回答的是两个问题。做上线决策要用已发布分支的数；做长期投入判断可以参考开发分支。

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

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

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

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

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

整套采集其实只有三步。

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

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

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

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

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

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

用同一套逻辑可以量的东西不止一个。任何采用标准本地化文件格式的项目，都能导出同样结构的数据——这类文件的结构 (https://www.gnu.org/software/gettext/manual/html_node/PO-Files.html)几十年没变过，一条原文、一条译文、若干条注释，译文为空就是没翻。

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

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

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

## 四个数，二十分钟

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

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

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

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

## 三档判读线

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

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

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

## 查完之后的三种处置

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

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

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

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

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

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

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

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

## 我一开始想错了哪几条？

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

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

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

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

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

## 以为分布是二值的

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

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

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

## 以为掉队的都是小语言

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

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

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

## 猜对的那三条

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

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

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

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

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

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

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

至于内容那一层怎么估、要不要机器翻译打底，保哥在机器翻译直接发布的质量线 (https://zhangwenbao.com/machine-translation-direct-publish-search-risk-quality-line.html)和母语审校的验收清单 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)里分别写过，跟这一层不共用同一套判据。

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

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

前者是这篇的主题，后者归架构层。你选了西班牙语的墨西哥版本，页面上的语言声明就会带上地区，这会影响搜索引擎对页面的地区判断，也会影响读屏软件的发音。这两件事的取舍规则不一样，架构层那一套在结构化数据里的语言与地区字段 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)那篇里，标准侧的定义则可以直接查W3C关于页面语言声明的说明 (https://www.w3.org/International/questions/qa-html-language-declarations)。

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

## 搜索引擎那半边不归这里

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

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

## 交给谁

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

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

## 常见问题解答

## 完成度多少算可以上线？

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

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

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

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

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

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

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

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

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

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

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

## 权威参考资料



## Nike这四个字母在哪门语言里都是一个整块，写成本地文字之后碎成九片

- URL：https://zhangwenbao.com/minor-language-brand-name-token-fragmentation.html
- 分类：小语种SEO
- 发布：2024-12-10  |  更新：2026-08-02
- 摘要：14个品牌与14个品类词在39门语言实测：品牌名整块率拉丁32.8%对非拉丁4.8%，拉丁原名与本地转写87.7%零交集。给出按页面位置分的写法表与自测流程。
- 关键词：品牌建设,AI搜索,多语言SEO,小语种SEO

> **TLDR**：摘要：拿维基数据里14个真实品牌和14个电商品类词的官方多语言写法，逐个丢进模型的词表数一遍。Nike这四个字母在英语、俄语、希腊语里都是完整的一个块，转写成本地文字之后：日语3块、泰语3块、老挝语9块而且8块是半个字节，阿姆哈拉语6块全是字节。品牌名整块率拉丁字母语言平均32.8%，非拉丁只有4.8%，19门语言是0。更要紧的是拉丁原名和本地写法之间236组比较有207组连一个块都不共用——在模型看来，那压根就是两个毫不相干的字符串。

> 
摘要：拿维基数据里14个真实品牌和14个电商品类词的官方多语言写法，逐个丢进模型的词表数一遍。Nike这四个字母在英语、俄语、希腊语里都是完整的一个块，转写成本地文字之后：日语3块、泰语3块、老挝语9块而且8块是半个字节，阿姆哈拉语6块全是字节。品牌名整块率拉丁字母语言平均32.8%，非拉丁只有4.8%，19门语言是0。更要紧的是拉丁原名和本地写法之间236组比较有207组连一个块都不共用——在模型看来，那压根就是两个毫不相干的字符串。

有个做小家电的客户去年问了我一个当时答不上来的问题。他们在俄语市场同时用两种写法：官网用拉丁原名，社媒和本地经销商用西里尔转写。问题是，AI回答里提到他们品牌的时候，两种写法的出现频率差了将近一个量级。

当时我给的解释是搜索量和外部提及的差别，这个解释站得住，但不完整。

后来我拿tokenizer把这两串字符各数了一遍，才发现还有一层更底层的东西：拉丁原名在模型的词表里是一个完整的块，西里尔转写是三个块，而且这三个块跟拉丁原名那一个块之间没有任何交集。

模型不是把它们当成同一个品牌的两种写法，是当成两个不相干的字符串。这件事跟搜索引擎那一层完全不同——搜索引擎至少还有同义词表和实体库能把它们连起来，词表这一层什么都没有。

顺着这个念头，我把14个真实品牌和14个电商品类词的官方多语言写法全拉了下来，在39门语言上逐个切一遍。下面这些数字就是那次测量的结果。

## 一个名字在模型眼里到底算不算一个东西

## 这篇跟本站写过的品牌名转写不是同一个问题

本站很早写过品牌名进小语种市场会长出三种写法 (https://zhangwenbao.com/brand-name-transliteration-loanword-minor-language-search.html)，那篇解决的是用户会打哪一种、你该覆盖哪几种、优先级怎么排。判据全部来自用户行为。

这一篇问的是另一个问题：这几种写法在模型内部长什么样。判据不来自用户，来自那本词表。

两个问题的答案可能冲突，而冲突恰好是这篇最有价值的部分——用户最爱打的那个写法，未必是模型最认得的那个写法。后面有一整节讲这个冲突怎么处理。

另外要跟上一篇量整段文本的token膨胀 (https://zhangwenbao.com/minor-language-llm-token-inflation-cost.html)划开。那篇算的是成本和容量，是量的问题；这篇算的是一个名字的完整性，是形的问题。同一本词表，量整段字决定你花多少钱，量一个名字决定机器认不认得你。

## 数据源为什么用维基数据

要量“品牌名在各语言里的写法”，第一个问题是写法从哪儿来。自己翻译不行，我不懂那些语言；找译者成本太高而且不可复现。

最后用的是维基数据的实体接口 (https://www.wikidata.org/wiki/Special:EntityData/Q20718.json)。每个实体有一组多语言标签，由各语言社区自己维护，一个实体编号就能把几十门语言的官方写法一次拿全。

这份数据的好处是它反映的是各语言社区的共识写法，不是某个人的翻译；坏处是它偏向百科式的正式写法，跟商业场景里的实际用法可能有出入。

所以下面所有的数只能用来看结构和量级，不能直接当成你自己品牌的答案。你自己的品牌得自己测，方法在最后一节。

## 选了哪些品牌和哪些品类词

品牌取了14个：三星电子、耐克、宜家、阿迪达斯、丰田、华为、小米、亚马逊、Zara、奈飞、索尼、飞利浦、IBM、雀巢。挑的标准是全球知名度高、各语言都有正式写法、覆盖不同的品类和不同的原产地。

品类词也取14个，全是电商里最常见的：手机、鞋、洗衣机、咖啡、电视、冰箱、背包、手表、吸尘器、空调、笔记本电脑、耳机、太阳镜、信息技术。

语言选了39门，跟上一篇那70门语言是同一份清单的子集——只留了维基数据里标签齐全的那些。

切分工具还是tiktoken (https://github.com/openai/tiktoken)，词表用o200k_base那一代，同时记录每个名字被切成几块、其中几块是不完整的字节。

## 先看一个最简单的例子

Nike这四个字母，在英语里是一个token。整个名字就是词表里的一个条目，模型读到它的时候，那是一个不可再分的东西。

俄语维基里这个品牌的标签写的也是Nike，希腊语同样。这两门语言直接保留了拉丁原名，所以在词表里同样是一个块。

换成本地文字之后：日语ナイキ3块、韩语나이키3块、中文耐克2块、泰语ไนกี้3块、印地语नाइकी3块。

老挝语ໄນກີ້，5个字符，切成9块，其中8块是半个字节。阿姆哈拉语ናይኪ，3个字符，切成6块，6块全是字节碎片。

## 四个字母对九个碎片，这个对照说明什么

一个名字被切成几块，直接决定了模型处理它时的“完整性”。一个块意味着这个名字在模型内部有一个独立的表示；九个字节碎片意味着它得靠上下文把这九块拼回一个概念。

拼得回来吗？大部分时候拼得回来，模型见过足够多的老挝语文本。但拼这个动作是有成本的，而且在上下文不足的时候会拼错。

更直接的后果是匹配。当你要模型“把文中所有出现的品牌名替换成标准写法”，它对一个整块的匹配是确定的，对九个碎片的匹配是概率的。

这就是为什么同一条指令在英语上百分之百执行到位，在老挝语上偶尔漏掉几处——不是模型偷懒，是那个名字在它眼里本来就不是一个明确的边界。

## 整块率：一个名字被切成一个块的比例是多少？

## 拉丁字母32.8%，非拉丁4.8%

把14个品牌在每门语言里的写法逐个数，统计其中有多少个是“一个块”，这个比例我叫它整块率。

13门拉丁字母语言的品牌名整块率平均是32.8%。26门非拉丁语言是4.8%。

英语最高，42.9%——14个品牌里有6个是完整的一个token。德语和法语27.3%，西班牙语33.3%，斯瓦希里语和约鲁巴语50%（这两门的样本少，标签不全，参考价值有限）。

非拉丁那一侧：希腊语37.5%、格鲁吉亚语22.2%、亚美尼亚语10%、波斯语8.3%、韩语8.3%、乌克兰语11.1%。

剩下19门语言是0.0%。一个都没有。

## 整块率为零的那19门语言

完整名单：保加利亚语、塞尔维亚语、蒙古语、希伯来语、阿拉伯语、乌尔都语、日语、简体中文、泰语、老挝语、高棉语、缅甸语、印地语、孟加拉语、泰米尔语、泰卢固语、马拉雅拉姆语、僧伽罗语、阿姆哈拉语。

这份名单里有一个细节值得注意：阿拉伯语和简体中文也在里面。这两门语言在上一篇的token膨胀表里表现相当好——阿拉伯语1.38倍、简体中文1.25倍，都比德语便宜。

也就是说，整段文本便宜，和单个名字完整，是两回事。一门语言可以在成本上占优，同时在专名的完整性上全军覆没。

原因是词表里存的整块是按频率来的，而常见的整块基本都是这门语言的高频功能词和常用词根，品牌名这种专名的频率永远排不上。拉丁字母语言之所以还有三成整块率，是因为那些品牌名本来就是拉丁字符串，蹭到了英语词表的位置。

这条机制本身有专门的研究，《语言模型的tokenizer在语言之间制造了不公平》 (https://arxiv.org/abs/2305.15425)量的是整段文本的成本，专名的完整性是同一个机制在另一个侧面的表现。

## 为什么这个比例比token数更值得看

token数会随词表换代改善，这一点上一篇量过，印度诸语两代下来省了将近九成。

整块率不会。它取决于这个具体的字符串有没有单独拿到一个位置，而品牌名的频率在整份训练语料里是极低的，扩容多少代都轮不到它。

所以这两个数的性质不同：一个是会好转的成本项，一个是结构性的、基本不变的属性。做长期决策的时候要分开对待。

另一个原因是它更接近你真正关心的问题。你关心的不是这个名字花多少钱，是模型认不认得它、会不会拼错它、能不能在答案里正确提到它。整块率跟后面这几件事的关系更直接。

## 英语的42.9%意味着什么

反过来看英语这一头也有信息量。14个品牌里有6个在词表里是独立条目，说明这些品牌名在训练语料里出现的频率高到足以单独占一个位置。

这是个很硬的门槛。要拿到一个位置，你的品牌名得在全网的英语文本里频繁到跟常用词一个量级。

换句话说，词表里有没有你的名字，本身就是一个品牌知名度的读数，而且是全球口径的、无法用预算买到的那种读数。

这个读数还有个副作用：已经拿到位置的大品牌，在AI相关的每一个环节都比后来者更稳。它的名字不会被拼错，不会被切错，不会在长上下文里被拆散。这是一层没人讨论过的先发优势。

## 品类词比品牌名更惨吗？

## 35门语言的品类词整块率是零

同一套方法量14个品类词，结果比品牌名更极端。

英语21.4%——mobile phone、shoe这类词里只有三个是完整一块，其余都要拆成两块以上。德语7.1%，法语、西班牙语、葡萄牙语、意大利语、荷兰语、波兰语、土耳其语全部是0.0%。

39门语言里，品类词整块率为零的有35门。只有英语、德语、日语、简体中文这四门不是零，而后两门也只有7.1%。

这个结果第一眼看着奇怪：品类词是高频词，为什么反而比品牌名更碎？

## 因为品类词往往是两个词

答案在样本本身。“手机”在多数语言里不是一个词，是一个词组：mobile phone、мобильный телефон、โทรศัพท์เคลื่อนที่、هاتف محمول。

词组必然拆，因为词表存的是词不是短语。所以品类词的整块率低不完全是语言的问题，一部分是概念本身的问题。开放词表建模那份综述 (https://arxiv.org/abs/2112.10508)把这个折中讲得很清楚：词表必须在“整块查得快”和“罕见词也能拼出来”之间取舍，取舍的结果就是常见的进整块、罕见的拆片段。

但真正的差别在拆成几块。英语的mobile phone是2块，俄语4块，希腊语7块，泰语6块，缅甸语10块，老挝语22块，阿姆哈拉语13块。

而老挝语那22块和阿姆哈拉语那13块里，几乎全是字节碎片——不是“把词组拆成两个词”，是“把每个字拆成两三截”。

## “手机”这一个词，十七门语言的切法

用一个具体的词把上面的抽象说法落地。手机是电商里最通用的品类词之一，各语言都有稳定的说法。

英语mobile phone切成2块，正好是两个词。德语Mobiltelefon是个复合词，也是2块，切在Mobil和telefon之间。

俄语мобильный телефон 4块，阿拉伯语هاتف محمول 4块，孟加拉语4块，印地语5块，泰米尔语5块，格鲁吉亚语6块，泰语6块，希腊语7块，僧伽罗语8块，缅甸语10块。

日语携帯電話4个字切成3块，韩语휴대 전화5个字符3块，中文4个字3块。这三门语言的表现明显好于同为非拉丁的南亚诸语。

然后是两个离群值。阿姆哈拉语ነፋስ ስልክ，7个字符，13块，其中12块是字节碎片。老挝语ໂທລະສັບມືຖື，11个字符，22块，22块全是字节碎片。

把最好和最差摆在一起：英语2块，老挝语22块。同一个概念，同一个日常品类，在模型内部的表示复杂度差11倍。而这个词是那门语言的电商站上出现频率最高的词之一。

## 一张关键词表的总账

把14个品类词的平均值折成一张500词的关键词表，账是这样的。

语言 | 平均每词 | 500词表的token数 | 相当于英语 | 

英语 | 2.3 | 1142 | 1.00倍 | 

荷兰语／简体中文 | 3.2 | 1607 | 1.41倍 | 

德语 | 3.5 | 1750 | 1.53倍 | 

日语 | 3.7 | 1857 | 1.63倍 | 

俄语／希伯来语 | 4.4 | 2214 | 1.94倍 | 

阿拉伯语 | 4.5 | 2250 | 1.97倍 | 

泰语 | 5.2 | 2576 | 2.25倍 | 

希腊语 | 6.3 | 3136 | 2.74倍 | 

僧伽罗语 | 6.9 | 3437 | 3.01倍 | 

缅甸语 | 7.6 | 3818 | 3.34倍 | 

阿姆哈拉语 | 8.2 | 4083 | 3.57倍 | 

老挝语 | 18.2 | 9100 | 7.96倍 | 

这张表最实用的读法是：如果你的流程里有“把整张词表塞进提示词让模型对照着改”这一步，最后一行那门语言的这一步单次要花掉英语的八倍。

而且9100个token的词表加上正文和指令，在不少配置下已经开始挤了。挤的时候框架静默截断，截掉的是词表尾巴——按重要性倒序排的话，尾巴上正好是长尾词。

## 希腊语那个2.74倍是个警告

表里有一行容易被跳过：希腊语每词6.3个token，比僧伽罗语只低一点，比泰语还高。

希腊语在上一篇整段文本的膨胀表里是2.14倍，已经偏高；到了单个词这一层变成2.74倍，恶化了。

这说明整段文本的倍数和词表的倍数不是一个数，而且可以不同向。整段文本里有大量高频功能词能拿到整块，把平均值拉下来；纯词表没有功能词，全是实词，平均值就上去了。

所以拿整段文本的倍数去估词表的成本会系统性偏低，多数语言偏低两到四成。要估词表，就用词表量。

## 碎片率：哪几门语言的名字是靠字节拼出来的

整块率看的是“有没有一步到位”，还有一个更狠的指标：这些块里有几块根本不是字。

把14个品牌名在每门语言里切出来的块加总，数其中有多少块单独拿出来不构成一个合法字符，这个比例叫碎片率。

老挝语91.5%——59个字符切成106块，其中97块是半个字节。阿姆哈拉语100.0%——15个字符切成30块，没有一块是完整的字。

然后是一个我没预料到的数：简体中文的品牌名碎片率是20.0%，比泰米尔语的20.6%只低一点点，比缅甸语的0.0%和高棉语的0.0%都高。

原因是品牌译名用的汉字组合不是日常高频组合。“雀巢”“奈飞”“宜家”这类译名在通用语料里的频率，远低于同样两个字的常用词，于是拿不到整块，只能按字节拼。

这条推翻了我开工前的一个隐含假设：中文因为单字信息密度高，专名应该比较稳。实测下来中文的专名跟印度诸语一个量级。

## 同一门语言里，品牌名和品类词的碎片率不一样

还有一组对照值得单独看：同一门语言，品牌名和品类词的碎片率往往差很多。

日语品牌名5.6%，品类词15.4%。简体中文品牌名20.0%，品类词13.3%。高棉语品牌名0.0%，品类词24.0%。乌尔都语品牌名0.0%，品类词4.8%。

方向不统一，说明这不是语言的属性，是具体字符串的属性。哪一串恰好在词表里有位置，是训练语料决定的，没有规律可循。

实操上的含义是：别用一门语言的一个测量结果去推这门语言的其他词。要知道某个词的处境，就测那个词，成本是几秒钟。

这也是为什么这篇给的方法比给的数字重要。我的14个品牌不是你的品牌，我的数字对你只有参照价值，方法才是能直接拿走的。

## 转写成本地文字那一下，代价到底是多少？

## 同一个品牌，两种写法各数一遍

这一节是整篇最能直接落到决策上的一段。做法很简单：拿同一个品牌，把它的拉丁原名和各语言的本地转写各切一遍，比块数。

语言 | 拉丁原名 | 本地转写 | 块数对比 | 

俄语 | Nike＝1块 | Найк | 3块（3倍） | 

希腊语 | Nike＝1块 | Νάικι | 4块（4倍） | 

日语 | Nike＝1块 | ナイキ | 3块（3倍） | 

韩语 | Nike＝1块 | 나이키 | 3块（3倍） | 

泰语 | Nike＝1块 | ไนกี้ | 3块（3倍） | 

印地语 | Nike＝1块 | नाइकी | 3块（3倍） | 

泰米尔语 | Nike＝1块 | நைக் | 2块（2倍） | 

阿拉伯语 | Nike＝1块 | نايكي | 3块（3倍） | 

希伯来语 | Nike＝1块 | נייקי | 3块（3倍） | 

格鲁吉亚语 | Nike＝1块 | ნაიკი | 4块（4倍） | 

缅甸语 | Nike＝1块 | နိုက်ကီ | 5块（5倍） | 

僧伽罗语 | Nike＝1块 | නයික් | 3块（3倍） | 

老挝语 | Nike＝1块 | ໄນກີ້ | 9块，8块是字节 | 

阿姆哈拉语 | Nike＝1块 | ናይኪ | 6块，全是字节 | 

规律很整齐：转写一次，块数变成2到9倍，而且完整性从“一个不可分的东西”降到“一串需要重新拼装的片段”。

## 三星电子那个更夸张的例子

品牌名短的时候差距还不明显，名字一长就摊开了。

Samsung Electronics在英语里19个字符，2块（Samsung一块，Electronics一块）。日语サムスン電子6个字符5块，中文四个字2块，韩语4个字3块。

泰语ซัมซุง อีเลคทรอนิคส์，20个字符，12块。缅甸语32个字符，19块。孟加拉语21个字符，11块。泰米尔语22个字符，14块。

老挝语ຊຳຊຸງ ເອເລັກໂຕຣນິກ，18个字符，34块，其中33块是字节碎片。

英语2块，老挝语34块。同一个公司的名字，同一个意思，在模型内部的表示复杂度差17倍。

## 这些数字该怎么用

先说不该怎么用：不要拿它当成“别转写”的证据。转写与否首先是市场问题，用户打得出来、看得懂、认得出，这三条比块数重要得多。

该用的地方是当你已经决定要两种写法并存的时候——多数小语种市场都是这个情况——用它来决定哪一种写在哪儿。

具体判据是：希望被机器准确识别的位置用整块那一版，希望被人搜到看到的位置用用户实际会打的那一版。这两个位置在页面上是可以分开的。

本站写结构化数据那篇 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)给过一个同构的结论：正文越本地化越好，标记里却要反着写回国际格式。这里是同一条原则的又一个实例，只是这次的消费方从搜索引擎换成了模型。

## 同一个品牌的两种写法，在模型里有没有共同的块？

## 236组比较，207组交集为空

上一节比的是块数，这一节比的是块本身。

做法是：拿每个品牌的拉丁原名切出一组token编号，再拿它在某门非拉丁语言里的写法切出另一组，求交集。

14个品牌乘上各语言，一共236组有效比较。其中207组的交集是空的，占87.7%。

交集为空的意思是：这两串字符在模型内部没有共享任何一个表示单元。它们不是“同一个东西的两种写法”，是两个从零开始的字符串。

## 剩下那12.3%是怎么回事

有交集的那29组，绝大多数是因为该语言的维基标签本身就保留了拉丁原名——比如俄语和希腊语的Nike条目。那当然有交集，因为它们本来就是同一串字符。

剩下极少数是巧合：转写后的某个字节组合恰好跟拉丁原名的某个片段撞到了同一个编号。这种撞车没有语义含义，纯属编码层的偶然。

所以更准确的说法是：只要真的转写了，交集就是零。没有例外。

这个结论看起来是废话——不同字符集当然不共享编码。但它的推论不是废话：任何依赖字符串相似度的机制，在跨写法的品牌名上都会完全失效，包括模糊匹配、编辑距离、前缀匹配、向量之外的一切浅层方法。

## 搜索引擎那一侧有兜底，这一侧没有

同样的问题在搜索引擎那边早就存在，但那边有几层兜底：实体库把不同写法挂在同一个实体上、同义词表可以手动配、用户的点击行为会把它们关联起来。

词表这一层什么兜底都没有。它是纯粹的字符串到编号的映射，不认识实体，不认识同义词，也不学习。

模型本身当然知道Nike和ナイキ是同一个品牌——那是它在训练中学到的语义知识，存在参数里，不在词表里。但这层知识的可靠性远低于词表层的确定性，而且在冷门语言上会明显减弱。

判断方法很直接：拿你的品牌名的两种写法分别问模型同一个问题，看回答的内容和详细程度差多少。差得越多，说明这层语义关联在这门语言上越弱。

## 同一个词在标题里和在句子中间，是同一串块吗？

## 英语的答案是“是”，而这正是问题所在

量品类词的时候我撞见一个更细的现象，它比整块率更容易被忽略。

拿英语的phone试：单独写是1块，前面加个空格还是1块，放句子中间1块，放句首1块。四种情况完全一致。德语的Telefon、波兰语的telefon，也是四种全一致。

之所以这么稳，是因为词表把带前导空格的版本单独存了一份。英语是空格分词的语言，这个设计对它极其友好——一个词无论出现在哪儿，模型看到的都是同一个编号。

问题在于，所有关于“关键词要不要精确出现”的直觉，都建立在这个稳定性成立的前提上。而这个前提只对英语和几门主要拉丁语言成立。

## 俄语和阿拉伯语的答案是“不是”

俄语的телефон：单独写2块，前面加个空格变1块。阿拉伯语的هاتف：单独写2块，加空格1块。泰米尔语的கைபேசி：单独写5块，加空格4块。

也就是说，同一个词出现在句子中间和出现在一个列表项的开头，模型收到的是两串不同的编号。字符完全一样，编号不一样。

数值上不大，一两个块而已。但它打破的是一个默认假设：同一个词在页面的不同位置是同一个东西。

在英语上这个假设成立，所以没人验过它。在小语种上它不成立，而同样没人验过它。

## 老挝语反过来，加空格反而更碎

老挝语的ມືຖື更奇怪：单独写8块，前面加空格变成9块。方向是反的。

原因是老挝语在词表里几乎没有整块，所有组合都靠字节拼。加一个空格改变了字节边界，反而把原来能拼在一起的两个字节拆开了。

这类现象在字节回退占主导的语言上会经常出现，没有规律可循——它取决于那本词表里恰好存了哪些字节组合。

所以对这一档语言，任何关于“这个词值几个块”的说法都必须带上下文。我做实验时吃过这个亏：第一版脚本把词单独编码计数，得出的表跟真实文本里的表现对不上。

## 这件事会在哪几个位置真的咬到你

第一处是提示词里的关键词清单。清单通常一行一个词，每个词都在行首，行首那个位置的编码跟正文里的不一样。

第二处是少样本示例。你给模型看几个例子让它照做，例子里的词和正文里的词如果编码不同，示例的效果会打折。

第三处是结构化输出。让模型返回JSON，字段值里的词被引号包着，引号改变了边界，跟正文里的编码又不一样。

第四处最隐蔽：锚文本那一层本来就有变形问题 (https://zhangwenbao.com/minor-language-internal-link-anchor-inflection-variants.html)，屈折语里一个词进句子就要变格。变格已经让字符串对不上了，编码层又加了一次不对齐，两层叠在一起，“精确匹配”这个概念在小语种上基本失去意义。

## 名字碎成一堆之后，具体哪几件事会变差？

## 指令执行的确定性下降

最直接的一处是替换类指令：把文中所有品牌名统一成标准写法、把所有型号加上前缀、把某个词全部替换掉。

这类任务在整块的名字上接近百分之百，在碎片化的名字上会漏。漏的方式还很讨厌——不是整段漏，是十处漏一两处，抽查很容易抽不到。

为什么会漏？因为模型要先从一串字节碎片里还原出“这是一个专名”，这一步是概率的。上下文清晰的时候还原得准，上下文短的时候就未必。

所以症状会集中在标题、属性值、按钮文案这类短文本上——正好是最赚钱也最容易被机器认错的那几类字段 (https://zhangwenbao.com/minor-language-page-language-detection-misidentification-short-text.html)。

## 生成时的拼写稳定性下降

第二处是让模型自己写出这个品牌名。整块的名字它只能写对，因为那是一个不可分的输出单元。碎片化的名字它是一块一块拼出来的，中间有出错的空间。

实际表现是偶尔多一个元音符号、少一个声调记号，或者用了另一种合法但不是你规定的转写。这类错误母语者一眼能看出来，不懂那门语言的人完全看不出来。

这也解释了一个常见现象：AI写的小语种文案里，品牌名的写法在同一篇里就会前后不一致。不是模型不认真，是它每次拼装的结果有随机性。

破法是把品牌名从生成环节里拿掉——用占位符生成，生成完之后本地替换。这样模型压根不需要写出那个名字。

## 被引用时的名字准确度下降

第三处影响最难量化，但可能最要紧：AI回答里提到你的品牌时，写出来的是哪一种写法、写没写对。

如果你的名字在这门语言里是碎片化的，模型倾向于用它更有把握的那个写法——通常是拉丁原名，因为那是一个整块。

这件事有好有坏。好处是拉丁原名的写法更稳定；坏处是如果你的本地化策略是主推本地写法，模型会持续输出跟你的策略不一致的那一版。

这一层跟你的语种有没有被AI答案覆盖到 (https://zhangwenbao.com/ai-overviews-100-countries-six-languages-minor-language-citation.html)是两个问题，得先过了覆盖那一关，这一层才有意义。

## 跨语言的品牌监测会数不准

第四处是报表侧。要统计品牌在各语言内容里的提及次数，脚本按字符串匹配数，而各语言的写法互不相同。

这件事本身不新鲜，做多语言监测的人都知道要建别名表。新的部分是别名表要建到什么颗粒度——如果模型输出的写法带随机性，别名表就得覆盖变体，而变体是列不完的。

相对可行的做法是反过来：不数写法，数上下文。在一段文本里找“这个品牌所在的语义位置”，而不是找那个字符串。这需要另一套工具，成本高很多。

低成本的折中是接受误差，但把误差按语言标出来——整块率高的语言数得准，整块率为零的语言数出来的数偏低，报表里注明这一点，别拿两个数直接比。

## 本地化流水线里最先出问题的那一步

把上面几件事串起来看，会发现它们集中爆发在同一个位置：批量处理。

单篇人工把关的内容不会出问题，人一眼就能看出品牌名写错了。出问题的是那些一次处理几百条、没人逐条看的环节——商品标题批量改写、属性值批量翻译、描述批量生成。

这些环节的共同点是量大、单条价值低、没有逐条验收。而它们恰好是最依赖“模型能准确识别这个名字”的环节。

所以排查的顺序应该反过来：不是先查内容质量，是先查这条流水线上有没有一步依赖模型识别专名。有，就把那一步单独拎出来加一道显式对照。

## 那到底该保留拉丁原名还是转写？

## 先承认两个口径会打架

用户口径的答案在本站早就给过：看当地人实际打什么，多数非拉丁市场里本地写法的搜索量更高。

机器口径的答案正相反：拉丁原名是一个整块，本地写法是一堆碎片。

两个口径打架的时候，先别急着选一个。它们对应的是页面上不同的位置，而位置是可以分开的。

本站写地名的本地名与外来名 (https://zhangwenbao.com/minor-language-place-name-endonym-exonym-search.html)时用过同一套思路：不是二选一，是判断每个字段的消费方是谁，然后按消费方填。

## 按位置分的一张表

位置 | 写哪一版 | 理由 | 

标题、H1、正文首段 | 用户实际打的那版为主，拉丁原名并列一次 | 这里的消费方是用户和搜索引擎 | 

正文其余部分 | 本地写法 | 可读性优先，模型有上下文可用 | 

结构化数据的name字段 | 本地写法 | 跟页面主体一致 | 

结构化数据的替代名字段 | 拉丁原名必填 | 给机器一条确定的锚 | 

图片替代文本、文件名 | 拉丁原名 | 文件名本来就只能拉丁 | 

喂给模型的提示词与术语表 | 拉丁原名为主键，本地写法作值 | 主键要整块才稳 | 

数据源与平台字段 | 按平台要求，通常拉丁原名 | 跨市场对齐优先 | 

这张表的核心思路只有一句：给人看的地方按人的习惯写，给机器当锚点的地方留一个整块。

## 替代名那一格具体怎么填

结构化数据里有个专门放别名的字段，schema.org的alternateName (https://schema.org/alternateName)，多数站都空着。

这一格是成本最低、收益最直接的一处改动：把品牌名的所有写法都列进去，拉丁原名、本地转写、常见的错误写法各一条。

它不影响页面显示，不影响用户体验，改一次管很久。而它给出的是一条明确的“这几串字符指同一个东西”的声明，而这正是词表那一层给不了的东西。

本站写缩略语那篇 (https://zhangwenbao.com/minor-language-acronym-initialism-local-forms-inflection.html)里说过同一件事：一个概念在这门语言里有几种形态，词表要单独立一层。替代名字段就是那一层在页面上的落点。

## 什么时候应该只用拉丁原名

有几种情况可以不纠结，直接全用拉丁原名。

一是品牌名本身是无意义的生造词，转写过去在当地也没有含义，转了只是增加一种写法要维护。

二是目标用户的键盘上打拉丁字母比打本地文字更顺手，这在几个市场是真实存在的。

三是你的品类本身是技术类或者奢侈品类，这两类的用户天然接受拉丁原名，甚至更信任拉丁原名。

反过来，快消、日用、母婴这几类，本地写法几乎是必须的——用户不会打拉丁，而且拉丁写法会显得这个牌子跟自己没关系。

## 不懂这门语言，怎么自己测一遍自己的品牌名？

## 二十分钟能跑完的最小测试

整套流程不需要懂那些语言，只需要拿到你自己品牌名的各语言写法。

准备三样东西：你的品牌名清单（拉丁原名加各语言写法）、一个tokenizer库、一台能跑Python的电脑。

输出是一张表，每行一个语言，四列——写法、字符数、块数、其中几块是字节碎片。这里的“字符数”指的是Unicode码点数，不是UAX #29定义的字素簇 (https://www.unicode.org/reports/tr29/)——对天城文、孟加拉文这类文字，两个数会差不少，报数的时候要说清用的是哪一个。

核心代码就是编码一次取长度，加上逐个token试解码判断是不是完整字符。整个脚本不到三十行。

## 各语言写法从哪儿来

最可靠的来源是你自己的本地团队或者经销商实际在用的写法。他们写在合同、发票、社媒账号名上的那一版，才是这个市场真正流通的写法。

没有本地团队的话，退而求其次是搜索建议——把拉丁原名打进去，看引擎给出的本地写法建议。这条路本站讲工具返回零怎么补数据 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)时详细写过。

再退一步是维基数据，也就是我这次用的源。它的写法偏正式，但至少是社区共识，不是某个人拍脑袋定的。

三个来源如果给出不同的写法，那本身就是个发现——说明这个市场里你的品牌名还没收敛，这比块数重要得多。

## 结果怎么读成动作

块数1到3、零字节碎片：不用管。这个名字在模型里是稳的。

块数4到8、字节碎片少于一半：可以用，但要在结构化数据的替代名字段里补上拉丁原名，并且在提示词里用拉丁原名做主键。

字节碎片超过一半：这个写法不适合当任何自动化流程的锚点。生成环节用占位符，替换环节用本地脚本，监测环节按上下文数而不是按字符串数。

三档的分界线不精确，你可以按自己的容错度挪。重点是这张表最后必须变成三种不同的做法，而不是一列数字。

## 顺手多测两样

测品牌名的时候，顺手把两样东西一起测了，成本几乎为零。

一是你的核心品类词。品类词的块数决定了关键词表的整体成本，也决定了模型能不能准确识别品类边界。

二是你的型号和SKU编码。这一类通常是字母加数字的混合串，切出来往往比想象中碎，而它们在商品页上出现的密度非常高。

三样加起来一次跑完，得到的是一张属于你自己的对照表。这张表建议存进内容规范里，因为它一两年不会变。

## 三种看着稳妥、实际会留后患的做法

## 为了让块数好看，去改品牌的本地写法

第一种是过度反应。看到本地写法碎成九块，就想换一个切得整齐一点的写法。

这个方向是错的。品牌名的写法首先要用户认得、打得出、念得顺，块数在这三条面前排不上号。

而且换写法的成本远高于块数带来的收益——已有的外部提及、经销商物料、社媒账号全部要跟着动，而外部世界怎么写你的名字，你本来就管不了 (https://zhangwenbao.com/brand-name-transliteration-loanword-minor-language-search.html)。

正确的做法是接受碎片，然后在流程上绕开它：主键用拉丁原名，生成用占位符，替代名字段填全。

## 把整块率当成语言优先级的判据

第二种是把这个数用错了地方。19门语言整块率为零，很容易被读成“这19个市场不适合做”。

这个推论有两个问题。一是整块率反映的是这个具体名字的处境，不是这个市场的价值。二是整块率低的语言往往就是竞争最稀薄的语言，两件事由同一个原因决定。

本站最早那篇算优先级的文章 (https://zhangwenbao.com/minor-language-seo-priority-language-cost-model.html)说过，按单一指标排序，第一年一定会做反。这一条是同类的错，只是指标换了一个。

整块率的正确用途是决定“在这门语言上要不要多做一层防护”，不是决定“做不做这门语言”。

## 假设模型知道两种写法是同一个品牌

第三种最隐蔽，因为它在多数时候是对的。

模型确实知道Nike和ナイキ是同一个品牌，这层知识存在参数里。但这层知识的强度跟这门语言的语料量正相关，在冷门语言上会明显减弱。

而你没法直接观测这层强度。它不报错，只是在某些查询上答得薄一点、在某些替换上漏一处。

能做的是别把它当成保证。任何依赖“模型会自己关联起来”的流程，都该在小语种上加一道显式的对照——把两种写法在提示词里明确并列一次，成本几个token，收益是把概率变成确定。

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

品牌名在这门语言里该怎么转写、用户实际打哪一种，不归这一层，那是用户行为的问题。

商标能不能注册、有没有跟别人的商标撞车，不归这一层，那是法律的问题。

页面上品牌名的排版、字体缺字形、大小写折叠，不归这一层，那是字形集和字体文件 (https://zhangwenbao.com/minor-language-web-font-glyph-set-first-screen-cost.html)的问题。

这一层只管一件事：这个名字进模型之后，还是不是一个东西。它决定的是自动化流程的可靠性，不决定这个名字好不好。

## 常见问题解答

## 换一家模型厂商，整块率还是这个样子吗？

绝对数会变，结构不变。各家的词表规模和构成不同，某些品牌在这家是整块、在那家是两块，这种个案差别很常见。但“拉丁字母语言的整块率明显高于非拉丁”这条结构性结论，在任何一家的词表上都成立，因为它由训练语料的语言构成决定，不由某一家的工程选择决定。要用在具体决策上，最稳妥的做法是拿你实际在用的那家的分词库重跑一遍，改一行代码的事。有一种情况值得单独测：如果某家厂商在某个区域市场投入很大，它的词表可能对那几门语言做过专门优化，这种优化不会写进公告，只能靠实测发现。

## 品牌名碎成一堆，会影响搜索引擎收录和排名吗？

不会。搜索引擎的分词和索引走的是完全另一套机制，跟模型的词表没有关系。你的页面在搜索里的表现只跟内容、结构、外链这些老因素有关，不会因为品牌名在某个模型的词表里碎成九块而变差。会受影响的是所有经过大模型的环节：AI答案里的提及、AI改写的准确度、站内AI客服的识别、批量处理脚本的可靠性。所以判断这件事要不要管，先看这些环节在你的流程里占多少分量。如果一个都没用上，这篇对你的实际价值就只有一条：结构化数据的替代名字段填一下，几分钟的事，早晚用得上。

## 结构化数据的替代名字段填了，模型真的会读吗？

读不读取决于内容进模型的路径。如果是通过检索管线拿到你的页面，结构化数据通常会被一起提取，替代名那几串字符会跟着进上下文，这时候它是有用的。如果是模型凭训练时记住的知识回答，那这个字段不起作用，起作用的是你的品牌名在训练语料里出现过多少次、以什么写法出现。所以这个字段的价值在于覆盖前一种路径，而前一种路径正是内容更新之后能最快见效的那一条。填它的成本很低，不确定性主要在收益侧，这个投入产出比在我看来是划算的。另外它对搜索引擎那一侧也有明确用途，那部分收益是确定的。

## 我们的品牌名是纯英文，是不是就没这个问题了？

问题小很多，但没有完全消失。纯英文品牌名如果知名度够高，在词表里可能是一个整块，那确实很稳。如果是新品牌或者生造词，它在词表里同样没有位置，会被拆成几块，只是拆出来的都是拉丁字母片段，不会退到字节级。实际影响是拼写稳定性——生造词模型容易拼错，尤其是那种故意省元音或者双写辅音的写法。测一下就知道：把品牌名单独编码，看是不是一块。如果不是一块，在提示词里给个明确的拼写示例，能省掉不少返工。至于要不要为了整块去改名字，那显然不值得，知名度上来了自然就有位置了。

## 型号和SKU这类编码，情况一样吗？

更碎。字母数字混合串在词表里几乎不可能有整块，因为它们的组合是无穷的。一个像XR-2400W这样的型号，切出来通常是四到六块，而且切法跟前后有没有空格、有没有连字符强相关。这带来两个实际问题：一是模型抄型号容易抄错，尤其是数字部分；二是让模型从一段文本里提取所有型号，召回率会明显低于提取品牌名。破法是在需要精确的场景里别让模型碰型号，用正则提取或者占位符替换。这一条在多语言场景下没有额外恶化——型号本来就是拉丁字符，各语言一视同仁，算是这堆麻烦里少见的好消息。

## 这套测量多久重跑一次？

品牌名清单变了就重跑，否则一两年跑一次就够。词表换代的时候值得重跑一遍，但对品牌名这类低频字符串，换代带来的变化通常很小——扩容出来的新位置会分给高频组合，专名依然排不上。真正需要重跑的时机有两个：一是你进了新市场，多了一种写法；二是你换了模型厂商。第一种只需要跑新增的那几行，第二种要全表重跑。跑完把新旧两版并排，重点看有没有哪个写法从整块变成了碎片，那种情况虽然少见但会影响已经上线的流程。

## 权威参考资料



## 语言代码注销了385个，其中七成不是消失，是并进了另一门语言

- URL：https://zhangwenbao.com/minor-language-code-retirement-macrolanguage.html
- 分类：小语种SEO
- 发布：2024-11-27  |  更新：2024-11-27
- 摘要：ISO语言代码十八年变更实测：385个注销里46%被合并、26%被拆开，仅19%是查无此语言；在册7921门中有两位码的只有184门。
- 关键词：多语言SEO,小语种SEO,出海建站,网站本地化

> **TLDR**：摘要：把ISO语言代码的全部变更记录从2006年翻到2024年，一共1423条申请、2250行变更。截到2024年底，累计有385个语言代码被注销，其中46%是被并进了别的语言、26%是被拆开，真正判定为查无此语言的只占19%。也就是说七成以上的注销不是消失，是换了地方，机械替换会把一门语言静默换成另一门。同时在册的7921门语言里，有两位代码的只有184门，2.32%。你在hreflang里最顺手的那种写法，覆盖不到在册语言的四十分之一。

> 摘要：把ISO语言代码的全部变更记录从2006年翻到2024年，一共1423条申请、2250行变更。截到2024年底，累计有385个语言代码被注销，其中46%是被并进了别的语言、26%是被拆开，真正判定为查无此语言的只占19%。也就是说七成以上的注销不是消失，是换了地方，机械替换会把一门语言静默换成另一门。同时在册的7921门语言里，有两位代码的只有184门，2.32%。你在hreflang里最顺手的那种写法，覆盖不到在册语言的四十分之一。

有个问题被问过太多次，答案却很少有人真的去查：挪威语在hreflang里到底该写no还是nb。

问的人一般会得到一个模棱两可的回复，大意是两个都行、看情况、随便挑一个别乱换。这个回复不算错，但它绕过了一件更根本的事——no和nb这两个代码，是被两个不同的机构、在两套不同的规则下、为了两件不同的事发出来的，它们之间的关系是被人写在一份文件里的，不是天然如此。

保哥今年秋天认真去翻了那份文件。准确说是翻了一整个库：ISO 639-3的变更申请库，从2006年这套体系上线那年开始，每一次新增、每一次改名、每一次合并、每一次拆分、每一次注销，都有一个申请编号、一份提案、一个生效日期，全部公开挂在网上。

翻完之后的感受不太好形容。你会发现自己一直当成常量在用的那串两三个字母，其实是一份有人受理、有人评议、有生效日期的行政档案。它会变，而且变过很多次。

下面这些数字全部截到2024年12月31日，口径是按结果生效日期算的，不是按申请年份。这个区别不是抠字眼——2021年提交的那份闽南语拆分申请，结果到2024年10月15日才下来，按申请年份截会把它整条丢掉。

## 这串语言代码到底是谁在维护？

先把角色理清楚，后面的数字才有落脚点。

## ISO 639不是一份标准，是好几份

很多人把ISO 639当成一份表，其实它长期是分册的：两位字母的那一份、三位字母那一份、覆盖更全的那一份、还有语系那一份，各管各的编号规则，各有各的维护机构。

2023年这几册被整合进了同一份标准，编号规则不变，但称呼变了。注册机构自己那页讲各分册关系的说明 (https://iso639-3.sil.org/about/relationships)现在写的是Set 3，不再写Part 3。

这件事对你没有任何技术影响，一个字母都不用改。但它是个很好的提醒：连这套编号体系本身的组织方式都会变，何况里面那些具体的代码。

顺带说一句，网上很多讲hreflang的文章还在按老称呼写，包括我自己早年写的那篇。称呼这种东西不影响正确性，但它能告诉你一份资料是哪年写的。

对做SEO的人来说，只需要记住一件事：你日常打交道的两位码来自其中一册，三位码来自另一册，两册的维护机构不是同一家，更新节奏也不一样。

## 三位代码的注册机构是一家做语言调查的机构

三位代码这一册的日常维护，交给了一家长期做少数语言田野调查的机构。它负责受理申请、组织评议、写裁决、每年发布更新后的码表。

这个安排解释了后面很多现象。受理方的知识背景是描写语言学和田野调查，所以它对一门语言够不够格的判断，几乎全部落在语言本身的证据上，跟这门语言在政治上、商业上有多重要基本无关。

它也解释了为什么这个库长这个样子：申请要写提案、要附参考文献、要接受公开评议，整个流程更像投一篇论文而不是提一个工单。

还有一点值得留意：受理方本身也在出版一份全球语言数据库，两套东西的语言划分高度一致。所以你在别的资料里看到的语言数量，很可能跟这份码表同源。

这不是问题，但它意味着你没法用那份数据库去交叉验证这份码表——它们本来就是一家出的，对上是应该的，对不上才奇怪。

## 一年只开一到两次门

把2250行变更按生效日期铺开，最扎眼的不是总量，是分布。2008年1月14日一天生效了409行，2012年2月3日一天231行，2013年1月23日一天202行。

再看每年有几个生效日：2019年全年只有1月25日这一天，2023年是1月20日和12月15日两天，2024年是4月3日和10月15日两天。

这意味着这张表不是随时在变的活水，而是一年开一到两次闸。你的语言代码对表工作，一年做两次就够了，做十二次是浪费。知道这一点，这件事就从一个隐忧变成了一个日程条目。

2011年更极端，全年只有5月18日一个生效日期。2019年也是，全年只有1月25日那一天。

## 为什么这件事值得SEO的人花半天

因为语言代码是少数几个能同时出现在你站上五六个不同位置的东西：页面的语言声明、hreflang的每一条、结构化数据里的语言字段、商品数据源的语言设置、分析报表的语言维度。

这几个位置分属不同的人维护，各自都以为自己写的是同一套东西。hreflang的完整用法 (https://zhangwenbao.com/international-seo-hreflang-complete-guide.html)那一层讲的是这些标签之间怎么互指，而这一层要回答的更靠前：你互指用的那串字符，本身还成立吗。

还有一个更实际的理由：这几处位置里，只要有一处写着已经注销的代码，排查起来的第一反应通常是怀疑代码写错了，而不是怀疑代码本身作废了。方向一错，半天就没了。

这个坑我自己踩过一次。当时一个站的某个语言版本在两个分析工具里的量差了接近一倍，查了两天配置，最后发现是其中一个工具按新代码归类、另一个还按老代码，而两个代码指的是同一批人。

## 在册的7921门语言，能写成两位码的有几门？

先给你一个数字，然后再解释它为什么让人别扭。

## 7921门在册，184门有两位码

翻开2024年10月那次变更生效之后的在册表，一共7921门语言。按类型拆：在用的7076门、已经灭绝的602门、历史语言215门、人造语24门、另有4个特殊代码。

然后数有两位代码的那一栏：184门。2.32%。

这个比例意味着，你在hreflang里写的那种两个字母的写法，能覆盖的语言不到在册语言的四十分之一。剩下那97.68%要么写三位码，要么根本没法在你的系统里被表示。

顺便说一句，这7921门里已经灭绝的有602门。做语言优先级的时候如果你的清单是从某个全量表直接拉的，记得先把这一栏筛掉，不然会算进一批没有活人在说的语言。

## 184门里还有35门是宏语言

更细一层：这184门里，有35门的范围标着宏语言，只有149门是个别语言。

宏语言是什么后面有一整节，这里先说结论：你写zh、ar、ms这几个最常见的两位码时，写的其实不是一门语言，是一个装着若干门语言的口袋。

再往细看，184门按语言类型拆是174门在用、5门历史语言、5门人造语。也就是说这份最短最好用的清单里，还挤着拉丁语这类没人日常说的语言，和世界语这类被造出来的语言。

不是说它们不该有代码。只是当你拿两位码当作重要语言的近似值时，这份名单的构成会让这个近似值偏得比你想的多。

反过来看也一样成立：有两位码的149门个别语言，是这套体系里被表示得最完整的一批。它们在几乎所有系统里都能被正确处理，而这恰恰是它们跟其余七千多门语言最大的差别。

## 两位码短缺不是历史遗留，是设计如此

有人会觉得这是历史包袱，早晚补齐。补不齐。两位字母一共只有676个组合，扣掉保留段和已用段，剩下的位置根本装不下七千多门语言。

RFC 5646定义的语言标签规则 (https://www.rfc-editor.org/rfc/rfc5646)里写得很清楚：有两位码的就用两位码，没有的用三位码。这条规则的存在本身就承认了两套编号会长期并存。

所以正确的心态不是等它补齐，而是从一开始就假定你的链路要同时吃两位码和三位码。这一点在做印度、非洲、东南亚市场时几乎必然会撞上。

这条规则还有一个不太直观的后果：同一门语言在不同的系统里可能被写成不同长度的代码，而两种写法都合规。你做数据对齐的时候，得先做一次归一化。

归一化的方向应该统一到三位码，因为三位码是全集，两位码是子集。反过来做会丢掉97.68%的语言。

## 这个数字对小语种选品意味着什么

做小语种优先级和成本测算 (https://zhangwenbao.com/minor-language-seo-priority-language-cost-model.html)的时候，有一个很少被写进模型的成本项：这门语言在你的技术栈里能不能被表示。

能不能表示不是玄学，它有具体表现——分析工具的语言维度里有没有这个选项、广告后台的定向里有没有、内容管理系统的语言下拉里有没有、翻译服务商的语言列表里有没有。

这几处的清单长度差别巨大。有的按两位码建，那你可用的就是184门；有的按三位码建，那才是七千多门那个数量级。先查你自己链路上最短的那一环，它决定了这门语言在你这里的天花板。

顺带一个观察：越是靠近内容生产端的工具，语言清单越长；越是靠近投放和分析端的工具，清单越短。所以卡住你的通常不是写不出来，是量不出来。

## 顺手可做的一次自查

找一个下午，把你站上所有出现过语言代码的位置列出来，逐个记下它用的是两位还是三位、允许填几位、填错会不会报错。

保哥帮一个做户外装备的独立站做过一次，一共找出七处，其中三处只接受两位码，两处三位两位都收但不做校验，还有两处的下拉框是几年前手工维护的，里面躺着两个早已注销的代码。

最后那两个代码后面会讲到，它们是这篇文章真正的主角。

这次自查还有个副产品：你会发现有几处位置压根就没有语言这个概念，比如某些老的商品导入模板。那几处不是写错了，是根本没设计过，属于另一类问题。

## 一个语言代码是怎么消失的？

先说结论：截到2024年底，累计有385个语言代码被注销。这个数字本身不算大，问题在注销的方式。

## 四种注销理由，比例完全不是直觉那样

官方的退役表把注销理由分成几类，逐条数下来：被并进别的语言177个占46%，被拆开102个占26%，判定为查无此语言72个占19%，重复登记33个占9%，另有1个是换了代码。

翻这张表之前，我估计查无此语言会占大头，理由很朴素——早年登记得粗，后来发现有些语言根本不存在或者是同一门语言的两个名字。

实测反过来了。真正判定为根本不存在的只有19%，而72%的注销属于它还在，只是换了地方。这一条打脸打得挺响，也正好是最有实际后果的一条。

这四类的比例这些年也没怎么变过。早期的注销里查无此语言的比例略高一些，后期几乎全是重新划界，符合一个逐渐成熟的登记体系应有的样子。

## 它还在只是换了地方，才是最难查的那种

为什么这个区别要紧？因为两种情况在你的系统里表现完全不同。

如果一个代码是因为查无此语言被注销的，你的页面拿它去声明语言，最坏结果是被当成未知语言忽略掉——难看，但不至于错到别人身上。

如果它是被并进另一门语言注销的，那这个代码背后的那批内容，从注销那天起在标准的口径下就属于另一门语言了。你还在按老代码分类、按老代码出报表、按老代码给用户匹配版本，而所有下游系统都已经按新代码理解它。

这种错不会报错。它表现为报表里某个语种的量莫名其妙掉下去、另一个语种莫名其妙涨上来，而两个数字都是对的。

更难受的是，如果你的站上有内容真的是用那门语言写的，那这批内容的语言标注从注销那天起就跟标准对不上了，而没有任何一个环节会告诉你。

## 三个能直接查证的例子

抽三个具体的看。第一个是Yinglish，代码yib，2007年7月18日被并进English，也就是eng。一门混合语被判定为不构成独立语言，归到了英语底下。

第二个是比利时手语，代码bvs，同一天被拆成两个：法语区的手语sfb和弗拉芒手语vgt。荷兰语和佛兰芒市场那道分界 (https://zhangwenbao.com/dutch-seo-netherlands-belgium-flemish-two-markets.html)在这里以一种很直接的方式重演了一次——语言的分界跟着语言社群走，而不是跟着国界走。

第三个最狠：孟加拉国的吉大港语，代码cit，被拆成罗兴亚语rhg和吉大港语本身，而留下来的那一半也换了新代码ctg。原来那个cit现在指向空气。

这三个例子分别对应三种典型：一门混合语被归到主语言底下、一门语言按社群边界被拆成两门、一门语言拆分后两半都换了新号。你自己那几门语言大概率能对上其中一种。

## 拆分是唯一会让两边都失效的操作

上面第三个例子指出了一条很反直觉的规律：合并的时候，老代码至少有一个明确去向；拆分的时候，按规则老代码必须整个退役，然后给拆出来的每一部分发新代码。

也就是说，如果你的表里存着一个后来被拆分的代码，你不能简单地把它换成拆出来的任何一个——因为你根本不知道这条记录当初指的是拆出来的哪一半。

102个被拆开的代码，每一个都是这样一颗需要人工判断的地雷。批量替换脚本在合并那一类上能跑，在拆分这一类上必须停下来问人。

还有一种更麻烦的情形：拆出来的几门语言里，有一门沿用了原来的名字。你的表里如果是按语言名而不是按代码存的，这时候名字对得上，代码却已经换了，两边各自都不报错。

## 2024年这一年注销了几个

给个近期的量级感受：2024年全年注销的代码只有2个。2023年是14个，2022年10个，2021年9个。

最猛的一年是2008年，注销83个。2016年39个，2015年25个，2012年27个。

所以这件事的节奏是：越早期的代码越危险，因为它经历过那几个大清理年份；2015年之后进表的代码相对稳定。你的词表里那些从十几年前的老项目继承下来的语言代码，才是要优先核的。

这条对老站尤其要紧。一个跑了十年的站，它的语言配置很可能是十年前建的，而那正好是注销最密集的那几年之后不久，中间又攒了两轮变更。

## 为什么代码退役总是扎堆在一月？

把385个注销按生效日期铺开，会看到一个很整齐的形状。

## 七成的注销发生在几个特定的日子

最集中的几天：2008年1月14日一天注销75个，2009年1月16日48个，2016年1月15日39个，2012年2月3日27个，2015年1月12日25个，2020年1月23日21个。

六天加起来235个，占全部注销的六成。剩下的散落在十几个别的日期上。

原因不神秘：这个库的工作节奏是按年的，一批申请集中受理、集中评议、集中裁决、集中生效。所以对表的最佳时机是每年一月底和年中各一次，正好卡在两个生效窗口之后。

还有一个更早的高峰：2007年7月18日一天生效了149行变更，那是这套三位码体系上线之后的第一次大规模整理。今天还能查到的很多老代码，都是那一天没了的。

## 一次批量整理长什么样

2018年提交的那批修改申请有88行，全部在2019年1月25日同一天生效。按语系拆，其中76行是澳大利亚语系；按地区拆，79行属于太平洋地区。

这显然不是八十几个人各自提了一份申请，而是某一次针对澳大利亚原住民语言的系统性梳理，一次性提交上来。

这类批量整理的特征是：修改的是名称和指称范围，不是代码本身。也就是说代码没变，但这个代码指的是什么变了。这种变更最容易被忽略，因为你的表里那一行字符串一个都没动。

这类整理还有个特点：它们往往来自某个学术项目或某个国家的语言调查成果，一次性把某个语系的登记信息校准一遍。所以变更会高度集中在一个语系、一个地区。

对你的意义是：如果你做的市场正好在某次批量整理覆盖的范围内，那一年的变更值得逐条看；不在的话，扫一眼就行。

## 改名比改码更常见

把所有修改类的变更按改动的属性分：参考名占32.0%、指称范围占30.8%、附加名称占23.9%、宏语言成员关系占10.2%、范围类型占2.7%、语言类型占0.3%。

合起来看，将近九成的修改是在动名字和这个代码管多大范围这两件事。代码本身其实相当稳定，不稳定的是代码背后指的东西。

这条对做语言选择器里那些语言名怎么写 (https://zhangwenbao.com/minor-language-endonym-language-picker-sort.html)的人特别要紧：你界面上那个语言名，可能在某一年被官方改过，而你的代码一个字母没变，所以没有任何机制会提醒你。

指称范围的改动最值得警惕。它的意思是这个代码涵盖哪些话语变体被重新划了一次，代码字符串一个字母没变，但它管的人群变了。

## 把生效日期当成版本号来用

实操上有个很省事的做法：不要去记哪个代码变了，而是记住你上次对表是按哪个生效日期的版本对的。

官方的码表下载页 (https://iso639-3.sil.org/code_tables/download_tables)提供的是纯文本的制表符分隔文件，包含在册表、宏语言成员表、退役表三份，加起来不到两兆。

把这三份文件按日期存进你的仓库，下次更新的时候做一次文本对比，变了什么一目了然。这件事的全部技术含量就是记得存上一版。

如果你的团队用版本控制系统管配置，把这三份文件直接提交进去是最省事的做法：每次更新提交一次，差异对比是现成的，还自带时间线。

## 被合并掉的那门语言去了哪里？

177个被并进别处的代码，去向不是随便挑的，能查得一清二楚。

## 177个代码指向118个不同目标

先破一个直觉。原本以为合并的方向应该是大量小语言被吸进少数几门大语言，形成几个巨大的黑洞。

实测不是。177条合并指向118个不同的目标语言，吸收最多的那一门也只吃进了9条。这不是几个黑洞，是一百多次各自独立的局部整理。

这条更新了一个很实用的判断：你不能假设某个消失的代码八成是并进了当地的主流语言。它更可能是并进了一门你同样没听说过的邻近语言。

吸收最多的那门语言是危地马拉的一门玛雅语系语言，吃进了9条，全部是它自己的地区变体。第二名6条，第三名5条。曲线掉得非常快。

## 奥克语那一次是最好的教材

2007年3月14日，五个代码同一天被并进奥克语oci：奥弗涅语、加斯科涅语、利穆赞语、朗格多克语，还有最有名的那个——普罗旺斯语prv。

普罗旺斯这个词在中文互联网上的知名度，比奥克语高出不知道多少倍。而在这套标准里，它从2007年起就不再是一门有独立代码的语言了。

一个代码的知名度和它的存续状态完全不相关。你凭印象觉得眼熟的代码，可能十七年前就注销了；你觉得没听说过的代码，反而是现役的那个。

这五个名字在中文世界的知名度差别也很大。加斯科涅、朗格多克这些词在旅游和红酒语境里出现得相当频繁，而它们作为语言代码已经消失了十七年。

## 合并的判据是什么

翻这几条的申请文档，理由几乎都是同一个模式：这几个变体之间可以互相听懂，且没有各自独立的书面标准，因此不构成不同的语言。

互相能不能听懂这条判据，在下一篇里会被拆开细讲，因为它是整个受理流程里最硬的一道闸。这里只需要记住：合并的理由是语言学上的，不是行政上的。

顺便说，这也解释了为什么合并的目标那么分散——判据是逐对比较的，比出来什么样就是什么样，没人在做全局规划。

有一个例外情形值得记住：如果几个变体之间可懂度足够高，但各自有长期存在的独立身份和成熟的书面标准，标准里另有一条通道允许它们保留各自的代码。这条通道在下一篇里是主线。

## 你的表里怎么处理这一类

合并这一类是四种注销里最好处理的：老代码有唯一去向，直接替换就行，历史数据也可以合并统计。

唯一要注意的是报表的连续性。如果你有一门语言的历史数据是按老代码存的，替换之后那个新代码的历史曲线会突然抬高一截，而这一截不是增长。做趋势分析的时候，代码合并的日期需要在图上标一条竖线。

见过一次因为没标这条线，团队开会讨论了半小时某个语种为什么在某个月突然增长四成。

还有一处容易漏：翻译记忆库和术语库通常也按语言代码分区。代码合并之后，两个库如果不合并，同一门语言会有两套互不相通的记忆，命中率会莫名其妙地低。

## 还有一种更隐蔽的合并

除了代码被整个注销，还有一种情况：代码没变，但它被划进了某个宏语言底下，成了成员之一。

这种变更在退役表里查不到，只在宏语言成员表里体现。而多数人的对表流程根本不下载那份文件。

2024年10月那次变更就是这么一个例子：两个新代码被创建出来，同时中文这个宏语言的成员清单被更新，把这两个新代码加了进去。成员表变了，在册表和退役表都毫无动静。

所以完整的对表动作是三份文件都要下载。只下在册表的人会漏掉注销，只下在册表和退役表的人会漏掉成员关系变更。

## 拆分为什么比合并更容易咬人？

102个被拆开的代码，是这张表里真正需要人工判断的那部分。

## 拆分之后原代码必须整个退役

规则是这样的：如果一个代码原本涵盖的范围被认定为两门或更多门不同的语言，那这个代码不能保留给其中任何一门，必须整体注销，然后为每一门发新代码。

吉大港语那个例子最典型：cit拆成罗兴亚语rhg和吉大港语ctg，连沿用原名的那一半都换了新号。

这个设计有它的道理——保留原码给其中一半，会让所有历史数据的含义变得含糊。但代价是：你手里那条写着老代码的记录，从此没有唯一正确的迁移目标。

这条规则背后的逻辑是：一个代码的含义必须在整个生命周期里保持稳定。宁可让所有人重新映射一次，也不允许同一个代码在不同年份指不同的东西。这个选择对档案是好事，对你的迁移是坏事。

## 一拆五和一拆十一都出现过

拆分的粒度差别很大。2007年南部壮语ccy被拆成五门语言，2023年泽姆语zua被拆成五个，波尔奇语plj被拆成四个。

而2024年10月那次闽南语的申请，一口气提出要拆成十一门，最后只通过了其中两门。这条在下一篇里是主角。

拆得越碎，你的迁移工作越没法自动化。判据很简单：拆出来超过两个，这批数据就只能靠人按内容判断，脚本能做的只有把它们挑出来。

拆分申请的通过率也随粒度下降。粗粒度的拆分（一分为二、一分为三）通过率明显更高，一口气拆成十来门的申请，多半会被砍掉大部分。

## 拆分的高发地带在哪里

把139行拆分类的变更按地区看，太平洋、东南亚、非洲三块占了大头。原因很好理解：这几个区域当年登记得粗，一个代码常常涵盖了一大片方言连续体。

这对做东南亚三国那一层语言差异 (https://zhangwenbao.com/southeast-asia-seo-vietnam-thailand-indonesia-language-layer.html)和非洲市场语种选择 (https://zhangwenbao.com/africa-market-language-selection-swahili-hausa-francophone.html)的人是个提醒：你在这两个区域用到的语言代码，被后续拆分的概率显著高于欧洲和美洲。

欧洲那边拆分很少，但驳回率极高，原因完全是另一回事，下一篇会讲。

反过来，如果你的市场在南美或南亚，拆分的风险相对低。这两个区域早年的登记工作做得比较细，后来需要重新划界的情况少。

## 拆分留下的痕迹要去哪里找

退役表里，拆分那一类不填合并去向那一栏，改填一段文字说明，写清楚拆成了哪几个。比如泽姆语那条写的就是拆成图莱语等五门语言，并把新代码逐个列出来。

这段文字是纯文本，格式不统一，没法直接解析成结构化数据。想批量处理拆分类的注销，第一步得先接受你要读一遍这102行字。

好消息是102行读完不到二十分钟，而且读完之后你对自己业务涉及的那几门语言会有一个非常具体的印象。

读的时候有个小技巧：先按你自己业务涉及的语系筛一遍，通常一百多行里跟你有关的不超过五行。剩下的可以直接跳过。

## 宏语言是语言学概念，还是给旧系统留的台阶？

这一节是整篇文章里最想让人记住的一段，也是翻这个库最大的一次意外收获。

## 宏语言到底是什么

在册表里有63个代码被标为宏语言，底下登记了459条成员关系。成员最多的是萨波特克语59个，其次是克丘亚语44个、马来语37个、阿拉伯语30个、苗语26个、中文19个、壮语18个。

另一头，只有两个成员的宏语言有26个之多。挪威语就是其中之一：no这个两位码指的是宏语言，底下挂着书面挪威语nb和新挪威语nn两门个别语言。

回到开头那个问题。no和nb不是同义词，也不是新旧两种写法，它们是口袋和口袋里的一件东西。你写no，说的是挪威语这个整体；你写nb，说的是其中一种书面形式。这两句话在语义上根本不等价，只是在多数系统的实现里被当成了等价。

官方对宏语言的定义大意是：某些情况下，多门个别语言在使用中被当成一个整体对待，需要一个代码来指代这个整体。听起来像个语言学分类。往下看就知道不是。

## 加泰罗尼亚语那次，泄露了这个机制的用途

2006年有一份编号2006-129的申请，请求把加泰罗尼亚语拆成两个代码，一个给瓦伦西亚语，一个给不含瓦伦西亚的加泰罗尼亚语。

这份申请的公开文档 (https://iso639-3.sil.org/request/2006-129)里有一段几乎是自白的话。注册机构说，按标准的管理规则，这样拆意味着原代码要退役、要发两个新代码，而这会让所有已经在用这个代码的应用面对大量拆分工作，对应的两位码含义也会变得含糊；考虑到这个代码已有的存量应用规模，简单地拆成两个新代码不是一个可接受的处理方案。

注意这句话说了什么：存量规模本身，被当成了不批准拆分的一条理由。这跟这两个变体在语言学上是什么关系没有任何关系。

然后注册机构做了一件更有意思的事——它提出了一个折中方案：把加泰罗尼亚语重新定义成宏语言，同时为两个具体变体各发一个新代码。这个方案被公开征求意见。

## 但这份申请最后还是被驳回了

一开始我以为故事到这里就结束了，宏语言这个机制就是这么被逼出来的。翻到文件末尾才发现不是——最终的裁决是不批准，加泰罗尼亚语至今仍然是个别语言，不是宏语言。

驳回的理由回到了那条唯一的硬判据：互不相通。文件里写得很直接，连支持这份申请的评议人自己都承认两者可懂度很高，而区域外的语言学者一致把它看成一门语言；这里的差别更多关系到可接受性，而不是可懂度。

这句话值得抄下来贴在墙上。可接受性不是判据，可懂度才是。一门语言的使用者觉得自己说的是另一门语言，这个感受在这套体系里不产生任何效力。

顺带一提，瓦伦西亚语最后拿到的不是一个语言代码，而是一个地区子标签，写法是ca-valencia，由语言标签的登记表授权。标准这一层不给你新代码的时候，标签那一层可能给你一个子标签。这条对做地区变体的人是个非常实际的出路。

## 同一句话在十七年后又出现了一次，这次通过了

如果只有一个案例，可以说是特例。但2023年12月15日生效的那份梵语申请，把同样的逻辑又说了一遍，而且这次走通了。

那份申请原本只是请求为吠陀梵语创建代码。注册机构采纳了，但做了修改：同时创建古典梵语的代码，并把梵语本身升格为宏语言，底下挂这两门历史语言。

这份裁决书 (https://iso639-3.sil.org/request/2011-041)里的原话是：这个方案在既有应用继续使用单一代码的需要，和学界把古典梵语与吠陀梵语当作不同语言的要求之间，取得了平衡。

两次独立的案例，相隔十七年，一次没通过一次通过了，但注册机构用来描述宏语言这个工具的说辞是同一套。到这里可以下结论了。

## 更有意思的是，宏语言这个身份还能被撤销

前面提到2007年3月14日有五个代码被并进奥克语。那次动作的完整版本还有后半句：奥克语本身的范围，同时从宏语言改回了个别语言。

也就是说，一门语言可以在某一年被升格成宏语言、底下挂几个成员，几年后又被降格回个别语言、成员代码全部退役。这不是理论可能，是已经发生过的事。

在册表里今天查oci，范围那一栏写的是个别语言。而那六个曾经存在过的变体代码，只留在退役表里。

这条推翻了一个很自然的假设：宏语言是一个更稳定的、更上层的分类。它不是层级，它是一次判断，而判断会被推翻。

## 结论：宏语言是兼容层，不是语言学概念

把三条案例串起来：存量规模能当驳回理由；升格宏语言被明写成对既有应用的照顾；宏语言身份可以被撤销。

宏语言不是一个语言学概念，是为了不打断已经在用这个代码的系统而设的向后兼容层。

这一条直接解释了几件长期让人困惑的事。为什么中文一个代码底下挂着十九门语言；为什么阿拉伯语底下挂着三十门；为什么印尼语和马来语算不算一门语言 (https://zhangwenbao.com/indonesian-malay-seo-two-markets-vocabulary-split.html)这个问题在标准里的答案那么别扭。

答案是：标准并没有回答这个问题。它提供了一个中间层，让不想回答的人可以继续不回答。

## 这对你的实操意味着什么

三条。第一，看到宏语言代码要下钻一层：写zh的时候问自己到底指哪一门，写ar的时候更要问，因为标准阿拉伯语和各地方言之间的差距 (https://zhangwenbao.com/arabic-seo-rtl-layout-msa-dialect-keyword.html)比你想的大。

第二，宏语言的成员清单会无声地变。上面说过，2024年10月中文那个宏语言就多了两个成员，退役表里查不到，在册表里也只是多了两行。

第三，如果你的系统必须在宏语言和成员语言之间二选一，页面上选宏语言更安全，因为兼容层的设计目的就是兜住不确定性。但报表要按成员语言拆，不然你会永远看不见增长发生在哪一半。

还有一个隐藏的坑：塞尔维亚-克罗地亚语这个宏语言，两位码是sh，在语言标签的登记表里已经被标为不推荐使用，替代值指向具体的三门语言。做塞尔维亚语和保加利亚语市场 (https://zhangwenbao.com/bulgarian-serbian-seo-cyrillic-latin-dual-script.html)的时候，如果你的老系统里还留着sh，那是一处需要主动清理的地方。

## 这个库这十八年在忙的是什么？

把2250行变更按年份铺开，能看出一条挺清楚的弧线。

## 新建量的曲线已经压平了

按生效年算新建的语言代码数：2008年145个是峰值，2012年137个，2013年125个，然后一路下滑，2019年只有16个，2024年14个。

累计下来，这十八年一共新建了944个代码。前六年就占掉了六成。

这个库已经从造语言转成了改名字。这个转变对你有个直接好处：你现在维护的这份代码表，未来几年被新增项冲击的概率很低，真正的变数在改名和调整范围那一侧。

这条也解释了为什么这些年新出现的语言代码，你多半没见过。它们集中在非洲和太平洋那些原本登记就粗的区域，而不是你的目标市场。

## 申请量的谷底在哪一年

按申请年份数，2007年是峰值258条，2011年166条，2012年151条。然后逐年下滑，2022年34条，2023年只有5条。

2023年那个数字低得有点异常。合理的解释是那一年标准本身在修订，很多事情在等结果。

2024年提交的申请回升到了十九条，但到这一年年底，这十九条一条都还没生效——从提交到出结果的滞后大约是一年，慢的能拖到三年以上。

有个细节值得留意：申请量的谷底跟变更行数的谷底不在同一年。行数最少的年份是2024年，只有29行；而申请数最少的是2023年。两个数之间隔着一年左右的处理周期。

## 一份申请要等多久

说到等，这个库里等得最久的那几份值得单独拎出来。

2006年提交的一份关于中古希腊语的申请，2023年12月15日才有结果，整整十七年。2009年提交的两份希腊语相关申请，也是同一天出结果，等了十四年。2011年那份梵语申请等了十二年。

这几份为什么等这么久，裁决书里写了：它们涉及历史语言能不能被当成宏语言拆分这个先例问题，而这个问题在ISO 639整套标准的修订过程中一直悬着。它们等的不是评审，是标准本身。

对你的实际含义是：你不能指望通过盯着申请队列来预判变更。队列里躺着的东西可能十年不动，而真正影响你的那些变更往往来自一次批量整理，压根不在你关注的名单上。

## 修改类变更在改什么

前面提过修改的属性分布，这里补一个更有用的角度：修改类变更的驳回率只有6.5%，而新建是25.3%、拆分是25.9%。

换句话说，想改一门已有语言的属性很容易过，想把一门语言立起来要难四倍。

这条判据在下一篇里会被展开成一整篇文章的主线，因为它背后藏着这套体系真正的价值取向。

还有一个数字值得记住：合并的驳回率是9.8%，注销是8.4%，都不高。也就是说，减少一门语言比增加一门语言容易得多。

## 这件事怎么落到你的站和你的报表上？

前面全是背景，这一节是能直接抄走的部分。

## 先把语言代码出现的位置数清楚

典型的多语言站，语言代码至少出现在这几处：页面根元素的语言声明、每一条hreflang、站点地图里的语言备用链接、结构化数据里的语言字段、商品数据源的语言与目标国家设置、分析工具的语言维度、内容管理系统的语言配置、以及翻译记忆库的语言对。

八处。结构化数据里那个语言字段该怎么填 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)那一篇讲过其中一处的特殊要求，这里要说的是：这八处很少由同一个人维护，也很少有任何一处会校验另一处。

所以第一步不是改，是数。把这八处各自现在写着什么导出来，放进同一张表里横着看一遍。

数的时候建议连同每一处的负责人一起记下来。这份清单真正的价值不在技术，在于它把一件横跨四五个团队的事收敛成了一张能开会的表。

## hreflang取值真正该对的是另一份表

有个容易搞混的点值得说清楚：hreflang里能填的值，规则并不直接来自三位码那份标准，而来自语言标签的注册表。

IANA维护的语言子标签登记表 (https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry)是那份实际生效的清单。它会从ISO的码表里同步，但同步有延迟，而且它对已经废弃的子标签处理方式是标注为不推荐并给出替代，不是直接删掉。

这个差别对你有利：一个在ISO那边已经注销的代码，在语言标签登记表里通常还留着，并带着一条指向替代值的说明。这条说明就是你做迁移时最可靠的依据。

所以对表的顺序应该是：先看ISO的退役表知道发生了什么，再看语言标签登记表拿到官方推荐的替代值。

这两份表还有一个结构性差别：ISO那边一个代码只有在册或注销两种状态，语言标签登记表那边还有一个中间态叫不推荐使用。中间态才是给迁移用的。

## 四种注销的处理方式各不相同

把动作按注销理由分开定，比一刀切省事得多。

被并进别的语言那177个：可以脚本自动替换，历史数据合并统计，图上标一条竖线。重复登记那33个：同样可以自动替换，因为本来就是同一门语言的两个号。

被判定查无此语言那72个：直接删掉这一行，同时去查你的内容库里有没有真的标着这个语言的页面，如果有，那批内容的语言标注从一开始就是错的。被拆开那102个：脚本只负责挑出来，逐条人工判断，别自动。

把这四类动作写成一份四行的处理规则，贴在对表脚本的注释里。下次换人做这件事的时候，这四行比任何文档都管用。

## 报表侧要防的是那种不报错的错

语言维度出问题的典型症状不是报错，是数字看着挺正常但讲不通。

常见的三种：某个语种的量在某个月阶梯式变化而内容没动过；两个语种的量此消彼长而总量不变；某个语种的转化率长期显著异常，高得或低得没有道理。

第三种最值得警惕，因为它常常是页面语言被机器认错 (https://zhangwenbao.com/minor-language-page-language-detection-misidentification-short-text.html)和代码注销两个原因叠加的结果。先查代码，再查识别，顺序反了会绕很久。

还有一种更隐蔽的：某个语种在报表里从来就没出现过。这通常不是没有流量，而是这门语言的代码根本不在报表工具的维度取值里，那批访问被归到了其他一栏。

## 把这件事变成一年两次的日程

最后给一个具体到能贴在日历上的方案。

每年二月和十一月各做一次，每次不超过两小时。动作是：下载三份码表存进仓库；跟上一版做文本对比；把变更行按四种理由分类；对照你站上那八处位置的清单，找出交集；处理交集，其余归档。

八处位置的清单只需要建一次，后面每年复用。第一次建清单大概要半天，之后每次两小时，这是这件事的全部成本。

如果实在挤不出这两小时，退而求其次的做法是只做一件事：拿退役表跟你站上那份语言配置做一次交集。这一步五分钟，能挡住九成的问题。

## 我一开始猜错了哪几条？

翻这个库之前先写了一份预期清单，翻完之后逐条对账。错的比对的有意思。

## 猜错一：以为注销的主要理由是查无此语言

这是错得最离谱的一条，也是价值最高的一条。实测查无此语言只占19%，而它还在只是换了地方那两类加起来占72%。

猜错的根源是把注销想象成纠错。实际上这个库里绝大多数注销是重新划界，跟对错无关。

纠错和重新划界，在你的数据迁移里是完全不同的两件事：前者该删，后者该换。猜错这一条的人，会把该换的也删掉。

这条猜错还牵出一个更一般的教训：任何一份看起来在做清理的记录，先别默认它清理的是错误。它更可能是在重新划界，而划界这件事没有对错。

## 猜错二：以为合并会集中到少数几门大语言

实测177条合并指向118个不同目标，最多的一门只吸收9条。

这条猜错的后果是策略性的：如果合并真的集中，你只需要关注几门大语言就能覆盖大部分风险；实际情况是分散的，只能按你自己涉及的语言逐个查。

好在你涉及的语言通常不超过二十门，逐个查也就是半小时的事。

顺带修正一个相关的直觉：合并的方向也不总是小并进大。有几条合并的目标语言，使用人口比被合并掉的那门还少，判据只看语言学关系，不看规模。

## 猜错三：以为修改类里参考名会占四成以上

实测参考名32.0%，指称范围30.8%，两者几乎并列。

这条猜错得不算严重，但它改变了一个判断：如果改名占绝对多数，那对表主要是显示层的事；实际上指称范围的改动占了差不多同样的份额，而指称范围变了意味着这个代码管的东西变了，那是数据层的事。

附加名称那一类占23.9%，也常被忽略。它的意思是一门语言多了个别名，而别名恰恰是用户在搜索框里会打的那种写法。做词表的人应该关心这一栏。

## 猜对的那一条也值得说

猜对的是2018年那批修改：确实是一次批量整理，88行全部同一天生效，76行属于同一个语系。

猜对不稀奇，稀奇的是这条猜对之后引出了一个原本没想到的问题：批量整理不改代码，只改代码的含义，所以它在任何基于字符串比对的监控里都是隐身的。

换句话说，你最容易发现的变更是最不重要的那一类，最难发现的是最要紧的那一类。这个顺序不太友好，但知道了就能反过来用——对表的时候先看修改类，再看注销类。

所以更实用的对表顺序是：先看修改类里指称范围和成员关系那两栏，再看注销表，最后才扫新建。跟大多数人的直觉正好相反。

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

最后划一下边界，免得把不同层的问题混着解。

## 代码有没有，和软件里能不能选，是两件事

一门语言在标准里有代码，不代表用户的设备能设成它。安卓、火狐、Chrome三家界面语言清单的实测 (https://zhangwenbao.com/minor-language-ui-locale-list-coverage.html)那一篇量过：三家最多的一份只有181门，跟七千多门差着两个数量级。

标准这一层管的是身份，软件那一层管的是可达性。身份是可达性的前提，但远远不是充分条件。

一门语言同时具备两个条件才算真正可用：标准里有代码，且用户的设备和浏览器清单里有它。只满足前一个，你能写出合法的标签，但接不到用户。

## 代码有没有，和本地化数据全不全，也是两件事

拿到代码只是拿到一个编号。这门语言的日期怎么写、数字怎么分节、星期从哪天开始，属于另一套数据。本地化数据的自有率实测 (https://zhangwenbao.com/minor-language-locale-data-inheritance.html)和非公历纪年数据的缺口 (https://zhangwenbao.com/minor-language-non-gregorian-calendar-data.html)两篇讲的都是那一层。

常见的错误组合是：拿到了三位码，就以为这门语言在系统里能正常显示日期和金额。那两件事之间没有任何自动关联。

判断方法很简单：拿到代码之后去查一下这门语言的本地化数据文件有多大。几百字节的多半是个空壳，真正有自有数据的文件通常在几十KB以上。

## 代码这一层不解决市场决策

最后一条，也是最要紧的一条。这套体系判定两个变体是不是不同的语言，用的是语言学判据，而你判定要不要为它们各做一套内容，用的是市场判据。

这两套判据经常给出相反的答案。捷克语和斯洛伐克语 (https://zhangwenbao.com/czech-slovak-seo-content-reuse-decision.html)有两个代码但内容能大量复用，北欧三语 (https://zhangwenbao.com/nordic-seo-swedish-norwegian-danish-content-sharing-boundary.html)的复用边界又跟代码数量对不上，克罗地亚语和斯洛文尼亚语 (https://zhangwenbao.com/croatian-slovenian-seo-two-small-markets-decision.html)更是两个方向都不成立。

标准告诉你这是几门语言，它不告诉你该做几套内容。后面那个问题，得你自己拿转化数据回答。

还有一个方向的错配同样常见：两个市场共用一个代码，但用户搜的词分叉得很厉害。乌克兰语和俄语那种双语市场 (https://zhangwenbao.com/ukrainian-russian-seo-bilingual-market-content-split.html)是典型，代码这一层完全看不出来。

所以这两层的正确用法是：代码这一层负责把技术链路铺对，市场那一层负责决定投多少钱。前者是及格线，后者才是策略。

## 常见问题解答

## 怎么快速查一个语言代码是不是已经被注销了？

去注册机构的码表下载页拿那份退役表，是个制表符分隔的纯文本文件，一共几百行。用表格软件打开，第一列就是被注销的代码，直接搜就行。同一份下载页还有在册表和宏语言成员表，建议三份一起拿，对表的时候要交叉着看。整套动作不到五分钟。

## 发现代码被注销了，直接替换成新代码就行吗？

要分情况。如果注销理由是被合并进另一门语言，那有唯一的去向，可以直接替换。如果理由是被拆开，就不能自动替换，因为原来那个代码涵盖的范围现在对应两个或更多新代码，你得逐条判断这批内容具体属于哪一个。如果理由是查无此语言，那就该删，同时要回头查你为什么会有标着这门语言的内容。

## hreflang里到底该写两位码还是三位码？

规则是有两位码就写两位码，没有就写三位。在册的七千多门语言里只有184门有两位码，所以做小语种基本上必然会遇到只能写三位的情况。要注意的是，判断依据应该是语言标签的登记表而不是凭印象，登记表里对每个子标签是否推荐使用都有标注。

## 宏语言代码和它的成员代码，该用哪一个？

页面上和hreflang里通常写宏语言代码更安全，因为它的设计目的就是兜住不确定性，下游系统对它的支持也更完整。但内部报表建议按成员语言拆开统计，否则某一门成员语言的增长会被整个口袋的数字盖住。两套并存不冲突，页面写宏语言、报表拆成员，是比较稳妥的组合。

## 这些代码变更会影响已经收录的页面吗？

不会直接影响收录，搜索引擎不会因为一个语言代码被注销就把页面从索引里拿掉。真正的影响在匹配环节：如果一个用户的语言偏好指向的是新代码，而你的页面声明的是老代码，两边对不上，语言协商和地区版本匹配就接不住这个用户。影响是渐进的，也因此不容易被发现。

## 多久对一次这张表比较合适？

一年两次足够。这个库的变更是集中生效的，多数年份只有一到两个生效日期，而且往往在年初。所以二月和十一月各做一次，正好卡在生效窗口之后。每次的动作是下载三份码表、跟上一版做文本对比、按注销理由分类处理，两小时之内能结束。



## 同一段内容翻成老挝语，字数一个没多，模型读一遍的价钱翻了八倍

- URL：https://zhangwenbao.com/minor-language-llm-token-inflation-cost.html
- 分类：小语种SEO
- 发布：2024-11-22  |  更新：2026-08-02
- 摘要：70门语言实测大模型token膨胀：老挝语8.23倍、阿姆哈拉语5.82倍，字符数却与英语相当。给出完整倍数表、128K窗口真实容量、三代词表的改善分布与自测方法。
- 关键词：AI搜索,多语言SEO,内容运营,小语种SEO

> **TLDR**：摘要：拿FLORES-200的平行语料把同一批1012个句子在70门语言上各切一遍，量出来的不是小数点后的差别——老挝语要花英语8.23倍的token，而它的字符数跟英语几乎一模一样。更麻烦的是那批token里有89.73%根本不是字，是半个字的字节。这笔账会顺着上下文窗口、检索切块、接口账单、免费额度一路往下传，而所有这些额度都是按英语的密度定的。本文给出70门语言的完整倍数表、老挝语与泰语差4.14倍的原因、三代词表的进步到底分给了谁，以及一个三十分钟能自己跑完的最小实验。

> 
摘要：拿FLORES-200的平行语料把同一批1012个句子在70门语言上各切一遍，量出来的不是小数点后的差别——老挝语要花英语8.23倍的token，而它的字符数跟英语几乎一模一样。更麻烦的是那批token里有89.73%根本不是字，是半个字的字节。这笔账会顺着上下文窗口、检索切块、接口账单、免费额度一路往下传，而所有这些额度都是按英语的密度定的。本文给出70门语言的完整倍数表、老挝语与泰语差4.14倍的原因、三代词表的进步到底分给了谁，以及一个三十分钟能自己跑完的最小实验。

今年夏天有个做户外装备的团队让我帮着看一份AI改写的预算。他们要把英语站的商品描述批量改写成十一门语言，供应商按篇报价，一篇多少钱，语言不加价，看起来很干净。

我当时觉得这份报价单太干净了。干净到不像是算过账。

于是把他们的样稿抓了三段出来，各语言版本都有，扔进tokenizer数了一遍。英语那段1131个token，德语1481，泰语2252，缅甸语3581。同一段话，同一个意思，最后一门语言的机器成本是第一门的三倍出头。而报价单上，这三门语言在同一行，同一个价钱。

供应商没算错，他们只是按人工的口径报的价。人翻一段话，语言难易有差别但不会差三倍。机器读一段话，差别就是三倍。这两个口径中间没有人做过换算。

## 那段老挝语和它的英语原文一样长，账单上却是八倍

## 一次本来只想核对预算的测量

核完那份报价单，我起了个念头：三倍这个数是巧合还是常态？十一门语言太少，看不出规律。

要看出规律，得有一份真正的平行语料——同一批句子，被专业译者翻成几十门语言，句句对齐。凑巧这份东西是现成的。

Meta做机器翻译评测时建了一套FLORES-200数据集 (https://github.com/facebookresearch/flores)，从维基文章里抽了两千多个句子，找专业译者翻成204门语言，逐句对齐。它本来的用途是给翻译模型打分，但它同时也是一把现成的尺子：同一个意思，在每门语言里到底占多少地方。

我取了它的devtest部分，每门语言1012个句子，选了70门跟本站写过的市场对得上的语言，一门一门地数。

## 三代词表、七十门语言、十三万字符的平行语料

切分工具用的是OpenAI公开的tiktoken (https://github.com/openai/tiktoken)，三代词表都跑：p50k_base、cl100k_base、o200k_base，规模分别是50281、100277、200019个条目。

每门语言的1012个句子拼成一整串，量四个数：Unicode码点数（下文说“字符”都指这个）、UTF-8字节数、三代词表各自切出来的token数，以及一个我后来发现最关键的数——字节回退率。

英语那一份是13.3万字符、26878个token。这就是基准线，后面所有倍数都是拿它比出来的。

为什么要三代都跑？因为词表是会换的，而换代的时候厂商只会告诉你“对多语言更友好了”。友好多少，友好给谁，从来没有一份逐语言的清单。

## 先说结论：贵的不是字数，是每个字要几个块

老挝语那一份是131100个字符，英语是132977个。两边字数几乎完全一致，差不到1.5%。

但老挝语切出来是221170个token，英语是26878个。8.23倍。

这个对照把我原来的假设按在地上打了一顿。我开工前写的预期里有一条明明白白：“token数跟字符数基本线性，膨胀主要来自某些语言字更多。”实测下来这条完全不成立。老挝语一个字都没多，贵的是每个字要几个token。

换成单位数字更直观：英语平均每个字符0.202个token，老挝语1.687个。同样一个字符，一边不到五分之一个token，一边要一个半还多。

所以这件事的正确说法不是“小语种内容更长”，是“小语种的每个字更碎”。这两句听着像一回事，落到优化动作上完全相反——前者让你去删字，后者告诉你删字没用。

我把这条当成整篇的第一句骨架句，因为后面所有的账都从它长出来。

## 这件事跟本站讲过的分词器不是一回事

本站过去写小语种，“分词”这个词出现过很多次。泰语那篇讲的是搜索引擎怎么把没有空格的句子切开 (https://zhangwenbao.com/thai-seo-no-spaces-word-segmentation-keyword.html)，切错了会影响匹配和收录。那是检索侧的分词。

这篇讲的是另一件事：大模型把一串字符转换成它内部能处理的编号，切分单位跟语言学意义上的词没有关系，跟搜索引擎的词典也没有关系。它切的依据只有一条——这段字节组合在训练语料里出现得够不够频繁。

两者唯一的共同点是都叫“切”。除此之外，规则不同、后果不同、能采取的动作也不同。搜索引擎切错了你可以补词典，模型切碎了你补不了，那本词表是随模型一起发布的，改不了也换不了。

还有一层要提前划开：这篇不讨论模型在这门语言上答得准不准。小语种内容里模型顺手编出来的那些本地规矩 (https://zhangwenbao.com/low-resource-language-ai-hallucination-rate-content-risk.html)是另一个问题，那是能力层。

## 开工前写下的十二条预期，错了六条

本站做这类实测有个规矩：开工前把预期逐条写下来，跑完对一遍。不写下来的话，人总会觉得自己早就知道。

这次写了12条，跑完对下来错了6条，其中4条直接翻转成了正文的骨架。

错得最狠的是第五条：我以为天城文因为组合字符多，印地语会是膨胀最严重的那一批。实测印地语只有1.57倍，在70门语言里排到中游偏下，比匈牙利语和拉脱维亚语都便宜。

第四条也错了。我以为字节回退这种极端情况只会出现在最冷门的几门语言上，结果繁体中文15.87%、高棉语14.65%、韩语5.40%、简体中文4.97%都有，只是量级不同。

还有一条错得很有意思：我以为中日韩因为单字信息密度高，总体不吃亏。这条一半对一半错，而错的那一半正好是最容易在会上被讲错的那一半，后面有一整节讲它。

剩下几条对账放在各节里就地说，不集中列了。

## 模型到底是怎么把一句话切开的？

## 词表是一本有限的册子，你的语言在里面占几页

模型不认字，它认编号。所有输入在进模型之前，都要先按一本固定的册子换成一串编号，这本册子就是词表。

词表的条目数是定死的。o200k_base是200019条，多一条都没有。这20万个位置要分给全世界所有语言的所有常见字节组合，还要分给代码、数字、标点、表情符号。

位置怎么分？按训练语料里的出现频率。哪段字节组合出现得多，哪段就单独占一个位置；出现得少的，只能拆成更小的片段去拼。

这就是整件事的机制。它不是谁在歧视谁，是一套按频率分配有限位置的算法，跑在一份英语占绝对多数的语料上，得出的必然结果。

这个结论早有人量化过。《语言模型的tokenizer在语言之间制造了不公平》 (https://arxiv.org/abs/2305.15425)那篇给出的极端差距是十几倍，我这次的实测在数量级上跟它对得上，差别是我用的是更新一代的词表，而且逐门语言给了数。

## 词表里没有的字，只能一个字节一个字节地拼

拆到最细会拆成什么？答案是单个字节。

这套编码方案出自机器翻译领域一篇讲罕见词怎么用子词单元表示的论文 (https://arxiv.org/abs/1508.07909)，它的底层保证是永远不会失败——最坏情况下退回到字节级，一个字节一个token，总能把任何输入表示出来。这条兜底机制叫字节回退。

对英语来说这条兜底几乎不会触发，因为英语字符在UTF-8里就是一个字节，而且常见组合早就有整块了。对非拉丁文字来说完全不同：一个老挝文字符在UTF-8里是三个字节，如果这三个字节的组合没有整块，就会被拆成两到三个token，每个token都只是半个字。

我在统计里加了一列专门量它：把每个token单独解码，看它的字节序列自己能不能构成一个合法的UTF-8字符。不能，就记一次回退。

老挝语的这一列是89.73%。也就是说这门语言的内容进模型之后，接近九成的token拿出来看都不是字，只是字的一截。

阿姆哈拉语是88.31%，跟它是一对难兄难弟。这两门语言的文本在模型内部基本是以字节流的形态存在的，字这个单位在那一层已经不存在了。

这个数比倍数更值得记，因为它解释了倍数从哪来，也预告了另一件事——一个词被拆成一堆半截字节之后，它在模型眼里还算不算一个东西。那是另一篇的题目。

## 七十门语言实测下来，贵的到底是哪几门？

## 完整的膨胀倍数表长什么样

先把结果整个摆出来，再逐段解释。下面这张表是相对英语的token倍数，用o200k_base词表，同一批1012个句子。

档位 | 语言（相对英语的倍数） | 

4倍以上 | 老挝语8.23、阿姆哈拉语5.82 | 

2.5到4倍 | 高棉语3.34、缅甸语3.16、中库尔德语2.77、僧伽罗语2.69、旁遮普语2.62 | 

1.9到2.2倍 | 约鲁巴语2.17、希腊语2.14、泰语1.99、泰米尔语1.98、卡纳达语1.97、马拉雅拉姆语1.96、泰卢固语1.93 | 

1.6到1.9倍 | 蒙古语1.89、马耳他语1.87、马拉地语1.82、拉脱维亚语1.81、匈牙利语1.79、古吉拉特语1.79、亚美尼亚语1.79、格鲁吉亚语1.79、塞尔维亚语1.78、乌克兰语1.75、普什图语1.72、保加利亚语1.71、孟加拉语1.70、日语1.66、乌尔都语1.65、波兰语1.64、尼泊尔语1.61 | 

1.4到1.6倍 | 捷克语1.60、哈萨克语1.58、印地语1.57、芬兰语1.56、豪萨语1.55、波斯语1.53、越南语1.49、斯瓦希里语1.49、希伯来语1.48、韩语1.47、意大利语1.47、土耳其语1.43、俄语1.42、繁体中文1.42、丹麦语1.40 | 

1.4倍以下 | 阿拉伯语1.38、法语1.37、瑞典语1.35、挪威语1.35、西班牙语1.32、德语1.31、马来语1.30、印尼语1.25、简体中文1.25、荷兰语1.25、葡萄牙语1.23 | 

这张表最该先看的不是最上面那两行，是它的分布形状——绝大多数语言挤在1.2到2.0之间，然后突然有几门冲到3以上，最后两门离群到4倍以外。

换句话说，多数语言的代价是可以忽略的量级差别，少数几门是完全不同的账本。做优先级排期的时候，前一类不必单独讨论，后一类必须单独讨论。

这个形状本身就值得记一笔。当年多语言模型铺到七十多种语言那次 (https://zhangwenbao.com/multilingual-bert-seventy-languages-minor-language-seo-watershed.html)，受益的分布也是这种长尾形状——大部分语言差不多，少数几门单独成一档。

如果你手上的市场全在1.2到1.6这一档，读到这里其实就可以结束了，这笔账在你的预算表里是个小数点。真正需要往下读的是名单里有第二档和第三档语言的人。

## 最贵的那两门语言不在任何人的预期名单里

老挝语8.23倍，阿姆哈拉语5.82倍。这两门语言的字节回退率分别是89.73%和88.31%。

我开工前的预期名单里最贵的是印地语，理由是天城文的组合字符多。这个理由听起来很专业，实测下来完全站不住——印地语1.57倍，比匈牙利语还便宜。

老挝语和阿姆哈拉语的共同点不是文字复杂，是这两门语言的网络内容太少。维基百科各语言版本的条目数清单 (https://meta.wikimedia.org/wiki/List_of_Wikipedias)上，老挝语只有五千多条，是泰语的三十三分之一；阿姆哈拉语的处境类似。

训练语料里没有足够的量，词表分配位置的时候就轮不到它们，于是只能退回到字节。所以“文字复杂”和“语言昂贵”这两件事之间没有直接因果，中间隔着一个变量：这门语言在互联网上有多少字。

这条推论有个立刻能用的推论：一门语言的膨胀倍数是可以预测的，不用等实测——先看它的网络内容存量，八九不离十。后面有一节专门验这个预测能力有多准。

顺便说一句，非洲那几门主要语言的处境跟阿姆哈拉语类似。本站写非洲选语种那篇 (https://zhangwenbao.com/africa-market-language-selection-swahili-hausa-francophone.html)用的判据是有没有人拿这门语言写价格和退货政策，现在可以再加一列：机器读它要多花几倍。

## 印度诸语其实早就便宜下来了

印地语1.57、马拉地语1.82、泰米尔语1.98、泰卢固语1.93、卡纳达语1.97、马拉雅拉姆语1.96、孟加拉语1.70、古吉拉特语1.79。

这一整片语言现在都落在2倍附近，跟希腊语差不多，比约鲁巴语还便宜。

两代词表之前完全不是这个样子。同一批语言在p50k_base那代，泰米尔语是英语的15.01倍，马拉雅拉姆语是14.65倍。这个数据现在已经过期了，可它仍在很多中文资料里被引用。

本站写印度十一门语言的预算排期 (https://zhangwenbao.com/india-multilingual-seo-eleven-languages-nine-scripts-priority.html)时，成本模型里没有这一项，因为那时候这一项还不影响决策。现在它更不影响了——但方向是反的：不是因为它小，是因为它已经被解决掉了大半。

## 拉丁字母不等于便宜，约鲁巴语比希腊语还贵

拉丁字母这一档里，最便宜的是英语1.00，最贵的是约鲁巴语2.17。同一套字母，内部差2.17倍。

约鲁巴语比希腊语2.14贵，比泰语1.99贵，比泰米尔语1.98贵。它用的是二十六个拉丁字母加几个变音记号，看上去跟英语没差多远。

原因还是那一条：语料量。约鲁巴语在互联网上的内容比希腊语少得多，而它的变音记号让常见词的字节组合跟英语的完全对不上，于是既拿不到自己的整块，也蹭不到英语的整块。

本站量字体成本那篇 (https://zhangwenbao.com/minor-language-web-font-glyph-set-first-screen-cost.html)里，书写系统是个有效判据，字形集大不大直接决定文件多大。到了token这一层，同一条判据完全不成立——能用书写系统解释的问题和不能用书写系统解释的问题，要分开处理。

马耳他语1.87、祖鲁语1.72、豪萨语1.55，都是同一个道理。这几门语言在很多人的心智里属于“拉丁字母，应该好办”，实测下来跟俄语波兰语一个量级甚至更贵。

## 中日韩这三门的数字要分两个口径读

简体中文1.25倍，比德语1.31、法语1.37、西班牙语1.32都便宜。日语1.66，韩语1.47。

看到这里很容易得出一个结论：中文在这件事上不吃亏，甚至占便宜。

这个结论只在一个口径下成立，换个口径就翻过来，而两个口径都是实测。

这个结论只在一个口径下成立——同一篇文章的口径。同样一篇文章翻成中文，token数确实比翻成德语少。

换个口径就翻过来了。按“一个上下文窗口能装多少字”算，英语能装63万个字符，简体中文只能装16.9万，是26.6%。因为中文一个字的信息量大，同样的字数装的内容多，但同样的token装的字数少。

## 繁体和简体，同一门语言两套字差百分之十三

简体中文33584个token，繁体中文38120个。同一批句子，同一个意思，差13.5%。

字符数上繁体反而更少（41733对44262），token数却更多。字节回退率差得更明显：简体4.97%，繁体15.87%，三倍出头。

原因不难猜——训练语料里简体的量比繁体大，常见的简体词组拿到了整块，繁体的对应写法只能拆。

本站算小语种优先级的那套成本模型 (https://zhangwenbao.com/minor-language-seo-priority-language-cost-model.html)里，简繁一直是被当成同一门语言的两个写法处理的，主要成本项是词库和地区用词。现在多了一项：如果你有大量AI改写或AI问答的工作量，繁体那一侧要多留13%的预算。

## 为什么老挝语比泰语贵四倍，而它们的文字是一对亲戚？

## 先把两门语言的字形结构摆在一起

这一节是本篇最想讲的一段，因为它把“语料量决定一切”这个结论钉死了。

老挝文和泰文是亲戚。两套文字同源，字形结构一样，都是辅音带元音附标，都不写空格，都有声调符号。在Unicode里，两个块的排列顺序也是对应的，老挝文那个块的字符位置基本能跟泰文块一一对上。

换句话说，从字符编码的角度看，这两门语言的文本长得几乎一模一样。字符数也接近：老挝语131100，泰语127373，差不到3%。

如果token膨胀真的是由文字结构决定的，这两门语言的数字应该非常接近。

它们不接近。这一对是整份数据里最干净的对照组，因为文字这个变量被控制住了，剩下只有一个变量在动。

## 实测：8.23倍对1.99倍

老挝语221170个token，泰语53488个。同样的1012句话，同样的字数，同样结构的文字，差4.14倍。

每字符的token数：老挝语1.687，泰语0.420。

这个对照我跑完的第一反应是脚本写错了，把两份文件的路径搞混了。回头逐行核对，没错。又单独拿几个词手工验了一遍，也没错。

最直观的一个例子是“手机”这个词。泰语写作โทรศัพท์เคลื่อนที่，18个字符，切成6块；老挝语写作ໂທລະສັບມືຖື，11个字符，切成22块。字少了将近四成，块多了将近三倍。

而那22块里，22块全是字节碎片，没有一块是完整的字。

同一个概念，同一片区域，两门亲戚语言，这就是差距。

## 字节回退率89.73%对0.74%

倍数只是结果，回退率才是原因。

泰语的字节回退率是0.74%，基本可以当零看。这意味着泰文的常见字符组合在词表里都有位置，模型读到的是字，不是字节。

老挝语89.73%。模型读到的几乎全是字节。

两门文字同源，一门拿到了整块，一门没拿到。差别只有一个：泰语的网络内容量是老挝语的几十倍。泰语维基185785条，老挝语5594条，差33倍。

所以这一节的结论可以写得很硬：决定一门语言在模型里贵不贵的，不是它的文字，是这门语言在互联网上有多少字。文字结构一模一样的两门语言，可以差出4倍。

这条结论的价值在于它把一个看起来玄乎的技术问题，换算成了一个你本来就在查的数——内容存量。而内容存量是本站判断一门语言值不值得做 (https://zhangwenbao.com/minor-language-qa-long-tail-content-value-ai-era.html)时早就在用的指标。同一个数，现在多了一个用途。

## 同一套书写系统内部的分化比系统之间还大

把这条推论横着验一遍，会发现它到处成立。

拉丁字母内部：约鲁巴语2.17对英语1.00，差2.17倍。阿拉伯字母内部：中库尔德语2.77对阿拉伯语1.38，差2.01倍。西里尔内部：蒙古语1.89对俄语1.42，差1.33倍。天城文内部：马拉地语1.82对印地语1.57，差1.16倍。汉字内部：繁体1.42对简体1.25，差1.14倍。

而书写系统之间的差别呢？阿拉伯语1.38比希腊语2.14便宜，希伯来语1.48比匈牙利语1.79便宜。非拉丁的阿拉伯语比拉丁的约鲁巴语便宜36%。

所以书写系统这个变量在解释力上排不上号。它能解释字体大小、能解释排版、能解释输入法，唯独解释不了这一层。

看到一门语言用的是非拉丁文字就默认它在AI管线上更贵，这个直觉在70门语言里有一半是错的。真要一句话记住，就记语料量那一句。

## 这条推论怎么用在没测过的语言上

假设你手上有一门我没测的语言，想估它的倍数，不跑实验能不能估个八九不离十？

可以。查两个数：这门语言的维基百科条目数，以及它有没有大规模的商业网站群。

条目数百万级的，基本落在1.2到1.6；十万到百万级的，1.6到2.2；一万到十万级的，2.5到3.5；一万以下的，往4倍以上估。

这个粗估法我拿测过的语言反着验了一遍，误差在半个档位以内。它当然不能替代实测，但排期会上够用了，而查条目数只要三十秒。

## 上下文窗口里，你的语言能装多少字？

## 把token口径换成字符口径，排名会变

倍数那张表回答的是“这段内容进模型要花多少”。还有一个问题它回答不了：“这个窗口能装下多少内容”。

这两个问题在英语世界里是同一个问题，因为英语的字符和token之间是个稳定的比例。到了多语言场景，它们分家了。

换算方法很简单：拿窗口的token容量除以这门语言的每字符token数，得出这门语言在这个窗口里能装多少个字符。

拿128K这个常见容量算，英语能装633349个字符，老挝语75874个，只有12.0%。阿姆哈拉语11.4%，高棉语34.8%，缅甸语39.0%，僧伽罗语36.9%。

## 128K窗口在各语言里的真实容量

把主要市场的容量列出来，方便直接拿去用。

档位 | 128K窗口能装的字符数（相当于英语的比例） | 

八成以上 | 西班牙语90.2%、荷兰语89.6%、德语88.8%、葡萄牙语88.7%、法语87.0%、马来语85.1%、意大利语80.5% | 

六到八成 | 印尼语86.3%、俄语75.7%、他加禄语74.3%、瑞典语74.1%、丹麦语73.6%、土耳其语71.9%、越南语70.5%、豪萨语68.4%、芬兰语68.0%、罗马尼亚语68.9%、克罗地亚语65.9%、波兰语64.5%、阿拉伯语63.9%、印地语63.1% | 

五到六成 | 亚美尼亚语61.8%、波斯语61.3%、格鲁吉亚语61.0%、保加利亚语60.9%、捷克语60.4%、乌尔都语59.6%、泰米尔语58.9%、乌克兰语58.3%、孟加拉语57.6%、希腊语55.8%、蒙古语54.9%、希伯来语52.2% | 

三到五成 | 泰语48.1%、约鲁巴语44.4%、缅甸语39.0%、旁遮普语38.6%、僧伽罗语36.9%、中库尔德语35.2%、高棉语34.8%、韩语34.2% | 

三成以下 | 简体中文26.6%、日语26.3%、繁体中文22.1%、阿姆哈拉语11.4%、老挝语12.0% | 

这张表最实用的地方在于它能直接换算成一句人话：同一套长上下文方案，在西班牙语上你能塞进去一整本产品手册，在老挝语上只能塞八分之一。

而多数团队的做法是一套方案全语言复用，参数写死在配置里，从来没按语言拆开看过。

顺便提醒：窗口容量和有效容量不是一回事。塞满窗口跟效果好之间没有正相关，材料给多了模型反而抓不住重点。这里给的是物理上限，不是建议值。

## 检索切块的粒度是按token定的

这一层的影响比账单大，但被讨论得少。

把内容灌进检索系统的时候，通常要先切块。切块大小的默认值是按token定的，512、1024、2048这几个数出现得最多。

512个token在英语里大约是2500个字符，够装一整段完整的论证。同样512个token在老挝语里是303个字符，装不下一个完整的句子。

后果是什么？检索出来的片段在英语里是自洽的，在老挝语里是半截话。半截话喂给模型，模型要么理解错，要么当成噪声丢掉。

解法不复杂，把切块参数从token数改成字符数，或者按语言各设一个值。判断自己有没有中招也简单：抽二十个切出来的块，找母语者看一眼，问一句这一段能不能单独读懂。

## 长上下文方案在哪几门语言上不成立

这两年流行一种做法：不做检索，直接把整个知识库塞进超长窗口。这个做法在英语上确实省事。

它成不成立取决于两个数：你的知识库有多少字，这门语言的容量比例是多少。

假设知识库是40万字符。英语下这是128K窗口的63%，能塞。德语88.8%的容量，还剩点余地。泰语48.1%，塞不下，得砍一半。老挝语12.0%，只能塞进去七分之一多一点。

所以同一个架构决策，在语言清单上到某一行就会失效，而失效那一行在哪儿取决于你的知识库多大。这是个可以提前算出来的边界，不必等上线才发现。

更麻烦的是失效方式不报错。塞不下的时候框架通常是静默截断，你只会看到某几门语言的回答质量莫名其妙差一截。这一条会跟小语种幻觉那件事 (https://zhangwenbao.com/low-resource-language-ai-hallucination-rate-content-risk.html)叠加：没有材料的时候模型不会说不知道，它会编。

## 这笔账落到日常的活上，一共要重算几处？

## 关键词表：500词在老挝语里值九千个块

先从最常见的那份文件说起。

拿14个电商品类词做样本，量各语言的平均值：英语每词2.3个token，德语3.5，俄语4.4，泰语5.2，僧伽罗语6.9，缅甸语7.6，阿姆哈拉语8.2，老挝语18.2。

换算成一张500词的关键词表：英语1142个token，德语1750，泰语2576，缅甸语3818，老挝语9100。

如果你的流程里有“把整张词表塞进提示词让模型对照改写”这一步——很多团队都有——这一步在老挝语上的单次成本是英语的近8倍。

更要紧的是它可能塞不下。塞不下的时候框架会截，截掉的是词表尾巴，而词表通常按重要性倒序排，尾巴上是长尾词。症状会长成这样：小语种版本的改写结果里长尾词覆盖特别差，团队第一反应是模型对这门语言不熟，实际上是词表根本没进去。

## 批量改写与翻译：按篇计价的报价单会失真

回到开头那份报价单。

供应商按篇报价没有恶意，人工翻译就是这么算的。问题是他们的成本结构里有一大块是接口调用，而那一块是按token计的。

倍数在1.2到1.6这一档时，供应商自己吸收掉了，没人会为百分之几十去改报价单。到了3倍以上，这笔差价就吃掉利润了，于是要么他们涨价，要么他们降配——换更便宜的模型，或者砍掉一轮质检。

降配这条路对你更危险，因为它不通知你。你看到的还是同样的交付物，只是这门语言的质量悄悄差了一档。省掉的那道工序最后要拿收录和排名分期还 (https://zhangwenbao.com/machine-translation-direct-publish-search-risk-quality-line.html)，这条老账在这儿换了个形式又出现一次。

所以采购这类服务时值得多问一句：这几门语言你们用的是同一个模型和同一套流程吗。这个问题不需要对方给证据，问出来本身就有作用。

## 站内的AI客服与问答

这是唯一一处成本按用户量而不是内容量走的地方，所以它的账最容易失控。

每一次对话都要带上系统提示词、检索到的片段、历史轮次。这三样在小语种下全都膨胀，而且是叠加的。

假设一次对话平均消耗3000个token，其中2000是检索片段和历史。在3倍膨胀的语言下，同样内容的这2000会变成6000，单次对话成本翻一倍以上。

更麻烦的是历史轮次。轮次越多，历史越长，膨胀的绝对量越大。所以小语种的对话会更早撞上轮次上限，被迫截断或者重开。用户那一侧的体验是：聊到第五轮机器人开始忘事，而英语用户聊到第十五轮才会遇到同样的事。

## 免费额度与限流：同样的额度不是同样的工作量

最后这一处最容易被忽略，因为它不出现在任何账单上。

各家平台的免费额度、速率限制、并发上限，单位全是token。同样的额度，在英语上够跑完一天的活，在3倍语言上只够三分之一。

限流触发的时候表现是接口报错或者排队，运维会看到，但很少有人把它跟语言联系起来。日志里只有请求失败，没有语言这一列。

所以有个很小但很有用的动作：给调用日志加一列语言标签。加完之后所有按语言分化的问题都会自己浮出来，不只是限流。本站写语言判定那篇 (https://zhangwenbao.com/minor-language-page-language-detection-misidentification-short-text.html)里说过同一句话——把关键指标按语言拆开看，它几乎是所有语言层问题的通用破法。

## 三代词表的进步，到底分给了谁？

## p50k到o200k，各语言省了多少

词表换代这件事，厂商的说法通常是一句“对多语言支持更好了”。好多少，好给谁，没有清单。

这次三代都跑了，可以把这份清单补出来。省下的百分比按从多到少排：泰米尔语87.4%、马拉雅拉姆语87.2%、格鲁吉亚语87.1%、卡纳达语85.6%、古吉拉特语85.4%、泰卢固语85.3%、孟加拉语82.4%、亚美尼亚语82.2%、缅甸语81.3%、印地语79.0%。

另一头：英语4.2%、乌兹别克语24.6%、阿姆哈拉语25.3%、他加禄语27.4%、丹麦语28.7%、意大利语28.9%。

这份清单里有两条完全不同的信息。第一条是好消息：印度诸语和高加索几门语言的膨胀被砍掉了将近九成，它们从“贵得离谱”变成了“略贵”。如果你的成本模型是两代词表之前建的，这几行现在全部作废。

第二条是坏消息，而且藏得比较深，下面两节分开说。

## 英语自己只省了4.2%

英语从28055降到26878，三代下来省了4.2%。

这个数字说明一件事：词表扩容的收益英语基本没拿到。这不奇怪，英语在p50k那一代就已经接近饱和了，常见词早就全是整块，再扩四倍词表也没多少可优化的。

所以扩容的四倍空间几乎全部分给了非英语。这一点值得说清楚，因为“厂商不管小语种”这个印象在中文圈里挺普遍，实测数据不支持这个印象。

他们管了，而且管得力度不小。问题在别的地方。

## 最需要改善的两门语言拿到的最少

坏消息在这儿。

阿姆哈拉语的膨胀倍数是5.82，全场第二贵。它从p50k到o200k只省了25.3%，是所有非英语语言里改善幅度最小的。

老挝语8.23倍，全场最贵，省了37.7%，同样排在末尾那一档。

换句话说：改善幅度最大的是本来就还行的那一批，改善幅度最小的是本来就最惨的那一批。

根子在分配规则：扩容之后新增的位置还是按语料频率分，语料最少的那几门依然排在最后。一篇逐语言评估分词质量的研究 (https://arxiv.org/abs/2012.15613)指出过一条出路——为单语言单独训一套词表比共享一套大词表更好，但那是训模型的人的选项，不是用模型的人的选项。

## 这不是单调关系，是一条倒U形曲线

我开工前的第二条预期写的是“改善幅度跟语料量正相关”。实测下来这条是错的，而且错得很有意思。

正确的形状是倒U形：语料量最大的那一头（英语）几乎没有改善空间，语料量最小的那一头（老挝语、阿姆哈拉语）拿不到新增位置，改善最大的是中间那一段——有一定量、但在旧词表下还没被充分覆盖的语言。

印度诸语、格鲁吉亚语、亚美尼亚语、缅甸语全都落在这一段。

这个形状有个直接的预测价值：如果你的语言现在的倍数在1.5到3之间，下一代词表大概率还会给你一些改善；如果已经在4倍以上，别等了。

## 内容供给量能不能预测这个倍数？

## 拿维基条目数做代理指标

前面反复说“语料量决定一切”，这一节把它验成一个数。

训练语料的组成没有公开，没法直接查。但有个现成的代理指标：这门语言的维基百科条目数。它跟一门语言在互联网上的内容存量高度相关，而且随时可查。

本站在算小语种优先级那篇 (https://zhangwenbao.com/minor-language-seo-priority-language-cost-model.html)里就用过它，当时的用途是判断竞争密度。现在它多了一个用途。

我取了能拿到数的19门语言，把条目数和膨胀倍数都取对数之后算相关系数。

## 十九门语言的相关系数是-0.734

把两头的数摆出来看更直观。

条目数最多的五门：英语7217635条对应1.00倍、德语3140245条对应1.31倍、法语2772345条对应1.37倍、荷兰语2224227条对应1.25倍、西班牙语2128835条对应1.32倍。

条目数最少的五门（这19门里）：蒙古语27943条对应1.89倍、希腊语271523条对应2.14倍、希伯来语402074条对应1.48倍、乌尔都语668470条对应1.65倍、土耳其语693272条对应1.43倍。

再把没进这19门统计的两个极端加上：老挝语维基5594条，8.23倍；泰语185785条，1.99倍。这一对正好补上曲线的最右端，也是全篇最干净的那组对照。

## 这跟本站量过的另外两把尺子怎么合起来看

本站到目前为止量过三把跟“这门语言值不值得做”有关的尺子，这是第三把。

第一把是内容供给密度，回答“有没有人跟你竞争”。第二把是工具返回零之后自己补出来的需求量 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)，回答“有没有人在搜这类东西”。这一把回答的是“机器处理它要多花几倍”。

三把尺子的有意思之处在于它们并不同向。老挝语在第一把上是机会（本地几乎没人写这门语言的商业内容），在第三把上却是全场最贵。同一门语言，一个信号说进，一个信号说别用机器做。

僧伽罗语也是这样：供给侧几乎空着，倍数2.69偏贵。这组合的意思是——值得做，但要控制机器工序的用量，人写比机器写划算。

## 不懂这门语言，怎么自己把这个数量出来？

## 三十分钟能跑完的最小实验

这一节把整套方法压成可以照抄的步骤，不需要懂那门语言，也不需要懂机器学习。

要准备的东西只有三样：一份平行语料、一个tokenizer库、一台能跑Python的电脑。

整个流程是：下载语料、取出你要的那几门语言、每门语言数一遍token、除以英语那一份。

输出是一张表，两列——语言，倍数。加上字节回退率就是三列。

## 平行语料从哪儿拿

首选还是FLORES-200，理由前面说过：专业译者翻的、句句对齐、204门语言、公开可下、版本固定。

下载下来是个压缩包，二十几兆，解开之后每门语言一个纯文本文件，一行一句。文件名是三字母语言码加书写系统码，比如泰语是tha_Thai，老挝语是lao_Laoo。

如果你的语言不在里面（204门覆盖得已经很广，但确实有漏的），替代方案是拿你自己站上的真实内容——同一批商品描述的各语言版本，效果更贴近实际，只是各语言之间未必严格对齐。

用自己的内容还有一个额外好处：能测出你的内容特性带来的差异。技术类内容英文术语多，膨胀会低于通用语料；生活类内容本地词多，膨胀会高。

## 三行代码算出你的倍数

核心的代码真的只有三行：加载编码器、读文件、数长度。

先装tiktoken，然后取o200k_base这个编码，把整个文件的内容读成一个字符串，调用encode方法，取返回列表的长度。

对每门语言重复一遍，最后拿各语言的数除以英语的数。

要注意两件事。第一，别逐句编码再相加，跟整篇编码的结果会有出入——词的前后有没有空格会改变切法，而这件事在非拉丁语言上尤其不稳定。第二，第一次运行时库要联网下载词表文件，几十兆，之后就有缓存了。

## 字节回退率怎么算

这一列比倍数更能说明问题，而且算起来只多五行。

做法是：编码之后拿到token列表，对每一个token单独调用解码成字节的方法，然后试着把这段字节按UTF-8解码成字符串。

能解码成功的，说明这个token本身是一个或多个完整的字符。解码失败的，说明它只是某个字符的一截。

数一下失败的比例，就是字节回退率。

## 把结果读成三档动作

数量出来之后要落到动作上，不然就是一张没人看的表。我用的是三档。

1.0到1.8倍：不用管。按现有流程做，成本差异在预算的噪声范围内。这一档覆盖了大多数欧洲语言和东南亚的几门主要语言。

1.8到3.0倍：值得优化，但不改架构。具体动作是把术语表从提示词里搬出来、检索片段数减一点、质检改成抽样。这几个动作加起来能省掉大半差价。

3.0倍以上：改架构或者改分工。长上下文方案在这一档不成立，大批量AI改写在这一档不划算。正确做法是把机器工序压到最少，把预算移到人工那一侧——这一档的语言通常也是竞争最稀薄的，人工写出来的东西性价比反而更高。

## 三种看着合理、实际会把结论带偏的做法

## 用字符数直接推token数

最常见的一种。手上有一门语言的倍数，看到另一门语言字符数差不多，就直接套用。

老挝语和英语的字符数只差1.5%，倍数差8.23倍。这个反例就够了。

更细一点的错法是拿书写系统套。看到两门语言都用天城文，就默认倍数接近。印地语1.57，马拉地语1.82，差16%，还算接近；但泰文的1.99和老挝文的8.23，两套亲戚文字，差4倍。

正确做法只有一个：实测。二十分钟的事，没有任何理由用估的。

## 拿一门语言的倍数代表整个书写系统

第二种是前一种的升级版，也更常见于技术方案里。

比如在配置里写一条规则：非拉丁文字的语言，切块大小减半。这条规则会同时误伤和漏掉两批语言。

误伤的是阿拉伯语1.38、希伯来语1.48、俄语1.42、简体中文1.25这一批——它们全是非拉丁，倍数却比德语法语还低，减半等于白白损失一半上下文。

漏掉的是约鲁巴语2.17、马耳他语1.87、祖鲁语1.72这一批——全是拉丁字母，规则不会触发，但它们真的需要调整。

## 把这个倍数当成放弃一门语言的理由

第三种是决策层面的误用，代价最大。

会上摆出一张表，某门语言8.23倍，很自然会有人说：那这门语言太贵了，先别做。

这个推理有两处漏洞。第一，8.23倍贵的是机器工序，不是整个市场。人工写作、外链、页面开发的成本一分钱没变。

第二，倍数高的语言恰好是内容供给最稀薄的语言——因为两件事都由同一个原因决定，这门语言在互联网上的内容少。内容少意味着机器难做，同时也意味着竞争少。

所以正确的结论不是“别做”，是“别用机器做”。这两句话在排期表上导向完全不同的动作：前者删掉一行，后者把那一行的预算从接口费挪到人工费。

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

最后划一下边界，免得这篇被当成一个万能解释。

模型在这门语言上答得准不准，不归这一层。那是训练数据和模型能力的事，跟切成几块没有直接关系。

页面能不能被搜索引擎正常收录和匹配，不归这一层。搜索引擎的分词是另一套机制，本站泰语那篇讲的是那一套。

字体大小、排版、首屏加载，不归这一层。那是字形集和字体文件的事 (https://zhangwenbao.com/minor-language-web-font-glyph-set-first-screen-cost.html)，判据是书写系统，跟这里正好相反。

## 常见问题解答

## 换一家模型厂商，这些倍数还成立吗？

绝对数字会变，相对关系基本不变。我这次用的是tiktoken那一系的三代词表，别家模型有自己的词表，规模和构成都不同，同一门语言的倍数会有出入，通常在正负三成以内。但排序几乎不会变——语料多的语言便宜、语料少的语言贵，这条是由词表的构建方式决定的，不是某一家的选择。真要用在决策上，最稳妥的做法是拿你实际在用的那家的分词库重跑一遍，方法完全一样，改一行代码。有一个例外值得注意：有些厂商会为特定语言单独优化词表，如果你的核心市场恰好在那个名单上，实测出来的数会明显好于通用规律，这种情况只能靠实测发现，公告里通常不写。

## 字节回退率高的语言，模型是不是根本理解不了？

不是。回退高只影响效率，不直接影响理解。模型在训练时见过大量这种字节序列，它有能力从字节层面重建语义，只是要多花几层计算。实际表现上，这类语言的理解质量确实偏弱，但主因是训练语料少，不是切分方式——两件事由同一个原因导致，容易被混为一谈。判断方法很简单：找一段这门语言的文本，让模型复述一遍，看它有没有理解错。多数情况下它复述得没问题，问题出在需要专业知识或本地事实的时候，那是知识层的缺口，不是切分层的。所以看到回退率高，该调整的是成本预期和上下文预算，不是对模型能力的判断。

## 把内容先翻成英语再喂给模型，是不是能省掉这笔钱？

能省token，但会付出别的代价，而且多数场景下不划算。先翻成英语意味着多一次调用（翻译本身也要花钱），而且原文的信息会在中转的那一步损失一部分——语法信息、语气、专有名词的本地写法。更实际的问题是产出：如果最终要的是这门语言的内容，模型用英语想完再翻回去，出来的东西会带着英语的句式和结构，母语者一眼能看出来。这套做法只在一种场景下成立：你要的输出是结构化数据或者判断结果，不是可读的文本。比如让模型判断一段评论是好评还是差评，先翻英语再判断是可以的，因为输出只有两个字。要产出内容，别中转。

## 这个倍数会不会影响我的页面在AI答案里被引用的机会？

有间接影响，但不是决定性的。检索系统给每个候选来源的篇幅是有限的，同样长度的内容在高膨胀语言里占的位置更多，被截断或者被排除的概率相应更高。不过引不引用你，首要判据还是内容本身对不对得上问题，其次是来源可不可信，切分效率排在很后面。所以不必为这件事改写内容。真要做点什么，方向是让关键结论出现在段落靠前的位置——被截断的时候前面那部分留下的概率更大。这条建议在任何语言上都成立，只是在高膨胀语言上收益更明显。至于你的语种到底有没有被点亮 (https://zhangwenbao.com/ai-overviews-100-countries-six-languages-minor-language-citation.html)，那是更前置的一个问题，得先过了那一关这一层才有意义。

## 这套测量多久重跑一次？

一年一次就够，跟着词表换代的节奏走。词表不是频繁更新的东西，一代能用一两年，季度级的重跑纯属浪费时间。重跑的时机有两个信号：一是你在用的模型换了大版本，二是你的语言清单里加了新市场。第一个信号触发的是全表重跑，第二个只需要跑新增的那几门。重跑的时候语料必须固定用同一批句子，否则量到的是语料差异而不是词表差异，这一点前面强调过，因为它是最容易犯的错。跑完把新旧两版表并排放，改善明显的语言可以考虑把机器工序的比重往上调一档。

## 权威参考资料



## AI概览一次铺到100多个国家，可点亮的语言只有6门，你的语种大概率不在里面

- URL：https://zhangwenbao.com/ai-overviews-100-countries-six-languages-minor-language-citation.html
- 分类：小语种SEO
- 发布：2024-11-19  |  更新：2026-07-27
- 摘要：官方公告里国家数是三位数，语言数只有六门，德语法语一门都不在。讲清这两个坐标怎么拆开测，已点亮的语言里段落该怎么改，以及语序为什么决定一句话能不能被摘去当答案。
- 关键词：出海SEO,多语言SEO,AI概览,小语种SEO

> **TLDR**：摘要：官方那句一次铺到100多个国家，说的是国家数，不是语言数。同一份公告里的语言名单只有六个词，德语法语意大利语荷兰语一个都不在。这篇讲清国家坐标和语言坐标怎么拆开测，已经点亮的六门语言里引用位靠什么抢，以及一件中文圈几乎没人提的事：一段话能不能被摘出来当答案，跟这门语言把谓语放在哪儿有关。

> 摘要：官方那句一次铺到100多个国家，说的是国家数，不是语言数。同一份公告里的语言名单只有六个词，德语法语意大利语荷兰语一个都不在。这篇讲清国家坐标和语言坐标怎么拆开测，已经点亮的六门语言里引用位靠什么抢，以及一件中文圈几乎没人提的事：一段话能不能被摘出来当答案，跟这门语言把谓语放在哪儿有关。

## 官方公布的是国家数，你真正要的是语言数，这两个数差了多少？

## 一次点亮100多个国家，语言名单上只有六个词

先看原始表述。AI概览扩到100多个国家和地区的官方公告 (https://blog.google/products-and-platforms/products/search/ai-overviews-search-october-2024/)写得很清楚：覆盖范围超过100个国家和地区，月活用户超过10亿。

同一篇公告里还有另一句，位置靠后，字数少得多。

语言支持包括英语、印地语、印尼语、日语、葡萄牙语和西班牙语。

六个词。三位数的国家，一位数的语言。

这两个数字放在一张幻灯片上，读者本能会去记那个大的。市场部记住了100多个国家，转头就把方案要求发到了你手上。

而你要回答的问题其实是：我这门语言在不在那六个词里面。

国家和语言是两个独立坐标，公告合并公布，你的报表不能跟着合并。德国在那100多个国家里，德语不在那六门语言里。这两句话同时成立，不冲突，可它们对一个德语站的意义完全相反：前者说你的市场被覆盖了，后者说你的用户用德语提问时什么都不会发生。会议室里如果只念前半句，接下来三个月的预算就会花在一个还没开门的入口上。

还有一个细节值得留意：公告里的语言那句话没有配任何图表，而国家那句话配了地图。版面权重本身就是一种口径表达——放在图上的数字会被记住，藏在正文里的名单不会。你在内部转述这份公告时，最好反过来做，把六门语言那句话放大，把国家数缩小成一行注释。

## 你的国家在名单里，不等于你的用户能看到

把这件事想成一扇门有两把锁会容易些。

第一把锁是地理位置，第二把锁是查询语言。

公告开的是第一把。第二把要另一份名单说了算。

所以住在柏林的用户拿英语提问，可能会触发；同一个人换成德语问同一件事，什么都没有。

这个现象最容易被误读成产品不稳定，或者被误读成灰度还没铺到我这儿。

其实它非常稳定，只是稳定在另一个维度上。

我见过一个做厨房小家电的团队，德国站和西班牙站同期上线，两边用同一套页面模板、同一套结构化数据。西班牙那边测出来的触发率一路往上走，德国这边六周纹丝不动。团队开了三次会讨论德国站是不是技术上出了问题，查了渲染、查了抓取、查了结构化数据，最后发现德语根本不在那份语言名单上。三次会的时间，够把西班牙站的问答页再铺两轮。

## 为什么公布口径永远是国家数

这不是故意藏着。

国家数是产品发布的自然计量单位，法务、合规、广告库存都按国家算。

语言数则是模型侧和评测侧的计量单位，两边的排期本来就不同步。

更现实的一点：国家数好听。

100多个国家听起来像铺满了世界地图，六门语言听起来像还在小范围试。

两句话描述的是同一件事。

凡是官方公布的口径跟你的决策口径不是同一个单位，你就必须自己做一次换算，这条不只对这一次扩容成立。上一轮生成式搜索扩到120多个国家和地区那次 (https://blog.google/products/search/google-search-generative-ai-international-expansion/)，公布的同样是国家数，语言那一侧当时也只加了四门。两次公告放在一起看，国家数从120涨到100多个的量级没变多少，语言数从四门涨到六门，一年只多了两门。

还有一层更实际的原因：语言状态是会回退的。某门语言短期内开出来又收回去，在这个阶段并不罕见，而国家开出去基本不会收。公布一个不会回退的数字，比公布一个可能要改口的数字安全得多。

## 先把这两个数字在自己的报表里拆开

动手成本很低，一次改完受益一整年。

报表里加一个查询语言字段，跟国家字段并列，谁都不许合并。

历史数据回填不了就从今天起算，别为了好看去补。

再加一个字段记这门语言在官方名单里的状态，只有三个值。

没进、进了、进了但没测过。

第三个值最容易被跳过，可它才是大多数团队的真实状态。

这套字段拆分跟俄语市场那次要把语言和国家拆成两个独立字段 (https://zhangwenbao.com/russian-language-market-seo-decision-after-2022-geopolitical-shift.html)的教训是同一件事，只是这回逼你拆的不是地缘变化，是一份公告里两个不同量纲的数字。当时是市场没了语言还在，这回是国家点亮了语言还没亮。方向相反，账要分开记这一点没变。

字段名怎么写也顺手定下来。查询语言那一列建议直接用语言标签的标准写法，RFC 5646定义的语言标签格式 (https://www.rfc-editor.org/rfc/rfc5646)里de-DE和de-AT是两行，pt-BR和pt-PT也是两行，将来要按地区再切一刀时不用重做。

## 那六门语言是怎么选出来的，跟上一轮有什么不一样？

## 名单跟一年前那次几乎是重合的

把两份名单摞在一起看，重合度高得有点意外。

一年前那次扩语进去的是印地语、印尼语、日语、葡萄牙语、西班牙语和韩语。

这一次的名单是英语、印地语、印尼语、日语、葡萄牙语、西班牙语。

换句话说，主体是同一批，节奏并不是每季度加几门。

大规模扩的是国家，语言那一侧基本按兵不动。

这个观察比任何预测都有用，因为它告诉你等待的单位不是月，是年。

语种覆盖的推进节奏跟国家覆盖的推进节奏差了一个数量级，而绝大多数排期表把两者当成同一条线在画。如果你的德语站排期表里写着预计下季度覆盖，那份排期表的依据多半是国家数那条曲线。按语言数那条曲线重画一遍，得到的日期会往后挪一年以上，方案的形状也会跟着变——那不是等待期，那是可以拿来干别的事的一整年。

两份名单唯一的实质变化是韩语出去了、英语进来了。英语本来就是默认语言，把它写进名单更像是口径统一，不算新增。这么算下来，一年之内真正新点亮的语言数是零。

## 六门里有两门是宾语放在动词前面的语言

这句话现在看像是语言学趣闻，往下读你会发现它是本文最实用的一段。

日语和印地语都是宾语在前、动词在后的语序类型。

印尼语、葡萄牙语、西班牙语和英语则是动词在宾语前面。

六门语言，两种截然不同的句子骨架，各占一半。

这个分布不是巧合，也不是设计，就是名单碰巧长这样。

但它意味着两套完全不同的段落改写策略，后面第四节整节都在讲这件事。

想先确认自己那门语言属于哪一类，世界语言结构地图集里主语、宾语与动词语序那一章 (https://wals.info/chapter/81)按语言列了表，查起来两分钟。土耳其语、韩语、芬兰语的一部分句式跟日语同属一类，德语和荷兰语属于第三种情况（主句里动词在第二位、从句里跑到最后），后面会单独讲。

顺带纠正一个常见的误解：语序类型跟语言难不难学、语料多不多、字母像不像英语，三件事互不相关。日语和印地语用的书写系统天差地别，语序类型却在同一格里；德语和英语的词汇高度同源，语序类型却分属两类。

## 名单不动的这一年，模型侧其实一直在扩

这里有个反差值得记下来。

产品侧的语言名单一年只多了两门。

底层模型能处理的语言数在同一时期是几十上百门在涨。

两者之间的差值不是技术差距，是运营决策的差距。

能不能生成是一回事，敢不敢在一个国家默认开出来是另一回事。

后者要考虑的是评测人力、法务口径、错误的舆论成本。

这条判据在上一轮扩语顺序的观察里 (https://zhangwenbao.com/sge-non-english-language-coverage-early-observation.html)已经验证过一次：语言开放是运营决策不是技术决策，所以按书写系统难度、按语料规模、按现有搜索份额去推上线顺序，全部失效。这一次的名单再次证实了它——如果按语料规模排，德语法语早该进去了。

这个差值是可以自己量的。拿翻译类产品公开的语言支持清单当参照，云端翻译服务的语言支持列表 (https://cloud.google.com/translate/docs/languages)是一百多门的量级，跟搜索侧那份六门的名单摆在一起，差距一眼就看出来了。能处理不等于会开放，中间隔着的是运营决策。

## 怎么用二十分钟测出自己的语种到底在哪一档？

## 三种状态要分开：国家没进、语言没进、进了但你的词不触发

这三种状态的表现在后台看是一样的，都是零。

处理方式却完全不同，混在一起就会做出反向的决策。

国家没进，你做什么都不会有反应，只能等。

语言没进，页面照做，但别指望这个入口带量。

进了但不触发，这一档才是真正能动手的。

而大多数团队在没分清之前，就已经开始改页面了。

第三种状态最容易被误判成前两种，原因很朴素：大多数人第一批测的是自己排名最好的那几个商业词，而商业词恰恰是触发率最低的一类。测完一轮全是零，结论就写成还没开放。真相是名单里有你，只是你挑的那批词不在触发范围内。这个误判的代价是整整一个季度的观望。

判断顺序也要固定：先确认国家，再确认语言，最后才测词。顺序反过来做，你会拿一堆触发率数据去解释一个根本还没开门的入口，越分析越糊涂，最后得出一个玄学结论。

## 十条通用疑问句的测法

方法粗糙但够用，二十分钟能出结论。

挑十条本语言的通用疑问句，不带品牌词，不带型号。

比如某个品类怎么保养、某个材质能不能进洗碗机、多久换一次。

用本语言、在目标国家的网络环境下逐条问一遍。

记三件事：有没有出概览、概览里挂了几条链接、链接落在哪个国家的域名上。

十条里出现三条以上，就可以判定这门语言在名单里。

这套测法沿用的是小语种问答长尾那篇里数供给密度的那套动作 (https://zhangwenbao.com/minor-language-qa-long-tail-content-value-ai-era.html)，区别只在于记录的字段：那边数的是前二十位里有几条在正面回答，这边数的是十条里有几条触发。共同点是都不依赖任何外部工具，打开结果页自己数就行——对一个连关键词工具都覆盖不到的语言来说，能自己测出来的指标本身就是稀缺品。

记录格式越简单越好，一张表五列：问句、有没有概览、链接条数、来源域名、测试日期。别加评分、别加分类、别加主观判断，这张表要能在一年后被另一个人原样重跑，多一列主观字段就少一分可比性。

## 别拿排名最好的商业词去测

这条值得单独写一节，因为它反复害人。

排名最好的词通常是商业意图最强的词。

商业意图强的查询，概览的触发率天然偏低。

用它们测，你会得到一个系统性偏低的结论。

更麻烦的是这个结论看起来很可信，毕竟样本是你最熟的词。

测覆盖用通用疑问句，测商业价值才用商业词，两件事分开做。

顺带说一句反过来的偏差：如果只用极长的疑问句测，触发率会偏高，你又会得出一个过于乐观的结论。测试词表的意图分布，必须跟你真实的流量意图分布大致对齐，否则测出来的是词表的性质，不是产品的性质。保哥的习惯是十条里放六条通用疑问句、三条比较型、一条商业词，比例固定下来，每次重测都用同一张表，这样跨月对比才有意义。

更稳妥的做法是把词表固定成两张：一张探测表，只管测覆盖，永远不变；一张业务表，跟着品类走，随时可换。两张表混用是绝大多数团队的现状，也是跨月数据没法对比的根本原因——你以为在观察产品的变化，其实在观察自己词表的变化。

## 一门语言的语序，会不会决定你的段落能不能被摘去当答案？

## 被摘出来的那一句，是从段落开头往后截的

先说一个大家都默认、却很少写下来的前提。

摘要不是把整段读完再重写，很多时候是从头往后取一小段。

取多长，取决于版面和字符预算，不取决于你那句话说完没说完。

换句话说，截断点落在哪儿，你说了不算。

英语内容营销这二十年练出来的应对方式叫结论前置。

把答案放在第一句的前半部分，后面截掉多少都不影响。

问题是结论前置这个动作在不同语言里的可行性根本不一样，而这件事几乎没人讲。它不是写作习惯问题，是句法问题：有些语言允许你在句子前三分之一就把核心信息交代完，有些语言的语法结构逼着你把最关键的那个词留到最后。前者截断无害，后者截断致命。Unicode断行算法那份技术报告 (https://unicode.org/reports/tr14/)规定的是在哪里可以断，不负责断了之后那句话还成不成立——后半件事归你管。

## 主谓宾在前面的语言，截断也还成立

先看好办的那一类。

西班牙语、葡萄牙语、印尼语、英语都属于动词在宾语前面的类型。

一句话的主干在前三分之一就交代完了。

后面接的多半是修饰、条件、例外、补充说明。

砍掉这些，句子会变得不精确，但方向不会反。

读者读到半句，知道的仍然是你想让他知道的那件事。

这也是为什么英文世界那套答案段落写法看起来这么天经地义：它是在一个截断友好的语序上发育出来的。尼尔森诺曼集团关于前两个词决定用户要不要往下扫的研究 (https://www.nngroup.com/articles/first-2-words-a-signal-for-scanning/)做的是英语界面，结论在英语里成立得非常好——因为英语句子的前两个词确实承载了足够的信息量。同一条经验搬到语序不同的语言上，成立度会掉一大截。

这里也有例外要留意。西班牙语和葡萄牙语的形容词在名词后面，一串修饰语拖得很长时，截断会把限定条件砍掉——比如某个只适用于特定型号的说明，砍完就成了适用于全部型号。方向不反，范围会变大。

## 谓语在句尾的语言，截断会把结论砍掉

现在看麻烦的那一类。

日语和印地语的谓语在句子末尾，否定成分也在末尾。

这意味着一句话的肯定还是否定，要读到最后一个词才知道。

三营业日内免费配送，这句话的免费两个字在日语里排在很后面。

而不接受退货这种表达，否定的部分同样压在句尾。

从前面截一半，剩下的可能是一个意思悬空的半句，也可能是意思正好相反的半句。

这不是理论推演，是可以自己验的：拿本语言的一段商品说明，用工具砍到120个字符，然后请母语同事只读这半句、说出他理解到的意思。做英语和西班牙语的时候，多数人能说个八九不离十；做日语的时候，你会看到对方读完抬头问一句所以到底能不能退。这个实验做一次，比读十篇方法论管用。通用依存语料库里日语那份句法标注 (https://universaldependencies.org/ja/index.html)可以直接看到谓语中心在句子里的位置分布，不用自己数。

## 德语那个把动词甩到句尾的框型结构

德语是第三种情况，也是最有意思的一种。

主句里动词排在第二位，看着跟英语差不多。

可一旦用了情态动词、完成时，或者写成从句，实义动词就跑到句子最后去了。

德语语法把这个叫作框型结构，前后两个动词部分像一副夹子把整句夹住。

夹子的后半边掉了，前半边单独看常常什么都没说。

而商业页面上的句子，恰恰最爱用情态动词和从句。

所以德语的问题跟日语不完全一样：日语是稳定地把谓语放最后，德语是在一半句式里把关键动词甩到最后。稳定的困难可以系统性绕开，不稳定的困难要靠逐句检查，后者的工程成本反而更高。德语的依存标注 (https://universaldependencies.org/de/index.html)和 宾语与动词语序那一章 (https://wals.info/chapter/83)放在一起看，能直观看出这门语言为什么会被归到一个单独的类型里。顺便说，德语的复合词还会把整个概念压进一个长单词，截断时连词都可能被砍成两半，这是德语复合词那篇 (https://zhangwenbao.com/german-seo-compound-words-umlaut-eszett-keyword-research.html)讨论过的老问题在新场景下的回声。

## 怎么把一段话改成截断之后还站得住的形态？

## 首句自足性：砍到120个字符还成不成立

给这件事起个名字，团队里才好交接。

叫首句自足性，判据只有一条：砍到120个字符，这句话还说不说得通。

120这个数不神圣，按你自己观察到的截断长度调。

关键是把它写进验收清单，变成一个可以被打回的项。

检查方式极其原始：复制、截断、找母语同事读一遍。

不需要懂那门语言的人也能组织这道工序。

把一个语言学问题降级成一道机械工序，是小语种质量控制里唯一可规模化的路子。你不可能给每门语言都配一个语言学家，但你可以给每门语言配一条能被外行执行、被母语者判定的检查规则。这条思路跟母语审校验收清单那篇 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)是一脉相承的：审校说读着自然不能当验收通过，得给出可判定的具体项，这里的具体项就是截断之后还成不成立。

这道检查还有个附带产出：它会顺手暴露出一批写得又长又绕的段落。这类段落在传统搜索里只是可读性差一点，在被截断的场景下则是直接失效。所以哪怕这个入口一直不开，这道工序也不算白做，它本质上是一次针对本语言的可读性体检。

## 否定词的位置比否定这件事更重要

这一条是上面那条的特例，但值得单拎出来。

凡是句子里含否定的段落，都要当高危段落处理。

因为截断造成的最坏结果不是信息缺失，是意思翻转。

缺失读者会去点开原文，翻转读者会直接照着错的做。

能不能退、含不含税、需不需要预约，这几类句子最容易出事。

解法很土：把否定的结论用一个独立的短句先说一遍，再展开条件。

做户外露营装备的团队最容易踩这个坑，因为他们的页面上全是这类条件句：某型号帐篷不适合零下10度以下使用、某燃料在部分国家不能空运。这些句子在日语和德语里写完，否定部分都在后半段。把它们改成先给结论、再给条件的两句式，字数会多一点，但截断之后不会变成一句鼓励你带着它上雪山的话。

还有一类更隐蔽的：双重否定和让步句。不是不能退，只是需要先联系客服，这种句子在多数语言里从前面截一半，剩下的都是不是不能退那半截，读者拿到的印象跟你想表达的完全相反。这类句式在本地化文案里出现频率很高，因为它读着委婉。

## 条件从句要前置还是后置

顺着上面接着说，条件句是第二个高危区。

如果满足某某条件则免运费，这种句式在中文里也常见。

截断如果落在条件说完、结论还没出的位置，读者拿到的是半个前提。

比较稳妥的写法是先给主结论，再补条件。

但这条不能一刀切，有些语言的自然语序就是条件在前。

硬改会得到一段读着别扭的本地文案，得不偿失。

判断方法是问母语同事一句话：这样写读着别不别扭。别扭就退回原语序，改成把结论重复一遍放在段首。宁可让段落显得啰嗦一点，也不要让它在截断之后说出你没打算说的话——多一句重复的成本是几个字符，说反了的成本是一次投诉加一条负面。

顺便说一句技术侧的事：截断落在哪儿并不总是按字符数硬切的，UAX #29定义的文本分段规则 (https://unicode.org/reports/tr29/)给出了词与句的边界判定方法，实现上通常会往前找一个合法边界。这解释了为什么同样长度的两段话，截出来的位置能差好几个字。

## 这套改写为什么不能靠翻译英文模板？

## 结论前置是英语内容营销训练了二十年的文体

先承认它的价值，再说它的边界。

英文内容里那种开门见山的答案段，是长期训练出来的产物。

写作课教它，编辑规范里写着它，工具在提醒它。

二十年下来，它成了英语商业内容的默认文体。

默认到大家忘了它是被训练出来的，以为它天然如此。

于是一翻译，连同这个文体一起搬了过去。

一种文体能不能被直接移植，取决于目标语言的句法给不给它落地的位置。结论前置在西班牙语里落得下去，在日语里落下去要动语法结构，不只是换词。这时候翻译出来的东西会呈现一种很特别的状态：每个词都对，整段读着不像本地人写的，而且不像的地方说不上来在哪儿。母语审校往往只会打一个语感不佳的标记，说不出根因。

顺着这条线还能推出一个更一般的结论：任何一种写作规范，都带着它诞生时那门语言的语法假设。字符数上限带着英语的信息密度假设，段落结构带着英语的语序假设，标题写法带着英语的中心词位置假设。搬到别的语言之前，先问一句这条规范默认了什么，比直接问它适不适用有用得多。

## 多数小语种的商业页面里没有这种段落

这是个供给侧的观察，跟需求无关。

打开任意一门小语种的品类页面，从头读到尾。

你很难找到一段专门用来正面回答一个问题的文字。

有的是产品参数、品牌故事、促销信息、法务声明。

不是本地同行不会写，是这门语言的商业网页从来没有这个写作传统。

英语世界里那批内容营销从业者干了二十年的事，在很多语言里根本没发生过。

这件事换个角度看是天大的好消息：引用位在小语种市场里不是被本地强者占着，是空着没人接。不是竞争激烈到你挤不进去，是整个语种里能被摘出来当答案的段落供给量极低。你要做的不是打败谁，是在一片没人写这种段落的语言里，成为第一个写的。这个窗口不会一直开着，但它现在确实开着。

可以做个粗糙的普查：随机挑二十个本语言的品类页，统计有几个页面里存在至少一段直接回答问题的文字。英语站做这个统计，命中率通常过半；换成中小语种，命中率掉到一两成是常事。这个数字自己十分钟能测出来，比任何行业报告都贴近你的真实处境。

## 直译英文答案段会同时错两处

把上面两条合起来，就能看清直译的双重问题。

第一处错在语序上，结论落到了句子后半段。

第二处错在语域上，那种斩钉截铁的英文断言语气在有些语言里显得没礼貌。

日语尤其明显，直白的断言配上敬体框架，读着别扭得很。

两处错叠在一起，就成了那种读得懂但没人愿意读完的文字。

而这两处错，各自的修法方向是相反的：一个要往前提，一个要往回收。

日语这一侧的具体处理办法，敬语层级那篇 (https://zhangwenbao.com/japanese-seo-keigo-politeness-levels-conversion-ranking.html)拆得比这里细：用户在搜索框里打的是常体裸词，页面上写的是敬体长句，同一个意思字面不是同一串。放到本文的语境下，这个裂缝多了一层后果——被摘去当答案的那一句，是从敬体长句的开头截的，而常体裸词的信息量都压在那个被截掉的尾巴上。

还有第三处容易被忽略的错：数字和单位。英文答案段里的尺寸、重量、温度往往用的是英制，直译过去数字不动、单位不动，本地读者要么换算不过来，要么直接读错。这一处不是语言问题，是本地事实问题，但它总是跟前两处一起出现。

## 引用位一共有几个，你到底在跟谁抢？

## 概览里挂出来的链接是个位数

先把盘子的大小说清楚。

一次概览里挂出来的来源链接，通常是三到五条。

不是十条，不是二十条，是个位数。

传统结果页第一屏能塞十个位置，这里砍到一半以下。

所以引用位是一种比排名位稀缺得多的资源。

稀缺意味着两件事：拿到的收益高，拿不到的落差也大。

值得提醒的是这个数字本身会变，改名并在美国全量上线那次的官方说明 (https://blog.google/products/search/generative-ai-google-search-may-2024/)里就调整过链接的呈现方式。所以别把三到五条当成一个可以写进模型的常数，把它当成一个需要每月重测的观测值。你的报表里应该有一列记录这个数字，而不是一句话写死在方案里。

还要注意这几条链接不是按排名给的。传统结果页的位置跟排名强相关，这里的来源选取更接近一种按内容片段挑选的行为，所以出现你排在第八位却被引用、排在第一位却没被引用的情况，属于正常现象，不必去改标题。

## 小语种里合格候选少，门槛低但位置也少

这一节是本文里最反直觉的一段。

直觉是小语种市场竞争小，所以容易抢。

前半句对，后半句不完全对。

竞争确实小，合格候选确实少。

但位置也少，而且不会因为你这门语言小就多给你几条。

所以正确的描述是：门槛低、位置少、进去之后份额高。

这是一个赢家通吃程度比英语市场更高的结构。英语里三到五个位置由几十个够格的候选来竞争，谁掉下来都有人补位；小语种里三到五个位置可能只有五六个够格的候选，一旦你进去了，就很难被替换掉——因为替换你需要另一个同样够格的候选，而这门语言里凑不出那么多。这个结构对早进入者的奖励，比对英语市场的早进入者大得多。

还有一个容易被忽略的后果：因为候选少，一旦本语言里出现了一份质量明显更高的内容，位置的更替会非常干脆。英语市场里的位置变动是缓慢的、渐进的；小语种里更像是一次替换，昨天还没有的东西今天占满了三条里的两条。这对后来者是机会，对已经在位的人是提醒。

## 抢不到位置的时候，第二条路是被当成事实来源

还有一种收益，不体现在链接上。

你的内容可能被读进去、被用来组织那段答案，却没有拿到链接。

这在英语市场是个争议话题，在小语种市场则是个概率更高的事件。

因为本语言里能提供本地事实的文档太少，你写的那份很可能是唯一一份。

拿不到链接当然吃亏，但影响还是发生了。

更要紧的是：如果你不写，那段答案会拿英语内容里的事实来填。

这就接上了另一个更严重的问题。本地规则类的事实——退货期限、尺码对照、税费口径、材质合规——如果本语言里没有权威来源，模型会用英语世界的默认值补上，读着通顺、格式正确、内容错误。低资源语言幻觉率那篇 (https://zhangwenbao.com/low-resource-language-ai-hallucination-rate-content-risk.html)把这类错误的四种形态拆得很细，本文只补一句：你把本地事实写清楚这件事，除了抢引用位，还有一层防守价值，它挤掉的是一个本来会被编出来的答案。

## 语言还没点亮的市场，现在做什么不算白做？

## 无悔投入和赌注投入要分开排

等待期最怕的不是不动，是乱动。

把手上的动作分成两堆，判据只有一条。

如果这个入口三年不开，这件事还有没有价值。

有价值的进无悔堆，没价值的进赌注堆。

无悔堆现在就做，赌注堆等语言点亮再说。

这条分法朴素到不像方法论，可它能挡掉八成的浪费。

举例说明会更清楚：把本语言的常见问题整理成结构清晰的问答内容，属于无悔投入——就算这个入口三年不开，它照样能拿传统搜索的长尾、照样能减少客服工单。而为了迎合某种猜测中的抽取格式去改写全站段落结构，属于赌注投入，因为它的全部价值都押在一个还没发生的产品行为上。无悔投入的判据不是收益高低，是收益依不依赖那个还没发生的事件。

## 先把本语言的问句表建起来

这是无悔堆里性价比最高的一项。

本语言用户到底怎么问问题，这件事跟产品有没有上线无关。

关键词工具在小语种上给不出数据，但问句可以从别处捞。

客服工单、评论区、社群提问、站内搜索日志，四个来源全是免费的。

捞出来按疑问词归类，一门语言两三天能整出几百条。

这份表在语言点亮那天，就是你唯一的先发优势。

关于工具没数据时怎么自己补，小语种关键词工具没数据那篇 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)列了三种土办法，可以直接搬。这里只补一条本文特有的做法：问句表要记录原始问法，不要归一化。用户打的那句啰嗦的、带语气词的、语法不规范的原话，恰恰是最接近真实查询的形态，被你整理成规范书面语之后就丢掉了最有用的信息。

表里还要留一列记语言标签，别只写语言名。同一门语言在两个国家的问法可能不一样，IANA维护的语言子标签注册表 (https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry)里能查到标准写法，用标签当主键，将来合并或拆分数据都不会乱。

## 基线数据现在不存，以后就没有对照组

这一条是纯粹的时间窗口问题。

语言点亮之后再想知道点亮之前是什么样，来不及了。

要存的东西不多，三条曲线足够。

核心问句集的点击率、品类页的入口占比、品牌词的搜索量走势。

每周存一次，一年也就五十来行。

没有基线，将来任何涨跌你都只能靠猜来归因。

这件事的价值要在一年后才兑现，所以它总是排期表上第一个被砍掉的项。保哥的经验是把它做成一个每周自动跑的脚本，让它不占用任何人的注意力——需要有人记得去做的事，一定会被忘记；不需要有人记得的事，才能坚持一年。至于抓取和引用之间本身就存在的时延，引用滞后那篇 (https://zhangwenbao.com/ai-citation-refresh-lag-llm-cutoff-rag-indexing-delay.html)拆过其中的机制，做归因时要把这段延迟一起算进去，否则会把上周的改动跟这周的波动错误配对。

## 怎么跟总部解释你这个市场的数字对不上？

## 一百多个国家这句话在会议室里的杀伤力

这是个沟通问题，但它消耗的预算是真的。

总部看到的是覆盖100多个国家和地区。

你所在的国家在那份名单里，这是事实。

于是问题变成了：别人都有数据，你为什么没有。

解释技术细节很难赢，因为对面记住的是那个大数字。

有效的做法是把两个数字并排放在同一张表上。

一列写国家覆盖状态，一列写语言覆盖状态，你的行是已覆盖加未覆盖。并排放置比任何解释都有效，因为它把一个需要理解的技术问题，变成了一个一眼能看见的表格错位。再补一行同样处境的市场——德国、法国、意大利、荷兰当时都在这一栏里——对方立刻明白这不是你的执行问题。

还有一个常见的追问要提前准备好：那为什么某某竞品有。多数情况下答案是他们测的是英语查询，或者他们的用户在那个国家用的本来就是英语。把这句话准备成一张截图，比临场解释有说服力得多。

## 用语言字段而不是国家字段做汇报

结构性的解法在报表口径上。

把汇报的主维度从国家换成查询语言。

同一份数据，换个主键，故事就顺了。

德国站的数据里混着英语查询和德语查询两拨人。

按国家看是一团糊，按语言看是两条清晰的曲线。

英语那条有反应，德语那条平的，一目了然。

这个改动还有个附带好处：它顺手解决了跨国语言的老问题。西班牙语的用户散在十几个国家，葡萄牙语横跨两个大陆，按国家切会把同一门语言的数据切碎，按语言切再按国家做二级维度，两边都能看。西班牙语两个市场关键词分叉那篇 (https://zhangwenbao.com/spanish-seo-es-es-latam-keyword-divergence.html)讲的是词表要拆，这里讲的是报表要拆，方向一致。

改口径要一次改到位，别做双轨。同时维护国家口径和语言口径两套报表，最后一定会出现两边数字对不上、每次汇报先花十分钟解释差异的局面。旧报表留一个快照存档，新报表从某个日期起全面切换，干净得多。

## 给每个结论配一个复检日期

最后这条是保哥这些年最受用的一个小习惯。

凡是写下德语暂未覆盖这类结论，后面必须跟一个日期。

不是完成日期，是复检日期。

写明这个结论在什么时候会失效、到那天由谁重测一遍。

没有复检日期的结论会在文档里躺成永久事实。

而这个领域里，六个月前的事实经常已经不是事实了。

复检日期还有一个隐藏作用：它把结论的所有权固定住了。写着待复检2025年3月、责任人某某的结论，比一句德语暂未覆盖有用得多，因为后者谁都可以引用、谁都不用负责，而前者到期会自动变成某个人的待办。

复检日期的间隔按变化速度定，别一律设成一年。语言名单这类事三到六个月复检一次比较合适；语序、句法这类语言本身的属性，一辈子不用复检。把结论按会不会过期分成两类，只给会过期的那类配日期，清单才不会膨胀到没人愿意看。

## 这套东西怎么排进现有的内容生产？

## 六周能排完的一轮节奏

给个可以直接抄的排期。

第一周测语言状态，十条问句跑一遍，出三档结论。

第二周建问句表，四个免费来源各捞一轮。

第三周挑二十个页面做首句自足性检查，先不改。

第四周按检查结果改写，只改高危段落。

第五周存基线，把三条曲线的脚本挂上。

第六周复盘，把复检日期写进文档，这一轮就算收口了。

六周里真正花人力的是第三第四周，其余四周加起来不超过三个人天。把成本压到这个量级，这件事才有可能在一个还没点亮的语言上被批准。如果你的方案要花两个月，那它在预算会上活不过第一轮提问。

这六周里有一件事必须排在最前面，就是第一周的测试。顺序错了会很难受：先改了页面再测，你会发现自己改的是一个还没开门的入口；先建了问句表再测，至少那张表是无悔投入，不会白做。所以测试排第一不是因为它最重要，是因为它最便宜且能决定后面几周的形状。

## 谁来做首句自足性检查

这道工序的分工要提前说清。

截断这个动作谁都能做，一个脚本或者一次复制粘贴。

判定截断之后成不成立，必须是母语者。

但母语者不需要懂搜索、不需要懂产品。

他要回答的问题只有一个：这半句话你读懂了什么。

把问题问成这样，一个客服同事十分钟能判二十条。

凡是需要专业判断的检查项，都要想办法拆成一个外行能执行的动作加一个母语者能回答的问题。拆不开的检查项，最后一定会因为排不上人而空转。这条经验适用于小语种质量控制的所有环节，不只是这一处。

判定结果只记三档就够：读懂了、读了个大概、读出来是反的。第三档要单独拉出来立刻处理，前两档进排期。分档越少，不同的人判出来的结果越一致，这道工序才能跨月对比。

## 母语审校的验收清单要加一条

老清单不用推翻，加一行就行。

原来的验收项是这段话读着自不自然、术语对不对、语气合不合适。

新增一项：这段话的前120个字符单独拿出来，说不说得通。

这一项跟前面所有项都不冲突，也不增加多少工作量。

但它挡住的是一类原来完全没人负责的问题。

验收清单的价值不在于严格，在于把没人负责的地带划给某个人。

另外提醒一句，这一项要写在审校清单里，不要写在写作规范里。写作规范是给撰稿人看的，撰稿人在写的时候很难同时兼顾语感和截断；放在验收环节，由另一双眼睛来查，通过率反而更高。屈折语锚文本那篇 (https://zhangwenbao.com/minor-language-internal-link-anchor-inflection-variants.html)里也用过同一招：语法上做不到的事，换个位置就能做到。

加这一项的时候顺手把它的判定权也写清楚：由审校说了算，不由撰稿人自辩。这类检查最容易滑向拉锯——撰稿人解释这句话读全了就通顺，审校说但我读半句读不懂。规则写成读半句读不懂就打回，争议一次都不会发生。

## 什么时候该停下来重测

最后说触发重测的三个信号。

第一个是官方又发了一份带语言名单的公告。

第二个是你那十条问句里，突然有一条开始出概览。

第三个是复检日期到了。

三个信号任意一个亮起，整套测试重跑一遍，别只补测一条。

因为语言状态的变化通常是批量的，一条变了往往意味着一批都变了。

重测的成本是二十分钟，误判的成本是一个季度。这个账不用算第二遍。真到了名单里出现你那门语言的那一天，前面五周攒下的问句表、改好的段落、存了一年的基线，会在同一周里一起兑现——这才是等待期该有的样子。

还有一个信号容易被漏掉：本地竞品的页面结构突然变了。如果同行开始在品类页顶部加短答案段，多半是他们已经测到了什么。竞品的动作有时候比你自己的监控更早，因为他们的测试样本跟你的不一样。

## 常见问题解答

## 我的国家在那100多个里，为什么用本地语言搜什么都没有？

因为国家覆盖和语言覆盖是两把不同的锁。官方公告公布的是国家数，同一篇里的语言名单只有英语、印地语、印尼语、日语、葡萄牙语、西班牙语六门。如果你的语言不在这六个词里面，那么在已覆盖的国家里用这门语言提问，同样不会有反应。先确认自己卡在哪一把锁上，再决定要不要投入。

## 用十条问句测出来全是零，能直接判定我这门语言没进名单吗？

不能，还差一步排除。全是零有三种可能：国家没进、语言没进、进了但你挑的词不触发。第三种最容易被误判，因为大多数人第一批测的是自己排名最好的商业词，而商业意图强的查询触发率本来就低。把测试词表换成通用疑问句再跑一遍，如果还是零，这个结论才站得住。

## 首句自足性检查里的120个字符是硬标准吗？

不是，它是一个起点值。真实的截断长度会随版面、语言、设备变化，你应该按自己观察到的情况调整，观察不到就先用这个数。重点不在于数字精确，在于把这道检查变成验收清单上一个可以被打回的项——有一个粗糙但会被执行的标准，好过一个精确但没人跑的标准。

## 日语和德语的段落改写，能不能用同一套规则？

不能，两者的困难性质不同。日语是稳定地把谓语放在句尾，所有句式都一样，因此可以用一套统一的改写模板系统性绕开。德语是在一部分句式里才把实义动词甩到最后，主句和从句表现不同，只能逐句检查。稳定的困难可以批量处理，不稳定的困难要靠逐条过，后者的工程成本反而更高，排期时要给德语留出更多人力。

## 语言还没点亮，现在改页面是不是白费功夫？

要看改的是哪一类。把本语言的常见问题整理成结构清晰的问答内容属于无悔投入，就算这个入口三年不开，它照样能拿传统搜索的长尾、照样能减少客服工单。而为了迎合某种猜测中的抽取格式去全站改写段落结构属于赌注投入，全部价值都押在一个还没发生的事件上。判据是这一条：如果入口三年不开，这件事还有没有价值。

## 小语种市场的引用位是不是更容易抢？

门槛更低，但位置也更少，两件事要一起看。一次概览挂出来的来源链接通常是三到五条，不会因为语种小就多给几条。真实的结构是：合格候选少所以容易进，位置少所以进去之后份额高，被替换掉的概率也低——因为替换你需要另一个同样够格的候选，而这门语言里凑不出那么多。这是一个对早进入者奖励很高的结构。

## 内容被读进去了却没拿到链接，这算不算白做？

不算，但要换个角度算账。本语言里能提供本地事实的文档往往极少，你写的那份可能是唯一一份，即使没拿到链接，那段答案里的事实也来自你。反过来说，如果你不写，退货期限、尺码对照、税费口径这类本地规则就会被英语世界的默认值填上，读着通顺、格式正确、内容错误。所以这件事除了争取曝光，还有一层挤掉错误答案的防守价值。

## 权威参考资料



## 关键词表照着全体德国人说话的样子建，可买这类东西的只有其中一代人

- URL：https://zhangwenbao.com/minor-language-generational-vocabulary-older-buyers.html
- 分类：小语种SEO
- 发布：2024-11-13  |  更新：2026-07-29
- 摘要：工具数据、竞品文案、母语审校三步都在往同一个方向偏，于是词表代表的是当代平均说法，而你的买家不在这个平均值里。讲清哪些词会分层、老词量怎么估、标题该选哪一个，以及多久复核一次。
- 关键词：关键词研究,多语言SEO,内容本地化,小语种SEO

> **TLDR**：摘要：关键词表是照着一门语言当下的通行说法建的，而通行说法是按全体人口平均出来的。买护理垫、买老花镜、买助行器、买厚棉睡衣的人，恰恰不在这个平均值里，他们用的是二三十年前那个词。这批词在关键词工具里量看着不高，在语料库的时间曲线上明显在降，在文案审校眼里已经过时，于是从建表那一刻起就被系统性地筛掉了。本文讲清楚词表为什么天然偏向年轻一代、哪些词会分层哪些不会、怎么用词频历史曲线和官方调查判断一个词是不是真在退场、老词该放页面哪几个位置，以及它跟包容写法那件事为什么方向正好相反。

> 摘要：关键词表是照着一门语言当下的通行说法建的，而通行说法是按全体人口平均出来的。买护理垫、买老花镜、买助行器、买厚棉睡衣的人，恰恰不在这个平均值里，他们用的是二三十年前那个词。这批词在关键词工具里量看着不高，在语料库的时间曲线上明显在降，在文案审校眼里已经过时，于是从建表那一刻起就被系统性地筛掉了。本文讲清楚词表为什么天然偏向年轻一代、哪些词会分层哪些不会、怎么用词频历史曲线和官方调查判断一个词是不是真在退场、老词该放页面哪几个位置，以及它跟包容写法那件事为什么方向正好相反。

## 同一件商品，两代人用两个词，你的表里只收了一个

## 一次德语站的实测

有个客户做居家康护类目，德国站，卖的是防滑垫、扶手、坐便椅这些东西。

他们的关键词表做得很规范，从工具导出、按搜索量排序、按意图分组，一共八百多条。

上线大半年，自然流量一直起不来。查技术、查内容深度、查外链，都没发现什么大毛病。

后来我让他们把站内搜索日志和客服工单里的原话拉出来，跟关键词表比对了一遍。

结果有点出人意料：用户实际打进来的词里，有相当一部分在那八百条里根本找不到。它们不是长尾变体，是同一件商品的另一个名字——一个更老的名字，年长的人一直在用，而年轻人已经不这么叫了。

更值得琢磨的是这批词的来源分布。它们几乎全部出现在客服工单和站内搜索里，一条都没有出现在关键词工具的导出结果里，也没有出现在任何一份竞品词表里。也就是说，所有基于工具和竞品的建表方法，都会稳定地漏掉它们。

后来我们把这批词单独拉了一张表，一共二十七条，覆盖了他们主力类目里的大半商品。二十七条听着不多，可它们对应的是整整一代买家的入口词，而那八百条里一条都没有。

这二十七条里有一半是同一件商品的两种叫法，另一半是用户用症状或者场景来指代商品的说法，比如按需要解决的问题来称呼它，而不是按它是什么。后一种在康护类目里尤其多。

## 那份词表是怎么来的

回头看这份表的生产过程，问题其实一目了然。

第一步是从工具导出品类词，工具的数据来自搜索行为的聚合，而聚合是按人头平均的。

第二步是拿竞品页面补充，竞品的文案是市场部写的，市场部的人平均年龄三十出头。

第三步是本地审校润色，审校的职业习惯是把词往当下的规范用法上靠，这一层的代价我在小语种内容找母语者审校，一句读着自然不能当成验收通过的判据 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)里专门算过。

三步下来，每一步都在往同一个方向偏，而且每一步都合理。没有任何一个环节出错，可它们叠加起来的结果是：一份完全正确的、代表当代德语平均说法的词表，而你的买家不在这个平均值里。

更值得警惕的是，这三步都是行业公认的最佳实践。一件事如果是照着教科书做出来的，出了问题就特别难归因，因为每一步单看都无可指摘。

## 为什么这件事很难被发现

因为它不产生任何异常信号。

页面正常收录，排名也不算差，只是排的都是那些量不大的词。

老词的搜索量在工具里看着不高，你即使偶然看到它，也不太会优先处理。

而站内搜索里那些搜不到东西的记录，通常没人每周去翻。

最要命的是心理上的自洽：你会觉得自己已经很认真地做过关键词研究了，八百条词是有据可查的。一件事只要看起来做过了，就很难再被重新审视一遍，这比根本没做过还难纠正。

还有一层心理因素：老词往往看着不专业，第一眼扫过去容易被当成用户打错字或者表达不规范，于是连被认真看一眼的机会都没有。

还有一个原因是这批查询往往集中在一天里的特定时段和特定设备上，如果你的报表默认按整体看，它们会被平均掉，连一个尖峰都不会留下。

## 为什么关键词表天生偏向年轻的那一代？

## 数据来源本身就带着偏差

搜索量数据是行为数据，谁搜得多谁的权重就大。

而搜索这个行为在人群里的分布本来就不均匀，年轻人搜得更频繁、更琐碎、更愿意换着词试。

年长用户的搜索次数少，词更固定，一次搜不到往往就放弃了，不会换词重试。

所以同样一批人，在搜索行为数据里被记录下来的密度差着好几倍。

这就带来一个隐蔽的后果：搜索量低不一定意味着想买的人少，也可能意味着想买的人搜得少。这两件事在数据上长得一模一样，而它们对应的商业结论完全相反。

这条偏差在广告数据里同样存在。年长用户点广告的比例低，于是广告平台给出的这批词的竞价热度也低，两个系统在同一个方向上互相印证，看起来就更像事实了。

这里还有个连锁反应值得一提：因为工具数据偏向年轻用户，所以按工具数据做出来的内容也偏向年轻用户，而这些内容又会吸引更多年轻用户来搜。做几轮下来，你的站会真的变成一个只服务一代人的站。

## 工具的样本还要再偏一次

第三方关键词工具的数据来自点击流面板、插件用户、广告接口这几类来源。

愿意装插件、愿意加入数据面板的是哪批人，不用我说。

小语种市场的样本量本来就小，再叠加这一层年龄偏差，误差会被放得很大。

我在小语种关键词工具返回的那个零是数据缺口 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)里讲过工具在小语种上的系统性缺数，代际这一层是同一个问题的另一个切面。

换句话说，你手里那个搜索量数字，是一个已经被过滤过两次的样本的估计值。拿它来判断一个老词值不值得做，等于拿一份年轻人的问卷去推断整个市场的偏好。

还有一个更难察觉的影响：搜得少也意味着这批人的行为数据在算法里的权重低，久而久之连搜索结果本身都会更偏向年轻用户的偏好。

## 写文案和做审校的也都不是那批人

这是最后一道过滤器，也是最难说服的一道。

母语审校看到一个老词，本能反应是这个说法有点旧了，改成现在通行的那个。

他做的是对的。从写作规范的角度，用当下的通行词就是更好的选择。

可搜索这件事的判据不是写得好不好，是命不命中用户打出来的字符串。

这跟我在用户搜的那个短词你的词典里查不到 (https://zhangwenbao.com/minor-language-clipped-short-forms-keyword-coverage.html)里写过的机制是同一类：内容生产链路上的每一道关卡，都在按某种正确性做筛选，而这些正确性标准里没有一条跟检索有关。

这道过滤器最难的地方在于，它是唯一一道由人执行、且执行者非常确信自己是对的关卡。前两道是机器和统计，你可以拿数据去修正；这一道是专业判断，只能靠流程去约束。

## 哪些词会分层，哪些不会？

## 第一类：技术更替换掉了旧名字

这一类最典型，也最容易识别。

德语里手机曾经叫Mobiltelefon，后来Handy成了主流，再后来Smartphone又盖过它。三个词至今都还有人用，只是用的人不是同一批。

电脑、冰箱、洗衣机、电视，几乎每个耐用消费品都经历过一轮换名。

规律是：旧名字往往更书面、更长、更描述性；新名字往往更短、更口语、更多来自外来语。这跟当年拿词典逐词换出来的那批直译词 (https://zhangwenbao.com/keyword-literal-translation-legacy-cost-non-english.html)正好是两种不同的历史遗留：一种是译错留下的，一种是用对过但时代变了。

做这一类的判断有个捷径：如果一个品类在过去三十年里经历过一次技术换代，那它几乎一定有代际分层的词，可以直接列进待查清单，不用先去找证据。

换代还有一个副产品：旧名字往往会保留在正式文书和说明书里，而新名字只活在口语和电商标题里。这意味着同一件商品在保修卡和商品页上叫两个名字，这是个很好的自查入口。

这一类还有个好用的判据是查专利和说明书。工程侧文档里的名称改得最慢，如果说明书里还在用老词，说明这个词至少在二十年前是主流，那今天五十岁以上的人多半就是这么叫的。

## 第二类：外来词替换掉了本族词

这一类在德语、法语、北欧语言里特别多。

年长一代用的是本族语构词，年轻一代直接用英语词或者英语词的本地化拼写。

比如钱包这个东西，德语里既有一个从法语借来的老词，也有一个纯德语构成的新词，两个词的使用人群明显不同代。

这一类比第一类难办，因为两个词的意思完全一样，没有任何语义差别可以作为区分依据，只有使用者的年龄不同。

更麻烦的是它跟地域变体常常纠缠在一起。同一个词在奥地利是当下的通用说法，在德国北部却已经带上了年代感，你如果只在一个国家做调研，很容易把地域差异误判成代际差异，反过来也一样。

识别这一类还有个小技巧：查这两个词的构词方式。一个是纯本族语构成，另一个能明显看出外来痕迹，那大概率就是这一类。

这一类里还有一个反例值得记住：有些外来词进来之后被赋予了本地特有的含义，跟英语原意已经对不上。这种词不是新旧关系，是两个不同的词，别把它们配成一对。

## 第三类：地域与代际叠在一起

德语区是这方面的典型。花菜在德国叫Blumenkohl，在奥地利和德国南部叫Karfiol；土豆、番茄、面包这些日常食材几乎都有类似的情况。

这些地域词在年长人群里的存活率明显更高，因为年轻一代受全国性媒体和电商标准品名的影响更大。同一门语言在两个市场之间的词汇分叉，我在荷兰语SEO省下的那份比利时预算 (https://zhangwenbao.com/dutch-seo-netherlands-belgium-flemish-two-markets.html)里按三类拆过，代际这一层可以直接套那张拆分表。

于是你会看到一个二维分布：横轴是地域，纵轴是年龄，四个象限里的用词各不相同。

做词表的时候如果只按国家分，就会把这一层压平掉。

处理办法不是把四个象限都做成页面，那太重了。务实的做法是让匹配层覆盖全部四个象限，展示层只选最大的那一个，剩下三个靠站内搜索的同义词表和正文里的一次自然提及接住。

地域这条线还有一个格外麻烦的地方：它跟配送和仓储绑在一起。同一个国家里，你的南方仓和北方仓服务的用户可能在用不同的词，而页面是全国一套。

## 哪些词不会分层

专业术语基本不分层，因为它们有行业规范约束，规范一改所有人一起改。

法定名称也不分层，药品的通用名、法规里的品类名都是写死的。

纯功能性的短词也很稳定，桌子、椅子、水这些词几百年没变过。

真正会分层的集中在三类：经历过技术换代的耐用品、受外来语冲击强烈的日常用品、以及带有明显地域传统的食品与服饰。属性词那一层还有一套并行的错位，见你的色卡上蓝和绿是两格 (https://zhangwenbao.com/minor-language-color-category-attribute-value.html)。

把这三类圈出来，你的排查范围一下就从整张词表缩小到几十个品类词，这件事的工作量就变得可控了。

还有一个稳定性判据：这个词有没有被印在包装上。印在包装上的名字改动成本极高，所以它一旦定下来就会稳定很多年，跟着包装走通常不会错得太离谱。

还有一类特殊情况是品牌名变成了通名。某个牌子的产品曾经主导过市场，于是它的名字被用来指代整个品类，年长用户至今这么叫。这类词做匹配层没问题，写进页面要小心，可能涉及他人商标。

## 怎么判断一个词是不是真的在退场？

## 词频历史曲线是最直接的证据

德语有个数字词典项目，每个词条下面都挂着一条基于历史语料的使用频率曲线。

你能直接看到一个词从哪一年开始起，哪一年到顶，现在处在什么位置。

这条曲线比任何主观判断都可靠，因为它来自实际的文本语料，而不是某个人的语感。

要注意的是语料的构成。这类语料库多以报刊和出版物为主，反映的是书面语的变化，口语的变化通常比它更早发生。

所以正确的读法是：曲线在降，说明这个词在书面世界里已经退场了；而书面世界通常是最后一个改口的地方，这意味着口语里它可能还活着，只是活在不写字的那批人嘴里——而这批人恰好会在搜索框里打字。

使用这条曲线时还要注意一点：它反映的是这个词在全部文本里的相对频率，而不是这件商品的需求量。商品变冷门也会让词频下降，别把品类的衰退读成词的退场。

德语的数字词典词条页 (https://www.dwds.de/wb/Handy)把这条曲线直接画在释义下方，翻两页就能看出一个词的兴衰走势。这类工具的价值在于它把语感问题变成了一张可以贴进汇报材料的图。

## 官方语言调查能给出年龄维度

词频曲线有个缺陷：它只有时间轴，没有年龄轴。

补这一块最好的来源是各国的官方语言使用调查。日本文化厅每年做一次国语相关的舆论调查，按年龄段统计人们对词语用法的认知和使用倾向。

这类调查里有一类问题特别有用：不同年龄段的人是否觉得别的年龄段用的词难懂。这个数字在最年长的组里通常明显高于其他组。

它给出的不是某个具体词的数据，而是一个背景参数：代际之间的词汇隔阂到底有多大。

知道这个背景参数很重要，它决定了你要不要为这件事投入。如果隔阂本身就不明显，那这件事的上限也就有限；而在日语和德语这类调查里，隔阂大到足以让人重新审视自己那份词表。

这类调查还有个用法：看它历年提问方式的变化。当一个词从调查问卷的问项里消失，通常说明它已经稳定到不值得再问了，这本身也是一种信号。

## 搜索量趋势有个陷阱

最容易想到的办法是看两个词的搜索量趋势，谁在涨谁在跌。

这个办法方向对，但有个陷阱：搜索量下降可能是词在退场，也可能是这批用户整体在退网。

两者在曲线上长得一样，结论却相反。前者意味着你该换词，后者意味着这批人还在，只是他们的行为没被记录下来。

区分办法是拿同品类里一个不分层的词做对照组，看它的曲线有没有同步下降。

如果对照词稳定而目标词在跌，那是词在退场；如果两个一起跌，那多半是整个品类的搜索行为在迁移，比如从搜索引擎转向了别的入口，这时候换词一点用都没有，得去别的地方找这批人。

还有一个更细的陷阱：搜索量数据通常是按精确匹配统计的，而老词的拼写变体往往更多，量被切碎在几个变体上，看起来就更低了。

还有一个办法能绕开这个陷阱：看同一批用户在别的品类上的行为。如果他们在其他类目里的搜索量稳定，只有你这个类目在跌，那问题多半出在词上而不是人上。

## 买这类商品的到底是哪一代人？

## 先把品类的年龄结构拿出来

这件事值不值得做，取决于你的买家年龄结构，而不是取决于语言本身。

康护用品、老花镜、保暖内衣、助行辅具、部分保健食品，买家高度集中在年长人群。

母婴、宠物、家居、园艺这几类的买家跨度大，两代人都有。

3C、潮流服饰、运动装备则明显偏年轻。

值得注意的是送礼场景会把这个结构搅乱：买的人年轻，用的人年长，而搜索行为跟着买的人走、评价内容跟着用的人走。这一类品类的词表要两代都收，因为你的入口词和口碑词分别来自两批人。

送礼这一类还有个额外的操作空间：页面上可以同时写两个词，一个给下单的人看，一个给收礼的人看，两批人读到的是同一句话里的不同部分。

## 官方统计里能查到什么

欧盟统计局有按年龄段拆分的网购比例数据，能查到各成员国不同年龄组在过去一年里网购过的比例。

日本总务省的通信利用动向调查同样按年龄段拆分，覆盖到高龄组。

这些数据的价值不在于绝对值，而在于变化速度：年长组的网购比例在过去十年里涨得比任何一组都快。

这意味着一件事：过去可以拿这批人不网购当借口跳过他们，现在这个借口越来越站不住脚了。

换个说法，这批用户是在这几年才刚刚成规模地进入你的市场的，而你的关键词表大概率是在他们进来之前建好的，之后再也没有从头审视过。

这些统计还有一个隐藏用途：它能帮你判断这批用户是不是刚进来的。如果某个年龄组的网购比例在最近几年才快速爬升，那你的历史数据里几乎不会有他们的痕迹，光看自己站的日志会得出错误结论。

欧盟统计局的个人电子商务统计 (https://ec.europa.eu/eurostat/statistics-explained/index.php?title=E-commerce_statistics_for_individuals)把网购比例按年龄组拆开列，能直接看到最年长那一组这些年的爬升幅度。这份数据的好处是它跨国可比，做多市场排期时特别省事。

## 年长买家的搜索行为有什么不同

词更固定，试错更少。他想到什么词就搜什么词，搜不到往往就换个渠道，而不是换个词。

查询更长更完整，更接近一句自然的话，因为他不太习惯用关键词式的碎片表达。这类完整句式的查询怎么承接，小语种的问答长尾没多少人搜 (https://zhangwenbao.com/minor-language-qa-long-tail-content-value-ai-era.html)那篇里的做法可以直接用。

更依赖第一屏，翻页的比例明显低。

这三条加在一起意味着：对这批用户来说，你要么在他第一次输入的那个词上被找到，要么就彻底不存在。年轻用户会替你补救，他搜不到会换个说法再来一次；年长用户不会，他默认是这个网站没有这个东西。

还有一条值得记：这批用户更可能在工作日的白天访问，而不是晚上。如果你的投放时段和客服排班是按年轻人的作息定的，那接待成本也要跟着调。

另外这批用户对页面上的电话号码格外敏感。能看到一个电话号码，哪怕他最终没打，也会明显提高下单意愿，这一点在只做线上客服的站上经常被低估。

## 老词还剩多少量，这个数怎么估？

## 工具给的数字一定偏低

前面说过样本偏差，这里要说的是它偏低的幅度。

我的经验是，在年龄分层明显的品类里，老词的真实需求通常比工具显示的高出一大截，具体倍数没法一概而论，但方向是稳定的。

所以工具数字的正确用法不是拿来算账，是拿来排序。

同一份工具里两个老词的相对高低是可信的，老词跟新词之间的绝对比例不可信。

这个区分很实用：你可以放心地用工具决定先做哪个老词，但不能用它决定要不要做老词这件事。后一个决定必须靠第一方数据。

另外还有个反向用法：如果某个老词在工具里的相对排名突然上升，通常不是这批用户变多了，而是这个词被某个新用途借走了，值得去看一眼具体是什么在带量。

## 站内日志和客服记录才是真数

站内搜索日志的价值前面已经提过。对代际这件事，还有一个来源常常被忽略：客服工单和电话记录。

年长用户更倾向于打电话或者写邮件问，而不是在搜索框里反复试。

所以客服那边积累的原话，是一份不会出现在任何搜索数据里的词库。

做法很简单：让客服把最近三个月的工单标题导出来，人工扫一遍，把商品名的说法圈出来。

这份材料的质量往往高得惊人，因为它是用户在没有任何提示的情况下，用自己的话描述自己想要的东西——这正是关键词研究一直想要却很难拿到的东西，而它可能已经在你们公司的工单系统里躺了好几年。

整理工单还有个额外收获：你会看到用户描述症状和需求的完整句子，那是写常见问题区的最好素材，比任何关键词工具给的问句模板都真实。

还有一个来源常被忘掉：产品说明书和保修卡上印的名字。那是公司内部文档链路上最保守的一环，往往保留着这件商品几十年前的正式名称。

## 三个信号交叉验证

单一来源都不够，我一般看三个。

第一个是词频历史曲线，判断这个词是不是真的在退场。

第二个是站内搜索和客服记录，判断你的用户里还有多少人在用它。

第三个是本地竞品和本地媒体，尤其是面向年长读者的媒体，看他们用的是哪个词。找这类本地信源的路子，做小语种外链，能用的都在当地人的圈子里 (https://zhangwenbao.com/minor-language-link-building-local-directories-media-communities.html)那篇里列过一份挖掘清单。

三个信号都指向老词还活着，那就该做；三个信号打架，通常说明这个词正处在换代的中间地带，那就两个都上，让匹配层去接。

三个信号里如果只能选一个，选站内搜索。它虽然样本小，但它是唯一一个直接来自你自己用户的信号，其余两个说的都是别人的用户。

## 页面上哪个位置该写哪个词？

## 标题：按买家结构选一个

标题只能选一个，这是硬约束。

选的依据是这个页面服务的买家结构，而不是哪个词更时髦。

买家明显偏年长的品类，标题就该用老词，哪怕市场部觉得它土。

买家跨度大的品类，用新词做标题，老词放描述和正文第一段。

有一种情况可以两个都放进标题：两个词都短，加起来不超长度限制。这种时候用一个自然的连接方式把它们串起来，比如用括号或者一个顿号，读起来不别扭就行，别硬拼。

还有一种折中做法：标题主词用新词，紧跟着用一个短括号补上老词。这么写有点挤，但在买家结构确实横跨两代的品类里，它比二选一的损失小。

另外要留意标题里的词序。老词放在前面还是后面，对同一批用户的点击影响不小，因为他们扫标题的耐心比年轻用户短，前几个字没命中就不看了。

## 正文和常见问题区是老词最好的容身处

正文里可以自然地把两个词都用上，这是最没有代价的做法。

常见问题区尤其合适，因为问答的语气本来就更口语，用老词一点都不违和。要注意的是承诺类句子的强度别跟着口语化一起松掉，那是另一条红线，见退货政策那句承诺译成日语之后 (https://zhangwenbao.com/minor-language-modality-obligation-commitment-strength.html)。

可以直接写一条问答，把两个词的关系讲清楚，比如某某和某某是不是同一个东西。

这类问答的额外好处是它同时接住了两批人：搜老词的人找到了你，而搜新词的人看到这条也不会觉得多余。

这一手其实是把词汇差异本身变成了内容。用户心里那点不确定，被你写成了一段回答，这比在页面上多堆一个关键词有用得多。

写这类问答还有个附带好处：它天然适合被摘成答案。一问一答、结论在前、两个词都出现，这样的段落在各种自动摘取的场景里表现都不错。

写的时候注意别用居高临下的口气。把两个词的关系写成一句平实的说明就好，不要写成某某的旧称这种带评判的表述，那会让用惯老词的人觉得自己被归到了过时的那一档。

## 站内搜索的匹配层必须全收

展示层要选，匹配层不用选，全收就行。

把老词、新词、地域变体全部塞进同义词表，指向同一批商品。

这一步成本极低，见效极快，而且不需要跟任何人讨论品牌调性。

我一般建议客户先做这一步，把零结果率降下来之后，再拿数据去谈标题和文案要不要改。

先改匹配层还有一个策略上的好处：它会源源不断地给你产生证据。当同义词表把老词接住之后，你能直接看到这批查询的转化率，而这个数字往往比任何论证都更能说服市场部。

同义词表还有个维护上的小建议：把每一条都标上加入日期和来源。半年后复核时，你能立刻分清哪些是靠数据加进来的，哪些是当初凭感觉塞的。

还有一个进阶做法：给同义词表里的每一条记录使用次数，用得多的词说明需求真实，可以考虑往展示层提；半年一次都没被触发的，就该从表里清掉。

## 广告和邮件模板别忘了

这两块常常独立于站内内容维护，也常常被漏掉。

广告词用新词、落地页用新词，等于把这批用户从投放这一步就筛掉了。

邮件模板更微妙，收件人列表里年长客户的占比往往高于站内平均，因为他们更倾向于订阅而不是靠社媒。

所以邮件里用哪个词，值得单独做一次分组测试。

这类测试的结论有时候会挺打脸：同一封邮件只改了商品名的说法，打开率和点击率就能拉开可见的差距，而这件事在此之前从来没人想过要测。

邮件这一块还有个细节：年长收件人打开邮件的设备更可能是电脑而不是手机，主题行的可见长度更长，这意味着你有空间把两个词都放进去。

## 这跟包容写法那件事，是不是反过来的？

## 一个是新词没人搜，一个是旧词还有人搜

我在德语站的正文早已换成带星号的包容写法 (https://zhangwenbao.com/minor-language-gender-inclusive-spelling-keyword-coverage.html)那篇里讲过一件事：一批新写法在正文里已经铺开了，可搜索框里用它的人始终是零。

这一篇讲的是镜像的另一半：一批旧说法在正文里已经被清干净了，可搜索框里还有人在用。

两件事的共同点是，页面上的用词和搜索框里的用词脱节了；不同点是脱节的方向正好相反。

前者是内容跑在了用户前面，后者是内容跑在了用户前面之后，没回头看还有谁没跟上。

把两件事并排放在一起看，能得出一条更一般的规律：内容团队的用词永远在向前走，而用户群体是分层的，任何一次向前走都会把某一层甩在后面。区别只在于甩掉的那一层是大是小、有没有购买力。

这条规律还有一个推论：内容团队更新得越勤快，被甩下的那一层就越厚。这不是让你别更新，而是说每次更新之后都该回头数一数还有谁没跟上。

这条规律还能反过来用：如果你想知道自己有没有把某一层用户甩下，最快的办法不是看数据，是找一个属于那一层的人，让他用自己的话说一遍他要买的东西。

## 两件事共用同一个字段

处理办法上，这两件事需要的是同一个东西：给词表加一列保质期。

包容写法那件事需要它，是因为规范可能随时变，写法可能几年后被取代。

代际这件事需要它，是因为老词会持续退场，你不能把三年前的判断一直用下去。

两者的差别在于复核方式：包容写法可以盯官方规范的公告，代际词没有任何机构会发公告，只能靠定期重跑数据。

所以词表里那一列写的不该是到期日，而是下次复核日。这个区别听起来很小，实际上决定了这件事是被动等通知还是主动排日历，而没有公告可等的那一类，只能靠后者。

还有一个共性：两件事都不能靠一次性项目解决，都需要在词表里留一个字段和一条复核节奏。区别只是复核的触发方式，一个看公告，一个看数据。

把两件事放在一起还能得出一条操作建议：任何一次全站范围的用词更新，都应该在上线前先把被替换掉的旧写法收进匹配层。这一步只要几分钟，却能兜住所有还没跟上的人。

## 还有第三种情况：两个词都不是用户在用的

值得留一句提醒。

有时候你会发现老词在退场、新词还没起来，用户在用的是第三个说法，可能是个描述性短语，可能是个品牌名变成的通称。

这种情况在新品类里特别常见，因为语言还没为这件东西定下名字。

判断办法还是回到站内搜索和客服记录，看用户到底是怎么称呼它的。

这时候最不该做的事是自己造一个词然后指望用户跟着用。语言这件事上，你不是规则制定者，只能是观察者，这一点跟品牌名那种可以自己定的东西完全不同。

遇到这种情况，最务实的做法是把用户的那个描述性短语原样收进匹配层，同时在正文里用它做一次自然的表述。你不需要给它下定义，只需要让搜它的人能找到你。

这种情况还有一个特征：三个说法的搜索量都不高，加起来才成规模。这时候最容易做出的错误决定是三个都不做，理由是每一个的量都不够。

## 用老词会不会让品牌显得很土？

## 先算一算这件事的真实代价

这是每次都会被问到的问题，而且问得有道理。

代价确实存在：老词会让一部分年轻用户觉得这个牌子有年代感。

但要把这个代价放到具体位置上算，而不是笼统地谈。标题里用老词，影响的是搜索结果页里那一行字的观感；正文里用老词，几乎没有观感成本。

而收益是明确的：一批本来根本找不到你的用户，现在能找到了。

我一般让客户这样算：如果这个品类的买家里有三成以上是年长人群，那标题用老词的收益远大于观感损失；如果只有一成，那就把老词留在正文和匹配层，标题不动。这条线不需要精确，量级对了就够。

这个账还有一个常被忽略的项：老词往往竞争更小，同样的投入能拿到更靠前的位置。观感损失是确定的一点点，位置收益却可能是成倍的。

## 按场景分开用，比全站统一好

没有必要全站只用一个词。

品类页和商品页可以按买家结构分别定，博客和品牌故事页可以完全用新词。

广告投放更适合做分组：按人群定向分开投，词也跟着分开。

这么做还有个额外好处，它把词的选择变成了一个可测的变量，而不是一场关于品味的辩论。

一旦有了分场景的数据，讨论的性质就变了。原来是市场部和SEO在争哪个词更好，之后是大家一起看哪个场景该用哪个词，谁都不用退让立场，这比讲一百句道理管用。

分场景还有一个好处是可回退。某个场景试下来数据不好看，只改那个场景就行，不用把全站的用词再翻一遍。

做分场景测试时建议把周期拉长一点。年长用户的决策链条通常更长，两周的数据往往还没跑完一个完整的转化窗口。

## 谁来拍板

我的建议跟大多数用词争议一样：搜索侧提供证据，品牌侧保留一票否决，但否决要写理由。

写理由这条很关键。口头否决没有成本，写下来就得想清楚。

而且理由记下来之后，下一次复核时可以拿出来重新看一遍，那时候数据可能已经变了。

这套流程不复杂，难的是把它固定下来，别每次都从头吵一遍。

还有一条经验：把决定权明确到人，而不是到部门。到部门就意味着每次都要重新开会，到人就意味着有人对结果负责，而对结果负责的人通常比一屋子人更愿意看数据。

另外建议把这类决定和它的理由存在同一个地方，跟词表放在一起。半年后复核时，人能换，判断的依据不能丢。

## 一份半天能跑完的代际词盘点

## 上午：把候选词圈出来

第一步筛品类：从整张词表里挑出经历过技术换代、受外来语冲击、或者带地域传统的那几类，通常剩下几十个词。

第二步查曲线：把这几十个词逐个丢进词频历史工具，记下它们各自处在上升、平台还是下降阶段。

第三步找对应：处在下降阶段的词，找出它今天的替代词，两两配对。

第四步核实：把配对表发给本地同事，让他标注每一对在他的语感里分别是谁在用。

这四步加起来一个上午足够，最花时间的是第二步，但它可以交给实习生做，判断标准很机械：曲线在涨还是在跌，不需要任何语言能力。

如果时间只够做半天里的一半，那就只做第一步和最后一步：筛出品类，然后把配对结果丢进站内搜索的同义词表。中间那两步可以下次补。

顺带一提，这半天里最容易被拖长的其实是第四步，因为本地同事不见得随时有空。稳妥的做法是提前一周把配对表发过去，让他有时间零散地填，别指望当场坐下来一起过。

## 下午：定落点并上线匹配层

先做匹配层，把所有配对塞进站内搜索同义词表，当天就能上。

再做展示层，逐个页面判断标题要不要换，这一步会慢一些，可以排进下一个内容周期。

然后是广告和邮件模板，把老词加进关键词列表和文案变体。

最后给词表加上下次复核日那一列，填上六个月后的日期。

整件事真正的产出不是那几十个词，而是那条同义词表和那个复核日期。词会变，机制不会变，机制立起来之后每半年重跑一次，成本就摊薄到可以忽略了。

还有一个容易漏掉的落点是站内的分类导航名。那里的词一旦定下来往往几年不动，而它恰恰是用户浏览时最先读到的一组词。

另外导航名和筛选器标签这两处还有个额外约束：它们的长度受版式限制，老词往往更长，塞不进去。这时候可以让标签用短的新词，而把老词放进这个分类页的标题和第一段里。

## 验收看哪几个数

第一个是站内搜索的零结果率，这是最灵敏的指标，同义词表一上线当周就能看到变化。

第二个是进站查询里老词的条数，从近似零变成多少。

第三个是这批查询的转化率，跟新词查询做对比。

如果第三个数明显更高，那这件事就不只是补漏，而是找到了一批竞争更少、意图更强的需求。

这种情况在康护、保健、家纺这几类品类里挺常见，因为竞品的词表跟你原来那份一样，也是从同一批工具里导出来的，大家漏的是同一批词。

另外建议把零结果率按查询语言和词龄分开看。整体零结果率下降三个点听着不多，但如果这三个点全部来自老词那一组，说明这件事的效果是精准打中的，而不是被别的改动稀释掉的。

还有一个值得记录的软指标：客服那边有没有减少解释性对话。当用户搜到的页面用的就是他习惯的词，他不需要再打电话确认这是不是同一个东西，这部分成本的下降不会出现在任何SEO报表里。

## 什么时候不必做这件事

买家高度集中在年轻人群的品类可以跳过，比如潮流服饰和电竞外设。

专业术语主导的B2B品类也可以跳过，行业规范会替你把用词统一好。

还有一种情况：你的小语种站整体质量还没过关，正文还是机翻直发的状态。那先解决那件事，这件事排后面。

顺序反了不会有任何收益，就像在一间还没通电的房子里挑灯泡的色温。

最后提醒一句：这件事最好别在旺季前动标题。匹配层随时可以上，展示层的改动要留出观察期，而旺季的数据波动会把观察期彻底搅浑，到时候你分不清是词的功劳还是季节的功劳。

最后补一句判断顺序上的经验：先看买家年龄结构，再看语言里有没有分层，最后才看词表。反过来从词表出发，你会在几百条词里迷路，而买家结构这一步只要一张后台报表就能判掉。

日本文化厅那份按年龄段做的国语舆论调查 (https://www.bunka.go.jp/tokei_hakusho_shuppan/tokeichosa/kokugo_yoronchosa/index.html)可以当作一个现成的背景参照：它每年都会问不同年龄段的人怎么看待彼此的用词，而最年长那一组给出的隔阂感明显高于其他组。看一眼这个数，你就知道这件事在你那门语言里的天花板大概在哪儿。

还有一个常被问到的问题：这件事要不要等到站内内容全部本地化完成之后再做。不必等。匹配层的改动跟内容质量是两条独立的线，先把老词接住，用户至少能找到东西，哪怕落地页写得还不够好。

## 常见问题解答

## 不懂这门语言，怎么判断一个词是不是在退场？

有一个几乎不需要语言能力的办法：查词频历史曲线。像德语的数字词典这类项目会给每个词条挂一条基于历史语料的使用频率曲线，你只需要看它是在涨、在平台期还是在跌。这一步机械到可以交给任何人做。接下来把处在下降阶段的词和它今天的替代词配成对，发给本地同事，只问一个问题：这两个词分别是谁在用。

整个过程你需要的语言能力为零，需要的只是知道该查什么。真正需要母语判断的只有最后一步，而那一步问的是使用人群，不是对错。另外提醒一句，查曲线时要把词的拼写变体一起查，有些老词在不同年代的正字法下写法不同，只查一种会看到一条假的下降曲线。

## 老词的搜索量在工具里很低，怎么说服老板做？

别用工具数字说服，用第一方数据。最有力的三个数是：站内搜索里老词的出现次数、这些查询的零结果比例、以及客服工单里用老词描述商品的条数。第三个尤其有说服力，因为那是用户在完全没有提示的情况下说出来的原话，而且它通常已经在工单系统里躺了好几年，谁都没想过要看。

汇报时可以把结论压成一句话：我们每个月有多少次搜索用的是页面上根本没有的词，其中多少次直接返回了空白页。这句话不需要任何SEO背景就能听懂。如果客服工单不方便导出，退一步可以听十通电话录音的开场白，用户说明来意的那半句里通常就带着他习惯的商品名。

## 为什么关键词工具会系统性地漏掉这批词？

因为工具的数据来自行为样本，而这个样本在两个环节上都偏向年轻用户。第一个环节是搜索行为本身：年轻人搜得更频繁、更愿意换词重试，同样一批人在数据里的密度差好几倍。第二个环节是数据采集：点击流面板、浏览器插件这类来源的用户结构本来就偏年轻。两层偏差叠加之后，小语种市场的样本量又小，误差会被进一步放大。所以工具数字可以用来给老词内部排序，但不能用来判断老词值不值得做。值得补充的是，这两层偏差在大语种上同样存在，只是样本量大掩盖了它；到了小语种，它会直接暴露成一片看不懂的零。

## 老词和新词，能不能干脆两个都写进标题？

可以，但有条件。两个词都短、加起来不超出标题的显示长度、并且能用自然的方式串起来，那就两个都放。做不到就别硬拼，硬拼出来的标题读着像关键词堆砌，点击率会掉，得不偿失。做不到的时候按买家结构选一个进标题，另一个放进页面描述和正文第一段，剩下的交给站内搜索的同义词表去接。展示层永远要做取舍，匹配层不用取舍，这个分工能解决绝大多数用词纠结。另外提醒一点，两个词都进标题的时候别用斜杠连接，那种写法在搜索结果页上读起来像参数表，不像一句人话。

## 这跟词的地域变体是同一件事吗？

不是同一件事，但经常纠缠在一起。地域变体是横向的，同一时间不同地方说法不同；代际差异是纵向的，同一地方不同年龄说法不同。麻烦在于两者会叠加：一个词在奥地利是当下通用的说法，在德国北部却已经带上了年代感。如果你只在一个国家做调研，很容易把地域差异误判成代际差异。稳妥的做法是把两个维度分开记录，词表里分别留一列，匹配层把四个象限全收，展示层只按主力市场选一个。实操上有个简单办法：调研时至少覆盖两个地区加两个年龄段，四个格子都拿到样本，才分得清是横向差异还是纵向差异。

## 多久复核一次？会不会做完就一劳永逸了？

不会，这件事没有做完的一天。建议半年复核一次，重跑词频曲线和站内日志即可，熟练之后一次两小时。关键是要在词表里加一列下次复核日，而不是到期日。跟那些有官方规范约束的写法不同，代际词的退场是渐进的、没有任何机构会发公告，你不可能等到通知，只能主动排日历。另外新品上市后一个月是值得加做一次的窗口，因为用户描述新东西的时候最容易暴露出他们习惯的说法。另外建议把复核安排在换季前，那时候正好要更新一批商品文案，两件事合并做，边际成本几乎为零。

## 用了老词，会不会伤害品牌形象？

要看放在哪个位置。正文和常见问题区里用老词几乎没有观感成本，甚至更亲切；标题里用才涉及品牌观感，因为那是搜索结果页上唯一露出的一行字。所以我的建议是分位置定：买家里年长人群占三成以上的品类，标题可以用老词；不到一成的，老词留在正文和匹配层。另外别把这件事变成品味之争，按场景分开投放和分开测试，让数据说话。

一旦有了分场景的数据，讨论就从谁的审美更好变成了哪个场景该用哪个词，这比讲道理管用得多。还有一个折中：老词只出现在正文和常见问题区，标题保持新词，这样搜索结果页上的观感完全不受影响，而搜老词的人进来之后仍然能读到自己熟悉的说法。



## 德语站的正文早已换成带星号的包容写法，可搜索框里用这种写法的人还是零

- URL：https://zhangwenbao.com/minor-language-gender-inclusive-spelling-keyword-coverage.html
- 分类：小语种SEO
- 发布：2024-10-15  |  更新：2026-07-28
- 摘要：星号、冒号和下划线插在词中间只占一个字符，分词器却会在那里切一刀，把词切成两个都没有搜索量的碎片。讲清品牌合规、无障碍与检索三方的最优解为什么互不相同、唯一的交集落在哪种写法，以及德语的现在分词名词化为什么四项全过。
- 关键词：关键词研究,出海SEO,多语言SEO,小语种SEO

> **TLDR**：摘要：德语里指人的名词有一族新写法，用星号、冒号或者下划线把两种词尾并进一个词。这些符号在页面上只占一个字符，在分词器眼里却是一道词边界，于是那个词被切成两半，传统写法和新写法两边的查询都接不住。本文按品牌合规、无障碍、检索三方各自的最优解拆开这一层，指出唯一的交集，并给词表加一个别的词类都不需要的字段。

> 摘要：德语里指人的名词有一族新写法，用星号、冒号或者下划线把两种词尾并进一个词。这些符号在页面上只占一个字符，在分词器眼里却是一道词边界，于是那个词被切成两半，传统写法和新写法两边的查询都接不住。本文按品牌合规、无障碍、检索三方各自的最优解拆开这一层，指出唯一的交集，并给词表加一个别的词类都不需要的字段。

## 为什么这一批词在正文里已经铺开，搜索量却始终是零？

## 先说清楚这篇文章处理的是哪一层问题

德语里指人的名词分阴阳两套形态，顾客、学生、作者都是如此。

要同时指代两种人，传统做法是把两个完整的词都写出来。

近些年出现了几种更紧凑的写法，用一个符号把两套词尾并进一个词。

星号、冒号、下划线、中圆点，各家用的符号不完全一样。

这篇文章不讨论该不该用，只讨论用了之后关键词覆盖会发生什么。

做德国文创礼品那个站的时候，这件事是市场部先提出来的，理由是品牌语气要跟上当地的表达习惯。我们当时觉得这是个纯文案问题，改就改了，直到三个月后做词表复核，才发现有一整批指人的名词在搜索侧彻底不在场。

之所以要先划这条线，是因为这个话题在中文圈的讨论里几乎全是立场之争，而立场之争对做站的人没有任何操作价值。你需要知道的只有一件事：不管最后决定用哪种写法，页面上都必须有一个能被检索系统当成完整词元处理的形态在场，这一条跟立场无关，是工程约束。

## 正文里的采纳速度和搜索框里的采纳速度完全不同步

这是这一层最核心的一个观察，也是最容易被数据掩盖的一个。

网站、媒体、机构文书里的新写法比例这几年一直在涨。

而搜索框里出现这些符号的比例，几乎一直贴着零。

两条曲线在同一个时间段里，一条上升一条不动。

如果只看内容侧的数据，你会以为这个写法已经成为主流。

DWDS收录的这个动词词条 (https://www.dwds.de/wb/gendern)本身就能说明这个话题在德语文本里的活跃程度，用例密度这几年一直在增加。但内容侧的活跃跟查询侧的活跃是两回事，而绝大多数人手里只有内容侧的数据，因为那是自己能数的。

这两条曲线分家还有一个特别容易误判的地方：内容侧的数据是自己能数的，查询侧的数据要么来自第三方工具、要么来自站内日志，多数团队两样都没有认真看过。能数的那个数会自动成为决策依据，哪怕它衡量的根本不是你要的东西，这是所有指标错配的共同起点。

## 判别法只有一句：这个变化要不要用户多按一个键

不同步这件事听起来像个巧合，其实有一条很硬的规律在后面。

凡是只改变展示效果的规范变化，搜索侧几乎立刻同步。

凡是要求用户改变输入动作的变化，搜索侧永远滞后。

滞后的时长以年计，而且没有任何迹象表明它会自动缩短。

星号和冒号在手机键盘上都要切到符号面板，多按两下。

这条判别法可以推广到任何一次正字法或者书写习惯的变动：先问它落在展示层还是落在输入层。落在展示层的，内容改了搜索也就跟着改了；落在输入层的，内容和搜索会长期分家，而你的关键词表必须同时服务两边。

这条判别法在别的语言现象上也验证过。用户把长词削短 (https://zhangwenbao.com/minor-language-clipped-short-forms-keyword-coverage.html)是省键，所以搜索侧跑在内容侧前面；变音符号打起来费事，所以不打变音符号的写法在查询里份额一直很高。方向永远是一致的，输入成本低的那一边赢。

## 这是全站唯一一类有保质期的正字法

正字法这种东西通常几十年不动，改一次是件大事。

这一族写法不一样，它的规范状态每隔一两年就有新的进展。

官方机构的表态在变，各地的行政规定也在变。

于是词表里这一类词的结论，可能一年后就需要重新确认。

别的词类不存在这个问题，德语的复合词规则十年不会动一次。

这条特性直接决定了词表结构：这一类词需要一个别的词类都不需要的字段，用来记录上一次确认的时间。这跟德语复合词那种一次做对就能长期不动的工作 (https://zhangwenbao.com/german-seo-compound-words-umlaut-eszett-keyword-research.html)完全是两种性质，管理方式也得跟着换。

有保质期这件事还带来一个组织上的后果：这一族词不能一次性交付完就撤人。别的语言层工作做完可以交给流程去维护，这一类必须留一个明确的负责人，哪怕他一年只需要花两个小时。没有负责人的结果不是没人做，是所有人都以为别人在做。

## 星号、冒号、中圆点插在词中间，机器会读成什么？

## 非字母字符默认就是词边界

分词是检索链路上最靠前的一步，也是最不透明的一步。

默认规则很简单，遇到不是字母也不是数字的字符就切一刀。

星号插在词中间，那个词就被切成前后两段。

前一段是词干，后一段是阴性词尾，两段单独都不是完整的词。

于是这个页面在传统写法和新写法两边的查询上都不在场。

Unicode的文本分段标准附件 (https://unicode.org/reports/tr29/)定义了默认的词边界判定规则，星号、冒号、下划线在这套规则里的处理各不相同，值得逐个确认而不是凭印象假设。这跟缩略语用冒号接格尾被切开 (https://zhangwenbao.com/minor-language-acronym-initialism-local-forms-inflection.html)是同一个机制的另一次发作，只不过那一次符号在词尾，这一次符号在词中间。

值得注意的是不同符号在这套规则里的待遇并不相同。有些符号在特定上下文里不构成词边界，有些无条件构成。凭直觉假设所有符号一视同仁，是这一层最常见的一个想当然，正确做法是把你实际用到的那几个符号逐个查一遍规则，十分钟能查完。

## 切开之后两边的碎片都没有搜索量

被切出来的词干在德语里通常不是一个能独立使用的词。

被切出来的词尾更是如此，它只是一个构词成分。

两个碎片各自的查询量都接近零，加起来还是零。

这跟一个词被拆成两个都有量的词是完全不同的情况。

后者至少还能捞回一部分流量，前者是彻底归零。

这个后果比它看起来更严重，因为指人的名词恰好是购买意图最明确的一类词。顾客、买家、送礼的人、收礼的人，这些词后面往往跟着的是具体需求。整族词一起失效，损失的不是长尾而是中腰部。

这一族词还有一个特点让损失被进一步放大：它们经常出现在页面标题和分类名里，而不是埋在正文中间。标题里的词一旦失效，整个页面在这个概念上的主题信号都会变弱，影响的不只是那一条查询，而是这个页面被判定成关于什么的整体判断。

## 可见符号和不可见字符的机器后果是一样的

去年我们处理过一次隐形字符导致的标题拆分，机制跟这次一模一样。

区别只有一个，那次插进去的字符肉眼看不见。

这一次插进去的符号明明白白地显示在页面上。

可见与否只影响人的感受，不影响机器怎么切。

所以看得见反而更危险，因为它会让人误以为自己知道发生了什么。

这一条跟为了排版往词里插看不见的字符 (https://zhangwenbao.com/minor-language-line-break-soft-hyphen-invisible-character.html)那次的结论是连着的：只要改动落在字符串本身而不是样式表里，机器就会一起读到。可见性是给人的属性，不是给机器的属性，两者从来不在同一个维度上。

把可见和不可见两类放在一起看，还能得到一条更省事的自检：不管符号看不看得见，只要它出现在会被存进数据库、被写进接口、被拼进链接的那个字符串里，就按会被机器读到来处理。判据是它写在哪儿，不是它长什么样，这一条能省掉大量逐个符号的讨论。

## 官方规范到今天给出的结论是什么？

## 德语正字法委员会的立场

德语的正字法有一个跨国的官方机构在负责，德奥瑞三国共同参与。

这个机构在2021年3月给出过一份明确的建议。

建议的核心是这类词内特殊字符暂时不纳入官方规则集。

不纳入不等于禁止，而是继续观察其在实际使用中的发展。

这个表态之后几年，官方规则集里补上了一段专门讲词内特殊字符的条款。

这份建议的原文 (https://www.rechtschreibrat.com/geschlechtergerechte-schreibung/)可以直接读，它同时列出了几种被认为符合规范的替代写法，对做词表的人来说这份清单比结论本身更有用。官方规则集的页面 (https://www.rechtschreibrat.com/amtliches-regelwerk/)上那段关于词内特殊字符的补充条款则给出了更具体的适用说明。

这份建议里最实用的部分其实是那张替代写法清单。它把哪些写法被认为符合规范列得很清楚，而做词表的人真正需要的正是这张清单，不是那个结论。官方文件里最有用的经常不是它的立场，而是它顺带划出来的那个可选集合。

## 各地行政规定的方向并不一致

德国是联邦制，行政文书的用语规定由各州自己定。

2024年起有几个州在行政和学校文书里限制了这些写法。

另一些州没有类似规定，机构和企业照旧使用。

企业不受行政文书规定的直接约束，但会受到氛围影响。

法语区的情况类似，官方文书层面有过明确的限制性通函。

这些规定管的是政府和公立机构自己怎么写，跟商业网站没有直接的法律关系。但它们会改变一件事：当官方材料不再使用某种写法时，那种写法在正式语境里的出现频率会下降，进而影响用户对它的熟悉程度和输入意愿。这个传导链条很慢，却是单向的。

各州规定不一致这件事对做站的人有个具体影响：如果你的目标客户里有公立机构或者学校，它们所在州的规定会直接影响采购文书的写法，而采购文书里的用词往往就是采购人员搜索时用的词。面向政企的德语站要单独确认这一层，面向消费者的站基本可以忽略。

## 规范状态对关键词工作的实际影响

很多人把官方表态当成一个该不该用的信号，其实用处不在这里。

它真正的用处是告诉你哪几种替代写法是被承认的。

被承认的写法可以放心用在正式位置上，不会有人挑毛病。

而这些写法恰好也是分词器能正常处理的那几种。

规范和检索在这一层的结论意外地一致。

这种一致不是巧合。被承认的写法之所以被承认，是因为它们没有引入词内的非字母字符，仍然是合乎构词法的完整词。合乎构词法这件事，同时也是分词器能正确处理的前提，两套评判标准背后是同一条约束。

这条一致性还能反过来当成一个检验工具。当你不确定某个新写法能不能用的时候，先问它是不是一个合乎构词法的完整词。是的话，规范和检索大概率都能接受；不是的话，两边大概率都有问题，不必再分别去查两遍。

## 屏幕阅读器读到这些符号会怎么念？

## 不同软件的处理方式不统一

读屏软件遇到词内的星号时，行为并不一致。

有的会把符号名念出来，有的会插入一个短暂的停顿。

有的按用户的标点朗读设置来决定，取决于个人配置。

同一个页面，两个使用者听到的可能是两种东西。

这跟视觉呈现的情况正好相反，视觉上大家看到的完全一样。

面向读屏兼容性的设计指南 (https://webaim.org/techniques/screenreader/)解释了这类内容为什么难以预测，核心原因是朗读行为同时取决于软件、语音引擎和用户设置三者，页面作者只能影响其中最弱的那一环。

这种不一致带来的实际后果是你无法在验收清单上写出一条可核对的标准。视觉呈现可以截图对比，朗读行为没法截图，只能实机测试，而实机要测几套组合才算数又没有公认答案。凡是无法被写成可核对标准的要求，最终都会退化成个人偏好，除非你把它换成一个能核对的代理条件。

## 使用者调查给出的是分布不是结论

关于读屏用户实际使用什么软件、什么配置，有持续多年的调查数据。

调查显示主流软件的份额相当分散，没有哪一家占绝对多数。

份额分散意味着你无法针对某一个软件做优化。

只能选择那些在所有软件上表现都可预测的写法。

这个判断标准比追求某个软件上的最佳效果更稳妥。

读屏用户调查的结果页 (https://webaim.org/projects/screenreadersurvey10/)提供了这类分布数据，可以直接拿来当作决策依据。需要注意的是调查样本以英语用户为主，德语用户的软件分布未必相同，但份额分散这个结论在各语言区大体一致。

调查数据的另一个用法是给内部讨论提供一个共同起点。当有人主张某种写法读屏软件处理得很好时，问一句他说的是哪一款软件、什么配置，多数情况下对方给不出答案。把分布数据摆出来之后，讨论会自动从软件表现转到应该选可预测的写法上。

## 把无障碍这笔账单独记

无障碍和检索在这一层的诉求碰巧接近，但它们不是同一件事。

把两者混着汇报，将来复盘时会分不清收益来自哪一侧。

记账要分开，评估标准也要分开。

无障碍看的是可预测性，检索看的是词元完整性。

两者恰好指向同一批写法，纯属这一层的运气。

正因为是运气，就更不能把它当成通用规律去别处套用。别的场合里这两者经常是打架的，比如把重要信息做成图片对视觉设计有利、对读屏和检索都不利。诉求一致的时候要庆幸，但不能因此假设它们总是一致。

这一条推广开来是：两件事目标一致的时候，仍然要用各自的标准分别验收。合并验收会让其中一项的通过完全依赖另一项，等到某天两者不再一致时，被依附的那一项会毫无征兆地失守，而没有人会立刻发现，因为验收表上根本没有它的位置。

英文世界的大型风格指南也在处理同一类问题，只是英语不需要改动名词本身，所以它们的规则集中在代词和职业称谓上。微软风格指南里关于无偏见表述的一章 (https://learn.microsoft.com/en-us/style-guide/bias-free-communication)给出的判断框架可以借用，但它的具体条目搬不到德语上，因为两门语言的问题根本不在同一个语法层次。

## 四种替代写法里，哪一种同时满足三方要求？

## 三个审阅者各自的最优解不一样

这一层的特殊之处在于同一个词要同时通过三道审阅。

品牌和合规那一侧希望用最能体现立场的紧凑写法。

无障碍那一侧希望用朗读行为最可预测的写法。

检索那一侧希望用分词器能识别成完整词元的写法。

三方各自的最优解互不相同，这才是真正的难点。

多数关于这个话题的讨论只站在其中一方，所以给出的结论看起来都很确定，实际上都不完整。把三方的要求并排列出来之后，问题就从该选哪个变成了哪一个选项在三栏里都及格，这是一个能被回答的问题。

三方审阅这件事本身也是一个可复用的分析框架。凡是遇到一个字符串同时被多个部门关心的场景，先把每一方的最优解各自写下来，再看有没有交集。有交集就选交集，没有交集才需要谈判。大多数争论其实是因为没人先把三栏并排列出来，各方都以为对方在无理取闹。

## 四种候选写法各自的表现

第一种是特殊字符写法，紧凑、立场明确，但分词器会切开。

第二种是词内大写写法，不引入符号，但读屏和分词都不稳定。

第三种是双写全称，两个完整的词并列，谁都能正确处理。

第四种是换成中性名词，一个词解决问题，但不是所有概念都有现成的。

四种里只有第三和第四种在三栏里都及格。

把这四种写法列成一张四行三列的表，贴在文案规范的第一页，比写十条规则管用。新同事看一眼就知道边界在哪，不需要理解背后的分词原理，也不会因为不理解而在某个位置擅自换写法。

这张表还要标明每一种写法当前的实际使用比例，因为及格不及格是技术判断，而选哪一个还要看当地惯例。技术上安全但当地几乎没人用的写法，放在标题里同样会显得别扭，只不过这一次别扭的是文案而不是机器。

这张表列完之后还有一步容易被跳过：拿自己站上已经上线的内容做一次实测，看四种写法各自在站内搜索里能不能被找到。理论推演和实际配置经常不一致，你的检索引擎可能做过某些自定义处理，实测五分钟就能知道。

## 双写全称为什么是安全的

双写全称的写法里，两个词都是完整的、词典里有的词。

分词器切完之后得到两个有效词元，两边的查询都能命中。

读屏软件按普通词朗读，没有任何特殊处理。

唯一的代价是它长，在标题和按钮这类窄位置上装不下。

但正文里长一点几乎没有成本。

DWDS的顾客词条 (https://www.dwds.de/wb/Kunde)可以看到这个词两种性别形态各自的用例，双写全称本质上就是把这两个已经存在的词并排放。它不创造任何新的字符串，所以不会引入任何新的处理风险，这是它最大的优点。

双写全称还有一个不太被注意的好处，它在语义上是自解释的。搜索引擎和语言模型读到两个并列的词，能直接建立起它们指向同一个群体的关系，而这种关系在特殊字符写法里是靠人的常识补出来的，机器没有这个常识。

双写全称的长度问题也有缓解办法，就是只在第一次出现时用全称，之后段落里改用中性名词或者传统写法。这样既建立了完整的语义关联，又不至于让全文读起来啰嗦，代价只是需要在文案规范里多写一行说明。

## 中性名词是最省事的一种

德语里有一批集合名词天生不分性别，指的是一个群体。

用集合名词替换指人名词，一个词就把问题解决了。

它短、它是完整词元、它在词典里、读屏毫无障碍。

问题是不是每个概念都有现成的集合名词可用。

有的时候硬找一个，读起来会很生硬。

顾客群体那个集合名词 (https://www.dwds.de/wb/Kundschaft)是一个现成可用的例子，它本身就有独立的搜索量，不需要你去创造需求。这一类词值得单独列一张对照表，因为它们是这一层里唯一不需要任何取舍的解法。

找中性名词的时候有个省事的办法，就是去看当地的招聘广告和政府表格。这两类文本因为法律和规范的原因，很早就在系统性地使用中性表述，积累了一批现成的、已经被广泛接受的说法，直接拿来用比自己造一个安全得多。

## 德语的现在分词名词化为什么是这一层最好的解？

## 一个已经存在几百年的构词法

德语可以把动词的现在分词直接名词化，用来指做这件事的人。

这种构词法本身不带性别倾向，复数形态天然中性。

它不是为了这个话题新造的，是语言里早就有的东西。

因为早就有，所以词典收录、语料丰富、用户熟悉。

更关键的是它本身就有可观的搜索量。

这类形态里最常见的一个词条 (https://www.dwds.de/wb/Studierende)能看出它在真实文本里的分布，词典里的规范条目 (https://www.duden.de/rechtschreibung/Studierende)也早就收了它。这意味着你不是在赌一个新写法会不会流行，而是在使用一个已经流行的词。

这类形态在德语里的地位跟意大利语那种每个形容词都要跟名词改性数 (https://zhangwenbao.com/italian-seo-gender-agreement-elision-keyword-research.html)的情况正好互补：意大利语的问题是形态必须跟着走，德语这一族的价值恰恰在于它把性别这个维度整个拿掉了，剩下的只有数和格两个维度要处理。

这类构词法在别的语言里未必有对应物，这正是这一层没法跨语言复制方案的原因。法语那种一个市场分成两边的情况 (https://zhangwenbao.com/french-seo-accents-quebec-keyword-variants.html)提醒过一次同样的道理：语言层的解法必须一门一门地找，能借的只有分析问题的框架。

## 为什么它在三栏里全部及格

它是一个完整的词，分词器毫无问题。

它在词典里，词干还原和同义扩展都能正确处理。

它读起来是一个普通的德语词，读屏软件正常朗读。

它形态中性，品牌和合规那一侧也接受。

四项全过，这在这一层里是独一份的。

唯一的限制是这种构词法只在存在对应动词的时候可用。有一批指人名词背后没有一个自然的动词，硬造一个现在分词会很别扭。所以它是首选而不是通解，实操上大概能覆盖这一族词的三分之一到一半。

四项全过这件事值得强调一下，因为这一层里所有其他方案都是有取舍的。当一个选项在所有评价维度上都不劣于其他选项时，它就不该被当成一个需要讨论的选项，而该被当成默认值，只有在它用不了的时候才进入讨论。

## 它跟屈折变化的关系要单独确认

这类名词化形态本身还是要跟着格变化的。

它的变化规则跟形容词一致，不跟普通名词一致。

做关键词表的时候这一点必须显式确认，不能想当然。

变化形态的数量不多，但落点位置不同。

面包屑和列表里用哪个形态，跟正文句子里不一样。

这一层的处理方式跟最高级形容词那族词要跟名词性数格对齐 (https://zhangwenbao.com/minor-language-comparative-superlative-keyword-forms.html)是完全一样的，因为它们走的本来就是同一套形容词变化规则。做过那一族的人可以直接把方法搬过来，连表结构都不用改。

这一层有个具体的坑：这类名词化形态在单数和复数上的行为不一样，复数是中性的，单数仍然要选一个性。所以它只在你要指一个群体的时候好用，指一个具体的人时问题依然存在。做词表时要把这两种用法分开，别当成一个词处理。

## 商品数据源和广告平台会不会把这些符号清洗掉？

## 特殊字符在数据管道上的旅程

商品标题不只出现在你的页面上，它还会流进好几个下游系统。

购物数据源、广告投放、比价站抓取，每一站都有自己的字符规则。

星号在一些系统里有特殊含义，会被当作通配符或者标记。

清洗行为通常是静默的，不会有任何提示。

你在自己站上看着好好的，下游拿到的可能已经变了样。

这一层的排查方式是逐站取回实际入库的字符串做比对，而不是看自己发出去的那一份。数据管道上的每一次静默改写，都只能在终点被发现，中间任何一个环节的日志都不会主动告诉你它动过手。

这类静默改写还有一个特别难查的变种，就是某个环节把符号替换成了看起来很像的另一个符号。视觉上几乎分辨不出来，字符串却已经不同了，所有的精确匹配都会失效。查这类问题只能逐字符比对码位，肉眼核对是没有用的。

## 标题字符预算被符号挤占

各个渠道对标题长度都有限制，超出部分直接截断。

特殊字符本身占位，双写全称更是把长度翻倍。

在有限的字符预算里，这一族词会挤掉别的关键词。

所以标题位上的取舍不只是形态问题，还是预算问题。

这也是中性名词最受欢迎的原因，它最短。

把字符预算算清楚是这一步的前提，做法是列出每个渠道的长度上限，然后按最紧的那个来定标题模板。这跟替代文本的字符上限在不同语言里含义不同 (https://zhangwenbao.com/minor-language-image-alt-text-non-latin-script-search.html)是同一类问题，字符数这个单位在跨语言时从来不是等价的。

算字符预算的时候还要留意一件事：不同渠道的截断位置不一样，有的按字符数截，有的按显示宽度截。德语的长词本来就容易触发截断，再加上这一族词的额外长度，标题在几个渠道上被截在不同位置，同一个商品在各处显示出来的名字会不一样。

## 结构化数据里放哪一种形态

结构化数据的字段是给机器读的，不承担任何表达立场的功能。

所以那里应该放最标准、最不会引起歧义的形态。

多数情况下是中性名词或者传统写法。

特殊字符写法不适合出现在这些字段里。

这跟正文的取舍逻辑不同，不要图省事直接复用。

这条跟正文越本地化越好而结构化数据要写回国际格式 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)是同一条原则的再次应用。面向人的位置和面向机器的位置，优化目标不同，写成一样两边都不讨好。

这里还有一个操作细节，结构化数据的别名类字段可以放多个值。把中性名词、传统写法一并放进去，机器侧的覆盖就完整了，而这个位置不影响任何人的阅读体验，是全站最不需要取舍的地方，能放就都放上。

这里还要提醒一句，别名字段虽然能放多个值，但也不宜把所有变体一股脑塞进去。放进去的每一个值都在向机器声明这是同一个东西，塞入不相干或者极少使用的写法，反而会稀释这个声明的可信度。

## 页面上哪些位置可以用包容写法，哪些位置不能？

## 按位置定规则，比按词定规则好执行

给执行者一份词级别的清单，他要先判断这个词属于哪一类。

给他一份位置级别的规则，他只需要看自己在改哪个字段。

位置是明确的、有限的、不需要语言知识的。

所以规范应该写成一张位置清单，而不是一张词表。

这条经验在别的语言问题上同样成立。

位置清单大概十来行就能写完：页面标题、一级标题、正文、按钮、面包屑、替代文本、结构化数据、内部链接锚文本、筛选项标签、页脚。每一行标明允许哪几种写法，新同事看一遍就能上手，不需要理解任何分词原理。

位置清单还有一个隐含好处，它让规则的执行可以被审计。一条按位置写的规则可以用脚本自动检查，一条按词写的规则只能靠人读，前者上线之后一直有效，后者取决于当时看的人是否细心，两者的长期可靠性差着一个数量级。

## 标题与锚文本是硬约束区

页面标题和一级标题是检索权重最集中的位置。

内部链接的锚文本同样直接参与相关性判断。

这几个位置只能用完整词元，没有商量余地。

用了特殊字符写法，等于主动放弃这几个位置的权重。

代价太大，收益只是表达上的一点差别。

锚文本这一层还有额外的复杂度，因为德语的锚文本本来就要跟着句子的格变化走。屈折语站的锚文本报告里精确匹配那一栏的数字本来就是假的 (https://zhangwenbao.com/minor-language-internal-link-anchor-inflection-variants.html)，再叠一层特殊字符，这一栏就彻底没法看了。

这几个位置还有一个共同特征，它们都是会被复制到别处去的字符串。页面标题会进搜索结果、进书签、进分享卡片；锚文本会出现在别人的站上。凡是会被复制走的字符串，都要按最保守的写法来，因为你控制不了它在别处会被怎么处理。

这几个位置还有一个共性是它们的修改成本最高。正文改一段是几分钟的事，改标题要考虑已有排名、已有外链和已经被收录的版本，改完还要等重新评估。越是难改的位置，越要在第一次就用最保守的写法。

## 正文和问答区是自由区

正文段落里用哪种写法，对检索的影响小得多。

因为正文足够长，同一个概念会以多种形态多次出现。

只要传统写法在文中出现过，覆盖就算成立。

问答区同理，那里本来就该用用户的口吻写。

所以表达立场的空间主要在这两个区域。

问答区还有一个额外的好处，它天然允许同一个概念用不同说法反复出现，这在别的位置会显得啰嗦。小语种的问答长尾没多少人搜但认真写的也没几家 (https://zhangwenbao.com/minor-language-qa-long-tail-content-value-ai-era.html)，在这一族词上这个判断同样成立，而且问答区正好是唯一能把几种写法一起放进去而不别扭的地方。

正文自由不等于随便，还是有一条底线：同一个概念在正文里至少要有一次以完整词元的形态出现。做法是在第一段或者小标题下的第一句用传统写法或中性名词，之后段落里怎么写都行，这条底线的执行成本几乎为零。

## 用户生成内容不受你的规则约束

评论、问答、评价里的写法由用户自己决定。

他们几乎全部使用传统写法或者中性名词。

这批内容本身就是最好的真实用法样本。

定规则之前先把这批内容统计一遍，比看任何指南都准。

统计成本极低，导出来跑几个正则就有结果。

这份统计还有一个附加价值，它能让内部关于写法的讨论从立场之争变成数据之争。当双方都在引用外部依据的时候，争论不会有进展；把自己用户的真实分布摆出来，讨论会立刻收敛，因为那是双方都承认的事实。

这批内容还能当成一个免费的趋势监测器。每年把用户生成内容里各种写法的比例统计一次，比例的变化会比任何外部调研更早反映真实用法的走向，因为写的人就是你的用户本人，样本天然贴合。

统计的时候要把评价区和问答区分开数，两者的语体不一样。评价更口语、更接近搜索框里的输入；问答更书面一些。如果两个区域的写法分布出现明显差异，那个差异本身就是语体影响输入的直接证据。

## 词表在这一类词上要多加一个保质期字段

## 三个字段：概念、当前形态、上次确认时间

概念列写中性描述，不带任何目标语言的写法。

当前形态列写这一轮确定使用的那一种。

上次确认时间列记录最近一次复核规范状态的日期。

三列就够，不必把所有候选写法都塞进表里。

候选写法放在规范文档里，词表只记当前生效的那个。

时间列是这一类词独有的。别的词类不需要它，因为它们的正确答案不会随时间变化。把这一列加上去之后，每年做一次复核就有了明确的对象，不用凭记忆去想哪些词可能过期了。

这三列还有一条使用约定：当前形态那一列只能有一个值，不许写成两个用斜杠隔开。允许写两个的结果是下游取值的时候各取各的，同一个概念在不同位置出现不同形态，而这正是这套表要防止的事情。

## 复核的触发条件写清楚

不要定成每季度复核一次，那会变成一件没人做的例行公事。

改成事件触发：官方机构有新表态、主要平台改规则、同行集体换写法。

三个触发条件里任何一个发生，就把这张表拉出来过一遍。

平时不用管，一年可能一次都不触发。

触发时的工作量也不大，因为表只有三列。

事件触发比时间触发更适合这类工作，因为它的变化本身就是事件驱动的。定期复核会在没有事情发生的季度产生无意义的工作，几轮之后大家就开始走过场，等到真有事发生的时候，走过场的习惯已经养成了。

事件触发还需要指定谁来监测这三个事件。官方表态和平台规则可以订阅通知，同行写法要靠定期抽查。把监测责任写清楚之后，这套机制才真正跑得起来，否则触发条件写得再明确，也不会有人注意到条件已经满足了。

除了这三个事件，还有一个值得加进监测清单的信号，就是主流本地媒体的写作规范有没有调整。媒体的用词习惯直接塑造读者的熟悉度，它们的变化通常比官方表态更早，也比同行的商业写作更早。

## 跟母语同事的沟通方式

这个话题在当地是有立场分歧的，问法不当会跑偏。

不要问他觉得该用哪种写法，那是在问立场。

要问他自己在搜索框里会怎么打，那是在问行为。

行为问题几乎人人答得一致，立场问题人人不同。

而你要的恰好是行为数据。

母语者说读着自然不能当验收判据 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)这一条在这里有个新的用法：读着自然反映的是他对书面语的判断，而你需要的是他作为搜索用户的行为，两者在这一族词上恰好分歧最大。把问题换成动作，答案的可靠性会立刻提高一个档次。

这个问法的差别可以再往前推一步：问行为的时候要问最近一次而不是通常。通常会触发对方的自我描述，最近一次触发的是回忆，而回忆比自我描述可靠得多。这一条在做任何用户访谈时都成立，不限于这个话题。

## 上线后该怎么跟踪这条曲线

## 第一个数：查询里特殊字符的出现率

从站内搜索日志里统计包含这些符号的查询占比。

这个数在多数站上会是零点几个百分点甚至更低。

关键不是这个数本身，是它的变化趋势。

连续几个季度看，如果它开始明显上升，说明该重新评估了。

在它上升之前，一切按现有规则执行。

这个数是这一层唯一真正需要长期跟踪的指标，因为它直接对应那条滞后曲线。别的指标都是它的下游，它不动，别的也不会动。统计成本几乎为零，一条正则就够。

统计的时候要把几种符号分开数，别合并成一个特殊字符出现率。不同符号的普及程度不一样，合并之后你看到的是一个平均值，而真正有意义的信号往往只出现在其中某一个符号上，合并会把它稀释掉。

统计这个数还要注意排除内部流量和爬虫，这两类流量在站内搜索日志里的占比有时高得离谱，而它们的查询模式跟真实用户完全不同。不排除的话，某个内部同事反复测试的那几条查询会把整个分布带偏。

## 第二个数：指人名词族的整体覆盖

把这一族词单独拉出来算一次覆盖率。

分母是词表里的概念数，分子是站上有对应落点的概念数。

这个数如果明显低于全站平均，说明这一层还有系统性缺口。

缺口通常集中在筛选项和面包屑这类窄位置上。

补起来不难，难的是意识到它低。

算这个数的时候要按概念而不是按字符串来算，因为同一个概念有好几种写法，按字符串算会得到一个虚高的分母和一个虚低的覆盖率，两头都不准。字符层看不出重复而信息层十份一样 (https://zhangwenbao.com/multilingual-template-ten-languages-duplicate-content-risk.html)那篇讲的是同一个道理的反面，这里是字符层看着有很多行、信息层其实只有几个概念。

这个覆盖率还建议按位置拆开看一次，正文的覆盖率通常很高，窄位置的覆盖率通常很低。整体数字看着还行的时候，拆开看往往会发现问题全部集中在两三类组件上，而那几类组件恰好是模板生成的，改一次全站生效。

覆盖率算出来之后，最好把缺口清单直接生成成一张待办表，每行写清楚哪个概念缺在哪个位置。抽象的覆盖率数字很难推动工作，一张具体到组件的待办表可以直接派给前端，两者的执行率差距非常大。

## 第三个数：本地同行的写法分布

挑五到八家本地同行，统计它们在标题里用的是哪种写法。

这个分布是当地商业写作惯例最直接的样本。

每年看一次就够，它变化得比想象中慢。

如果分布开始明显偏移，那是比任何官方表态都早的信号。

因为商业写作跟着受众走，比规范文件反应快。

统计的时候要把标题和正文分开数，很多站的做法是正文用包容写法而标题用传统写法，这个内外有别本身就是一个信号，说明他们也遇到了同样的取舍并且做了同样的选择。看到三家以上都这么处理，你基本可以确认自己的方案是当地的主流做法。

看同行的时候还有一个信息容易被忽略，就是他们的改动时间。如果某几家是在同一个季度里集体换的写法，那多半是响应了某个外部事件而不是各自独立判断。找到那个事件，你就找到了这一层真正的驱动因素，比看结果本身有用得多。

还有一个观察角度是看同行有没有在同一个页面上同时使用两种写法。同一页混用通常说明他们也在做位置分区，只是没有对外说明。否定形态那一族词 (https://zhangwenbao.com/minor-language-negation-affix-exclusion-keyword-trap.html)上也出现过类似的混用现象，机制是一样的：正文表达和检索命中被分配到了不同的位置上。

## 常见问题解答

## 正文用包容写法会不会直接影响排名？

正文段落里用哪种写法，对排名的直接影响很小，因为正文足够长，同一个概念通常会以多种形态多次出现，只要传统写法或中性名词在文中出现过，相关性判断就能成立。真正有影响的是标题、一级标题、内部链接锚文本这几个权重集中的位置，在那里用特殊字符写法等于主动放弃这几个位置。所以结论不是不能用，而是分位置用。需要补充的是这个结论只适用于长正文页面，商品列表页和筛选页的文字总量很少，同一个概念往往只出现一次，那里的容错空间要小得多，基本要按标题的标准来处理。

## 为什么不干脆把所有写法都覆盖一遍？

因为特殊字符写法的查询量接近于零，为它建行、找落点、维护变体，投入产出比极低。更重要的是它在被分词器切开之后根本形不成一个可匹配的词元，就算你在页面上写了，也不会因此命中任何查询。覆盖的前提是那个字符串能被检索系统当成一个整体处理，这一族写法恰好不满足这个前提，所以它不是覆不覆盖的问题。换个角度说，覆盖这个动作的前提是那个字符串在检索系统里能被当成一个可匹配的单位，不满足这个前提的写法，写进页面只增加字符数不增加任何命中机会。

## 中性名词会不会显得回避问题？

这是文案和品牌层面的判断，不在本文的讨论范围内。从检索角度看，中性名词是唯一一种在词元完整性、朗读可预测性和字符长度三方面同时最优的写法，而且多数中性名词本身就有独立的搜索量。实操上常见的做法是标题和结构化数据用中性名词或传统写法，正文和问答区留给品牌自己决定，两边各取所需。另外要说明的是中性名词并不总是可用，有些概念在德语里找不到自然的集合名词或者现在分词形式，硬造一个读起来会很生硬，这时候双写全称才是那个兜底的选项。

## 这个问题在法语和西班牙语里一样吗？

机制一样，符号不同，成熟度也不同。法语用的是中圆点，西班牙语出现过用字母替换词尾的写法。共同点是都往词内引入了非常规字符，都会被分词器切开，都在搜索框里份额极低。区别在于各语言区的官方立场和普及程度差异较大，所以每个市场都要单独确认一次，不能拿德语的结论直接套用。还有一个值得注意的差别是各语言区的替代方案丰富程度不同，德语因为有现在分词名词化这条现成的路，选择空间明显比其他语言大，别的语言往往只剩双写全称一个安全选项。

## 怎么说服团队接受按位置分区的方案？

把三方要求列成一张表，让大家看到没有任何一种写法能在所有栏里得满分，问题就从选哪个变成了在哪个位置选哪个。这个转换本身能消掉大部分争论，因为它承认了每一方的诉求都是合理的，只是不能在同一个位置同时满足。再配上自己站内用户生成内容的写法统计，讨论通常在一次会议内就能收敛。如果争论仍然僵持，还有一个办法是把决策颗粒度降到单个位置：先就标题这一个位置达成一致，别的位置暂时不动。范围缩小之后结论容易得多，而标题本身已经解决了大部分的检索损失。

## 词表里的时间字段具体记什么？

记最近一次确认这个概念当前形态时的日期，以及确认时依据的是什么。依据可以是官方机构的表态、平台规则的更新，或者同行写法的统计。有了这两项，下一次复核时可以直接判断依据有没有变化，不用重新做一遍调研。字段本身很小，价值在于它把一次判断的上下文保存了下来，而不是只保存结论。另外建议把依据的链接也一并存下来，而不只是写一句依据是官方表态。半年后回头核对时，能直接打开原文比重新去搜一遍省事得多，而且能确认那个页面本身有没有被更新过。

## 用户生成内容里出现特殊字符写法要不要处理？

不要改动用户写的原文，那是真实语料，改了就失去了统计价值。需要做的是在展示层保持原样，同时在建立站内搜索索引时对这些符号做归一化处理，让搜同一个概念的人都能找到相关内容。原始数据保留、派生数据归一化，这条原则在所有涉及字符改写的场景里都成立。还要注意归一化规则要同时作用在索引侧和查询侧，只做一边等于没做。另外原始内容里的写法值得单独存一份统计，它是你手上唯一一份不受任何编辑加工影响的真实用法样本。

## 权威参考资料



## 小语种AI稿里读着最顺的那一段，恰恰是模型顺手编出来的本地规矩

- URL：https://zhangwenbao.com/low-resource-language-ai-hallucination-rate-content-risk.html
- 分类：小语种SEO
- 发布：2024-09-10  |  更新：2026-07-27
- 摘要：大模型写的小语种内容句子自然、语域也对，错的是里面那些本地事实。讲清英语默认值泄漏的四种形态、不懂那门语言怎么把错查出来，以及复核力度该按什么分档。
- 关键词：AI内容,内容SEO,多语言SEO,小语种SEO

> **TLDR**：摘要：机器翻译出的错读着别扭，母语审校一眼就能挑出来。大模型生成的小语种内容不一样，它的句子极其自然，错的是里面那些本地事实：退货期、门槛金额、支付方式、标准编号。审校最信任的信号是流畅度，而流畅度恰恰是这类内容最不缺的东西，于是这批错就这么过去了。

> 摘要：机器翻译出的错读着别扭，母语审校一眼就能挑出来。大模型生成的小语种内容不一样，它的句子极其自然，错的是里面那些本地事实：退货期、门槛金额、支付方式、标准编号。审校最信任的信号是流畅度，而流畅度恰恰是这类内容最不缺的东西，于是这批错就这么过去了。

## 机器翻译错的和大模型错的，为什么不是同一类错？

## 机翻错在说法上，一眼看得出

机器翻译直接发上线这件事，我们几年前就算过一笔账。那时候错误的形态很好认。

典型症状是词序别扭、搭配不对、专业术语被译成日常词，读起来像外国人写的。

这类错误有个好处：它自己会举手。任何一个母语者扫一眼就知道这段不是本地人写的。

所以机器翻译直发的那道审校 (https://zhangwenbao.com/machine-translation-direct-publish-search-risk-quality-line.html)虽然贵，但它的检出率很高，因为要找的东西摆在表面。

审校的工作方式也是围着这个特点设计的：通读一遍，凭语感标出别扭的地方。

这套方法在机翻时代是够用的，检出率能到八九成。

关键在于，这套方法的有效性完全建立在一个假设上：错误的内容读起来会不自然。这个假设在机翻时代成立得如此稳固，以至于没人把它当成一个假设写下来，它就成了审校流程里一条隐含的地基。而地基一旦被抽掉，整套流程会在没人察觉的情况下失效。

## 大模型错在事实上，读着毫无破绽

现在的生成内容是另一回事。句子流畅、搭配地道、语域也对。

你把它交给一个母语者，对方读完可能会说写得挺好，比我们上一版强。

问题出在那些具体的、可以被查证的细节上。一个日期、一个金额、一个机构名、一个标准编号。

这些细节不影响句子的通顺程度，所以通读的时候不会有任何异样感。

换句话说，错误从表层沉到了里层，而检查方法还留在表层。

这就是本文要讲的整件事：不是内容质量变差了，是错误改变了藏身的位置。

形象一点说，机翻时代的问题像是衣服穿反了，站远了都看得见；现在的问题像是衣服里缝错了一颗扣子的尺码，穿上去挺合身，出问题要等到某个具体场合。前一种靠看，后一种只能靠量。

这类错误还有一个让人难受的性质：它跟内容的整体水平不相关。同一篇稿子里，论述部分可能写得相当有见地，偏偏配送时效那一句是错的。所以不能用抽样通读来判断一批内容的可靠性，抽到的那几篇读着没问题，说明不了任何事，因为问题从来不是均匀分布在文字质量里的。

## 审校最信任的那个信号，正好失效了

母语审校在判断一段内容好不好时，最先用的信号就是流畅度。

这不是懒惰，是经验：过去二十年里，流畅度跟内容可靠性的相关性一直很强。

写得顺的内容，通常是懂行的人写的，懂行的人不太会把退货期写错。

现在这个相关性断了。流畅度变成了一件成本极低的事，任何人都能批量拿到。

而事实准确性的成本一点没降，它仍然需要有人去查、去核对。

两条曲线一个塌到地板一个纹丝不动，中间的关系自然就断了。

这条推论可以推广：任何一个曾经被当成质量代理的信号，一旦生产它的成本大幅下降，它就不再是代理了。流畅度是这一轮里最先失效的那个，后面还会有别的。在母语者读着自然不能当验收判据 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)那篇里我们已经提过一次，当时讲的是审校流程的形式问题，现在这个问题的严重程度又上了一档。

## 两类错误要配两套验收

结论很直接：验收不能只有一道，得有两道，而且两道的执行者可以不是同一个人。

第一道还是母语审校，看语言层面：语域、语气、术语、可读性。

第二道是事实核对，看内容层面：数字、日期、机构、编号、金额、单位。

第二道的关键在于，做这道工序的人不需要懂那门语言。

他要做的是把可证伪的句子挑出来，逐条对照官方来源。这件事跨语言是可执行的。

把两道工序分开还有个副作用是好的：责任划得清楚，出了事知道是哪一道漏的。

成本上这也是合算的。母语审校按小时计费，事实核对可以由内部的人做，而且随着核对清单的积累，速度会越来越快。一门语言做到第三批内容的时候，核对清单基本稳定，单篇耗时会降到二十分钟以内。

两道工序的先后不能颠倒。事实核对必须排在母语审校前面，因为审校在润色的时候有可能把一个具体数字改成一个笼统说法，或者把一句可核查的陈述改写成一句听着更顺的场面话。一旦具体信息被润掉，后面就再也没有东西可核对了，这一篇的事实风险等于被藏了起来。

## 低资源语言为什么更容易出这种事？

## 语料占比的真实数字

先看一组公开数字。大规模网页抓取语料的语言分布统计 (https://commoncrawl.github.io/cc-crawl-statistics/plots/languages)里，英语一门就占了四成以上。

排在前十的语言加起来能占到八成左右，剩下几百门语言分剩下那两成。

具体到单门语言，排在二十名开外的通常只有千分之几，再往后是万分之几。

这个分布跟网页内容语言份额的另一套统计 (https://w3techs.com/technologies/overview/content_language)互相印证，形状是一样的。

模型见到某门语言的次数，大体上跟这个比例成正比。

见得少不等于不会说，但见得少一定意味着关于这门语言所在社会的具体事实，模型知道得少。

这里有个容易混淆的地方要说清：语言能力和事实知识是两码事。模型说一门语言说得流利，靠的是这门语言的语法和常用搭配，这些东西在几百万句语料里就能学得不错；而某个国家的退货期是几天、哪家支付公司在当地占主流，这些是稀疏的事实，需要的语料量完全是另一个量级。流利度先饱和，事实密度后饱和，中间那段就是幻觉高发区。

## 缺语料的时候，模型在做什么

模型不会因为没见过就拒绝回答，它会用别的语言里学到的模式来补。

这个补的动作有个正式名字叫跨语言迁移，它本身是个了不起的能力。

正是靠它，多语言模型才能铺到七十多种语言 (https://zhangwenbao.com/multilingual-bert-seventy-languages-minor-language-seo-watershed.html)，让小语种享受到本来不该享受到的处理质量。

但迁移是有代价的。语法结构可以迁移，词汇对应可以迁移，事实不该迁移。

事实是绑定在具体社会上的：法律条文、商业惯例、生活习惯，换个国家就变了。

模型分不清哪些该迁移哪些不该，它只知道这里需要填一个数字，而它见过的数字是三十。

学界对这件事有过量化。有研究专门测了同一条事实用不同语言问的时候模型答案的一致性 (https://aclanthology.org/2023.emnlp-main.658/)，结论是一致性远低于直觉，而且低资源语言那一侧掉得更明显。也就是说同一个模型，你用英语问和用某门小语种问，得到的可能是两个互相矛盾的答案，它自己并不觉得有什么问题。

## 迁移过来的不只是语法

如果迁移只发生在语法层，那是纯粹的好事。麻烦在于它连带把语境也搬过来了。

模型学到的商业写作模式，绝大部分来自英语世界的电商内容。

那些内容里反复出现的数字、机构、流程，成了它心目中的默认值。

生成小语种内容的时候，语言换了，默认值没换。

于是你会看到一段地道的德语，讲着一套美国的退货规矩。

这个组合的欺骗性极强，因为语言那一层做得越好，内容那一层的错就越不容易被怀疑。

分词这一层也在放大这个问题。研究发现同一段内容在不同语言上被切成的片段数量差距可以达到好几倍 (https://arxiv.org/abs/2305.15425)，低资源语言普遍被切得更碎。切得越碎，模型在这门语言上能利用的上下文就越少，越倾向于回到它最熟悉的那套默认模式上去。

## 编出来的东西，为什么总带着英语的影子？

## 退货期那个数字

最典型的一个例子是退货期。英语电商内容里最常出现的数字是三十天。

这个数字不是法律规定的，它是美国零售业的商业惯例。

欧盟这边完全不同。消费者权利指令给的是十四天的无理由撤回权 (https://ec.europa.eu/info/law/law-topic/consumer-protection-law/consumer-contract-law/consumer-rights-directive_en)，这是法定下限。

落到德国，民法典里那一条把撤回权的期限写得明明白白 (https://www.gesetze-im-internet.de/bgb/__355.html)，同样是十四天。

如果模型给你生成的德语页面上写着三十天，句子毫无问题，事实错得离谱。

更糟的是这个错误方向对你不利：写多了就是承诺，客户拿着页面来主张权利，你得认。

我在一个婴童推车项目里见过接近的情况，页面上的退换说明和后台的实际政策对不上，差的正好是这类默认值。发现它的不是审校，是一个客服在处理投诉时觉得不对劲，往回查了一遍页面。从内容上线到被发现，中间隔了将近五个月。

## 免运费门槛与货币

第二类是金额。免运费门槛在英语内容里常见的表述是几十美元。

生成小语种内容时，货币符号往往被正确替换了，数字却原样保留。

于是四十九美元变成了四十九欧元，看着很自然，实际是两个不同的门槛。

更隐蔽的是数字格式本身。小数分隔符、千位分组、货币符号的位置，各语言各不相同。

这些在区域数据的数字与货币格式定义 (https://www.unicode.org/reports/tr35/tr35-numbers.html)里都有标准答案，但模型经常按英语习惯写。

格式错误不影响理解，却会让本地读者立刻察觉这段话不是本地人写的。

金额类错误还有个特点：它同时出现在正文、结构化数据和商品字段里，而三处的生成路径可能不同，改了一处另外两处还留着。结构化数据里那些不可见字段 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)正是最容易被漏掉的一处，因为它错了没有任何人会投诉。

还有一个容易被漏的地方是税费的呈现方式。有些市场习惯标含税价，有些市场习惯标不含税价再另行计算，模型按训练语料里的多数写法来，跟你实际的结算逻辑未必一致。这一项跟门槛金额一样，属于用户会拿计算器验算的那类信息，错了会被立刻发现，而且发现的时机通常是在结算页。

## 支付方式的推荐

第三类是服务商名字。英语内容里出现频率最高的支付方式，在很多市场根本不是主流。

模型生成荷兰语内容时如果没提当地最常用的那个支付方式，而是推荐了一个国际品牌，读者的信任感立刻打折。

更糟的情况是它提到了一个在当地并不提供服务的品牌，那就是硬伤了。

这类错误的检出成本极低：把内容里出现的所有服务商名字列出来，逐个查它在当地有没有业务。

十分钟能查完，但前提是有人想到要查。

这件事跟落地页上那批被当成装饰的信任元素 (https://zhangwenbao.com/minor-language-landing-page-trust-signals-payment-address-support.html)是同一批对象，只不过那时候的问题是没写，现在的问题是写错了。

两者的危害程度不一样。没写只是少接住一批高意图查询，写错了是主动给出错误承诺，用户按着做发现行不通，损失的是信任而不只是流量。所以这一类在核对清单里应该排在前面。

物流服务商也是同一类。模型很容易写出一个在当地并不派送、或者只做企业件不做个人件的承运商名字。这一项跟支付方式合在一起查最省事，因为它们通常出现在同一个段落里，都属于用户在下单前会确认的条件。查完一次记进事实卡，后面所有内容都能直接复用这两行。

## 这四类错有个统一的名字

把前面三类加上格式类归拢起来，它们有一个共同的结构。

模型在需要一个本地值的地方，填入了英语世界的默认值。

我把这个现象叫作英语默认值泄漏。名字不重要，重要的是它把一批看似无关的错误归到了一个成因下。

归到一个成因下的好处是，检查动作可以统一：凡是可能存在本地差异的值，全部标记待核。

而不是分别去记退货期要查、货币要查、支付方式要查这样一长串。

这份可能存在本地差异的值的清单，一门语言写一次，之后所有内容通用。

这个视角还能预测新的错误类型。任何一个你还没遇到过、但确实存在本地差异的字段，都可以提前放进清单，不必等它出事。发票要求、保修期限、年龄限制、包装标识，凡是各国规矩不同的，全都是候选。按成因归类比按症状归类的优势，就在于它能覆盖还没发生的那部分。

## 幻觉在小语种内容里，一共有几种形态？

## 第一类：本地法规与标准编号

这一类风险最高，因为它同时涉及合规和责任。

常见形态是文中引用了一个标准编号、一条法律条款、一个监管机构的名字。

编号这种东西模型特别容易生成，因为它见过成千上万个类似格式的编号。

格式对了，编号本身可能指向另一个完全不相干的标准，或者根本不存在。

婴童品类是重灾区，因为这个品类的安全标准多、编号密、消费者又特别在意。

核对方法是去标准化机构的官方目录里查这个编号，看它对应的标题是不是文中说的那件事。

顺带说一个可以定期看的公开来源：欧盟那个危险产品快速预警系统的公开通报 (https://ec.europa.eu/safety-gate-alerts/screen/webReport)，能看到哪些品类近期因为哪些标准被通报。做婴童、玩具、小家电这些品类的团队，把它当成月度例行阅读，既能核对标准编号，也能提前知道自己的品类正在被盯什么。

## 第二类：本地服务商与平台名

这一类包括支付公司、物流公司、电商平台、评价平台、行业协会。

错误形态有三种：名字拼错、这家公司在当地不提供服务、这家公司已经改名或退出。

第三种最阴险，因为它曾经是对的，模型学到的是几年前的事实。

这一类跟模型的训练时间点直接相关，也是训练截止时间造成的信息滞后 (https://zhangwenbao.com/ai-citation-refresh-lag-llm-cutoff-rag-indexing-delay.html)在内容侧的具体表现。

核对方法是打开这家公司的官网，看它的服务地区列表里有没有你的目标市场。

三分钟一家，一篇内容里通常不超过五家。

有一个偷懒但有效的做法：把这类名字全部换成描述性说法，比如写当地主流的即时转账方式而不写具体品牌名。这样既避开了核对成本，也避开了品牌变动的风险。代价是内容的具体感下降一点，但在拿不准的时候，模糊比错误安全得多。

## 第三类：计量单位与格式

这一类包括尺寸单位、重量单位、温度单位、纸张规格、电压与插头标准。

英语世界的默认值在这里格外顽固，因为美制单位在训练语料里出现得太频繁。

一段德语的产品描述里冒出英寸，或者一段法语的说明里出现华氏度，都是常见情况。

格式那一半前面说过了，数字分隔符、日期顺序、地址行的排列都算。

这一类的检出最容易自动化：写一组正则，扫出所有单位符号和数字格式，人工只看扫出来的部分。

一个脚本能覆盖所有语言，写一次长期用。

自动化的时候要注意一个细节：不要只扫符号，还要扫数值的合理范围。一辆婴童推车的重量写成七点五磅还是七点五公斤，符号都对，数值差了一倍多。范围校验只要给每个字段配一个上下限，就能把这类换算错误一次性挡住。

纸张与包装规格是这一类里最不起眼的一项，却经常出现在说明书和使用指引类内容里。同一件商品的包装尺寸标准，在不同市场的表述惯例不一样，模型混用之后，读者按文中的数字去比对实物会对不上。这类错误不会引发投诉，但会悄悄削掉一部分对内容的信任。

## 第四类：称谓、地址与联系方式

这一类看着最不起眼，却直接影响转化。

称谓涉及正式程度和性别形式，各语言规则不同，写错了读者会觉得被冒犯。

地址格式各国排列顺序不一样，邮编在前还是在后，门牌号在前还是在后，都不一样。

联系方式的坑在电话号码格式和区号，以及客服时间用的是哪个时区。

还有一类是隐私相关的告知义务，欧盟市场对此有明确要求。

比如数据收集时应当告知用户哪些事项 (https://gdpr-info.eu/art-13-gdpr/)是有条文规定的，生成内容里那段隐私说明不能靠模型自由发挥。

法国的监管机构还给了一份面向企业的合规入门指引 (https://www.cnil.fr/fr/rgpd-par-ou-commencer)，这类官方发布的入门材料是核对隐私文案时最省事的对照物，比找律师快，也比问模型可靠。

称谓这一项还有个跟检索直接相关的后果。有些语言的正式称谓和日常称谓在字面上差别很大，页面上用了一种，用户搜的是另一种，两边对不上。这跟内容准确其实是两个问题，但它们经常同时被模型的默认倾向带偏，所以放在一张清单上一起检查更省事。

## 不懂那门语言，怎么把这些错查出来？

## 先把可证伪的句子挑出来

整篇内容里，绝大部分句子是不可证伪的：观点、描述、建议、修辞。

可证伪的句子有个明显特征：它包含一个具体的、有唯一答案的信息。

一个数字、一个日期、一个专有名词、一个编号、一个百分比。

把这类句子挑出来，一篇三千字的内容通常只有十五到二十五句。

这个挑选动作不需要懂那门语言，因为数字和专有名词在任何书写系统里都是可识别的。

挑完之后交给翻译工具逐句译成中文或英文，再逐条核对。

学界给这套工作方式起了名字并做成了评测集，细粒度事实核查基准 (https://arxiv.org/abs/2311.09000)做的就是把一段文本拆成可核查的原子断言再逐条判定。原理跟这里说的完全一样，只是他们做得更细。做内容的人不必做到那个粒度，挑出带具体信息的句子就够。

挑句子的时候有个简单的操作口诀：看句子里有没有可以被另一个人独立查证的东西。有就挑出来，没有就跳过。按这个口诀，一段抒情的品牌介绍可能一句都挑不出来，而一段配送说明可能整段都要挑。挑出来的密度本身也是个有用的信号，密度越高的段落，风险等级就越高。

## 数字、编号、专有名词三类优先

时间有限的时候，按这个顺序查。数字最优先，因为它错得最频繁且后果最直接。

编号第二，因为它一旦错就是硬伤，而且检出成本很低。

专有名词第三，包括机构名、公司名、平台名、标准组织名。

剩下的那些不可证伪的句子，交给母语审校去看语言质量，两条线并行。

这个分工的好处是两边都在做自己擅长的事，没有重叠也没有空白。

实际操作下来，事实核对那条线花的时间通常只有母语审校的三分之一。

还有一个优先级判据可以叠加：这句话如果错了，会不会构成一个对外承诺。构成承诺的排在最前面，因为这一类的代价不是被搜索引擎判低质，是真金白银赔出去。退货期、保修期、免运费门槛、配送时效都属于这一类。

百分比要单独说一句。它看着像数字，其实经常是模型自己算出来或者凭印象给的，而且很难核对到确切来源。做法上建议直接删掉那些无法追溯来源的百分比，改成定性表述。一个查不到出处的精确数字，比一句模糊的定性判断更危险，因为前者会让读者以为背后有数据支撑。

## 用本地官方来源核对

核对的时候，来源等级要卡住。第一等是政府和监管机构的官网。

第二等是行业标准组织和法定登记机构。第三等是相关企业的官网。

不要用问答社区、不要用聚合网站、更不要用另一个模型来核对。

用模型核对模型这件事听着省事，实际上两边可能共享同一批默认值，一起错还互相确认。

官方来源的另一个好处是它可以被引用。核对完之后把链接留在文档里，将来有争议时拿得出依据。

德国那边法律条文全文在线可查，欧盟层面的指令也有官方页面，这类来源找起来并不费劲。

把核对来源整理成一张按市场分组的表，是这件事里回报最高的一次性投入。一个市场大概八到十二个链接：消费者保护、隐私、标准、税务、支付监管各一两条。表建好之后，后续每一篇内容的核对都是查表，不是重新搜索。核对的成本主要在找来源，不在读来源，所以固化来源清单能把单篇耗时压掉一大半。

## 十条清单跑一遍要多久

把前面的东西压缩成一张十条的清单，逐条过：退货与撤回期限、免运费门槛与货币、支付方式、物流服务商、标准与法规编号、计量单位、数字与日期格式、地址与电话格式、隐私告知、客服时间与时区。

一篇三千字的内容，熟练之后二十分钟能过完。

第一篇会慢，可能要一个半小时，因为你在同时建那张来源表。

到第五篇左右速度就稳定了，因为大部分来源已经在表里。

这个时间成本相对于内容生成节省下来的时间，占比很小。

换句话说，生成式工具省下的时间，拿出一小部分回来做核对，剩下的仍然是净赚。

需要提醒的是这十条不是通用清单，它是按电商内容的常见风险排的。做别的内容类型要重排：技术文档的风险集中在版本号和参数，医疗健康类集中在剂量和适应症，金融类集中在费率和资格条件。清单的条数保持在十条左右就好，太长了没人会真的逐条过。

## 复核强度该按什么分档？

## 按语言的语料丰度分三档

不是所有语言都需要同样的复核力度，把力气平均分配是浪费。

第一档是高资源语言：德语、法语、西班牙语、日语这一类，语料充足，事实密度高。

第二档是中等资源语言：北欧几门、中东欧几门、东南亚几门，语料有但不厚。

第三档是低资源语言：使用者不少但网络语料稀薄的那一批，非洲和南亚有不少。

三档对应的抽检比例可以定成一成、三成、全量。低资源那一档必须逐篇过。

怎么判断一门语言在哪一档？看前面那份语料分布统计里它的百分比，超过百分之一算第一档，千分之一到百分之一算第二档，以下算第三档。

学界的跨语言评测也支持这个分法。一项横跨多语言多任务的模型评测 (https://aclanthology.org/2024.naacl-long.143/)发现模型表现随语言资源量下降的曲线不是线性的，到了低资源那一段会陡然下滑。这意味着分档比按连续比例调整更实用，因为真实的质量差异本来就是阶梯状的。

分档时有个细节要注意：判断依据是这门语言在网络语料里的占比，不是它的使用人口。有些语言使用者上亿，网络书面语料却很稀薄，因为使用者主要在口语场景里用它。这两个数字可以差出一个数量级，按人口分档会把一批高风险语言错误地放进低风险档，正好放松了最该收紧的地方。

## 按内容的责任等级再加一层

光按语言分档还不够，同一门语言里不同类型的内容风险差别很大。

责任等级最高的是那些构成对外承诺的内容：退换政策、保修条款、配送时效、价格说明。

其次是涉及安全和合规的内容：产品标准、使用限制、年龄限制、成分说明。

再次是可能影响购买决策但不构成承诺的：选购建议、对比、使用技巧。

最低的是纯描述性内容：品牌故事、场景介绍、氛围性文案。

四个等级对应四种处理：逐句核对、清单核对、抽样核对、只做语言审校。

责任等级这个维度还有一个好处：它跟语言无关，所以判定规则全站通用，写一次就能给所有语言版本用。定规则的时候把它挂到页面模板上，某个模板产出的内容天然属于哪一级，不用每篇重新判断。

责任等级的判定不需要每篇讨论，把它绑到内容类型上就行。政策类、条款类、参数类的模板天然是高责任，导购类、场景类的模板天然是低责任。绑定之后，一篇内容属于哪一级在选题的时候就确定了，不用等写完再评估，也就不会出现赶工期时临时降级的情况。

## 两个维度叠出来的矩阵

把语料丰度三档和责任等级四级叠起来，得到一个十二格的矩阵。

右上角那几格是低资源语言加高责任内容，这是唯一必须百分之百人工逐句核对的区域。

左下角那几格是高资源语言加低责任内容，可以直接发，抽样都可以省。

中间那些格子按比例抽检，比例从三成到八成不等。

这张矩阵的价值不在于精确，在于它把一个模糊的要谨慎变成了可以排进工时表的数字。

而且它能拿去跟上级谈资源：右上角有多少篇内容，就需要多少小时的核对工时。

矩阵填好之后会发现一件事：真正需要重投入的格子通常只占内容总量的一到两成。剩下八成可以走轻流程。这个结论对推动流程落地很关键，因为如果听起来是所有内容都要加一道工序，反对的声音会很大；说清楚只有两成需要加，阻力立刻小很多。

## 为什么错误率这个指标会骗人？

## 同样的错误率，后果不一样

假设两批内容的事实错误率都是百分之三，一批是英语，一批是某门小语种。

直觉上这两批的风险相等。实际上差得很远。

英语那批内容的读者多、渠道多、反馈路径畅通，错误很快会被指出来。

小语种那批的读者少，而且他们发现问题之后未必会告诉你。

于是同样的错误率，英语那批的错误寿命可能是两周，小语种那批可能是两年。

用错误率衡量风险，等于假设所有错误的寿命一样长，这个假设显然不成立。

翻译研究里也有类似的观察。一项针对多语言翻译模型幻觉的系统研究 (https://arxiv.org/abs/2303.16104)指出，低资源方向上的幻觉不但更频繁，而且形态更隐蔽，输出跟输入几乎没有语义关联却读着完全通顺。检测这类输出需要专门的方法，靠常规质量指标是发现不了的。

## 可发现性才是关键变量

把风险重新定义一下：风险等于错误率乘以错误寿命。

错误寿命由可发现性决定，而可发现性跟语言、渠道、用户构成都有关。

这个改写带来一个直接的操作结论：应该在可发现性最低的地方投入最多的事前检查。

而可发现性最低的地方，恰好是低资源语言加低流量市场，也就是最容易被忽略的那一批。

常规的资源分配逻辑是按流量分，流量大的多投入。这跟风险逻辑正好相反。

两套逻辑打架的时候，正确做法不是二选一，是分开算：内容生产按流量分配，质量检查按可发现性分配。

这个思路可以推广到别的地方。凡是反馈回路弱的环节，都要靠事前检查来补，因为事后没人会告诉你出了问题。结构化数据是全站唯一写错了没人会投诉的地方 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)那条老结论，讲的是同一件事的另一个版本。

可发现性还可以进一步拆成三个因子：读者数量、读者反馈意愿、反馈渠道的可达性。三个因子在小语种市场上通常同时偏低，所以它们是相乘而不是相加的关系，掉下来的速度比直觉快得多。理解这一点之后就不难接受一个结论：小语种内容的事前检查标准，应该比英语内容更严而不是更松。

## 投诉链路的语言决定了可发现性

还有一层结构性原因容易被忽略：投诉链路本身是有语言的。

很多出海团队的客服系统、工单系统、反馈表单，界面和处理流程都是英语的。

一个只会说本地语言的用户，看到页面上的错误，要跨过一道语言门槛才能告诉你。

大部分人不会跨这道门槛，他们的做法是关掉页面去别家买。

所以你收到的投诉量，反映的不是错误的多少，是你的投诉链路对哪种语言友好。

这也解释了一个常见的错觉：小语种版本的投诉最少，团队因此认为它质量最好。

要打破这个错觉，有个成本很低的办法：在小语种版本上放一个用本地语言写的、一句话就能提交的反馈入口，不要求填邮箱不要求登录。开三个月看看数量。多数团队第一次做这件事的时候，收到的问题数量会超出预期，而且其中相当一部分是内容错误而不是功能问题。

## 提示词能不能把幻觉压下去？

## 能压一部分，压不住哪一部分

提示词工程在这件事上确实有用，但作用范围有限，要说清楚边界在哪。

它能压住的是风格层面的偏移：语域太美式、句式太英语、举例都是美国场景。

这些通过明确指令加上几个示例，改善很明显。

它压不住的是模型压根不知道的事实。你要它写某个小市场的退货规则，它不知道就是不知道。

要求它准确并不能让它变得准确，只能让它更自信地说出一个错误答案。

这一点跟人不一样：人不知道会犹豫，会加限定词，模型不会。

有研究专门测过多语言场景下的这类问题，模型在非英语语境下的行为一致性明显低于英语 (https://arxiv.org/abs/2401.13136)，同一套约束在英语上生效、换一门语言就未必生效。这意味着你在英语上调好的提示词模板，直接搬到小语种上要重新验证，不能默认继承。

## 把本地事实当输入，而不是让它回忆

真正有效的做法是改变信息的来源方向。

不要问模型退货期是多少天，而是把退货期是十四天这句话作为输入给它，让它写进内容。

这个转换把模型的角色从知识来源变成了语言工具，而后者才是它真正可靠的部分。

具体做法是给每个市场维护一份事实卡：退货期、门槛、支付方式、物流商、客服时间、法规要点。

生成内容时把这张卡片连同指令一起送进去，并明确要求所有本地信息只能来自卡片。

这张卡片一个市场维护一份，每季度核一次，成本很低。

事实卡还有个衍生用途：它天然就是核对清单。生成完之后，把内容里所有本地信息跟卡片比对一遍，不在卡片上的信息就是模型自己加的，全部标红待查。这一步可以完全自动化，因为卡片是结构化的。把事实前置成输入，等于同时解决了生成和验收两个环节。

## 不知道就说不知道这句话的实际效果

在指令里加一句不确定的地方就说不确定，效果比想象中弱。

模型对自己知道多少的判断本来就不准，尤其在低资源语言上更不准。

它可能对一个编错的编号很有把握，对一个正确的日期反而加了限定词。

所以这句话可以加，但不能因为加了就放松核对。

更有用的一个技巧是要求它把所有本地事实单独列在文末，用一个清单的形式。

这样核对的对象从一整篇内容变成了一份短清单，工作量直接降一大截。

这个技巧还有个副产品：如果清单里的某一条在正文里找不到对应位置，或者正文里有本地事实没进清单，说明生成过程本身出了偏差，这一篇建议重新生成而不是修补。把它当成一个廉价的自检信号，比通读全文快得多。

还有一种写法值得一试：要求模型在每个本地事实后面标注它的来源类型，是来自输入的卡片还是它自己补的。标注未必百分之百准确，但它会显著提高标出自己补的这一类的比例，因为这个要求把判断动作显式化了。标出来的那几条重点查，没标的抽查，核对效率能再提一截。

## 生成式结果引用了错的内容会怎样？

## 错误会被搬到结果页上

这一层是今年才变得要紧的。以前内容里的错误只影响看到这个页面的人。

现在结果页上那段生成的回答会从若干个页面里取材，你的错误可能被搬上去。

被搬上去之后，看到这个错误的人数量级不同了，而且它不再显示在你的页面上。

用户看到的是一个综合过的回答，未必会点进来核实。

对小语种市场来说这个放大效应尤其明显，因为这些语言里可选的来源本来就少，而哪几门语言已经被覆盖、哪几门还没轮到 (https://zhangwenbao.com/sge-non-english-language-coverage-early-observation.html)，本身就有一份可查的时间轴。

来源少意味着你被取材的概率高，也意味着一旦错了没有别的来源来对冲。

这跟供给稀缺让小语种内容更容易被引用 (https://zhangwenbao.com/minor-language-qa-long-tail-content-value-ai-era.html)是同一个机制的两面：稀缺带来更高的被引用概率，也带来更高的错误传播概率。同一个杠杆，两个方向都放大。

还有一个方向的影响也要考虑到：被搬上去的如果是正确内容，收益同样会被放大。所以这件事不是单纯的风险，是一个双向放大器。真正要避免的是在放大器接通之后才想起来检查内容，那时候被放大的是什么，你已经决定不了了。接通放大器之前把内容校准，是这件事唯一有效的顺序。

## 撤回的路径比发布长得多

发布一篇内容是几分钟的事，让一个已经被引用的错误消失要经过好几道。

第一步是改页面，这是你能控制的，当天就能做完。

第二步是等重新抓取，小语种站的抓取频率通常不高，可能要几周。

第三步是等生成侧更新它的取材，这一步的时间完全不可控。

三步加起来，一个错误从改正到彻底消失，几个月是常态。

所以这件事上事前成本和事后成本的比例极其悬殊，二十分钟的核对对几个月的清理。

加快第二步有个实际办法：改完之后主动推送这个页面的更新，别等自然抓取。面向生成式结果的那套落地流程 (https://zhangwenbao.com/english-seo-ai-mode-12step-overseas-dtc-playbook.html)里主动通知这一环，在纠错场景下的价值比在新增内容场景下还高，因为纠错是有时效压力的。

这三步里最容易被低估的是第二步。团队通常按自己站上主要语言的抓取频率来估时间，而小语种版本的实际抓取间隔可能是主语言的好几倍。改完之后隔两天去看还是老内容，很多人会以为是缓存问题，其实只是还没被重新抓取，这中间的等待期要提前跟业务方讲清楚。

## 官方自己也演示过这个问题

今年五月那次生成式结果在美国大规模上线之后，出现了一批被广泛传播的错误答案。

产品方随后专门发文说明了那批错误的成因与后续措施 (https://blog.google/products/search/ai-overviews-update-may-2024/)，其中提到的一类是系统误读了网上本来就存在的低质内容。

这件事对内容方的启示很直接：结果页上的错误，源头未必在生成侧，可能就在某个页面上。

换句话说，你写下的每一个本地事实，都可能成为别人看到的那个答案。

这个责任在英语市场被几十个来源分摊，在小语种市场可能就落在你一家头上。

这不是要吓唬谁，而是说明为什么在小语种上做事实核对的边际收益比在英语上高。

顺带一提，那次风波之后能明显感觉到一个趋势：对来源质量的要求在提高，而事实准确是质量里最硬的一条。把核对做扎实，短期是避险，中期反而是竞争优势，尤其在一门可选来源只有个位数的语言里。

这件事还有个侧面值得注意：公开说明里提到的那批错误，绝大多数发生在英语内容上，而英语正是来源最密集、纠错最快的那一门语言。同样的机制换到来源只有个位数的语言上，暴露程度只会更高。把英语市场发生的事当成小语种市场的下限而不是上限，这个预期设定更接近实际。

## 这套流程怎么排进现有的内容生产？

## 三个卡点插在哪

第一个卡点在生成之前：确认这个市场的事实卡是最新的，超过一个季度没核就先核。

第二个卡点在生成之后、母语审校之前：跑事实核对清单，把可证伪的句子逐条过。

顺序很重要，事实核对要在母语审校之前，因为审校可能会顺手润色掉某些具体信息。

第三个卡点在上线之后一周：抽查线上页面，确认改动都生效了，结构化数据里的字段也一起改了。

三个卡点分别由不同角色负责，互相不覆盖，也就不会出现都以为对方查过的情况。

把这三步写进内容生产的检查表里，比开会强调十次有用。

第三个卡点最容易被砍掉，因为它发生在大家心理上已经完成的时刻。但它抓到的问题往往是最尴尬的那种，比如正文改了商品字段没改、桌面端改了移动端模板没改。给它排一个固定的周会时间，五分钟，就能保住。

三个卡点还需要一条兜底规则：任何一次事实卡的更新，都要触发一次已发内容的回刷。否则卡片改了，之前按旧卡片生成的那批内容仍然停在旧数值上。回刷不必全量，按事实卡里哪一行改了，回刷引用了那一行的内容即可，前提是生成时记录过每篇用了卡片里的哪几行。

## 成本大概是多少

按一篇三千字的内容算，事实核对熟练之后二十到三十分钟。

事实卡的季度维护，一个市场一到两小时。

来源表的初次搭建，一个市场半天，之后基本不动。

把这些加起来，对一个同时做六个小语种市场的团队来说，大概是每月两到三个人日。

相对于生成式工具在内容生产上省下来的时间，这个投入占比很小。

保哥的说法是，这笔钱不花在事前，就得花在事后，而事后的价格是按月计的。

最后提醒一句排期上的现实：这套流程最好在开始大规模生成之前就建好。等到已经发了几百篇再回头补，你要面对的是一个存量清理项目，而存量清理从来没有人愿意批预算。趁着量还小的时候把工序钉进去，是成本最低的时机。

还有一笔账要算进来：这套流程会顺带提升内容的可复用性。事实卡一旦建好，它不只服务生成式内容，也能给客服话术、广告文案、商品字段当统一口径。一份被三个部门共用的事实卡，维护成本会自然被分摊掉，这时候它就不再是内容团队单独承担的开销了。

## 常见问题解答

## 大模型生成的小语种内容，错误跟机器翻译有什么不同？

机器翻译错在说法上，词序别扭、搭配不对，母语者扫一眼就能挑出来，所以通读式的审校检出率很高。大模型生成的内容句子极其自然，语域也对，错的是里面那些具体可查的本地事实：退货期、门槛金额、支付方式、标准编号。这些不影响通顺，所以通读时毫无异样感。错误从表层沉到了里层，而检查方法还留在表层，这是问题的全部要害。

## 为什么低资源语言更容易出这种错？

因为语言能力和事实知识的饱和速度不一样。几百万句语料就够模型把一门语言说流利，而某个国家的退货期是几天、哪家支付公司在当地占主流这类稀疏事实，需要的语料量是另一个量级。中间那段就是幻觉高发区。缺语料的时候模型会用跨语言迁移来补，语法可以迁移，事实不该迁移，但模型分不清，于是把英语世界的默认值填了进去。

## 英语默认值泄漏具体表现成什么样？

主要四类。退货期写成三十天，那是美国零售业的商业惯例，而欧盟法定的无理由撤回期是十四天。免运费门槛的货币符号换了、数字没换，四十九美元变成四十九欧元。推荐的支付方式是国际品牌而不是当地主流，甚至可能是在当地没有业务的品牌。还有数字与日期格式按英语习惯写。四类的共同结构是：需要一个本地值的地方，填入了英语世界的默认值。

## 不懂那门语言，能不能自己查出这些错？

能，而且比想象中容易。先把可证伪的句子挑出来，特征是包含一个有唯一答案的具体信息，数字、日期、专有名词、编号、百分比。这类句子在一篇三千字内容里通常只有十五到二十五句，挑选动作不需要懂那门语言，因为数字和专有名词在任何书写系统里都可识别。挑完逐句机器翻译，再拿政府、标准组织、企业官网这三等来源核对，二十分钟能过完一篇。

## 复核力度要不要所有语言一视同仁？

不要，平均分配是浪费。按语料丰度分三档，抽检比例定成一成、三成、全量；再叠一层内容责任等级，构成对外承诺的最高，涉及安全合规的次之，影响决策但不构成承诺的再次，纯描述性最低。两个维度叠成十二格矩阵，低资源加高责任那几格必须逐句核对，高资源加低责任那几格可以直接发。实际填下来，需要重投入的通常只占内容总量的一到两成。

## 为什么说错误率这个指标会骗人？

因为它假设所有错误的寿命一样长。同样百分之三的错误率，英语内容的读者多、反馈路径畅通，错误可能两周内就被指出；小语种内容的读者少，而且投诉链路本身往往是英语的，用户要跨一道语言门槛才能告诉你，多数人不会跨，直接关页面去别家。所以风险应该定义成错误率乘以错误寿命，而事前检查的投入要按可发现性分配，不能按流量分配。

## 提示词写得足够严格，能不能不做核对？

不能。提示词能压住风格层面的偏移，压不住模型压根不知道的事实，要求它准确只会让它更自信地说出错误答案。有效的做法是改变信息方向：给每个市场维护一份事实卡，把退货期、门槛、支付方式、法规要点写在卡片上，生成时连同指令一起送进去，并规定所有本地信息只能来自卡片。这样模型的角色从知识来源变成语言工具，而后者才是它可靠的部分。

## 权威参考资料



## 退货政策那句承诺译成日语之后，字面写出来是不这么做就不行

- URL：https://zhangwenbao.com/minor-language-modality-obligation-commitment-strength.html
- 分类：小语种SEO
- 发布：2024-08-06  |  更新：2026-07-28
- 摘要：情态词是页面上唯一一类字面意思和法律强度可以脱钩的词，而本地化每一步都在优化字面自然度，没有一步在守强度。讲清技术规范为什么要靠大写来锁定强度、日语的必须为什么是个双重否定、母语审校为什么总是把话说软。
- 关键词：出海SEO,多语言SEO,内容本地化,小语种SEO

> **TLDR**：摘要：同一句退货承诺翻成三门语言，字面全对，法律强度却落在三个不同的档上。日语把义务写成一个双重否定，芬兰语用条件式后缀把整句调软，德语的那个助动词在正式文本里比英语原词硬一截。母语审校只判地不地道，没有一道关卡在判这句话到底是承诺还是描述。本文把情态强度拆成三档，给出一份不需要语法知识就能执行的验收办法。

> 摘要：同一句退货承诺翻成三门语言，字面全对，法律强度却落在三个不同的档上。日语把义务写成一个双重否定，芬兰语用条件式后缀把整句调软，德语的那个助动词在正式文本里比英语原词硬一截。母语审校只判地不地道，没有一道关卡在判这句话到底是承诺还是描述。本文把情态强度拆成三档，给出一份不需要语法知识就能执行的验收办法。

## 退货政策那一句，为什么翻完之后强度就变了？

## 从一个日本烘焙器具站的退货页说起

那是一家做日本市场的烘焙器具站，主推模具和量具。

退货政策里有一句关键的话，英文原文写的是三十天内可无理由退货。

这一句是整个页面上被读得最多的一行。

日语版翻完之后，母语同事看了说没问题，语气还挺得体。

可客服那边慢慢发现，日本用户问退货问题的比例比别的市场高出一截。

把那句日语拿回来逐字读才看明白：译文里那个表示可以的成分被写成了一个很客气的形式，读起来更像是我们会尽量配合，而不是你有权退。字面上一个错都挑不出来，但它已经不是一句承诺了。用户读完还得再问一次，才敢下单。

整整两个季度，这一页的转化率一直被这一个语法成分压着。

后来把客服工单按语言分了一次组，日语站里问是不是真的可以退这类问题占了全部售前咨询的两成多，而英语站同类问题不到半成。这个差值一直挂在报表上，只是从来没有人把它跟那一句译文联系起来，因为报表上它长得像一个客服问题。

## 三个语言版本的同一句话，强度落在三档上

后来把这句话的几个语言版本并排放了一遍。

英文版是明确的承诺，主语是用户，动词是可以退。

德语版用了一个助动词，在德国读者眼里比英文原句还硬一点。

日语版用了敬体加上一个表示能够的形式，落点明显偏软。

芬兰语版更极端，译者用了条件式，整句变成了一种客气的假设。

四个版本描述的是同一套退货流程，同样的三十天，同样的无理由。但如果让四个市场的用户各自判断这家店有没有承诺过什么，答案不会一致。事实完全相同，责任却不同，而这个差异整个流程里没有一个环节在看。

这一层的问题，不在事实上，在事实之外的那一格。

这种并排比对其实是这一层最有效的诊断动作，成本也低。把同一句话的所有语言版本抄进一张表，每一行后面留一列写读完之后你觉得对方承诺了什么。填完之后差异一目了然，比任何自动检查都直观，而且不需要任何工具支持。

## 这不是翻译错误，每一句都能通过审校

要说清楚这件事，得先把它跟翻译错误分开。

翻译错误是可以指出来的：这个词译错了，那个数字写反了。

而这四句话里没有任何一处能被指为错。

拼写检查不响，术语库不响，标记校验不响。

母语审校读一遍，只会觉得这几句都挺自然。

这跟语态与施事者那篇 (https://zhangwenbao.com/minor-language-passive-voice-agent-loss.html)是同一类：那篇讲的是改完之后句子仍然完全正确，所以它不在任何一张检查表上。本篇讲的东西也不产生错误，它产生的是一个责任强度的差额。两者的差别在于，语态漂移少的是一个名词，情态漂移少的是一份约束力。

少一个名词能数出来，少一份约束力数不出来。

还有一个更根本的原因让这类问题躲过所有关卡：现有的质量体系是围绕错误建立的，每一道关卡都在找可以被指出来的缺陷。而强度差额不是缺陷，它是两个都正确的选项之间的选择。选择题在一个只处理判断题的体系里，是没有位置的。

顺带说一句，这也解释了为什么这类问题在自动化程度越高的团队里越隐蔽。自动检查跑得越全，绿灯就越多，而绿灯多本身会强化一种错觉：该查的都查过了。真正没被查的那一类，恰恰不会因为多加几项检查而浮出来。

## 判据：这句话是承诺还是描述

所以要给这一层配一把尺子，而且不能是语法尺子。

这把尺子只问一句：读完这一句，用户会不会认为你已经承诺了。

承诺意味着他可以据此要求你履行。

描述只是在说明一般情况通常是这样。

同一套流程，可以被写成承诺，也可以被写成描述。

这个判据的好处是它不依赖任何语言学概念。不需要知道什么叫情态动词，只需要判断读者会不会据此提要求。母语审校验收那篇 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)讲过，能交给不懂那门语言的人执行的检查才跑得下去，这条判据是同一个取向的产物：能交给不懂法律的人判断的判据，才有可能被真正执行。

下面所有的做法，都是从这一句尺子长出来的。

这把尺子还有一个附带用处，它能把内容侧和法务侧的对话从措辞拉回到意图上。以前的讨论常常卡在某个词该不该用，换成这把尺子之后，问题变成了这一句我们到底想不想承诺。后一个问题有明确答案，前一个没有。

## 情态词凭什么算一类特殊的词？

## 它不改变事实，只改变谁要负责

页面上的词大致可以分成两拨。

一拨在陈述事实：三十天、免运费、不锈钢、直径二十厘米。

这些词改一个字就是事实错误，谁都能查出来。

另一拨不陈述事实，只标注这句话的强度。

可以、必须、应当、通常、有可能，这一拨就是情态词。

它们的特殊之处在于：改动它们不会让任何一个事实变错，只会让这句话的约束力换一档。整页上只有这一类词具备这个性质。价格改了是事实错，情态改了是责任变，而后者在校对流程里根本没有对应的检查项。

没有检查项，是因为它压根不属于对错这个维度。

还有一个更实际的后果：情态词的改动不会留下任何可追溯的痕迹。事实类改动通常有对应的业务变更单，改了什么、谁批的、什么时候生效都有记录。而把一个可以改成通常可以，多半只是一次润色，连提交说明里都不会提。

## 差额只有在纠纷发生时才结算

更麻烦的是这笔差额的结算时点。

事实错误会立刻被用户指出来，当天就有反馈。

情态漂移不会。用户读完只是心里没底，然后去问客服，或者干脆不买。

真正把差额兑现的时刻，是发生纠纷、要判断当初到底承诺了什么的时候。

而那个时刻可能是半年之后，也可能永远不来。

于是这类问题有一个很讨厌的性质：它在日常运营的所有指标上都不响，只在极少数高代价的场合一次性结算。转化率上会有一点点损失，但那点损失淹没在噪声里，谁也归不到这一句话上。

凡是反馈周期以年计的问题，都得靠事前的规则来管，不能指望被发现。

这种延迟结算还会造成一个认知偏差：因为长期没有出事，团队会把现状当成验证过的安全状态。而实际上只是还没轮到而已。凡是这类结构的问题，都不能用没出过事来证明没问题，只能用事前定下的规则来证明。

还有一个连带影响落在客服身上。用户读完没底就去问，客服凭自己的理解回答，而客服的口径又常常比页面上写的更宽松。于是同一件事在页面上、在客服回复里、在实际执行中变成了三个版本，纠纷真来的时候，最松的那个版本往往会被拿出来说事。

## 跟语态漂移的区别在哪儿

这两件事经常被放在一起说，所以有必要划清。

语态漂移改的是句子的结构，删掉的是一个名词。

它的后果是信息少了，某个实体没被记住。

情态漂移不删任何成分，句子的骨架一个字不动。

它改的是这句话跟现实之间的关系强度。

排查办法也因此完全不同：语态漂移可以靠数名词发现，情态漂移数什么都数不出来，因为漂移前后的词数、实体数、关键词密度全都一样。这也是为什么本篇最后给出的是一套判读办法，而不是一套统计办法。

能数的问题和不能数的问题，从一开始就得走两条路。

把这两件事一起排查其实是可行的，只是要分两趟跑。第一趟数名词，找语态漂移，这一趟可以自动化；第二趟读句子，找情态漂移，这一趟必须由人来做。先跑第一趟能顺手把范围缩小，因为两类问题高度集中在同一批说明性段落里。

## 人类唯一一次把情态强度写死，用的是什么办法？

## 用大写把三个词圈出来

有意思的是，这个问题在另一个领域早就被认真处理过。

互联网技术规范里，一句话到底是强制还是建议，关系重大。

于是有了一份专门定义关键词的文件，把几个词的强度写死。

必须、不得、应当、可以，各自有精确的含义。

写规范的人只要引用这份文件，读的人就知道每个词有多重。

这份关键词定义文件 (https://www.rfc-editor.org/rfc/rfc2119)最有意思的地方不在于它定义了什么，而在于它采用的手段：为了让这几个词的强度不被误读，它要求把这些词全部大写。人类在需要精确表达强度的时候，最后退回到了一个排版手段。

语言本身给不了这个精度，所以只能在语言之外加一个记号。

这套办法还有一个细节值得学：它没有试图定义所有表达强度的词，只挑了几个最常用的圈起来。范围收窄换来的是可执行性，因为读的人只要认得这几个大写词就够了。任何想覆盖全部情况的强度体系，最后都会因为太复杂而没人用。

## 补充规范又加了一条：只有大写才算

这件事后来还有个补丁，同样值得一读。

原来的文件没说清楚小写的那几个词算不算。

于是有人在文档里写了小写的must，读者就不知道该不该当成强制。

后来专门发了一份补充规范 (https://www.rfc-editor.org/rfc/rfc8174)，明确只有全大写的形式才具有规范含义。

小写的同一个词，只是一个普通的英语单词。

这个补丁把问题挑得很明白：同一串字母，戴上一个视觉记号才有约束力，摘掉记号就只是个词。而这个记号完全在语言之外，靠的是字形不是语法。一门语言如果没有大小写，这套办法连搬都搬不过去。

顺便一提，这也是为什么这套关键词从来没有官方译本。

这个补丁还暴露了一个更普遍的现象：任何靠约定获得的额外含义，都需要一个不属于语言本身的载体来承载。技术文档用大写，法律条文用定义条款，商品页上其实也有类似的手段，比如把承诺单独放进一个带边框的区块里。

## 这套办法为什么没有译本

翻译这几个关键词的尝试当然有人做过。

但没有任何一份译本获得了规范效力。

原因很实在：这几个词的定义是靠英语的语用习惯撑起来的。

换一门语言，对应词的强度分布就变了，定义也就不再吻合。

更别说很多语言的对应词根本不是词，而是一个词尾。

这件事给本地化提了一个很硬的醒：凡是靠某一门语言的语用惯例定义出来的强度体系，都无法直接翻译，只能在目标语言里重新校准一遍。同样的道理在别的地方也成立：凡是拟合出来的东西，适用范围就等于拟合它的那批材料。区别只在于那一层搬不过去的是常数，这一层搬不过去的是词的强度。

拟合出来的东西，适用范围就等于拟合它的那批材料。

这一条推到本地化流程上，会得到一个不太受欢迎但很实用的结论：情态词不该进术语库。术语库的前提是源词和目标词一一对应，而情态词的对应关系随文体和上下文变。硬塞进术语库，得到的是一批看起来统一实际上强度乱跳的译文。

不进术语库不等于不管，只是管的方式要换。可行的替代是建一份档位说明，写清楚每一档要达到的读者效果，附上两三个已经验收通过的目标语言例句。例句比规则好用，因为译者能直接感觉到那个强度，而不需要在脑子里把定义翻译一遍。

## 同一个应当，德语和英语差多少？

## 英语的should大概落在什么位置

要谈强度差异，先得把参照物立起来。

英语里must是硬约束，may是纯许可，这两端争议不大。

中间那个should才是麻烦的一档。

技术规范里它被定义成有充分理由才可以不遵守。

而在日常商业文案里，它常常只是一句客气的建议。

同一个词在同一门语言里，跨了文体就换了强度。微软写作规范关于动词的章节 (https://learn.microsoft.com/en-us/style-guide/grammar/verbs)建议在面向用户的文案里少用这一档词，理由正是它的强度不稳定，读者容易各读各的。

参照物本身就在晃，跨语言比较就更需要小心。

在实际写作里，这一档词还有个隐蔽的用法：它经常被当成缓冲垫用。内容侧不确定该不该承诺的时候，就选这一档词把问题挂起来。挂起来的后果是决定被推给了译者，而译者不知道这是一个被刻意留白的地方，他会按自己的语感把它落到某一档上。

## 德语sollen在正式文本里更靠近必须

把它换成德语，落点会往硬的一边移。

德语对应这一档的助动词，在日常口语里确实是建议。

但在法规和正式文本里，它的惯例含义接近于原则上必须。

也就是说除非有例外情形，否则就得照办。

这不是某一本词典的说法，而是德语正式文体长期形成的读法。

Duden关于这个助动词族的词条 (https://www.duden.de/rechtschreibung/muessen)把几个成员的用法分得很细，能看出它们在不同文体里的分工。译者按日常语感选词，读者按正式文体读它，两边差出的正好是一整档。

而条款类页面恰好就是正式文体。

这个差异在跨境合同和条款翻译里是常识，但在商品页文案里几乎没人提。原因很简单，商品页不被当成正式文本对待。而德国用户读退货条款的时候，用的是读正式文本的那套预期，页面属于哪一类由读者的场景决定，不由你的排期决定。

## 强度是连续谱，刻度按语言变

把几门语言放在一起看，会得到一个更实用的图像。

强度不是三个格子，而是一条从纯描述到硬约束的连续线。

每门语言在这条线上有自己的几个刻度点。

刻度的数量不同，位置也不同，两门语言之间很少有一一对应。

这跟颜色词的情况非常像：都是在一条连续谱上切段，而各语言切的位置不一样。

颜色范畴那篇 (https://zhangwenbao.com/minor-language-color-category-attribute-value.html)给过一条判据，取值本身是不是连续谱，是判断有没有范畴错位风险的关键。情态强度是全站最典型的一条连续谱，而且它切段的位置比颜色还不稳定，因为它还随文体移动。

连续谱上没有正确答案，只有落在哪一段。

这条连续谱还有一个跟颜色不同的地方，值得单独记：颜色的切段位置是稳定的，一门语言里蓝和绿的边界几十年不动；而情态强度的切段位置随文体移动，同一个词在广告文案和条款页上落点可以差出一整档。稳定的谱能建映射表，不稳定的谱只能逐句判。

这个差别直接决定了投入方式：稳定的谱值得一次性建好映射表长期复用，不稳定的谱建表就是浪费。判断一类词该不该进映射表，看它的落点会不会随文体移动，就是一个足够可靠的过滤条件。

## 判据从怎么翻换成落在哪一档

知道了这一点，需求的写法就得改。

常见的写法是给译者一份术语对照表，规定某个词固定译成某个词。

这条路在情态词上走不通，因为对应关系本来就不存在。

更有效的写法是给出目标结果：这句话读完，用户应当认为我们已经承诺。

译者用什么手段达到这个结果，交给他自己判断。

这跟语态那篇 (https://zhangwenbao.com/minor-language-passive-voice-agent-loss.html)的结论是同源的：跨语言的写作要求要写成可以在目标语言里被验证的结果，不要写成源语言里的某种手法。本篇往前推了一步，这里的结果还得是一个不懂语法的人也能验证的结果。

验证者的门槛，决定了这条要求会不会被真正执行。

换成结果导向的写法之后，还有一个副作用是好的：它逼着内容侧把每一句的意图想清楚。写不出这一句希望读者得到什么结论，多半说明这一句本来就没想明白。很多在翻译阶段暴露出来的强度问题，回头看根源都在中文稿的含糊上。

## 日语把必须写成不做不行，会出什么事？

## 义务的标准写法是一个双重否定

日语在这一层给出了最有意思的一个例子。

日语表达必须做某事，最标准的形式是一个双重否定。

字面拆开是：如果不这样做，就不行。

合起来读，母语者理解成必须，没有任何歧义。

这不是一种迂回说法，而是这门语言表达义务的常规手段。

换句话说，日语页面上最需要被准确理解的那一类句子，在字面层是一串否定。日语敬语层级那篇 (https://zhangwenbao.com/japanese-seo-keigo-politeness-levels-conversion-ranking.html)讲过写得越客气离用户打的字越远，这里的问题不在客气，而在句式本身的结构。

结构问题跟措辞问题，需要两套不同的对策。

这个结构还有一层麻烦：双重否定在日语里读起来是完全中性的，它不带任何强调或者迂回的味道。所以译者不会觉得自己写了一个复杂句式，审校也不会觉得这里需要简化。对母语者来说这就是最自然的说法，简化反而显得突兀。

## 双重否定是抽取时最容易读反的结构

问题出在这类句子被机器处理的时候。

抽取式的问答系统要从页面上找出一句话回答用户的问题。

它需要判断这句话是肯定还是否定。

而双重否定是所有句式里最容易被判反的一种。

否定成分多一个少一个，结论就整个翻转。

这一条跟否定词缀那篇 (https://zhangwenbao.com/minor-language-negation-affix-exclusion-keyword-trap.html)有接口但不是一回事：那篇讲的是否定藏在词的内部导致过滤失效，这里讲的是两层否定叠在一起，导致语义被读成相反的意思。前者是漏掉，后者是读反，后者的代价明显更高。

漏掉只是没答上来，读反是给了一个错的答案。

这类风险有一个可以自测的办法：把那几句关键的日语原样丢给一个抽取式的问答工具，用中文或英文提问对应的问题，看它给出的答案跟事实是不是一致。答反了的句子先记下来，这些就是最该单独准备一份直白表述的地方。

要注意这类自测的结论只能当线索，不能当结论。工具答错可能是因为它对这门语言本来就弱，未必是句式的问题。稳妥的做法是拿同一门语言里一句结构简单的肯定句当对照组，对照组答对而双重否定答错，才说明问题真的出在句式上。

## 这不是译者的选择，是语言的默认

很容易想到的对策是让译者换个写法。

但这条路在日语上基本走不通。

不用双重否定表达义务，在日语里要么显得生硬，要么改变了语气层级。

而条款类页面恰恰是最讲究语气得体的地方。

逼译者换写法，等于让他在得体和清晰之间二选一。

更可行的做法是接受正文用标准写法，另外在结构化数据和常见问题区放一份不带双重否定的表述。结构化数据那篇 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)讲过正文越本地化越好而机器读的那份要写得笨一点，这里是同一个分工的又一次应用。

两份表述并存，各自服务各自的读者。

这里有一条更一般的原则：凡是某种表达方式是目标语言的默认选项，改它的成本就不是一次翻译的成本，而是持续对抗语言习惯的成本。这种对抗迟早会输，因为后面每一个接手的人都会按默认写法改回去。正确的做法是绕开而不是对抗。

## 情态藏进词内部之后，关键词表还管得了吗？

## 芬兰语用条件式后缀把整句调软

芬兰语给出的是另一种形态。

芬兰语有一个条件式的词尾，加上去之后整句就变成了假设语气。

它不是一个独立的词，而是动词中间的两个字母。

加上它，我们退货就变成了我们会退货吧这种口气。

译者用它通常是出于礼貌，因为直陈的说法在芬兰语里显得强硬。

结果是整句的约束力被下调了一档，而下调这件事没有留下任何独立的词。芬兰语十五个格那篇 (https://zhangwenbao.com/finnish-seo-fifteen-cases-consonant-gradation-keyword.html)讲的是名词的形态爆炸，动词这一侧同样有一整套形态，而且承载的是语气而不是关系。

找不到词，就没法用词表管。

条件式在芬兰语商业文案里的使用密度相当高，它几乎是默认的客气挡位。这意味着排查时不能把出现条件式当成异常信号，因为正常文案里到处都是。真正要看的是那几句承诺性的句子里有没有它，范围一收窄，判断立刻变得可行。

## 土耳其语把能力塞进动词中间

土耳其语的做法更直接。

表示能够做某事，土耳其语在动词词干后面接一段词尾。

整个能力的意思就藏在那几个字母里。

你可以退货这句话，退和能退是同一个词的两种形态。

中间没有空格，也没有任何一个独立的词表示能。

土耳其语后缀那篇 (https://zhangwenbao.com/turkish-seo-agglutinative-suffix-stacking-keyword.html)数过一个词能挂五层后缀，情态就是其中可能出现的一层。通用依存标注体系的语气特征 (https://universaldependencies.org/u/feat/Mood.html)把这一类取值单独列了出来，从取值表就能看出它在很多语言里是词的一个属性，而不是句子里的一个成分。

属性和成分的区别，决定了它能不能被检索到。

土耳其语这个词尾还有一个特点让排查更难：它跟别的词尾叠在一起之后，位置会变，形态也会随元音和谐变化。也就是说你连一个固定的字符串都锁不住。要找它只能靠形态分析，而多数内容团队手上没有这个工具，也没有理由为一句话去装一个。

## 词表管不了，只能用句式管

把这两门语言放在一起，结论就出来了。

用关键词表管情态，前提是情态得是一个独立的词。

而在相当一批语言里，它根本不占一个词的位置。

这时候任何基于词表的检查、任何正则、任何禁用词清单都是空转。

能用的办法只剩一条：按句子整句判读。

换句话说，这一层的质量控制必须从词的粒度提到句的粒度，而并列与列举那篇 (https://zhangwenbao.com/minor-language-coordination-ellipsis-list-keyword.html)里那些缺口恰好相反，它们在词的粒度上就能被数出来。粒度一提，成本就上去了，因为句子没法批量匹配。所以后面那份清单的重点不是覆盖全站，而是先框定必须逐句读的那一小批句子。

能缩小范围，才谈得上逐句读。

把粒度从词提到句还有一个连带好处：句级判读天然能覆盖那些不靠情态词、而靠整句结构调软的情况。比如把断言改成反问，或者在句末加一个模糊的补充。这些手段一个情态词都不涉及，任何词级检查都抓不到，而隔离读者一读就能感觉出来。

这条也提醒了一件事：句级判读虽然贵，但它是唯一一种不会随语言变化而失效的办法。词表要按语言重建，正则要按形态重写，而问一个母语者这句话有没有承诺什么，在任何语言上都是同一个动作。通用性本身就是一种成本优势。

## 跟否定词缀那件事的分工

这里要跟另一条规律划清界限。

否定在很多语言里也是词缀，这条本站已经写过。

那篇讲的是排除关键词、减号语法这类靠空格分隔的机制会全部失效。

本篇讲的不是过滤失效，而是判读失效。

前者的对策是改成正面圈定，后者的对策是提高判读粒度。

两条规律的共同祖先是同一件事：凡是把语法信息塞进词内部的语言，都会让以词为单位的工具集体失灵。但失灵的表现和对策各不相同，混在一起处理只会两头都做不好。

同源不等于同解，这一点在小语种上要反复提醒自己。

分工没划清最常见的后果是，团队会用一套办法去处理两类问题，然后得出这套办法没用的结论。实际上是用错了地方。判断该用哪一条的办法很简单：问这个问题的表现是漏掉了东西还是理解反了。漏掉走过滤那条线，理解反走判读这条线。

## 为什么母语审校总把强度往下调？

## 直白的义务在很多语言里不礼貌

现在来看这条链路上最反直觉的一环。

把义务说得干脆利落，在英语商业文案里是清晰的表现。

但在日语、德语、芬兰语的语境里，同样的干脆常常读作强硬。

面对消费者的文案，强硬是要付出信任成本的。

于是译者会本能地找一个更委婉的说法。

而这门语言里所有委婉的手段，几乎都在同一个方向上：把说话人的承诺程度往下调。敬语、条件式、被动、间接问法，全都是通过降低断言强度来实现礼貌的。

礼貌和约束力，在语法上共用同一根杠杆。

这一层还有个跨文化的细节：礼貌门槛的高低跟市场的成熟度无关，跟语言习惯有关。有人会以为发达市场更直接，实际正相反，日语和德语的正式文本都比英语更讲究措辞层级。按市场发达程度推测措辞风格，几乎每次都会推错。

## 礼貌手段的方向恰好是调软

这条规律值得单独拎出来说。

没有哪门语言是靠把话说得更硬来表达礼貌的。

礼貌的通用做法就是给断言留余地。

于是每一次为了得体而做的调整，都会顺手削掉一点约束力。

一句话如果被两三个译者依次润色过，削掉的就不止一点。

这跟削短形态那篇 (https://zhangwenbao.com/minor-language-clipped-short-forms-keyword-coverage.html)的结构完全一致：那篇讲的是每一道质量关卡都在把词往规范拉，三道拉完一个字不剩。这里是每一道润色都在把强度往下拉，几轮下来承诺就变成了描述。而报表上看到的仍然是内容质量在上升。

同一个机制，换了一个受害者。

这条规律还能解释一个常见现象：越是重要的句子，被润色的次数越多，强度掉得也越厉害。因为重要的句子会被更多人过目，每个人都想让它读起来更妥帖。于是页面上最关键的那一句，恰好是被削得最狠的那一句。

要挡住这个效应，最省事的办法是给这几句话加一个标记，注明它的档位已经定过，改动需要回到定档的人那里。标记不需要多正式，在文案文档里加一行注释就够了。关键是让后面的润色者知道这一句不是可以随手调的。

## 跟机器翻译比，人工改得更多

还有一个跟直觉相反的观察。

机器翻译在这一项上通常比人工保守。

它贴着源文结构走，源文是直陈句它多半也给你直陈句。

人工译者会往地道和得体的方向调整，而那个方向就是调软。

于是在情态强度这一项上，机翻的呆板反而保住了约束力。

这跟机器翻译直接发布那篇 (https://zhangwenbao.com/machine-translation-direct-publish-search-risk-quality-line.html)的整体结论并不矛盾，那篇讲的是机翻在通顺度和事实准确性上的风险。在结构保真这一个维度上，机翻的保守是优点，而这个优点恰好落在最需要保真的那类句子上。

说这个不是为了推荐机翻，是为了说明润色不是白拿的。

这个对照还能当成一个便宜的检测手段用：把源文丢进机器翻译，跟人工译文并排看那几句承诺。两者强度一致的地方基本可以放心，差得明显的地方值得单独拿出来问一句为什么这么改。这个动作不需要懂目标语言，看两份译文的结构差异就够了。

## 三档承诺模型：先归档再写句子

## 第一档：无条件承诺

把这件事变成可执行的，需要先分档。

第一档是无条件承诺，也就是不附任何前提的保证。

三十天内无理由退货，就属于这一档。

这一档的句子必须写成明确的断言，不允许任何软化手段。

不用条件式，不用可能，不用通常，不用尽量。

写法上有个很实用的抓手：第一档的句子主语必须是用户，动词必须是用户能做的动作。你可以退货比我们接受退货更硬，因为前者写的是用户的权利，后者写的是我们的行为。落地页信任元素那篇 (https://zhangwenbao.com/minor-language-landing-page-trust-signals-payment-address-support.html)提过承诺该写到什么程度，这里给的是同一件事在语法层的落法。

主语选谁，比动词选哪个词更能决定强度。

第一档还有一个容易被忽略的要求：这一句最好独立成段，不要跟条件、说明、例外挤在同一段里。挤在一起的后果是任何一次段落级的抽取都会把承诺和限制混在一起给出，而混在一起的表述在读者眼里往往比纯粹的限制还糟。

## 第二档：带条件的承诺

第二档是有前提的承诺。

比如商品未使用、包装完好、在保修期内。

这一档的关键不是强度，而是条件必须写在前面。

条件写在句尾，用户读到承诺就停了，后面那半句不一定看。

写在句首，用户从一开始就知道这是有前提的。

不同语言的条件从句位置习惯不同，有的偏好前置有的偏好后置。这一档的验收标准是条件和承诺不能被分在两句话里，因为分开之后任何一句被单独抽出来都是错的。

抽出来还对，是这一档唯一的硬要求。

条件前置这件事在有些语言里会跟语序习惯打架，尤其是习惯把从句放后面的语言。遇到这种情况，可行的折中是把条件单独写成一句放在承诺前面，而不是硬做成一个前置从句。两句话的写法在任何语言里都成立，而且抽取时不容易被拆错。

还有一个细节容易被忽略：条件本身也需要写得可判定。商品未使用这种说法，不同的人理解差别很大；换成包装未拆封、吊牌未剪，判断就变成了看一眼的事。条件写得含糊，等于把承诺的边界重新交回给了争论。

## 第三档：只是描述

第三档是纯描述，不构成承诺。

比如一般三到五个工作日送达，这是经验值不是保证。

这一档反而最容易出反方向的问题：被写得太像承诺。

用户按承诺理解，超时了就来投诉。

所以这一档的软化手段不但可以用，而且必须用。

三档一分，需求文档就好写了：每一句先标档位，再交给译者，验收时只核档位有没有变。译者不需要理解法律含义，只需要知道这一句该落在哪一档，而档位是一个可以直接标注的东西。

把判断前置到中文稿阶段，是这套办法最省钱的地方。

第三档最需要提防的是模板拼出来的句子。配送时效这类信息经常由系统按仓库和地区自动生成，模板里的措辞一旦写得太肯定，所有地区就都被写成了承诺。这类句子的档位问题一次出就是全站，比手写文案的风险高得多。

## 验收判据该交给谁来读？

## 写的人自查是无效的

档位标好了，还有一个执行上的坑。

最自然的做法是让译者自己核对档位有没有掉。

但这件事译者做不了，因为他知道原意。

知道原意的人读自己的译文，读到的是脑子里那个意思。

他看不出这句话对一个没有背景的读者来说有多软。

这是一个很普遍的问题：凡是要判断读者会怎么理解的检查，都不能交给知道答案的人做。审校验收那篇 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)说过一句读着自然不能当验收判据，这里再补一条：写的人觉得意思清楚，同样不能当验收判据。

判据的可靠性，取决于判的人知道多少。

还有一个更细的原因：译者在读自己译文的时候，读到的是自己刚刚做过的那些选择。每一个软化的地方他都知道自己为什么这么选，也知道那个选择是有理由的。理由充分和读者能不能读出承诺，是两件完全不相干的事。

## 交给一个不懂业务的人判

可行的做法是找一个隔离的读者。

这个人是目标语言的母语者，但不了解这套退货政策。

把译文单独给他看，问一个问题：这句话有没有承诺什么。

他的答案就是真实读者会得到的理解。

如果他答不确定，那这一句就没达到第一档。

这个测试的成本低得出奇：一次只需要几分钟，而且不需要对照源文。不对照源文这一点很关键，因为一旦把源文放在旁边，判断就会被源文带跑，跟译者自查是一个毛病。

隔离读者是这一层唯一有效的测量工具。

这个测试还可以做得更严格一点：让隔离读者用自己的话把这一句复述一遍，而不是回答是或否。复述会暴露出更细的偏差，比如他把无条件退货复述成了符合条件可以退货。复述比选择题更能反映真实理解，成本也只多出一两分钟。

复述测试还有一个附加价值，它能顺手发现译文里那些含义模糊但语法正确的地方。读者复述不出来，多半不是他理解力的问题，而是这句话本身就没把话说完。这类句子在源文里往往也是模糊的，只是中文读起来顺，没人察觉。

## 判据要写成结果不是手法

最后要注意需求怎么落到纸面上。

写成不要用条件式，是一条关于手法的要求。

手法类要求有两个毛病：译者可能有别的手段达到同样的软化效果。

而且有些语言里，那个手法本身是不可回避的。

写成读者读完应当认为我们已经承诺，才是关于结果的要求。

结果类要求可以在任何语言里被验证，手法类要求只在源语言里成立。凡是能写成结果的，就别写成手法，这条在跨语言协作里几乎没有例外。

手法是你的经验，结果才是你的需求。

把要求写成结果还有一个管理上的好处：结果类要求可以被任何人验收，而手法类要求只有懂那门语言的人能验收。前者意味着这件事可以排进常规流程，后者意味着每次都要等那一个人有空。能不能排进流程，往往才是一条规则活不活得下去的真正原因。

## 一份不依赖语法术语的情态验收清单

## 五步走完，不需要任何语法知识

把整篇压成一份能直接用的东西。

第一步，把这一批文案里所有涉及承诺的句子挑出来，逐句标档位。

第二步，把档位随原文一起交给译者，不额外规定用词。

第三步，译完之后找一个不了解业务的母语者，只给译文。

第四步，逐句问他：这一句有没有承诺什么，条件是什么。

第五步，把他的回答跟原始档位对照，不一致的返工。这五步里没有一步需要语法术语，也没有一步需要懂法律。问答长尾那篇 (https://zhangwenbao.com/minor-language-qa-long-tail-content-value-ai-era.html)提过一个思路，把判断做成用户会怎么提问的形式，这份清单用的是同一个转换。

能被普通人执行的流程，才是能长期跑的流程。

这五步里最容易被跳过的是第三步找隔离读者，因为它需要协调人。可以把它降级成一个更轻的形式：在内部沟通工具里建一个小频道，把待验的句子贴上去，请对应语言的同事随手回一句读后感。不必正式安排，回应率反而更高。

这五步跑第一遍会觉得慢，跑到第三遍通常就变成了半天的事。因为大部分句子的档位在前两轮就已经稳定下来，后面每次只需要核对新增和改动的那几句。把它挂进文案更新流程之后，边际成本会降到几乎可以忽略。

## 哪几类句子必须进这份清单

逐句读是有成本的，所以范围必须收窄。

必须进清单的第一类是退换货与撤回权相关的句子。

第二类是配送时效与运费承诺。

第三类是保修、质保和售后服务的范围。

第四类是价格、优惠和有效期的表述。

这四类的共同点是用户可能据此提出要求，而且要求是可以量化的。德国民法典关于撤回权的条文 (https://www.gesetze-im-internet.de/bgb/__355.html)是个很好的参照，它对告知义务的措辞要求相当具体，从中能看出监管方看重的正是表述的确定性。

其余的营销文案，档位掉一点无伤大雅。

这四类之外还有一个边界情况值得收进来，就是涉及安全和使用限制的说明。比如某个器具不能用于某种炉具，这类句子写软了会带来实际风险。它跟前四类的区别在于，前四类关系到商业承诺，这一类关系到用户安全，优先级只高不低。

## 什么时候该把这件事交给法务

最后是边界问题。

本篇讲的全部是语言层的判读，不是法律意见。

凡是涉及法定权利的表述，最终口径都得由法务确认。

语言侧能做的是保证译文没有把已定的口径改档。

这两件事分工明确：法务定该承诺什么，语言侧保证承诺没被稀释。

实际协作里最有用的一个动作是：把隔离读者的回答原样给法务看一遍。法务读不懂那门语言，但他能判断这个回答跟公司的口径差了多少。这比让他去审一份看不懂的译文有用得多，也比让语言侧去猜法律风险靠谱。

各管各的那一段，中间用一句普通人的转述接上。

实际协作里还有一个常见的误区，是把整件事一股脑推给法务。法务的产出是口径，不是译文；让他去审一份看不懂的译文，他只能要求越保守越好，结果是所有承诺都被削平。分工清楚之后，法务反而愿意给出更明确的承诺，因为他知道那个承诺不会在翻译过程中失控。

还有一个实际的做法是把这件事写进上线检查表的最后一项，而不是单独排一次评审。单独排评审的问题是它会被优先级挤掉，而挂在检查表里的那一项，只要没打勾就不能上线，执行率完全是两回事。

## 常见问题解答

## 情态词跟语气词是一回事吗？

不是。语气词管的是这句话听起来客气不客气，属于感受层面，不同的人可以有不同意见。情态词管的是这句话有多大约束力，是一个可以被追究的东西。两者在很多语言里共用同一批语法手段，这也是它们容易被混为一谈的原因。分开的办法是问一句：改掉它之后，用户能不能据此提要求这件事有没有变。变了就是情态，没变就是语气。实际操作中还有一个简单的区分办法，就是看这句话去掉那个成分之后还剩什么。去掉语气词，句子的约束力不变；去掉情态成分，这句话就变成了另一件事。

## 用禁用词表能不能管住这件事？

在情态是独立词的语言里能管一部分，在情态是词尾的语言里完全无效。而且即使能匹配，禁用词表只能拦住已知的那几个软化手段，译者换一种表达同样能把强度调下来。更根本的问题在于禁用词表管的是手法不是结果，而这一层需要管的恰恰是结果。可行的做法是把禁用词表当成粗筛，真正的判据仍然放在隔离读者那一步。还有一点要提醒，禁用词表一旦建立起来就很难废弃，团队会默认它已经覆盖了这个风险。用它做粗筛可以，把它当成保障就危险了。

## 三档模型要不要写进翻译需求文档？

要，而且要写在句子旁边而不是文档开头。写在开头的通用说明，译者第一遍会看，后面就忘了。逐句标注档位的成本并不高，中文稿定稿时顺手标一遍即可，而且这个动作还能倒逼内容侧想清楚每一句到底想承诺什么。实际操作里，标注过程本身经常会发现原文就有几句档位不清的句子。标注的粒度也值得注意，按段落标是不够的，因为一段里经常同时有承诺和限制。逐句标的成本比想象中低，一份两千字的文案通常半小时能标完。如果时间实在紧，至少要把退换货和配送这两块标完，它们占了纠纷来源的绝大部分。

## 隔离读者找不到人怎么办？

可以退而求其次，找一个懂那门语言但不参与这个项目的同事。关键条件只有两个：他是母语者，以及他没看过源文。第二个条件比第一个更重要，因为看过源文的人一定会被源文的意思牵着走。如果连这样的人都找不到，最低限度的做法是让译者隔一周之后再读一遍自己的译文，效果打折但聊胜于无。还有一个替代方案是找目标市场的客服同事，他们天天回答用户问题，对用户会怎么理解一句话最有直觉，而且通常没参与过文案撰写。找客服同事还有个额外好处，他们能顺带指出哪些表述在实际沟通中经常被误解，那是文案没写清楚的地方。

## 这件事跟本地化的语气规范冲突吗？

会有张力，但不是非此即彼。语气规范管的是整体口吻，而需要保住强度的只是那四类句子，占比通常不到全站文案的百分之五。可行的做法是给这一小批句子单独设一条例外规则，其余部分照常按语气规范走。把例外范围写清楚，比笼统要求所有文案都硬气要好执行得多。把例外范围写清楚还有一个好处，它让语气规范本身更容易被接受。一条允许例外的规范，比一条没有例外的规范执行率高得多。写例外的时候要把范围说死到句子级别，写成某几类句子而不是某些页面，页面级的范围一定会被扩大解释。

## 机器翻译在这一项上真的更可靠吗？

只在结构保真这一个维度上更保守，不代表整体质量更高。它贴着源文结构走，所以不容易把断言改成假设，但它同样会在别的地方出错，比如术语、事实和语气得体度。把它当成一个对照组更合理：先看机翻输出的强度落在哪一档，再看人工译文有没有偏离，偏离得多的地方值得单独看一眼。还要注意机翻输出本身也带着它训练语料的倾向，某些语言方向上它同样会系统性地调软。所以它只能当参照，不能当基准。另外机翻输出还可以当成一个基线记录下来，下次改文案时对照着看强度有没有再往下掉。

## 怎么知道自己站上有没有这个问题？

最快的办法是拿退货政策那一句做一次测试。找一个目标语言的母语者，只给他译文，问他这家店有没有承诺无理由退货。答案含糊或者要反问的，就说明强度已经掉了。这个测试一门语言只要几分钟，做完之后基本能判断这件事在你的站上是个别现象还是系统性问题。如果几门语言测下来结论一致，那多半是流程问题而不是某个译者的问题，该改的是需求文档的写法而不是换人。测完之后别忘了把结论写进需求文档，否则下一次换译者又会从头来一遍。

## 权威参考资料



## 用户搜的是症状，你写的是服务，而在日语里这两句话连动词都不是同一个

- URL：https://zhangwenbao.com/minor-language-intransitive-transitive-verb-pair-keyword.html
- 分类：小语种SEO
- 发布：2024-07-16  |  更新：2026-07-29
- 摘要：日语把东西自己出状况和人对它做了什么做成两个词，而你的内容供应链天生只产出后一种。讲清故障类查询为什么整片落空、词干还原为什么帮倒忙、标题该改哪一句，以及别的语言怎么对照。
- 关键词：关键词研究,多语言SEO,日本市场,小语种SEO

> **TLDR**：摘要：日语把东西自己出了状况和人对它做了什么分成两个不同的动词，成体系有几百对。用户在故障、售后、配件这些场景里打进搜索框的全是前一种，而你的页面从标题到正文全是后一种，两组字符串一个字都不重叠，母语审校也挑不出任何毛病。英语里这两件事共用一个词，所以整套关键词方法论从来没有为这一维准备过位置。本文讲清这两类词怎么分、用户在哪个环节会切换、你的内容为什么天生偏向其中一边、词干还原为什么反而帮倒忙、页面哪几个位置该放哪一类，以及这批查询的商业价值该怎么估。

> 摘要：日语把东西自己出了状况和人对它做了什么分成两个不同的动词，成体系有几百对。用户在故障、售后、配件这些场景里打进搜索框的全是前一种，而你的页面从标题到正文全是后一种，两组字符串一个字都不重叠，母语审校也挑不出任何毛病。英语里这两件事共用一个词，所以整套关键词方法论从来没有为这一维准备过位置。本文讲清这两类词怎么分、用户在哪个环节会切换、你的内容为什么天生偏向其中一边、词干还原为什么反而帮倒忙、页面哪几个位置该放哪一类，以及这批查询的商业价值该怎么估。

## 为什么日本用户搜出来的故障词，在你的页面上一次都不出现？

## 一次厨房小家电站的日志比对

有个客户做日本市场的厨房小家电，主力是咖啡机、电饭煲和料理机这几条线。

页面是找母语写手做的，术语规范，语气得体，商品页和使用指南都写得很扎实。

上线一年多，品牌词和品类词的表现都不错，可有一整块流量始终没有起来：跟使用问题相关的那一块。

保哥让他们把搜索词报告和站内搜索日志放在一起看，发现一个很整齐的现象。

用户打进来的查询里有相当大一批是描述状况的短句，比如电源进不去、盖子打不开、机器不转了。而站上所有的页面标题写的都是另一套说法：怎么开机、怎么开盖、怎么保养。两边说的是同一件事，可字面上没有一个字重合。

更关键的是，这批查询不是零星的长尾。把它们按词干归并之后，总量能占到使用类查询的一半以上，而这一半在词表里一条都找不到。词表六百多条，母语写手过了三遍，没有任何一个环节报错，因为从语言的角度看这份词表挑不出毛病。

还有一个细节后来被反复引用：这批查询的设备分布明显偏向手机，而且集中在傍晚到深夜。这跟人在厨房里手忙脚乱那一刻的场景完全吻合，也解释了为什么承接这批词的页面必须在第一屏就给出答案，用户没有耐心往下翻。

## 两组说法在字符串上没有交集

把两组查询并排放着看，差别不是词尾，是整个词。

用户那一侧的动词描述的是机器自己的状态：不动了、进不去、打不开。

页面那一侧的动词描述的是人的动作：启动它、装进去、把它打开。

在日语里这是两个不同的词，读音不同、写法不同，只有汉字那一部分是共享的。

于是精确匹配拿不到，短语匹配拿不到，连人眼扫一遍词表都不容易发现，因为两组词看上去确实很像，只是像在汉字上，不像在实际字符串上。

这里可以顺手记一条排查经验：凡是两组查询在语义上明显同源、字符串上却几乎不重合的，先别怀疑是拼写或者写法变体，先看它们的语法角度是不是不同。写法变体那一类差异通常只落在词的表层，而视角差异会把整个词换掉。

## 这不是正式度的问题也不是翻译质量的问题

第一反应通常是把它归到已知的某一类问题里去。

是不是用户用了口语，页面用了书面语。不是，两组词的正式度完全一样，都可以出现在说明书里。

是不是翻译不够地道。也不是，页面上那批词本来就是日本人写的。

是不是敬语用得太重。这一层在日语敬语那一篇 (https://zhangwenbao.com/japanese-seo-keigo-politeness-levels-conversion-ranking.html)里单独讲过，跟本文说的是两件事，而且那件事改了以后这件事一点都不会好转。

真正的差别在语法视角上：同一件事，可以从事情本身的角度说，也可以从做事的人的角度说，而日语为这两个角度准备了两个不同的词。你的页面全站站在后一个角度，用户在遇到问题的那一刻站在前一个角度。

把这几种可能一个个排除掉这件事本身很有价值。团队里对语言问题的第一反应往往集中在那几类熟悉的原因上，而只要这几类都排除了，剩下的解释就只能从语法结构里找，讨论也就从各说各话变成了查资料。

## 判据是看这句话的主语是谁

要判断一个动词属于哪一类，有个很简单的办法。

看这句话里发生变化的那个东西站在什么位置：它是主语，那就是第一类；它是宾语而另有一个人在做这件事，那就是第二类。

机器不转了，主语是机器，属于第一类。

我把机器关了，主语是人，机器是宾语，属于第二类。

这个判据的好处是它完全不需要日语能力。你把中文说法摆出来，问一句这句话里是谁在做这件事，答案是没有人在做，那对应的日语词就是第一类。这一步可以交给任何一个不懂日语的人做，而且做得比半懂不懂的人更准。

这条判据还有一个用法是反过来查自己的页面。挑十个标题，逐句问一遍谁在做这件事，如果十个答案全是用户，那你的整站就只覆盖了一半的视角，这个自查两分钟就能做完。

## 自动词和他动词到底差在哪，为什么英语里没有这个问题？

## 英语用一个词兼了两个职

这件事在英语里之所以不存在，是因为英语让同一个动词同时干两份活。

花瓶碎了和我把花瓶打碎了，英语里的那个动词是同一个词，一个字母都不用改。

句子的意思靠语序和有没有宾语来区分，词本身不动。

于是英语世界的关键词表里，这两种查询天然落在同一行上，你不做任何处理它们也是合并的。

这条差异值得单独记一笔：所有基于英语总结出来的关键词方法论，都默认同一件事只有一个动词。这条默认假设在英语上成立得太彻底，彻底到没有人想过它是一条假设，更不会有人在做日语站的时候想起来去检查它。

顺着这条线还能推一步：正因为英语没有这个区分，所有从英语出发的关键词工具在建议相关词的时候，也不会把另一个视角的说法推给你。工具不是漏掉了它，是它的模型里根本没有这一维。

## 日语把它们做成了成对的词

日语走的是另一条路，它把这两个角度固化成了两个词。

而且这不是零星几个词的例外，它是一个成体系的现象，配成对的动词有几百组。

更要紧的是这些对子集中在最日常的动作上：开关、进出、装卸、停动、坏修。

而最日常的动作恰好就是家电类目里出现频率最高的那些动作。

所以这件事对不同品类的杀伤力完全不同。卖服装的几乎碰不到它，卖家电、卖工具、卖任何带机械结构商品的站，会在整个售后和使用板块上一路踩到底。

这套对子还有一个方便的地方：它是可枚举的。日语教学材料里早就把常用的动词对整理成了表，你不需要从零采集，拿现成的表跟自己的品类词一交叉，第一批候选就出来了。

## 汉字相同容易让人误判成同一个词

有个陷阱专门坑懂一点日语的人。

成对的两个动词通常共享同一个汉字，只有后面跟着的假名不同。

于是一眼扫过去很容易觉得这就是同一个词的两种写法，顺手就并成一条了。

但它们在搜索里是彻底的两个字符串，共享的那个汉字救不了任何东西。

这一层跟日语三套文字的写法那一篇 (https://zhangwenbao.com/japanese-seo-hiragana-katakana-kanji-keyword-notation.html)要分开看：那一篇处理的是同一个词的多种写法，属于归一问题；这一篇处理的是两个不同的词，属于覆盖问题。归一做得再好也补不上一个从没写过的词。

这个陷阱有个很典型的表现：会一点日语的同事看完词表说没问题，完全不会日语的同事反而会问一句这两个是不是不一样。半懂不懂在这里比不懂更危险，因为汉字给了他一种已经看懂了的错觉。

## 动词的选择顺带暴露了用户在哪一步

这套区分还有一个副产品，而且是个很值钱的副产品。

用第一类词的人，东西已经在他手里，而且出了状况。

用第二类词的人，多半还在了解这东西该怎么操作，可能还没买。

也就是说，动词本身就是一个漏斗位置的信号，不需要任何模型去猜。

英语把这个信号合并掉了，所以英语世界的意图分类框架里根本没有这一维。而在日语站上，这一维是白送的：你只要看用户用了哪一类动词，就知道该给他一个购买入口还是一个解决办法。

这个信号还能用来做页面分流。同一批流量进来之后，用第一类词的引导到支持和配件，用第二类词的引导到商品和教程，分流规则就是一张动词表，不需要任何行为数据积累。

## 用户在什么场景下会用自动词，什么场景下用他动词？

## 故障和异常场景几乎全是第一类

最集中的一块是故障描述。

东西不工作了、灯不亮了、盖子卡住了，用户描述这些的时候不会说自己做了什么。

因为在他的认知里这件事就是机器自己发生的，他没做任何事。

这批查询的转化路径通常很短：找到原因、找到配件、或者找到售后入口。

值得注意的是这类查询往往带着焦虑，用户希望立刻拿到答案而不是先看一段品牌故事。所以承接这批词的页面结构应该跟商品页完全不同，第一屏就该给判断和动作。

这批查询还有个特点是几乎不带品牌名。用户描述的是现象，他心里的问题是这东西怎么了，而不是这个牌子怎么了。所以指望靠品牌词把这批流量接住是接不住的，它们从一开始就没打算提到你。

## 操作和保养场景偏向第二类

另一头是操作类内容。

怎么装滤网、怎么拆刀头、怎么清洗内胆，这些都是人主动做的事。

用户搜这一类的时候，东西是好的，他只是不知道该怎么弄。

这批词跟商品页和使用指南的匹配度天然就高，通常也是站上已经覆盖得最好的一块。

把两块摊开对比会看到一个很典型的分布：站上的内容密度和用户的查询密度正好错位，覆盖最好的那一块竞争最激烈，而竞争稀薄的那一块你一个页面都没有。

操作类内容还有一个容易被忽略的价值：它是购前用户在评估易用性时会看的东西。所以这一块即便竞争激烈也不能放弃，只是不该指望它顺带把故障类查询也接了，两者对页面结构的要求是相反的。

## 购前顾虑句里两类会同时出现

还有一类查询比较特别，两类词会一起出现。

用户在买之前会问这东西容不容易坏、会不会卡住、好不好拆洗。

容易坏用的是第一类，好不好拆洗用的是第二类，一句话里两边都有。

这类查询的商业价值很高，因为提问的人正处在下单前的最后一步。

处理办法是把这类问题原样收进商品页的问答区，别改写成书面表达。改写的动作看着是在提升文案质量，实际是在把用户的原话换成你自己的话，而用户的原话才是查询。问答长尾那一篇 (https://zhangwenbao.com/minor-language-qa-long-tail-content-value-ai-era.html)讲的正是这类内容为什么在小语种市场特别值钱。

这类混合句还有一个好用的地方：它是最容易验证选词对不对的样本。把这句话原样丢进搜索框，看看返回的前几条是不是同行的问答页，如果是，说明这个说法确实有人在用，而且你还没参与竞争。

## 怎么把这两类查询从日志里分出来

分类这件事听着难，实际有个很省事的做法。

不用给每条查询做语法分析，只需要准备一份词尾特征清单。

第一类动词的常见结尾形式数量有限，把它们做成一个匹配规则跑一遍日志就能分出大半。

剩下分不清的丢给本地同事，通常不会超过一成。

这个做法的价值不只在省时间，还在于结果可复现。任何人拿同一份规则跑同一份日志会得到同一个分组，而交给人凭感觉分类的话，换个人做出来的口径就变了，两个季度之间根本没法比。

规则跑完之后建议保留一份未分类的样本，别急着丢。那一成分不清的查询里往往藏着这门语言里最口语的说法，而口语说法正是口语短词那一篇 (https://zhangwenbao.com/minor-language-clipped-short-forms-keyword-coverage.html)说的那类工具看不到的词。

## 你的内容为什么天然全是他动词？

## 产品资料本来就是从操作视角写的

这件事的根源不在写手身上，在资料来源上。

说明书、安装指引、客服话术这三份东西，全部是站在教用户做事的立场上写的。

而站在这个立场上，动词只能是第二类，因为句子的主语必须是用户。

写手拿到的第一手资料就是这样，他写出来的第一稿自然也是这样。

所以这不是某个人的疏忽，是整条内容供应链的默认输出方向。厂商视角天生是操作视角，用户遇到问题时的视角天生是状态视角，两者错开是结构决定的，不是态度决定的。

顺着这条线还能推出一个预测：凡是内容生产高度依赖厂商资料的品类，这个错位就越严重。反过来，内容主要来自用户社区的品类，两个视角天然就都在，因为社区里说话的人本来就是遇到问题的那一方。

## 母语审校为什么一次都不会提

更麻烦的是这个错位过不了任何一道质检。

页面上的每个句子语法正确、用词得体、读起来自然。

母语审校的职责是判断这句话写得对不对，而它确实对。

审校不会问的问题是：用户会不会用另一个词来描述同一件事。

这跟母语审校验收清单那一篇 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)的结论一致：一句读着自然不能当成验收通过的判据，因为可读性和可检索性是两把不同的尺子，而审校手里只有前一把。

这里还有一个组织上的原因：审校拿到的是一份已经写好的稿子，他的工作范围是这份稿子内部。没有人给他一份用户查询清单，也没有人要求他对照着看，所以这件事在流程上根本没有出口。

## 跟被动语态那件事的区别在哪

有人会把这件事跟语态混为一谈，值得分清楚。

被动语态与施事者丢失那一篇 (https://zhangwenbao.com/minor-language-passive-voice-agent-loss.html)讲的是一个动词的两种形态，改了之后句子里少了一个名词。

本文讲的是两个不同的词，改不改都不缺任何成分，缺的是另一个词从来没在页面上出现过。

一个是信息被删掉了，一个是词根本没写过，排查方式完全不同：前者要数名词，后者要数动词。

还有一个更实际的差别：被动语态那件事你可以要求译者别那么写，而这件事没法靠约束写法解决，因为两类词都是对的，你要做的是补内容而不是改内容。

两件事还有一个差别体现在改动成本上。语态那件事可以在译审环节靠一条规范约束住，几乎不增加工作量；这件事必须新增内容，要走选题、写作、发布的完整流程，排期上要按内容项目来算，不是一条规范能解决的。

## 跟否定构词那件事正好是镜像

另一篇值得对照的是否定构词那一篇 (https://zhangwenbao.com/minor-language-negation-affix-exclusion-keyword-trap.html)。

那件事的特征是字符串极像而语义相反，无糖和含糖只差几个字母。

本文这件事的特征正好倒过来：字符串完全不同而说的是同一件事。

两者带来的错误方向也相反，一个是把不该并的并了，一个是把该覆盖的漏了。

把这两条放在一起可以推出一个更一般的检查项：判断两个词该不该合并，永远不能只看字符串距离。字符串距离在这两件事上都会给出完全错误的答案，而且两次错的方向还不一样。

这两篇放在一起还能得出一条给工具选型的建议：任何号称能自动扩展关键词的工具，先拿这两类词各测三条。一类看它会不会误并，一类看它会不会漏推，两轮测下来这个工具在屈折语和黏着语上的成色就清楚了。

## 词干还原和同义词能不能把两组词并起来？

## 词干还原会给你一个虚假的安全感

技术上的第一反应还是让工具摆平。

成对的两个动词共享词干，粗粒度的处理确实能把它们削到同一个形式。

削完之后统计口径上看起来覆盖率很好，两组查询都能对上同一个词条。

问题是这只解决了统计，没解决页面。

并回同一个词干不等于页面上出现过那个词。你的报表会显示这批查询已被覆盖，而实际情况是站上一个第一类动词都没写过，用户搜进来看到的仍然是一堆讲操作步骤的标题。

这种虚假的安全感有个更隐蔽的版本：报表上的覆盖率数字甚至会因为合并而变好看，因为分母里的查询被并到了已有词条上。指标改善和问题解决在这里是反向的，这大概是所有代理指标里最容易骗人的一种情形。

## 站内搜索可以靠同义词表接住

站内搜索那一侧倒是可以靠配置解决。

把常用的动词对显式写进同义词表，几十行就能覆盖主要品类。

这一步成本极低，而且见效非常快，通常一个发布周期内就能看到零结果比例下降。

建议按品类分组维护，因为不同品类高频的动词对并不一样。

需要留意的是不要把配对做成双向无条件等价。有些对子在特定语境下语义差别不小，全部双向打通会把不相干的结果也召回来，稳妥的做法是先单向打通，从第一类指向第二类。

同义词表这一步还有个附带收益：它会把你之前从来没统计过的一批查询暴露出来。配上之后再看站内搜索报告，你会第一次看到这批词的真实量级，而这个数字通常就是立项材料里最有说服力的那一个。

## 外部搜索那一侧只能靠补内容

站外就没有配置这条路可走了。

搜索引擎自己会不会把两个词关联起来，你既控制不了也观测不到。

唯一可靠的动作是让这批词真的出现在页面上。

出现的位置不需要很多，标题、首段和问答区各一次通常就够。

这一点跟绝大多数关键词工作是一样的：能配置的层可以配置，展示层只能靠写。区别只在于这一次要写的不是同义词，是同一件事的另一个视角。

补内容这件事有个最低限度的版本：不必为每个词对单独建页面，先在已有的支持页里补一段用用户说法写的开头就行。一段话的成本很低，而它已经足够让这个页面跟那批查询建立起字面上的联系。

## 结构化数据里该填哪一类

还有一个容易漏的位置是结构化数据。

问答类型的结构化数据里，问题那一栏应该原样保留用户的说法。

也就是说问题里出现第一类动词，答案里出现第二类动词，这个搭配是最自然的。

很多团队会把问题也改写成规范表达，改完两栏都是第二类，等于白做。

这条跟结构化数据本地化那一篇 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)的原则并不冲突：那一篇说的是格式字段要写回国际口径，而问题文本属于内容字段，内容字段永远跟着用户走。

问答区这个位置还有一个特别之处：它是全站唯一一个可以理直气壮地使用不规范说法的地方，因为那本来就是在引用用户的提问。别的位置要顾观感，这个位置顾的是真实感，两者的取向正好相反。

## 这批查询的商业价值该怎么估？

## 不能按购买意图那套模型估

这批词在常见的意图分类里通常会被划进信息类，然后被排到后面去。

这个划分本身没错，但它算漏了一件事：提这些问题的人已经买过了。

他不是潜在客户，他是现有客户，而且正处在一个可能流失也可能复购的节点上。

接住他的收益不体现在这次转化上，体现在配件、耗材和下一次购买上。

所以这批词的正确估值方式不是看它的直接转化率，而是看它挡住了多少次差评和退货。这个数字不好归因，但只要看一眼客服工单里同类问题的占比，量级就出来了。

把现有客户和潜在客户分开算这件事，在小语种市场尤其要紧。这类市场的用户基数小，复购和口碑占的比重比大市场高得多，一次没接住的售后问题造成的损失，往往比一次没成的转化大好几倍。

## 三个可以直接拿去汇报的数字

要立项就得有数，这里有三个最容易拿到的。

第一个是站内搜索里这类查询的次数和零结果比例。

第二个是客服工单里同一批问题的条数，这个数通常大得让人意外。

第三个是这批查询对应品类的退货率，因为很多退货的起点就是一个没找到答案的疑问。

三个数里第二个最有说服力，因为它是用户在完全没有提示的情况下说出来的原话，而且它已经在工单系统里躺了好几年，从来没人从这个角度看过它。

这三个数还有一个共同的好处：它们全部来自你自己的系统，不依赖任何第三方工具，也不需要解释统计口径。汇报时最怕的就是对方质疑数据来源，而工单条数这种数字没人会质疑。

## 竞争密度通常比商品词低一个量级

还有一个值得看的角度是竞争。

本土大站的资源基本都压在商品词和品类词上。

故障和使用问题这一块，愿意认真写完整回答的站要少得多。

而这类问题的答案又高度具体，很难靠模板批量生产。

结果是这一片的内容供给天然稀薄，你只要写得比说明书更像人话就已经有优势了。这个结构在小语种市场比在英语市场明显得多，因为整个语种的内容总量本来就小。

竞争稀薄这一点在小语种市场还有一层放大效应：整个语种的内容总量本来就小，愿意为一个具体故障写完整答案的站更少。这跟问答长尾那一篇 (https://zhangwenbao.com/minor-language-qa-long-tail-content-value-ai-era.html)观察到的供给结构是同一件事，只是这里的需求侧更明确。

## 先做哪几个词

不必一上来铺全量，按两个维度排序就行。

第一个维度是这台机器最常出的那几个问题，客服最清楚。

第二个维度是这个问题有没有可售的解决方案，比如一个配件或者一次上门服务。

两个维度都占的词排最前面，只占第一个的排第二梯队。

照这个顺序做，第一批通常十来个词就能覆盖掉大半的量，因为故障类查询的分布比商品类查询集中得多，头部几个问题就能占掉一半以上。

排序时还有一个隐藏维度值得考虑：这个问题解决之后用户会不会顺手再买点什么。滤芯、密封圈、刀头这类耗材的复购天然挂在故障和保养场景上，把它们列进来之后，这批词的账会好看很多。

## 页面上哪些位置该放自动词，哪些位置不能放？

## 标题要用用户那一侧的说法

承接这批查询的页面，标题应该直接写用户的说法。

不是怎么开机，而是开不了机的时候先看哪里。

这样写在搜索结果页上的辨识度也更高，因为它跟用户刚打完的那句话长得一样。

担心观感的话可以在后半句补上解决动作，两类词一句话里都放下。

这一条是本文里唯一一个需要动标题的地方，也是收益最集中的地方。别的位置都可以慢慢补，标题这一处不改，其它改动的效果会打很大折扣。

改标题的时候有个分寸要拿捏：别把整句故障描述原样搬上去，那样标题会很长而且读起来像在抱怨。取那个关键动词加上品类词就够了，后半句留给解决动作，这样既接住了查询又保住了专业感。

## 商品页正文只放一两处就够

商品页的处境不一样，它的主职是卖东西。

在商品页上大写特写故障场景会伤害转化，这个顾虑是合理的。

合理的做法是在规格区或者常见问题区放一两处，点到为止。

把详细内容放到独立的支持页上，用内链接过去。

这样分工的好处是两类页面各自的意图很干净：商品页承接购买，支持页承接问题，而支持页的内链又能把已经买过的用户带回配件和耗材页面。

商品页这一处还有个折中办法：把常见问题区的问题文本用用户的说法写，答案用规范说法写。问题那一行本来就短，出现一次口语视角的动词不会有任何观感成本，而它已经足够让这个页面沾上那批查询。

## 支持页和使用指南要分成两套

很多站把这两件事写在同一个页面里。

使用指南讲的是正常流程，支持页讲的是不正常的情况。

合在一起的结果是两批查询互相稀释，哪一批都排不上。

拆开之后各自的标题和首段都能对准一类词，效果立竿见影。

拆的时候有个简单的界线：句子的主语是用户的，归使用指南；主语是机器的，归支持页。这条界线正好就是本文那条语法判据，用起来不需要任何额外的判断。

拆页面这件事在排期上比想象中轻。支持页的内容大部分已经存在，只是散落在使用指南的各个小节里，把它们抽出来重组比从零写省一大半工时，真正新增的往往只有开头那一段判断路径。

## 面包屑和筛选器不要碰

最后要说清楚哪里不该动。

面包屑、分类名、筛选器取值这些位置是站点结构的一部分，要保持稳定和整齐。

把故障说法塞进分类名会让整个导航读起来很奇怪。

这些位置继续用规范的操作视角说法就好。

按位置分工这条原则在本站好几篇里都出现过，这里只是又一个实例：匹配层可以宽，展示层要窄，而导航属于展示层里最窄的那一档。

这条边界还有一个理由：导航文案会被大量页面复用，改一处影响全站。而故障说法天生是具体的、场景化的，把它放进一个要在几千个页面上出现的位置，无论从观感还是从维护角度都不划算。

## 德语、俄语、西班牙语有没有同样的分岔？

## 德语靠不同的词或者反身形式

德语的处理方式介于英语和日语之间。

有些概念它用两个不同的词，有些概念它靠给动词加一个反身成分来表达。

反身形式那一类在字符串上更容易识别，因为多出来的那个成分是固定的。

做德语站时可以先从反身形式入手，规则明确，跑一遍就能列出候选。

不过德语这里有个额外的复杂度：反身成分在句子里的位置不固定，可能离动词很远。这一点跟并列与列举那一篇 (https://zhangwenbao.com/minor-language-coordination-ellipsis-list-keyword.html)说的距离问题是同一类麻烦，短语匹配一样会失手。

德语这边还要提醒一句：反身形式在关键词工具里经常被当成两个词处理，导出的搜索量会被切开。看到某个词的量小得不合常理时，先确认工具有没有把那个成分单独算了一次。

## 俄语靠一个后缀切开两边

俄语走的是后缀路线。

同一个动词加上一个特定后缀，意思就从人做的事变成了自己发生的事。

这对识别是好消息，因为后缀是固定的，写条规则就能把两边分开。

但对词干还原是坏消息，因为还原器很可能直接把这个后缀削掉。

削掉之后两类词合成一个，症状跟日语那边一模一样：统计上覆盖了，页面上没有。这也说明本文的核心问题跟具体是哪门语言无关，只跟这门语言有没有把两个视角做成两个字符串有关。

俄语这条线还能跟生命度那一篇 (https://zhangwenbao.com/minor-language-animacy-accusative-keyword-forms.html)连起来看：两件事都发生在词尾，都会被词干还原动到，而且都是英语里不存在的维度。做斯拉夫语市场时这两项可以合并成一次排查，省一半沟通成本。

## 西班牙语和意大利语用代词标记

罗曼语族这边靠一个小词来标记。

那个小词有时黏在动词后面，有时单独站在前面，形态会随人称变化。

形态多这一点让候选列表比德语和俄语都长。

好在电商场景里用到的人称非常有限，实际要覆盖的形态没那么多。

这几门语言还有一个共性值得记住：越是靠附加成分来区分两个视角的语言，越容易被词干还原抹平；越是用两个完全不同的词的语言，越容易被人眼漏掉。两条路各有各的翻车方式。

罗曼语族这边还有一个实操建议：先从最高频的第三人称形态入手。商品文案和用户描述里绝大多数句子都是第三人称的，覆盖了这一种形态，实际能接住的查询已经接近八成。

## 怎么快速判断一门新语言要不要做这件事

开一个新市场时，这件事值不值得投入有个十分钟的判断法。

挑三个最常见的动作，让本地同事各写两句话：一句是东西自己出了状况，一句是人对它做了这件事。

看两句话里的动词是不是同一个字符串。

三组里有两组不同，那这门语言就要按本文的流程走一遍。

这个判断法不需要语法知识，也不需要查任何资料，问的是母语者的直觉输出。而且它顺带能拿到第一批词对，等于把调研和采集合并成了同一个动作。

这个十分钟判断法还有一个变体：直接问本地同事，用户抱怨机器出问题的时候一般怎么说。他脱口而出的那句话就是你要的第一类说法，而且比任何词典释义都更接近搜索框里的真实输入。

## 一套三天能跑完的自他动词补齐流程

## 第一天，从工单和日志里捞原话

第一步是采集，来源只有两个但足够了。

客服工单里的用户描述，站内搜索里的原始查询串。

两份数据合起来去重，通常能得到几百条候选。

这一步不要做任何改写，原话就是要保留的东西。

如果工单系统不支持导出，退一步可以听十通电话录音的开头。用户说明来意的那半句里几乎一定带着状态描述，而且是最自然的那一种说法。

采集这一步最容易被跳过的是去重之前先看一遍原始数据。同一个故障的不同说法之间的差别本身就是信息，去重规则定得太狠会把这批变体压成一条，而变体的数量恰恰说明了这个问题有多普遍。

## 第二天，配对并挑出高频的那十几组

第二步是把候选整理成动词对。

每一组两列，一列是用户的说法，一列是页面现在用的说法。

按出现次数排序，取前面十几组作为第一批。

剩下的长尾先放进匹配层，不必为每一条都写内容。

配对的时候可以顺手标一列有没有可售的解决方案，这一列在后面排优先级时直接决定顺序，而且它是市场和产品部门唯一关心的那一列。

配对表还有个用法是拿去跟商品页做交叉核对。把左列的说法逐条在自己站上搜一遍，看有没有页面能接住，接不住的那几行就是这一轮要补的内容清单，这份清单可以直接交给写手。

## 第三天，改标题并补支持页

第三步是落地，动作只有三个。

把第一批词对应的支持页标题改成用户的说法。

没有支持页的补一个，结构简单，第一屏给判断和动作。

同义词表把这十几组配上，站内搜索当天就能生效。

三个动作里前两个要走内容发布流程，第三个是配置改动，可以先上。建议先上配置那一个，它能在内容还没写完的时候就把站内搜索的零结果比例压下来，也能给后面的内容排期提供更准的数据。

落地时建议把这三个动作分给不同的人并行做，因为它们互相之间没有依赖。配置改动交给技术，标题改动交给运营，新页面交给内容，三条线各自跑各自的，一周之内就能全部上线。

## 验收看什么

上线之后盯三个信号。

站内搜索里这批查询的零结果比例，应该在一周内明显下降。

支持页的展现量，它会比点击更早出现变化。

客服工单里同类问题的条数，这个指标滞后但最能说明问题真的被接住了。

三个信号里第一个用来确认改动生效，第二个用来确认搜索侧开始认这批内容，第三个用来说服业务方继续投入。分工不同，别混在同一张报表里看。

另外建议给这三个信号各定一个观察窗口，别每天盯。零结果比例看一周，展现量看三周，工单条数看一个季度。窗口定错会让人在数据还没稳定的时候就下结论，进而砍掉一件其实做对了的事。

## 哪些事不归这一层管

## 写法归一是另一件事

同一个词在日语里可能有汉字、假名几种写法，这属于归一问题。

它的处理方式是把变体收进同一条词目，跟本文的覆盖问题不是一回事。

两件事的顺序建议是先覆盖后归一，因为一个从没写过的词，归一得再好也没有用。

反过来如果先做归一，你会看到一份很整齐的词表，整齐到看不出里面缺了一半的视角。

这也是这类问题难被发现的原因之一：所有的整理工作都会让表格看起来更好，而缺失的东西不会因为整理而浮出来。

这两件事的关系还可以再说明白一点：归一是把已有的东西整理好，覆盖是把没有的东西加进来。前者让报表变干净，后者让流量变多，而团队天然更愿意做前者，因为它的产出立刻可见。

## 内容质量那一半有独立的判据

本文只解决用哪个词的问题，不解决内容写得好不好。

支持页的答案是否真的解决了问题，属于内容质量的范畴。

那一层有自己的验收方式，跟关键词覆盖率没有关系。

两件事都要做，但要分开验，混在一起就会出现词覆盖了流量也来了而用户仍然不满意的情况。

顺带说一句，这两件事在排期上可以并行，因为它们改的不是同一批文件，也不需要同一批人。

分开验还有一个好处是责任清晰。词覆盖没做到是关键词那一侧的事，答案没写好是内容那一侧的事，两个问题混在一起的时候，最常见的结局是谁都觉得是对方没做好。

## 引擎那一半交给平台层

最后仍然有一半功课不在语言这一层。

搜索引擎自己会不会把两类动词关联起来、日本市场的主流引擎在这一点上有没有差异，这些属于引擎的行为。

本站把引擎那一半放在平台与多引擎那个方向里单独讲，这篇不展开。

分清楚的好处是排查顺序不会乱：先确认页面上有没有这个词，有了还不出现才轮到去研究引擎。

顺序反过来的团队通常会先花两周研究引擎的语义理解能力，然后发现自己站上根本没写过那个词。这个顺序值得写进排查手册的第一行。

另外提醒一句，日本市场还有一层平台因素值得单独看，但那属于引擎和渠道的选择，跟本文这一层的动作没有先后依赖，可以完全并行推进。

## 常见问题解答

## 不懂日语，怎么自己判断两个词是不是一对？

有个不需要日语能力的办法。把你要处理的那个动作用中文写成两句话，一句是东西自己发生了变化，比如盖子打不开了；另一句是人做了这件事，比如把盖子打开。然后把这两句中文分别丢进任意一个在线日语词典或者例句库，看返回的动词是不是同一个字符串。不是同一个，那就是一对。整个过程你需要的只是复制粘贴和字符串比对的能力。要提醒的是别只看汉字部分，成对的两个词汉字通常是一样的，差别全在后面的假名上，只对比汉字会得出所有词都一样的错误结论。

做完之后可以把配好的对子发给本地同事确认一遍，但问题要问得具体，问他机器出这个状况时用户一般怎么说。另外提醒一点，例句库返回的结果要挑生活场景的那几条看，技术文档里的用法往往偏书面，跟搜索框里的输入不是一回事。

## 把两类词都堆进同一个页面，是不是最省事？

短期看确实省事，长期看不建议。同一个页面同时承接购前操作问题和售后故障问题，会让页面的意图变得模糊，两类查询互相稀释，最后哪一类都排不到前面。更现实的问题是这两类用户需要的页面结构完全不同：操作类用户愿意从头看到尾，故障类用户希望第一屏就给判断路径。硬塞在一起，后者会在前三秒离开。合理的做法是商品页和使用指南保持现在的写法，另开一组支持页专门承接故障类查询，两边用内链连起来。

拆开之后每个页面的标题和首段都能对准一类词，这比在一个页面里塞两套说法有效得多，改动量其实也没大多少。还有一个附带好处是拆开之后两类页面的效果可以分别衡量，混在一起的时候你根本判断不出改动到底帮了哪一边。

## 这批词的搜索量在工具里看着很小，值得做吗？

工具给的数字在这一类词上系统性偏低，原因有两个。一是这批查询的说法非常分散，同一个故障用户能打出十几种不同的句子，工具按字符串统计就把量切碎了。二是很多这类查询本来就发生在站内搜索框里而不是搜索引擎里，工具根本看不到。所以判断它值不值得做，不要看工具的数字，要看你自己的第一方数据：站内搜索次数、客服工单条数、退货原因分布。

这三个数通常比工具数字大一到两个量级。汇报的时候也用第一方数据，因为它不需要解释统计口径，而且业务方对工单和退货这两个词天然敏感。另外建议把三个第一方数字按品类拆开看，通常会发现问题高度集中在一两条产品线上，先做那一两条的投入产出比最好。

## 词干还原已经把两类词合并了，为什么还要单独写？

因为合并解决的是统计口径，不是页面内容。词干还原让你的报表显示这批查询已经有对应词条了，但页面上一个字都没变，用户搜进来看到的还是那批讲操作步骤的标题。判断有没有真的解决，有个很直接的办法：拿一条实际查询在自己站上搜一遍，看返回的页面标题跟这条查询长不长得像。不像，那就是没解决。

另外还要注意还原器的行为跟版本有关，换一次搜索引擎版本，合并规则可能就变了，而显式写进同义词表的配对不受版本影响。稳妥的做法是两条腿走路，还原器兜底，核心词对显式写死。还有一个简单的验证动作是看页面源码里有没有那个字符串，搜不到就说明无论工具怎么报，这个词在你站上确实不存在。

## 改标题会不会影响已有页面的排名？

要看改的是哪一类页面。承接故障类查询的支持页，本来就没有排上什么名，改标题几乎没有下行风险，属于净收益。商品页和使用指南这类已经有排名的页面不建议动标题，它们现在的表现说明标题跟当前的查询是匹配的，动了反而可能掉。所以正确的做法是新开或者改写支持页，不碰已经跑得好的页面。如果一定要在已有页面上加，可以先加在首段和问答区，观察两三周没有负面影响再考虑动标题。

这个顺序也符合一般的改动原则：先在低风险的位置试，确认方向对了再往高风险的位置推。另外一个稳妥的做法是先在少数几个页面上试，观察两三周确认没有负面影响之后再批量推，改动范围小的时候回滚也容易。

## 其它品类需要做同样的排查吗？

要不要做取决于你的商品会不会自己出状况。带机械结构、带电、带耗材的品类必须做，家电、工具、户外装备、汽车配件都在这一档。纯软性商品比如服装、床品、饰品，这类查询的量非常小，做一次筛查确认就可以放过。判断办法很简单：翻一遍客服工单，看有多少条是在描述商品的状态而不是在问怎么用。

比例超过两成就值得按本文的流程走一遍。顺带说一句，即便是软性品类，退换货流程相关的查询里也可能出现这类词，那一块可以单独看一眼，成本很低。顺带一提，配件和耗材页面也值得单独看一眼，因为用户找配件的起点往往就是一句描述状态的话，而不是配件本身的名字。

## 这套办法在AI搜索那一侧还成立吗？

成立，而且理由更充分一点。生成式的回答需要从某个来源里抽取内容，而抽取的前提是这段文字在语义上跟问题对得上。如果全站没有任何一段文字是从用户那个视角描述这件事的，模型能拿到的最接近的材料就是操作步骤，回答出来自然也是操作步骤，跟用户想问的对不上。反过来，只要站上有一段用用户的说法写的判断路径，被引用的概率会明显提高，因为它跟提问的措辞更接近。

所以这件事在AI搜索那一侧的落点跟传统搜索是一致的：页面上得真的有那段文字，配置层的同义词在那边完全不起作用。还有一点值得留意，模型引用时倾向于挑那种结构清晰、判断路径明确的段落，所以这批内容的排版比一般文章更值得下功夫。



## 站上字最少的那几类页面最赚钱，也最容易被机器认成另一门语言

- URL：https://zhangwenbao.com/minor-language-page-language-detection-misidentification-short-text.html
- 分类：小语种SEO
- 发布：2024-06-19  |  更新：2026-07-27
- 摘要：语言标注是声明，识别器是猜测，两者冲突时赢的常常是猜测。讲清判错为什么总往语料多的那门语言倒、模板骨架占比怎么把分类页整个带偏，以及不用装工具就能测出判定结果的三种办法。
- 关键词：技术SEO,国际化SEO,多语言SEO,小语种SEO

> **TLDR**：摘要：你在页面头部写了语言，也配了地区标注，但机器并不完全按你写的来。它会自己数一遍页面上的字符和词，得出一个结论，两个结论打架时赢的往往是它数出来的那个。而文本越短判错概率越高，偏偏分类页、筛选页、商品列表这些最赚钱的页面文本最短。本文讲清判错怎么发生、往哪一边倒、怎么在半天内测出来。

> 摘要：你在页面头部写了语言，也配了地区标注，但机器并不完全按你写的来。它会自己数一遍页面上的字符和词，得出一个结论，两个结论打架时赢的往往是它数出来的那个。而文本越短判错概率越高，偏偏分类页、筛选页、商品列表这些最赚钱的页面文本最短。本文讲清判错怎么发生、往哪一边倒、怎么在半天内测出来。

## 机器为什么不完全相信你写在页面上的语言声明？

## 声明和猜测是两条并行的链路

页面上有几处可以声明语言：文档根元素的属性、响应头、站点地图里的标注、页面之间的互指标签。

这几处都属于声明，意思是你说这页是什么语言，它就登记成什么语言。前提是对方愿意读，而且读得到。

另一条链路完全不看这些。它拿到页面文本，统计字符分布和常见词，算出一个最像的语言，附带一个置信度。

两条链路的输出经常一致，一致的时候没人会注意到有两条链路。不一致的时候，事情才开始变得难查。

更麻烦的是，你在后台看不到任何关于第二条链路的信息。它不产出报告，不发告警，只在结果里悄悄生效。

这里可以先立一条判据：声明是给愿意读它的人准备的，猜测是给不读的人准备的。而在任何一条真实链路上，不读声明的环节永远比读声明的环节多，尤其是那些顺手抓一段文本就拿去用的环节。

把这两条链路画在一张纸上，会发现它们的使用者也不一样。读声明的多半是那些要按语言做分发决策的环节，比如把哪个版本推给哪个市场；靠猜测的多半是那些拿到一段文本就要立刻处理的环节，比如判断要不要提示翻译、要不要做分词、用哪套词典去切词。后者的数量远多于前者，而且它们大多不在你的可观测范围之内。

## 为什么猜测常常赢过声明

猜测发生得更早。文本一到手就能算，不需要等页面渲染完，也不需要额外请求任何资源。

声明的读取要晚一步，而且要求解析器认得那个字段，还要求那个字段没写错。

写错的概率并不低。地区码写成语言码、大小写不规范、写了一个根本不存在的标签，这几种在真实站点上都很常见。

一旦声明的值解析不出来，链路会静默地退回到猜测，不会告诉你它退回了。

这就是很多团队的困惑来源：明明配好了，行为却像没配。原因不是配置没生效，是配置被判成了无效值。

还有一类更隐蔽的情形：声明写对了，但跟页面内容明显矛盾。声明说这页是荷兰语，正文九成是英语，这时候不少实现会选择相信内容而不是相信标签。标签只在跟内容不冲突时才被采纳，冲突时它降级成一个次要信号，这一点在任何官方文档里都不会明说。

还有一个现实原因：很多环节根本拿不到你的声明。它们处理的是从页面上抠出来的一段纯文本，标签在抽取那一步就被剥掉了。W3C国际化问答关于HTML语言声明的说明 (https://www.w3.org/International/questions/qa-html-language-declarations)里讲得很清楚：声明属于文档，而文本片段一旦离开文档就不再携带它。

## 这跟地区定向不是一回事

语言和地区是两个维度，判错语言和定向错国家是两类问题，混在一起讨论会一直谈不拢。

地区定向靠的是域名、服务器位置、站点地图和后台设置，都是你能控制的信号。

语言识别靠的是页面上的字，这部分你也能控制，只是从来没人把它当成一个可以主动设计的东西。

把两者分开的好处是排查路径完全不同：定向问题去后台看设置，识别问题去页面上数字。

本文只讲后面那一半，前面那一半属于架构层，可以按国际化SEO与hreflang的完整实现清单 (https://zhangwenbao.com/international-seo-hreflang-complete-guide.html)那一套去排查。

一个很实用的分辨办法：问这个现象在单一市场的单语言站上会不会发生。会，那多半是识别层的问题；只在多市场多版本的站上出现，那多半是定向层的问题。用这一个问题就能把绝大多数议题分到正确的那一堆里去，会议上争论不下的时候尤其好用。

还有一个信号可以帮你快速定位：如果同一个页面在不同国家的搜索结果里都缺席，那多半是识别层；如果只在某一个国家缺席而在别的国家正常，那多半是定向层。缺席的范围本身就携带着诊断信息，看一眼就能省掉半天的排查。

## 语言识别到底在数什么？

## 字符分布是第一道筛子

如果页面上出现了某套书写系统专有的字符，语言范围立刻被收窄到几门语言之内。

希腊字母、谚文、天城文这类专属性很强的书写系统，第一道筛子就能筛得很准。

麻烦的是共用拉丁字母的那几十门语言，它们的字符集高度重叠，第一道筛子几乎不起作用。

西里尔字母也一样，俄语、乌克兰语、保加利亚语、塞尔维亚语共用大部分字母。

只有那几个专有字母能提供区分度，而它们在短文本里出现的概率并不高，Universal Dependencies的多语言树库项目 (https://universaldependencies.org/)里各语言的语料规模差异，也间接反映了模型能拿到多少这类区分证据。

这就解释了一个反直觉的现象：书写系统越独特的语言越不容易被判错，书写系统越常见的语言反而越危险。做小语种的人通常觉得非拉丁字母的语言更麻烦，在识别这一层上恰恰相反。

不过书写系统这一层也有陷阱：同一套书写系统里那几个专有字母，恰恰是最容易被用户省略的。塞尔维亚语的西里尔专有字母、乌克兰语的四个专有字母、罗马尼亚语带逗号的两个字母，用户在移动端经常打不出来，你的商品名如果照着用户的输入习惯写，判别力最强的那批字符就正好缺席了。

## 字符组合的频率是主力信号

主流做法是数字符组合的出现频率，比如连续三个字符构成的片段在这门语言里常不常见。

每门语言都有自己的高频组合，把页面上的组合分布跟已知分布比一比，最像的那个就是答案。

这种做法不需要理解语义，也不需要词典，速度快，覆盖语言多，所以被用得最广。

代价是它完全依赖统计，而统计需要样本。样本太少的时候，分布本身就不稳定。

常用的开源实现会同时给出一个置信度，但很多调用方直接取最高分那一个，把置信度丢掉了。

置信度被丢掉这件事影响很大：一个零点九的判定和一个零点三的判定，在下游看来是一样的结论。fastText的语言识别模型文档 (https://fasttext.cc/docs/en/language-identification.html)里明确给出了预测接口会返回概率值，能不能用起来取决于调用方，而调用方通常图省事。

还有一个容易忽略的点：这类模型通常有一个语言清单，清单之外的语言根本不会出现在结果里。如果你做的语言不在清单上，它会被强行归到最接近的那一门，而且置信度可能还不低。CLD3语言识别器的源码仓库 (https://github.com/google/cld3)里就列出了支持的语言清单，先去查一眼自己在不在上面，这是最省事的一次核对。

## 停用词和高频功能词是补充信号

有些实现会额外看一批高频功能词，比如冠词、介词、连词的出现情况。

这批词在同一语族内部差别很大，判别力比字符组合更强，尤其是在近亲语言之间。

但功能词恰恰是短页面上最缺的东西。一个分类页上全是名词短语，几乎没有完整句子。

没有完整句子就没有功能词，这道补充信号在最需要它的地方正好失灵。

这是短页面判错率高的一个具体机制，而不是一句笼统的样本太少。

反过来说，这也给了一个很便宜的改进方向：让短页面上多出现几个完整句子。一段两三句话的说明，带来的功能词数量比几十个商品名还多。这就是为什么给分类页加一小段说明文字的效果，往往比把商品名从二十个加到四十个更明显——加的不是字数，是句子结构。

功能词这条信号还有一个副作用值得知道：它对写作风格敏感。电商站的商品描述习惯写成短语堆叠，功能词天然就少；而同样一门语言的资讯类站点句子完整，功能词充足。所以同一门语言在不同类型的站点上，判定难度可以差出一个档次。

## 模板骨架也会被一起数进去

页面上的字不只有正文。导航、页脚、按钮、面包屑、筛选项标签，这些都是文本。

如果这些位置没有本地化，或者用的是英文缩写，它们会被一并统计进去。

骨架文本在长文页面上占比很小，在分类页上可能占到七成以上。

于是同一个站的两类页面会被判成两门语言，而团队从来没意识到这是同一套模板的结果。

这里可以提炼一条：骨架语言和内容语言是两个东西，判定结果取决于两者的比例。

模板骨架占比按语言重算一遍这件事，在一个模板生成十种语言的重复内容风险 (https://zhangwenbao.com/multilingual-template-ten-languages-duplicate-content-risk.html)里是从重复度角度讲的，这里是同一个数字的另一种用法：那篇关心骨架占比高会不会造成十份内容雷同，本篇关心骨架占比高会不会把页面的语言判定整个带偏。

骨架文本还有一个特点：它在全站每一页上都一样。也就是说，如果骨架用的是英语，那这份英语证据会被均匀地撒在你所有的页面上，而本地语言的证据分布极不均匀。全站的语言判定因此会呈现一种奇怪的形态：长文页面判对，列表页判错，中间的商品页看运气。

## 为什么文本越短，判错的概率越高？

## 统计需要样本，短文本给不了

字符组合分布是一个统计量，样本少的时候方差大，偶然出现的几个组合就能改变结论。

公开的评测里，判定准确率随文本长度上升得很快，几十个字符和几百个字符是两个量级的可靠度。

短到十几个字符的时候，很多实现干脆给不出有意义的结论，只能返回一个低置信度的猜测。

而下游拿到这个猜测之后，通常不会区分它是高置信度还是低置信度。

结果就是一个几乎等于抛硬币的判定，被当成一个确定的事实往下传。

更值得警惕的是，这种误差不是随机分布的。它有系统性的偏向，会稳定地往某一个方向倒，这一点下一节专门讲。

有一个细节值得单独提：很多实现在文本极短时会返回一个表示未知的标签，而下游代码常常没处理这个分支，直接把它当成某个默认语言。默认值是什么，取决于写代码那个人当时在做哪个市场，通常是英语。这是一条你在任何文档里都查不到、只能靠读源码才能发现的行为。

## 最短的页面恰好是最值钱的页面

把站内页面按正文字数排一遍，最少的那一批通常是分类页、筛选结果页、品牌页、商品列表。

这几类页面在电商站上承接的是购买意图最强的那批查询，转化率通常高出内容页几倍。

于是出现了一个很别扭的结构：判错风险最高的地方，正好是商业价值最高的地方。

反过来，那些洋洋洒洒几千字的指南类文章，语言判定几乎不会错，但它们的转化贡献有限。

投入和风险的分布正好错位，这也是这个问题长期没人管的原因之一。

这条错位可以直接搬成一个排查顺序：先查最短的页面，别从首页和长文开始。多数团队的直觉正相反，他们从首页开始查，而首页往往是全站语言证据最充分的一页。

还有一个层面的错位：这几类短页面往往是自动生成的，没有内容团队参与，所以它们从来没进过任何一次内容评审。评审流程盯的是文章和商品描述，而真正承接购买意图的那批页面，从生成到上线全程没有人从语言角度看过一眼。

## 动态加载会让文本更短

不少站的商品列表是异步加载的，首屏返回的文档里几乎没有商品名。

抓取工具如果不执行脚本，拿到的就是一个只有骨架的文档，正文近乎为零。

这种页面被判成什么语言，基本取决于导航和页脚用的是什么语言。

如果模板里还留着英文的按钮文案，那这页大概率会被判成英语。

排查这一类的办法是直接看未执行脚本时的文档内容，而不是看浏览器里渲染完的样子。

缓解办法不一定要改渲染架构。在原始文档里保留一份精简的商品名列表、把分类描述写进服务端返回的文档、给筛选项标签用服务端渲染，这三样都是局部改动，加起来就能让原始文档里有足够的本地语言文本，比整站换渲染方式现实得多。

还有一个折中办法：给这类页面配一份服务端渲染的精简版本，专门给不执行脚本的访问方使用。这不是做两套内容，而是同一批数据的两种输出形态，维护成本很低。前提是两个版本的内容必须一致，否则会引出另一类麻烦。

## 哪几对语言最容易互相认错？

## 误判总是往语料多的那一边倒

近亲语言之间的判错不是对称的。资源多的那门语言更容易成为默认答案。

原因很直接：分类器的先验来自训练语料的分布，语料多的语言在模型里的权重天然更大，Common Crawl按语言统计的网页占比图 (https://commoncrawl.github.io/cc-crawl-statistics/plots/languages)能直观看出这个分布有多陡。

所以马来语容易被判成印尼语，乌克兰语容易被判成俄语，波斯尼亚语容易被判成塞尔维亚语或克罗地亚语。

反方向的误判也存在，但概率明显低一档，这在实践里意味着小语种一侧承担了大部分损失。

这条不对称性是本文最值得记住的一句：你做的语言越小众，被吸收进邻居的概率就越高。

它还有一个推论：这类问题不可能靠等待模型变好来解决。语料分布的差距是长期存在的结构性事实，模型换代只会让高资源语言的判定更准，两边的差距未必收窄。

这条不对称性还能解释一个常见的困惑：为什么同样的模板，做印尼语没事，做马来语就出问题。团队往往会往技术实现上找原因，其实原因在语料分布上，跟你的实现一个字都没关系。识别层的风险是按语言的资源量分配的，不是按你的投入分配的。

## 共用书写系统的那几对最危险

克罗地亚语、塞尔维亚语的拉丁写法、波斯尼亚语，三者的短文本几乎无法区分。

印尼语和马来语的商品名重合度极高，很多品类词根本一模一样。

捷克语和斯洛伐克语在长文本上分得开，在几个词的标签上分不开。

葡萄牙语的两个变体属于同一门语言，判定不会错，但地区判定会错，那是另一个问题。

这几对语言的市场决策差异在克罗地亚语和斯洛文尼亚语的两个小市场决策 (https://zhangwenbao.com/croatian-slovenian-seo-two-small-markets-decision.html)与印尼语与马来语能不能合并成一套 (https://zhangwenbao.com/indonesian-malay-seo-two-markets-vocabulary-split.html)两篇里各有拆解，本篇只补识别层这一角。

近亲语言之间还有一个更细的分层：书写系统相同、词汇相近、语法相近，三样占得越多越危险。捷克语和斯洛伐克语三样全占，判错概率最高；克罗地亚语和斯洛文尼亚语只占前两样，稍好一点。这个三分法在捷克语和斯洛伐克语的内容复用决策 (https://zhangwenbao.com/czech-slovak-seo-content-reuse-decision.html)里是用来判断内容能不能共用的，在这里可以直接拿来估判错风险。

## 双语市场的页面最容易两头不靠

有些市场的用户日常混用两门语言，页面上也就自然出现两门语言的词。

这类页面的判定结果高度不稳定，同一页在不同实现下可能得到不同答案。

更常见的情况是被判成其中较强势的那一门，而你想覆盖的恰恰是另一门。

处理办法不是硬把另一门语言的词删掉，那会损害真实的用户覆盖。

正确的做法是在页面级别做取舍：主体语言只留一门，另一门以标注、括注、独立区块的形式存在，让统计上的主次分明。

嵌套型双语市场的关键词处理在菲律宾市场混合语言的关键词研究 (https://zhangwenbao.com/philippine-english-taglish-mixed-language-keyword-research.html)里讲过一套完整框架，识别层这一角可以直接接在那套框架后面用。

双语页面还有一个额外风险：它可能被判成两门语言之外的第三门。混合文本的字符组合分布跟任何一门单一语言都不像，识别器给出的结果有时会很离奇。遇到这种情况别急着调内容，先确认一下检测用的到底是哪一段文本，很多时候问题出在抽取环节而不是内容本身。

## 转写内容是最隐蔽的一类

用拉丁字母拼写本来用其他书写系统的语言，是很多市场的真实输入习惯。

这类文本在识别器眼里既不是原语言，也不是任何一门拉丁语言，判定结果会非常随机。

如果你为了覆盖转写查询单独做了页面，这些页面的语言判定几乎一定是错的。

这类页面本身仍然有价值，只是不能指望它们在语言维度上被正确归类。

务实的做法是给这类页面显式声明语言并接受判定可能错，同时不要让它们成为某个语言版本的主力落地页。

转写页面还有一个连带问题：它跟本语言的正式页面在内容上高度重合，而两者的语言判定又不一致，很容易被当成两个不相关的页面各自对待。稳妥的做法是让转写页面明确指向正式页面，把它当成一个入口而不是一个独立版本，这样即便判定错了，损失也被限制在入口这一层。

还有一个务实的判断：如果转写页面带来的流量本来就不多，那它的语言判定错不错其实无所谓，不必为它单独投入。判断依据是把这类页面的自然流量占比算出来，低于一个很小的比例就归到不管的那一类，把精力放回主力页面上。

## 混写页面会把整页拉向哪一门语言？

## 参数表是最大的一块英文飞地

商品参数表里往往全是型号、单位、材质缩写、认证编号，这些几乎都是拉丁字母。

一张二十行的参数表贡献的字符数，可能超过页面上所有本地语言正文的总和。

拿园艺工具站举例，一把修枝剪的参数表里，刃长、开合角度、材质牌号全是数字和英文缩写。

本地语言只剩下几个字段名，而字段名往往还被做成了图片或者缩写。

结果是这一页在统计上更像英语，而它恰恰是最重要的一类商品页。

解法不是删掉参数，而是把字段名写全、写成本地语言的完整词，并在参数值旁边补上本地语言的说明短语。字段名从缩写改成完整词，通常能把本地语言的字符占比拉高一大截，而这件事对用户也是有好处的。

参数表还有一个更简单的改法：把单位写成本地语言的完整词而不是国际缩写，比如厘米写成本地语言的完整拼写。这类词在每一行都出现，改一次就能在整张表上生效。缺点是表格会变宽，需要跟前端商量一下移动端的排版，但这属于可以解决的问题。

## 品牌名和型号不算证据

品牌名、型号、系列名在任何语言的页面上都长得一样，它们对判定没有贡献，还会稀释有效信号。

标题里如果品牌名和型号占了大半，剩下几个本地语言的词很难撑起判定。

这一点在标题模板设计上有直接影响：本地语言的品类词应该出现在标题里，而不是只靠品牌加型号。

顺带一提，这个改动对用户查询匹配也是正向的，属于一改两得。

品牌名在不同语言里的写法问题另有一套判断，本篇不展开。

还有一个相关的细节是替代文本。图片的替代文本属于页面文本的一部分，很多站的替代文本直接用了商品编号或者文件名，等于又贡献了一批无效字符。把替代文本写成本地语言的完整描述，既是无障碍要求，也顺手补了语言证据，这一条的性价比在非拉丁字母站点的图片替代文本写法 (https://zhangwenbao.com/minor-language-image-alt-text-non-latin-script-search.html)里有专门的拆解。

另外还有一处：面包屑。面包屑里的分类名如果用的是英文标识而不是本地语言的显示名，它会出现在几乎每一个商品页上。这一处的改动量通常只是一次配置，收益却是全站级别的，属于最容易被漏掉也最容易补上的位置。

## 数字和单位有本地写法，别浪费

小数点、千位分隔符、日期顺序、货币位置，这些在各语言里写法不同。

它们本身就是语言证据，写对了不仅用户看着自然，识别器也能多拿到几个信号。

很多站的这些格式是从后台直接输出的，用的是系统默认，也就是英语习惯。

改成本地格式的成本很低，通常只是配置一个地区参数的事。

顺带还能解决一批用户困惑，比如把一千零五十写成带点的形态在某些市场会被读成一点零五。

格式这件事还有一个更深的层面：日期和数字的本地格式属于地区数据，各语言的规则由公开的地区数据库统一维护，实现只要调用就行。Unicode通用地区数据仓库 (https://cldr.unicode.org/)就是这份数据的来源，绝大多数系统的本地格式化能力最终都指向它，不需要自己写规则。

## 判错之后，具体哪些环节会跟着出错

## 互指标签可能被整组忽略

页面之间的语言互指标签，前提是每一页的语言声明可信。

如果某一页被判成了另一门语言，这组标签的自洽性就出现了矛盾。

矛盾的处理方式各家不同，最坏的情况是整组标签被降权或忽略。

表现出来就是明明配得完全对称，某几门语言的版本还是不出现在对应市场。

排查时先别怀疑标签写法，先去看这几页被判成了什么语言。

排查这一类问题有个取巧的顺序：先挑一组配置最简单、页面最长的互指标签来验证，比如两个语言版本的长文章。如果这组正常而分类页那组不正常，问题基本可以锁定在识别层。用一组已知正常的配置当对照，比逐条检查标签写法快得多。

## 自动翻译会盖住你的原版

如果一页被判成了跟用户语言不同的语言，用户端可能出现自动翻译的提示或结果。

你精心做的本地化正文，被机器再翻一遍呈现给本来就说这门语言的用户。

翻出来的措辞通常比原文差，品牌语气也没了，而你在后台看不出这一层。

唯一的线索是转化率异常、跳出率异常，或者用户在反馈里提到读着奇怪。

这类现象的识别与防御属于另一个话题，本篇只指出它的上游可能是语言判错。

还有一个更容易被忽略的场景：站内的自动翻译插件。有些多语言插件会先检测当前内容的语言，再决定要不要翻译，如果它判错了，就会把本来已经是目标语言的内容再翻一遍。这类问题往往在上线很久之后才被用户投诉发现，而投诉的措辞通常是这页读着像机器翻的。

## 候选池和引用来源会挑错语言

问答类结果和生成式回答在挑来源时，会优先挑跟提问语言一致的页面。

被判成另一门语言的页面，在这一步会被整体跳过，而你在任何后台里都看不到这次跳过。

更糟的是，如果它被判成了一门高资源语言，它可能被拉去回答那门语言的问题。

那些提问者根本不是你的目标用户，展现有了，转化不会有。

这一层的观测手段极少，只能靠自己按语言抽样提问去反推。

反推的办法可以做得更结构化一点：用本语言问十条你最想被引用的问题，记录来源清单里有没有你的页面，再用邻近的高资源语言问同样十条，看你的页面有没有反而出现在那边。出现在错误的那一边，比两边都不出现更能说明是识别层出了问题，因为它证明你的内容是可见的，只是被归错了类。

## 站内的语言路由也会跟着乱

不少站会根据检测到的内容语言做一些自动化处理，比如推荐相关文章、生成站点地图分组、给内容打标签。

只要某一环用了自动检测而不是你的声明，判错就会顺着这条路扩散。

最常见的表现是相关推荐里混进了另一门语言的文章，用户点进去发现看不懂。

这类问题查起来不难，把内部所有做语言检测的位置列一遍就行，通常只有两三处。

把这几处统一改成读取声明值而不是自己检测，是成本最低的一次收口。

还要留意那些第三方服务：站内搜索、推荐引擎、评论过滤、广告投放平台，它们各自都可能做一次语言检测。这些服务不在你的代码库里，列表也就不会自动完整，需要按接入的服务逐个问一遍。问题清单其实只有一句话：你们是按我传的语言字段来，还是自己检测。

顺带说一个真实的排查经验：这类问题最常见的根因不是某个服务判错了，而是根本没人把语言字段传给它。接口文档里明明有这个字段，接入的时候图省事没填，服务只好自己检测。问一句有没有传，往往比问它怎么检测更快找到问题。

## 怎么在不装任何工具的情况下测出自己有没有被判错？

## 看浏览器给不给你弹翻译提示

浏览器的翻译提示本身就是一次语言判定的结果输出，而且是免费的、随时可用的。

用一个界面语言设成目标语言的浏览器打开你的页面，如果弹出了翻译提示，说明它认为这页不是那门语言。

逐类页面试一遍：首页、分类页、商品页、文章页、购物车，记录哪几类弹了提示。

弹提示的那几类就是判错风险最高的，通常正是文本最短的那几类。

这个方法粗糙，但它是唯一一个不需要任何权限、几分钟就能跑完的方法。

要提高准确度，可以在浏览器的翻译菜单里看它把源语言标成了什么，那个值就是它的判定结果，比有没有提示更精确。

这个测试还有一个变体：把浏览器界面语言设成一门完全无关的语言，比如英语，再打开你的页面，看它提示要把这页从什么语言翻译过来。提示里那个源语言就是判定结果，而且这个形态比有没有弹提示更直接，几秒钟就能记一条。

## 把文本粘进任意一个检测接口

公开的语言检测实现有好几个，把页面正文粘进去就能拿到判定结果和置信度。

关键是粘什么。要粘的是抓取工具实际能拿到的文本，不是你眼睛看到的全部内容。

做法是查看页面源码，把纯文本抽出来，去掉脚本和样式，再拿去检测。

同一页做两次对照：只用正文一次，正文加骨架一次，看结论会不会变。

如果两次结论不同，就说明骨架文本的比重已经足以影响判定，这是一个很明确的改进信号。

粘文本这一步有个容易搞错的地方：不要粘渲染后的可见文本，要粘原始文档里的文本。两者在动态站上差别巨大，而抓取方拿到的往往是前者。取原始文档只需要查看页面源代码，或者用命令行直接请求一次，不需要任何工具。

## 用同站两类页面做对照组

拿一篇长文和一个分类页做对照，两者用的是同一套模板、同一门语言。

如果长文判对而分类页判错，问题一定在文本量和骨架占比上，跟你的声明写法无关。

这个对照能省掉大量无用的排查，因为它一次性排除了配置层的嫌疑。

反过来如果两者都判错，那才需要回头去查声明值是不是写成了无效标签。

对照组的另一个好处是它在你换模板、换语言之后仍然可用，方法本身不会过期。

对照组还可以再加一层：拿同一门语言下不同类型的页面各测一遍，把结果排成一张小表。表里那几行判错的页面类型，就是这一轮要改的对象，而判对的那几行则告诉你证据密度到什么程度就够了。用自己的站当基准，比套用任何外部阈值都准。

对照组这套办法还有一个长期价值：它不依赖任何具体工具，也不依赖某个实现的当前行为。工具会换，接口会下线，模型会升级，但拿自己站上判对的页面当基准这件事永远成立，方法本身不会过期，这在这个变化很快的领域里相当难得。

## 短页面该怎么补足语言证据？

## 先算一算本地语言的字符占比

把一个典型分类页的纯文本导出来，人工标一遍哪些是本地语言、哪些是品牌型号和英文缩写。

算出本地语言字符的占比，这个数字就是你这一类页面的语言证据密度。

经验上，这个比例低于一半的页面就已经进入危险区，低于三成基本会被判错。

这个数字不需要精确，量级对就够用，它的作用是让讨论从感觉变成一个可比较的值。

把几类页面各算一个数，排个序，改进顺序自然就出来了。

这个测量还有一个额外用途：它给出的是一条可以持续跟踪的曲线。改版之后重算一次，就知道这次改版是把证据密度拉高了还是拉低了，而不必等几个月看流量。

标注的时候有个简化办法：不必逐字判断，按块估就行。把页面分成导航、筛选、商品名、参数、说明文字、页脚六块，每块估一个本地语言比例和字符数，加权求和。误差在几个百分点以内，完全够用来排优先级，而全部工作量不超过半小时。

## 把骨架文本本地化，优先级比想象中高

导航、筛选项、按钮、排序选项、分页文案，这些在分类页上的字符占比往往超过商品名。

把它们完整本地化，既是用户体验问题，也是语言判定问题，一次改动两头受益。

最容易被漏掉的是筛选项的值，比如颜色名、材质名、尺寸单位，很多站直接用了英文。

这几处的翻译量其实很小，通常几十个词，但它们在每一个分类页上都会出现。

换句话说，投入是一次性的，收益是乘以页面数量的，性价比在整套改动里最高。

这里有一个容易被漏掉的位置：错误提示和空状态文案。搜索无结果、筛选无结果、库存不足这类提示，往往是从组件库里直接带过来的英文，而它们出现在用户最需要引导的时刻。本地化这几句话，既是体验修复，也顺手把几个高频页面的证据密度拉了上去。

## 给短页面加一段真正有信息量的本地文字

在分类页顶部或底部加一段本地语言的说明文字，是最直接的补证据办法。

但要写成有信息量的段落，别写成关键词堆砌，后者既伤体验也不产生额外的判定价值。

一百到两百字就足够把判定拉稳，不需要写成一篇文章。

写作角度可以是选购建议、尺寸对照、本地使用场景，都是用户真的会看的内容。

顺带说一句，这段文字对长尾覆盖也有用，属于同一笔投入的两份回报。

这段文字放在哪里也有讲究。放在商品列表下方通常比放在最上方好，既不挤压商品的首屏位置，也仍然是文档里的正文。如果放在上方，控制在两三行以内，别把用户想看的东西推到折叠线以下——语言判定重要，但没有重要到可以牺牲转化。

## 一份按页面类型排的语言证据自检表

## 先按类型分组，别按单页排查

同一类型的页面用的是同一套模板，问题也是同一个，逐页排查纯属浪费。

把站内页面分成五到八个类型，每个类型抽两页做样本，结论可以覆盖整类。

抽样时挑正文最短的那一页，因为最短的那一页决定了这一类的风险下限。

每个类型记三个数：本地语言字符占比、检测结果、置信度。

三个数一填，哪一类要改、改到什么程度就都清楚了。

分组的时候建议按模板分，而不是按业务分类分。同一个模板生成的页面，语言证据结构是一样的，测一个就代表一批；按业务分类分组则可能把两套不同模板的页面混在一起，结论互相污染。问一句这批页面是不是同一个模板渲染的，就能分对组。

分组还有一个附带收益：它天然形成了一份模板清单。很多团队其实说不清自己站上到底有多少套模板，做这次排查的时候顺手把清单列出来，后面做任何模板级的改动都能复用，包括结构化数据、内链规则、页面速度优化。

## 把声明值单独核一遍

核对语言标签的写法是否合法，语言码和地区码有没有写反，有没有用了已废弃的标签。

合法性可以对着IANA语言子标签注册表 (https://www.iana.org/assignments/language-subtag-registry)核，那是所有语言标签的权威来源，三段式标签的组合规则则写在RFC 5646语言标签规范 (https://www.rfc-editor.org/rfc/rfc5646)里。

注册表里能查到每个子标签的类型、是否废弃、废弃后该用哪一个替代。

顺手核一遍书写系统子标签有没有在该写的时候写上，这一条在多书写系统的语言上是必需的。

这一步半小时能做完，属于低成本高确定性的部分，建议放在最前面做。

核对时特别注意那几个看起来对、其实不对的写法：只写语言码却在内容上用了地区变体、书写系统子标签该写没写、把地区码写成了小写或者把语言码写成了大写。这些写法有的会被容错处理，有的会被判成无效，而你无法预知每个实现的容错策略，唯一稳妥的做法是完全按规范写。

## 改完之后怎么验收

验收不要只看检测结果变没变，还要看置信度有没有明显上升。

从零点四涨到零点五和从零点四涨到零点九，稳定性完全不是一回事。

再跑一遍浏览器翻译提示的测试，看那几类页面还弹不弹。

两个信号都变好，才算这一轮改动生效，只有一个变好通常意味着还差一层。

把这两个数字记进上线前的检查清单，之后每次改模板顺手跑一遍，成本几乎为零。

验收还要留一道回归：把这份检查加进模板改动的上线清单里。语言证据密度是很容易被一次改版打回原形的，比如某次改版把说明文字挪到了脚本加载的区块里，或者把字段名换回了缩写。加一道自动化的抽样检查，成本是一次性的，而它防的是一类会反复发生的回退。

## 哪些问题不归语言层，该交给谁？

## 地区归属那一半交给架构层

判错语言和定向错市场是两回事，后者靠域名结构、后台设置和互指标签解决。

本篇讨论的所有动作都不影响地区归属，别指望改了文案就能换一个市场。

两个议题混在一起谈，通常会以互相甩锅收场，因为负责的团队都不是同一个。

把它们分成两张排查表，各自有各自的验收标准，会议效率立刻不一样。

地区那一半的完整拆解不在本篇范围内，架构层的文章讲得更细。

还有一类容易混进来的议题是同一门语言在多个市场的分配，比如西班牙语在西班牙和拉美、葡萄牙语在巴西和葡萄牙。那属于同语言多地区的问题，判定层根本分不出来，也不该由判定层负责。识别层只回答这是哪门语言，回答不了这是给哪个市场看的。

## 翻译质量那一半交给内容层

语言判对了不代表内容读着自然，判错了也不代表翻译质量差，两者没有必然联系。

本篇讲的是能不能被数出来，不是写得好不好，这两个目标偶尔还会互相拉扯。

比如为了提高证据密度硬加文字，就可能伤到内容质量，这时候要以内容质量优先。

加文字的正确姿势是加真正有用的信息，而不是为了凑字符数。

验收标准也该分开：内容质量交给母语审校，证据密度交给这张自检表。

两个目标真冲突的时候，有一个简单的排序：先保证内容对人有用，再考虑对机器好数。因为内容差是确定的损失，判定错是概率性的损失，用确定的损失去换概率性的收益从来都不划算。这条排序也能防住一类常见的过度优化。

还有一种情况要提前说清楚：如果某一类页面的本地语言文本注定上不去，比如纯参数型的技术规格页，那就别硬凑。接受它的判定不稳定，把它排除在主力落地页之外，用别的页面去承接这批查询，这是一个正当的选择，不是妥协。

## 引擎自己怎么判，不是你能优化的对象

你无法改变识别模型，也拿不到它的判定日志，能做的只有让页面上的证据更充分。

所以目标要定成让判对的概率更高，而不是让某个引擎给出某个具体结论。

把目标定错的团队会去做各种试探性的改动，结果不可复现，也没法沉淀成规范。

可复现的只有一件事：本地语言字符占比上去了，判对的概率就上去了。

这条因果关系足够简单，也足够稳，值得写进模板开发的验收标准里。

最后补一句关于预期管理的话：这套改动的效果不会立刻体现在流量上，它先体现在判定结果和置信度上，再传导到收录、展现和引用。中间隔着几周甚至更久。所以验收标准要定在你能直接测到的那两个数字上，而不是定在流量上，否则很容易在效果显现之前就被判定为无效而砍掉。

## 常见问题解答

## 我的站只做一门小语种，也会被判错吗？

会，而且比多语言站更容易被忽略。多语言站至少有版本之间的对照，一旦某个版本表现异常，还有个参照物；单语言站没有参照，判错之后所有页面一起偏，看上去反而像是市场本身不行。单语言站的另一个风险是模板往往是从英文站直接改过来的，骨架文案留了一堆英文，而这些文案在每一页上都出现。先做的事很简单：找一个正文最少的页面，把它的纯文本拿去检测一次，几分钟就知道有没有问题。

## 页面头部的语言属性到底还有没有用？

有用，而且必须写对，只是别指望它单独就能定调。它的作用是在证据充分的时候提供确认，在证据不充分的时候提供一个默认值，以及给浏览器、屏幕阅读器、断词规则、拼写检查这些渲染侧的功能当开关，MDN关于lang全局属性的说明 (https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/lang)把这几项影响列得很全。真正没用的是写错的属性值，比如把地区码写在语言码的位置、用了废弃标签、或者整站硬编码成同一个值。写对它的成本几乎为零，收益是让另一条链路至少有机会站在你这边。

## 用脚本渲染的商品列表，判定拿的是哪一版文本？

取决于抓取方执行不执行脚本，而不同抓取方的答案不一样。主流搜索引擎会渲染，但渲染有排队和预算；很多轻量抓取工具、部分内容聚合方、一部分模型训练用的抓取器不渲染。所以稳妥的假设是同时存在两个版本的文本，一个有商品名，一个没有。判断办法是直接请求页面拿原始文档，看里面有多少本地语言的字。如果原始文档几乎是空的，那就说明有一批抓取方看到的是一个没有语言证据的骨架。

## 本地语言字符占比多少才算安全？

没有一个官方阈值，但从实测经验看，超过六成基本稳定，五成左右开始出现波动，低于三成的页面判错概率相当高。更实用的做法不是盯绝对值，而是盯同站内的相对值：把长文页面的占比当成对照组，看短页面差多少。差距在十几个百分点以内通常没事，差到三十个百分点以上就该动手。用相对值的好处是它自动排除了品牌名、型号这类每个站都不一样的干扰。

## 被判成了高资源语言，会不会反而多拿一点流量？

基本不会，而且这个想法很危险。被判成另一门语言，意味着你的页面进了一个自己完全不占优势的池子，跟母语内容同台竞争，排名机会极低；同时它在真正属于你的那个池子里缺席了。展现数据上可能看起来有一点点起色，但转化会告诉你真相：那批人根本看不懂你的页面。这跟做一个自己不擅长的市场是同一类错误，只不过这次不是你主动选的。

## 加一段本地文字算不算为了SEO凑字数？

看你加的是什么。加一段真正回答用户问题的说明文字，是内容改进，顺便解决了证据密度；把关键词换着花样重复十遍，那是凑字数，既不解决判定问题也伤体验。判断标准很朴素：把这段文字单独拿给一个从没见过这页的人看，他能不能获得新信息。能，就留下；不能，就删掉重写。分类页最容易写出真信息的角度是选购判断、尺寸对照和本地使用场景。

## 这件事该由谁负责，前端还是内容？

责任要拆成两半。声明值的正确性、原始文档里有没有文本、模板骨架是否本地化，这三样归前端和模板负责，属于一次性的工程改动；补充说明文字、字段名写全、本地格式的数字与单位，这些归内容和运营负责，属于持续性的工作。麻烦的是这两半必须一起做才有效果，只做一半通常看不出变化，所以最好一次排期把两边都放进去，别拆成两个季度。

## 权威参考资料



## 那句德语翻得一个错都挑不出来，只是做这件事的那个名字不见了

- URL：https://zhangwenbao.com/minor-language-passive-voice-agent-loss.html
- 分类：小语种SEO
- 发布：2024-04-19  |  更新：2026-07-28
- 摘要：被动结构允许施事者整个不出现，而句子在语法上仍然完整，于是品牌名、工坊名、产地这些最贵的名词在译文里静静少了一个。讲清语态为什么不在任何一张检查表上、芬兰语的无人称形为什么连补都补不回来，以及哪些句子必须保住主体、哪些可以放过。
- 关键词：出海SEO,多语言SEO,内容本地化,小语种SEO

> **TLDR**：摘要：翻译过程中语态会自己改变，主动句变成被动句，而被动句可以合法地不说出谁做的。于是品牌名、工坊名、产地这些最该被记住的名词，在译文里静悄悄地少了一个。句子仍然完全正确，任何拼写、术语、标签检查都不会响。本文给出一套只数名词不评语感的排查办法，以及哪些句子必须保住施事者。

> 摘要：翻译过程中语态会自己改变，主动句变成被动句，而被动句可以合法地不说出谁做的。于是品牌名、工坊名、产地这些最该被记住的名词，在译文里静悄悄地少了一个。句子仍然完全正确，任何拼写、术语、标签检查都不会响。本文给出一套只数名词不评语感的排查办法，以及哪些句子必须保住施事者。

## 为什么译文里那个品牌名会凭空消失？

## 从一段芬兰语的工艺描述说起

那是一家做芬兰市场的珠宝配饰站，主打手工银饰。

商品页上有一段讲工艺的话，是全站最用心写的一段。

英文原句是主动句，主语就是那个自有工坊的名字。

芬兰语译文读起来非常地道，母语审校一次通过。

但那句话里，工坊的名字一个字都没有出现。

译者把主动句换成了芬兰语里常用的无人称说法，意思是“这些银饰是手工打磨的”。这句话完全正确、完全自然，也完全没有说是谁打磨的。整段描述里，那个本该反复出现的名字出现次数从三次掉到了零次。

而这一段，正是全站唯一一处解释品牌工艺来源的文字。

后来把这一段的三个语言版本并排数了一遍，英文版工坊名出现三次，德文版一次，芬兰文版零次。三个版本的可读性都很好，三个译者也都是母语的人，差别完全来自各自语言里这类文本的默认写法。这个结果第一次让团队意识到，问题不在某一个人身上，而在一条没人管的默认路径上。

## 问题不是语气也不是语体

先把这件事跟另一类问题分开。

语气和语体讲的是这段话听起来客气不客气、正式不正式。

那一层的判断标准是感受，不同的人可以有不同意见。

本篇讲的东西不需要任何感受判断。

它只问一句：源文里的那个名词，译文里还在不在。

日语敬语层级那篇 (https://zhangwenbao.com/japanese-seo-keigo-politeness-levels-conversion-ranking.html)处理的是语体换档会不会改写实词，那是一个关于措辞的问题。本篇处理的是一个可以数出来的结果：句子里少了一个名词，而这个名词是有名字的。可数和不可数，是这两类问题最大的区别。

可数意味着可以做成一个指标，不可数只能靠人吵架。

把两类问题分开还有一个实际好处：它们该交给不同的人。语气语体的判断只有母语的人能做，而且经常需要来回讨论；名词在不在的判断谁都能做，甚至可以完全交给脚本。混在一起处理，结果是本来能自动化的那一半也被拖进了讨论环节，成本白白翻倍。

## 这类丢失为什么特别值钱

丢的那个名词，往往不是随便一个词。

主语位置上站着的，通常是品牌、工坊、产地、材料来源。

这些恰好是内容里最难替代、最值得被记住的部分。

而句子里其余的成分，多数是通用描述。

换句话说，被动化删掉的正是这段话里唯一的专有信息。

这里有个不太直观的因果：被动化删掉的从来不是随机成分，它删的一定是施事者，而施事者位置天生偏向专有名词。一段描述里如果只有一个词是别人抄不走的，那个词多半就站在主语位置上，也就是被动化会删掉的那个位置上。

这一点还可以反过来用：想知道一段文字里哪个词最值钱，看看被动化之后哪个词会消失就行。这个小测试比任何关键词工具都直接，因为它测的不是搜索量，而是这段文字里有没有一个别人替代不了的成分。测下来发现没有任何词会消失的段落，本身就说明这段话写得太通用了。

## 被动语态到底删掉了什么？

## 被动是唯一一种可以合法少一个成分的结构

句子里的成分不能随便删，删了就不成句。

宾语不能凭空去掉，状语去掉了意思会变。

被动结构是个例外，它允许施事者整个不出现。

不出现之后，句子在语法上仍然完整。

没有任何一条语法规则被违反。

通用依存标注体系里的语态特征 (https://universaldependencies.org/u/feat/Voice.html)把主动、被动和几种中间形态分开定义，从标注的角度看得很清楚：语态一变，句子的核心论元关系跟着重排，原来的主语要么降级成一个可选的旁格成分，要么直接不出现。

可选这两个字，是整件事的关键。

值得补一句的是，这种合法性不是某一门语言的特例，而是被动这个结构在跨语言上的普遍特征。正因为普遍，它才特别危险：你没法通过换一门语言来规避，只能通过在每一门语言里各自盯住那个位置来规避。凡是普遍存在的机制，都不存在挑一门语言绕过去的选项。

## 降级和消失是两回事

被动化之后，施事者有两种命运。

一种是降级：还在句子里，但换了一个位置和一个介词。

英语里的介词短语、德语里的相应写法，都属于这一类。

另一种是消失：整个成分不出现，句子照样成立。

多数译者在多数情况下选的是后一种，因为更自然。

旁格成分的标注定义 (https://universaldependencies.org/u/dep/obl.html)里专门给施事者留了一个子类型，这从侧面说明了它的地位：它不是句子的必需成分，而是一个可以挂上去也可以不挂的补充。凡是标注体系里带“可选”标记的成分，在真实文本里的缺席率都远高于你的想象。

降级还能救，消失就只能重写。

实际排查中这两种命运的比例很悬殊。抽样看下来，被动句里带施事者的比例通常只有一两成，其余全是不带的。这跟写作建议里的印象差得很远，因为写作建议讨论的是该不该带，而真实文本反映的是人们默认带不带。默认值永远比建议更能决定最终结果。

判断某句话属于哪一种，不必懂那门语言：把译文丢进翻译工具倒译回英语，看看倒译结果里还有没有那个名字。有就是降级，没有就是消失。倒译不能用来评估质量，但用来查某个成分在不在是够用的。

## 主语位置在检索里的分量

为什么非得盯着这一个位置。

因为主语位置是一句话里最容易被机器当成主体的位置。

做实体抽取的系统，第一件事就是找谁做了什么。

名词性主语的标注定义 (https://universaldependencies.org/u/dep/nsubj.html)说明了这个位置在依存结构里的地位，它直接挂在谓语下面。

这个位置空着，整句话就没有主体可抽。

更实际的一层是：一段话里如果品牌名一次都没出现，那么这段话在任何按实体聚合的系统里都不会被算到这个品牌头上。内容还在，功劳不在。

还有一个细节值得知道：即使句子改成了被动、施事者降级成一个旁格成分，它在抽取结果里的权重也会明显低于原来在主语位置的时候。也就是说降级不是无损的，只是比消失好。要拿回全部权重，唯一的办法还是让那个名词回到主语位置上去。

## 共现被切断带来的连锁反应

还有一层损失更隐蔽。

品牌名和工艺词原本在同一句话里共同出现。

共现关系是机器判断“这个品牌跟这件事有关”的主要依据。

被动化把主语删掉之后，这对共现就断了。

工艺词还在，品牌名不在，两者不再有关联。

削短词那篇 (https://zhangwenbao.com/minor-language-clipped-short-forms-keyword-coverage.html)里提过一句，正文首段是最安全的共现位置。这条在这里要补一个前提：共现的前提是两个词真的在同一个句子里出现过，而被动化恰好会让其中一个不出现。位置选对了没用，成分先得在。

共现这件事还有一个跨段落的补救办法：如果某一句实在改不成主动，就在相邻的句子里让品牌名单独出现一次。虽然不如同句共现强，但总比整段没有强。要注意的是这个补救要写在同一段里，跨段落之后关联强度会再降一档，效果很有限。

## 语态为什么不在任何一张检查表上？

## 因为改完之后句子还是对的

这是整件事最根本的原因。

拼写错了，拼写检查会报。

术语用错了，术语库比对会报。

标签数量不对，标记校验会报。

语态改了，什么都不会报，因为没有任何东西错了。

把这句话展开就是一条很硬的判据：所有质量关卡检查的都是“对不对”，而语态漂移不产生任何错误。它产生的是一个信息量的差额，而信息量不在任何一张检查表的字段里。这跟标记错位那一类问题是同源的，只不过那一类至少还留下了一个位置可以比对。

这条判据可以拿去检查任何一套质量流程：把流程里所有的检查项列出来，逐条问它在检查什么错误。如果全部检查项问的都是有没有错，那这套流程对信息缺失是完全没有防御的。信息缺失和错误是两类问题，需要两套判据，而多数团队只准备了一套。

## 母语审校也发现不了

有人会指望母语审校这道关。

母语审校拿到的通常只有译文，没有源文。

他要判断的是这句话在这门语言里读着顺不顺。

而那句被动句读着非常顺，甚至比主动句更地道。

他没有任何理由改它。

母语审校验收清单那篇 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)里把验收拆成了几个维度，语言正确性只是其中一个。这一类问题落在维度之间：它既不是语言正确性问题，也不是术语问题，而是一个信息保全问题，而多数验收单上根本没有这个维度。

这里还藏着一个容易误判责任的地方：等问题被发现时，第一反应往往是母语审校没做好。实际上他做的正是他被要求做的事，而且做得没问题。要改的是任务定义不是执行人，把源文一并给他、并明确要求他核对某几个名词，这件事才轮得到他负责。

## 报表上看到的只是曲线平了

后果在数据上也很难归因。

品牌词的曝光少一点，实体相关的表现弱一点。

这些变化都在正常波动范围内。

没有任何一个指标会突然跳一下。

于是这件事可以持续好几年而不被察觉。

十语模板重复内容那篇 (https://zhangwenbao.com/multilingual-template-ten-languages-duplicate-content-risk.html)提过一个观测层错位的套路：换一层去看，结论相反。这里同样适用——从流量层看不出任何异常，从句子层数一下名词出现次数，问题一目了然。换层的关键是找到一个能被数出来的量，而不是找一个更好的报表。

还有一个原因让归因更困难：这类损失是从上线第一天就存在的，没有一个前后对比的基线。所有需要靠对比才能发现的问题，只要从一开始就存在，就基本上不可能被数据发现。要发现它们，只能靠有人主动去数一个绝对量，而不是等某条曲线掉下来。

## 自动打分也给不出信号

还有一道关卡值得单独说，因为很多团队指望它。

现在不少流程里会用模型给译文打一个质量分。

打分看的是流畅度、忠实度、语法合规这几项。

被动化之后的句子在这三项上表现都很好。

忠实度那一项理论上该扣分，实际上几乎不会。

原因在于忠实度的判断多数基于句子整体的语义相似度，而删掉一个专有名词对整句的语义向量影响很小——那句话讲的还是同一件事，只是没说是谁做的。凡是靠整体相似度衡量的指标，都对单个专有名词的缺失不敏感，而专有名词恰好是内容里最贵的那部分。

所以这道关卡跟前面几道一样，是绿的。

这一层还有个连带风险：打分高会让这批内容被当成优质样本，进而被用来做后续的记忆库和模型微调。于是一个信息缺失的写法被固化成了标准写法，往后每一批新内容都会照着它来。质量分在这里起的是放大作用，而不是过滤作用。

## 哪几门语言最容易把主动变成被动？

## 德语的说明书体是重灾区

先说最典型的一门。

德语的产品说明和技术文档传统上大量使用被动。

这种写法在当地读者眼里代表专业和客观，德语语法在线资源库 (https://grammis.ids-mannheim.de/)里对这一族结构的用法说明相当完整。

译者把英语的主动句改成被动，是在往地道的方向靠。

他做的是对的，只是没人告诉他这句话里有个名字要保住。

德语构成被动的那个助动词词条 (https://www.dwds.de/wb/werden)里能看到它在各类文本中的分布，用例密度在说明性文本上明显更高。德语复合词那篇 (https://zhangwenbao.com/german-seo-compound-words-umlaut-eszett-keyword-research.html)里讲过德语自己也在减负、少用长句和名词化，被动这一项是同一个趋势里最顽固的一块。

要说明的是，这条不能推出德语内容就该少用被动。说明性文本用被动确实更符合当地读者的预期，硬改成通篇主动反而显得业余。要保的只是那几句讲来源的话，其余照惯例写就好。目标是保住几个名词，不是改造一门语言的文体，这个边界一开始就要划清楚。

## 芬兰语和爱沙尼亚语有专门的形态

第二类语言更彻底。

它们有一套专门的动词形态，用来表达“有人做了这件事”。

这种形态不需要任何助动词，一个词尾就够。

用起来极其顺手，所以出现频率非常高，芬兰语依存树库的统计页 (https://universaldependencies.org/treebanks/fi_tdt/index.html)上能直接看到这类形态在真实语料里占多大比重。

芬兰语官方语言指南里关于这种形态的说明 (https://www.kielitoimistonohjepankki.fi/haku/passiivi)把它的构成和用法讲得很细。

关键在于，这种形态跟英语的被动不是同一个东西。英语的被动至少还给施事者留了一个位置，芬兰语这一套连位置都没有。这一点下面单独讲。

还有一个技术上的后果：这种一体化的形态会让自动检测更难做。被动如果靠助动词构成，正则就能大致筛出来；靠词尾构成的话，得先做形态分析才知道。这也是为什么后面给出的排查办法绕开了语态判断，改成直接数名词——那条路在这类语言上根本走不通。

还有一件事要提醒：这类形态在语法书里的叫法跟英语的被动是同一个词，于是沟通时特别容易鸡同鸭讲。跟译者聊之前最好先确认一下双方说的是不是同一个东西，否则你以为在讨论要不要改语态，他以为你在质疑他的用词。

## 日语的省略传统又是另一回事

第三类是主语本来就常常省略的语言。

日语的句子在上下文清楚的时候可以整句不出现主语。

这不是被动，是省略，但结果一样。

译者按母语习惯省掉主语，句子完全自然。

而商品页上的每一段话，对机器来说都缺少上下文。

日语三套文字那篇 (https://zhangwenbao.com/japanese-seo-hiragana-katakana-kanji-keyword-notation.html)讲的是字符层的选择，这里是句法层的另一个坑。省略和被动在语法上完全是两回事，落到“那个名词还在不在”这个结果上，它们是同一件事，所以排查的时候可以合在一起处理。

这类语言还有个额外的复杂度：省略是否合适取决于上下文距离，而商品页上的段落经常被单独摘出来展示，比如出现在列表页的摘要里或者被聚合到别处。原文里那个足够近的上下文，在展示时可能根本不在场。写的时候要按最坏情况假设，即这一段会被单独读到。

## 斯拉夫语族的反身形式也算一类

第四类要提一句，因为它最容易被漏掉。

俄语、波兰语一类语言可以用反身形式表达类似的意思。

这种写法在形态上不是标准被动，工具未必标成被动。

但它同样把施事者从句子里挤了出去。

排查工具如果只按被动标记筛，会漏掉这一整类，依存分析器的接口文档 (https://spacy.io/api/dependencyparser)里也说明了标注结果依赖各语言各自的模型质量。

处理办法是把判断标准从“是不是被动”换成“主语位置上有没有一个专有名词”。前一个标准依赖形态标注，后一个标准只依赖有没有那个词，跨语言更稳。

这一类还容易被漏掉的原因是它长得像主动句：动词后面挂一个反身成分，形式上仍然是主动形态。只有读懂意思才知道施事者不见了。所以对这类语言，任何基于形态标注的自动筛选都不可靠，只能靠数名词那条路，这一点跟粘着语的结论殊途同归。

## 芬兰语的无人称形为什么连补都补不回来？

## 它在语法上就不带施事者位置

这一节讲的是本篇最硬的一处差别。

英语的被动句可以在后面挂一个介词短语说明是谁做的。

德语也可以，写法固定，译者随手就能加。

芬兰语那套形态不行，它没有这个挂载点。

硬要加一个施事者，句子就不成立了。

所以这里的差别不是“省略了”，而是不可表达。前者是一个选择，后者是一个约束。面对省略，你可以要求译者补回来；面对不可表达，要求补回来等于要求他写一个病句。

这个差别在跟译者沟通时特别重要。如果你按英语的经验说“把动作的执行者加回去”，芬兰语译者会告诉你做不到，而你多半会以为他在推脱。实际上他说的是事实。跨语言协作里的多数误会，都源于一方把自己语言的可能性当成了普遍的可能性。

这条差别还提示了一个更一般的做法：给任何一门陌生语言写规范之前，先问一句这条要求在那门语言里能不能表达。花十分钟问一个母语的人，能省掉后面几轮无效的返工。规范写得再细，也抵不过一个在目标语言里根本不成立的前提。

## 唯一的解法是换句式

既然补不回来，就只能换一个句式。

把整句改写成主动句，让工坊名字回到主语位置。

芬兰语当然有主动句，用起来也完全自然。

只是译者默认不会选它，因为无人称形更符合这类文本的惯例。

所以这不是能力问题，是默认值问题。

芬兰语十五个格那篇 (https://zhangwenbao.com/finnish-seo-fifteen-cases-consonant-gradation-keyword.html)讲的是名词形态的展开，这里是动词那一侧的另一条约束。两者合起来说明一件事：这门语言的很多东西是长在词形里的，而词形一变，句子的成分构造跟着变，不像分析型语言那样可以单独挪动一个词。

换句式还有一个副作用要提前想到：主动句通常比无人称句长，而且句子的重心会前移。如果这段文字有字数限制，或者版面上留的行数是按原来的长度排的，改完之后可能要一起调版面。这类连带工作量不大，但不提前说，前端会觉得内容团队在临时加需求。

## 给译者的指令要写成结果不是写成手法

知道了这一点，指令的写法就清楚了。

不要写“请不要使用被动语态”。

这条指令在芬兰语上会让译者无所适从，因为那不是被动。

要写“这一句里工坊的名字必须出现”。

结果确定，手法交给译者，他自然会选一个合适的句式。

这条经验可以推广：凡是跨语言的写作要求，都要写成可以在目标语言里被验证的结果，不要写成源语言里的某种手法。手法是语言相关的，结果不是。这跟标记那一类问题的解法思路是一致的，只不过那边是把版面要求换成句法要求，这边是把语法要求换成成分要求。

这条经验还有一个更省事的用法：把它写进给译者的每一批任务说明里，而不是写进一份没人翻的总规范。任务说明是译者真正会读的东西，一句话就能带过。规范文档的问题从来不是写得不对，而是它跟具体任务之间隔了太远的距离。

## 施事者消失对检索和引用有什么影响？

## 品牌词密度掉得比想象中多

先看最直接的一层。

一段三百字的工艺描述，主动句写法里品牌名会出现两到三次。

全部被动化之后，这个数字通常是零。

整个商品页上，品牌名可能只剩下页头和页脚。

而页头页脚是模板，所有页面都一样。

于是这个页面上关于品牌的全部独特信号都没了，剩下的只是模板噪声。这一点在多语言站上特别值得警惕，因为英文版看起来完全正常，你不会想到去查别的语言版本。

这个数字最好按段落类型分开统计，而不是按整页平均。整页平均会被页头页脚和导航里的品牌名拉高，看着还不错。只统计正文描述段落，数字才真实。凡是模板里也会出现的元素，统计时都要先剔掉，否则你量到的是模板不是内容。

还有一个统计口径的选择要提前定：是数出现次数还是数出现过的段落数。次数会被某一段里的重复拉高，段落数更能反映覆盖面。做诊断的时候用段落数，做优化前后对比的时候两个都记，因为改写往往同时提高这两个数字而幅度不同。

## 被引用时更容易被改写成通用说法

第二层影响在被摘引的场景里。

一段没有主语的描述，被摘出来之后仍然没有主语。

下游系统要生成答案时，只能自己补一个泛称。

补出来的多半是“这类产品”或者干脆不提来源。

你的内容被用了，但没有被归属。

问答型长尾内容那篇 (https://zhangwenbao.com/minor-language-qa-long-tail-content-value-ai-era.html)讨论过内容在被摘引时的价值分配，这一层可以补一条更具体的：能不能被归属，取决于那段文字自身有没有携带主体，而不取决于这段文字写得好不好。写得越好越通用，被拿走得越干净。

还有一个可以自己动手验证的办法：把那段没有主语的描述单独复制出来，假装自己是第一次读到它，看看能不能判断出这是谁家的产品。判断不出来，那么任何一个下游系统也判断不出来。这个测试不需要工具，也不需要懂那门语言，只要盖住页面其余部分就行。

这一层还有个容易被忽略的场景：站内的推荐位和列表页摘要通常直接截取描述的前几十个字。如果主语在原句里靠后，或者干脆不存在，摘要里就更不可能有品牌名。写描述段落时把主体尽量放在开头，是一个几乎零成本的保险。

## 非英语市场的这一层更薄

第三层是市场差异。

英语内容多，一个品牌的信息可以从很多来源拼出来。

小语种市场上，关于你的信息可能只有你自己这一份。

这一份里如果没有主体，就真的没有第二份可以补。

非英语语言的生成式结果覆盖那篇 (https://zhangwenbao.com/sge-non-english-language-coverage-early-observation.html)里记过一个早期观察：小语种的来源池本来就浅。

来源池浅的直接后果是每一份来源的权重都更高，也就意味着一份来源里的信息缺失更难被别的来源补上。信息冗余度低的市场，单点失误的代价成倍放大，这条在选择先修哪门语言时很有用。

这一层还有一个不太好听但很现实的推论：越是刚进入的小市场，内容里的信息缺失越致命，而这些市场的内容往往又是预算最紧、流程最简的。资源分配上的直觉是先保大市场，而按风险算，恰恰是小市场的每一段内容更经不起丢东西。

## 机器翻译和人工翻译谁更容易改语态？

## 人工翻译改得更多也更彻底

这个结论跟直觉相反，值得说清楚。

机器翻译倾向于贴着源文的结构走。

源文是主动句，输出多半也是主动句。

人工译者反而会主动调整，让句子更符合目标语言的惯例。

调整的方向，往往正是把主动改成被动或者无人称。有意思的是，英语侧的简明写作指南 (https://www.plainlanguage.gov/guidelines/conversational/use-active-voice/)反而一直在劝人多用主动语态，两边的默认方向正好相反。

机器翻译直接发布那篇 (https://zhangwenbao.com/machine-translation-direct-publish-search-risk-quality-line.html)算的是质量下限的账，这里出现了一个少见的反例：在这一项上，机器翻译的保守恰好保住了信息，而人工翻译的地道恰好丢掉了信息。这不是说机翻更好，只是说明质量高低和信息保全是两个维度。

这个反例还提醒了另一件事：不要用单一维度去判断一条链路的好坏。同一条链路在流畅度上得分低，在信息保全上可能得分高。真正该做的是把要衡量的东西列全，再看每条链路各自的强项在哪儿，然后用流程去补短板，而不是简单地选一条更好的链路。

## 但机器翻译在长句上照样会翻车

话说回来，机器翻译也不是安全的。

句子一长，从句一多，结构重排的概率就上来了。

某些语言对上，模型学到的默认就是被动化。

技术文档语料训练出来的模型尤其明显。

所以两条路都得查，只是查的重点不一样。

人工译文要查的是那些译得特别漂亮的段落，机器译文要查的是最长的那些句子。这两个筛选条件都不需要读懂内容，一个按人工润色标记筛，一个按句长筛。

句长这个筛选条件还可以再精确一点：不是看字符数，而是看逗号和从句连接词的数量。一句话里超过两个从句连接词，结构重排的概率就明显上来。这个统计一条正则就能做，而且对目标语言的了解要求为零，适合放在交付后的自动检查里。

还有一类句子要单独盯：带有并列结构的长句。并列会让模型在重排时把几个动词合并处理，主语更容易在合并中被吞掉。写作阶段避免在讲来源的句子里塞并列，比事后排查划算得多，这属于一次性投入。

## 后编辑环节是最好的插入点

第三个观察是关于流程的。

如果链路上有后编辑这一步，这件事最适合放在那儿。

做后编辑的人手上同时有源文和译文。

他也有权限改句子，不像审校那样只能提意见。

需要他做的只是多看一眼主语位置。

把要求写进后编辑的作业指引里，成本几乎为零。强调标记漂移那篇 (https://zhangwenbao.com/minor-language-emphasis-markup-anchor-drift.html)里讲的验收项措辞规则在这里同样适用：写成“确认工坊名称在译文中出现”，比写成“注意语态”有效得多，因为前者可以在不理解全句的情况下核验。

如果链路上没有后编辑这一环，还有一个位置可以插：内容入库之前的那一步。多数站在把译文写进数据库之前有一次人工确认，哪怕只是复制粘贴，也是一次有人经手的机会。把检查清单贴在那一步，比新增一个环节现实得多。换个说法，要管住的是那个名词在不在，而不是句子用了哪一种语法结构。

## 扫一遍译文找出丢了主语的句子

## 第一步：先列出必须保住的名词

排查从一份清单开始，这份清单很短。

把品牌名、工坊名、产地名、自有材料名列出来。

加上各语言的变体写法，通常也就二三十条。

这份清单其实早就存在，在术语库里。看的时候顺便记下缺失集中在哪类段落上，这个分布决定了后面要不要跑全站扫描。

只是术语库管的是它怎么译，不管它出没出现。

这一步的产出是一份纯名词表，跟语法无关。把一个语法问题转成一个词表问题，是这套排查能便宜下来的关键，因为词表匹配不需要任何语言学工具，一条正则就够。简单说，结构化数据管的是这个页面属于谁，正文共现管的是这件事跟谁有关。

这份清单还要注意收一样东西：品牌名在目标语言里的转写形式和当地惯用的简称。用户和当地媒体用的往往不是官方全称，如果清单里只有全称，统计会把那些用了简称的段落误判成缺失。把简称一起收进来，误报率会明显下降。

## 第二步：按段落统计出现次数并跟源文对比

第二步是纯统计。

把源文和译文按段落对齐，各自数清单里的词出现几次。

两边数字一样的段落，直接跳过。

源文有、译文为零的段落，全部挑出来。还有一个折中做法是把品牌名放进小标题里，既保住了共现，读起来也不会显得堆砌。

源文三次、译文一次的，也挑出来。

这一步能跑在任何语言上，因为它只做字符串计数。要注意的是屈折语里名词会变形，所以匹配时要允许词尾变化，用前缀匹配或者把变体写进清单都行。顺序上先修自有内容，再看外部数据，否则两边的问题会混在一起分不清主次。

统计的时候还要做一次归一化：全角半角、大小写、连字符的有无都可能造成漏配。稳妥的做法是把源文和译文都先做一次统一处理再比对。这一步很容易被跳过，跳过之后跑出来的清单会掺进一批假阳性，人看几十条就会开始怀疑整套办法。

统计脚本还要能处理一个常见情况：同一个段落在源文和译文里的切分不一致，译者把一段拆成了两段或者合并了两段。稳妥做法是按小标题划分区块来对齐，而不是按段落序号，这样容错高很多，也不容易产生成批的假阳性。

## 第三步：只看挑出来的那几段

第三步才需要人。

看的是前一步挑出来的段落，通常只占全部段落的一小部分。

判断标准只有一条：这一段该不该有这个名字。

有些段落本来就不该有，比如通用的尺寸说明。排完序之后先拿一门语言试一遍完整流程，把脚本和验收项都跑通，再铺到其余语言。

该有而没有的，交给后编辑改写。

那家珠宝配饰站跑完这三步，全站两千多段里挑出来一百四十段，人看了半天，最后需要改写的是三十九段。真正需要人判断的量，通常比想象中小一个数量级，前提是前两步的筛选做得够狠。

看的时候建议按段落类型排序，把讲来源和工艺的排在最前面。这类段落数量少但价值高，先看完这一批，收益就已经拿到大半。剩下的可以慢慢看，甚至可以暂时不看。任何一份待办清单，排序方式对最终产出的影响都大于清单本身的完整度。

## 哪些句子必须保住施事者，哪些可以放过？

## 讲来源和工艺的必须保

不是所有句子都值得改，分清楚能省很多力气。

第一类必须保的是讲来源的句子。

谁做的、哪里产的、用谁家的材料，这些都要有主体。

这类句子通常也是全站最有价值的内容。

它们的数量不多，一个商品页上一般不超过三句。

判断办法很简单：这句话如果换成竞品也一样成立，那它就不需要主体；只有当它换个主体就不成立时，主体才是必需的。这条判据一句话就能教会执行的人。

这一类段落还有个特点值得利用：它们通常是全站复用率最高的内容，同一段工艺描述会出现在几十个商品页上。改一次，收益乘以商品数。所以哪怕单看一个页面觉得不值当，把复用倍数算进去之后，这几句话的优先级会一下子排到最前面。

改写的时候还有一条实用建议：不要逐句改，按段落重写。逐句改容易写出一堆结构雷同的主动句，读起来很生硬。整段重写反而更快，因为译者可以自己安排主语出现在哪一句上，只要保证整段里出现过就行。

## 讲功能和参数的可以放过

第二类是可以放过的。

讲产品有什么功能、参数是多少的句子，主体是产品本身。

这类句子用被动或者无人称写反而更清爽。

硬要在每句话里塞品牌名，读起来会很难受。

而且这类句子多半不承担品牌信号的作用。

颜色与属性值那篇 (https://zhangwenbao.com/minor-language-color-category-attribute-value.html)讲的是参数这一层该怎么对齐取值，跟本篇正好互补：参数那一层要的是精确和一致，工艺来源这一层要的是主体在场，两层的写作要求几乎相反。

这里还有一个容易走偏的地方：有人会想把品牌名塞进参数表的字段值里，比如在材质后面加个品牌前缀。这样做会同时污染筛选和结构化数据两处，得不偿失。参数那一层要的是干净的取值，品牌信号该由描述段落承担，两层各司其职最稳。

这一类里还有个例外要留意：如果某个功能本身是自有技术或者专利，那它就不再是通用描述，主体该回来。判断办法还是那句话，换个品牌这句话还成不成立。成立的归参数，不成立的归来源，这条判据在功能描述上同样好用。

## 讲承诺和责任的要单独看

第三类需要特别注意，因为它超出了检索范畴。

退换货、保修、质量承诺这类句子里，谁承担责任是关键信息。

被动化之后变成“可以退货”，谁受理就没说清楚。标注结果适合拿去跟译者沟通，因为它能具体指出是哪一处成分被去掉了。

这在有强制披露要求的市场上不只是表达问题。

这类句子应该由法务确认，不走普通内容流程。

处理这一类的原则跟前两类不同：前两类看的是检索收益，这一类看的是合规风险。同一个语法现象，在不同类型的内容上要用完全不同的判据去衡量，混在一起定一条统一规则，结果一定是两头都不合适。

这类句子还建议在各语言之间做一次一致性检查，看看承诺的主体和范围有没有在某个版本里变松或者变紧。语态漂移只是造成差异的原因之一，措辞选择同样会造成差异。承诺类文字的各语言版本值得单独存一份对照表，出问题时能立刻查到当时发的是什么。

## 这一项该怎么写进译审的规范里？

## 写成一条可以数的验收项

规范里加一条，措辞要能被验证。

写成“来源与工艺段落中，品牌或工坊名称至少出现一次”。

这条可以数，不需要判断语感。

不要写“避免过度使用被动语态”。

那条谁也不知道多少算过度。

微软写作规范里关于动词的一节 (https://learn.microsoft.com/en-us/style-guide/grammar/verbs)给的建议是优先使用主动语态，这类规范在英语内容上很实用，但直接搬到别的语言上要小心：它的前提是那门语言里主动句同样自然，而这个前提不是处处成立。

措辞里还要写清楚适用范围，也就是哪几类段落受这条约束。不写清楚，执行的人要么全篇都塞，要么干脆都不塞。范围写明确之后，这一条才从一个原则变成一个动作。规范里凡是没写适用范围的条目，最后基本都会被当成建议而不是要求。

这类文字还有一个特点：它在各语言之间的更新往往不同步，有的版本改过有的没改。验收的时候除了看语态，还要顺手核一下版本号或者生效日期，别让不同市场的用户看到不同代的承诺，那比语态问题严重得多。还有一点，这条要求写成禁令之后很难验收，写成必须出现的名词则一眼就能核。

## 让工具替人做前置筛选

规范之外还要配一个动作。

把前面那三步做成一个脚本，接在交付环节后面。

脚本跑完给出一份待看清单，人只看清单。

没有清单的时候，验收项会退化成走过场。

有清单的时候，它是一件具体的活。如果三个版本里只有一门语言异常，先查那门语言的默认写法，多半能找到共同原因。

这条经验在很多验收项上都成立：一条验收项能不能被真正执行，取决于有没有人替执行者把范围缩小到可以看完的程度。规范负责说清楚要什么，工具负责把要看的东西端到面前，缺一样都不行。另外被摘引时下游取的是正文那段字，结构化数据里的品牌不会被顺手带进去。

脚本的输出格式也值得花点心思：每一条给出段落原文、缺失的名词、以及源文对应段落，三样并排。让看的人不需要在两个文件之间来回切换。这类细节决定了这项检查能坚持多久，端到面前的东西越完整，它被长期执行下去的可能性越大。

措辞之外还要给一个例子。规范里附一句改写前和改写后的对照，执行的人一眼就明白要什么。纯文字的要求容易被理解成好几种意思，一个例子能把歧义压到最低，这在跨语言的协作里尤其重要。

## 把这一项交给谁

最后是分工。

这一项最适合交给后编辑或者译审，不适合交给母语审校。还有一个位置很好用，就是那段描述的第一句，主体放在开头对摘要场景特别友好。

原因前面说过，母语审校手上通常没有源文。

如果链路上没有后编辑，退而求其次交给项目经理。

项目经理不懂那门语言也没关系，因为这一步只需要数词。简单说，一个量的是外部有多少人提到你，一个量的是你自己有没有把话说完整。

数词这件事甚至不需要人做，脚本给出的数字就是结论。母语审校验收清单那篇 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)里那条分级思路在这里落到了最省的一档：能自动数的一律自动数，人只负责那些数不出来的判断。另外别忘了把这门语言的经验整理成一句话，下一门语言的规范可以直接照抄结构。

还有一种情况是外包给翻译服务商，那就把这条写进交付标准里，并且要求对方在交付时附上统计结果。让对方自己跑一遍，比你收到之后再跑省事得多，也更符合责任划分。验收标准里能量化的部分，都该尽量前移到交付方那一侧。

还有一个把工具用好的前提：脚本的误报率必须压到很低。一旦看的人连着遇到几条假阳性，他就会开始整批跳过。宁可让规则严一点、漏掉几条，也不要让清单里混进大量噪声，清单的可信度比覆盖率更值钱。

## 常见问题解答

## 要求译文里不用被动语态，是不是最简单的办法？

不是，这条要求在好几门语言上会直接失效。芬兰语那类有专门无人称形态的语言，译者根本不会认为自己用了被动；德语的说明性文本里被动是常规写法，一刀切禁用会让译文读起来很怪。更根本的问题是，这条要求限制的是手法而不是结果，译者绕过它的方式有很多种，比如改成名词化的写法，主语照样不见。正确的写法是要求某个名词必须出现，把手法留给译者自己选。真正稳的做法是把要求落在结果上，让译者自己去选那门语言里最自然的句式。

## 怎么快速判断我的站上有没有这个问题？

挑三个商品页，把讲品牌来源和工艺的那几段抽出来，源文和译文并排，各数一下品牌名出现几次。源文有而译文为零，问题就存在。这一步不需要懂那门语言，认得品牌名的字母就够。三个页面都正常也别急着下结论，换一个语言版本再抽三个，不同语言的表现差别可能很大。整个诊断二十分钟能做完，比任何报表都直接。整个诊断花不了多少时间，比等着某条曲线掉下来再去归因要快得多。把三个页面的数字并排记下来，差异模式会比单看一个页面清楚得多。

## 结构化数据里已经写了品牌，正文里少一次有关系吗？

有关系，两者的作用不一样。结构化数据告诉机器这个页面属于哪个品牌，正文里的共现告诉机器这个品牌跟这项工艺、这种材料有关。前者是归属，后者是关联，后者恰恰是内容独特价值所在。而且被摘引的时候，下游取的是正文那段文字，不会顺带把结构化数据里的品牌补进去。两处都要有，缺一处就少一层。两处都写上，成本几乎为零，缺一处就少一层，没有必要在这里省。这一层的补法也简单，把品牌名写进那段描述的第一句就够，不必每句都提。

## 每段都塞品牌名会不会显得刻意？

会，所以不要每段都塞。真正需要保住主体的只有讲来源、工艺和承诺的那几句，一个商品页上通常不超过三句。功能和参数类的句子用无人称写反而更清爽，硬塞品牌名读起来很别扭，也会被读者当成营销话术。判断标准是这句话换个主体还成不成立，不成立的才需要主体在场，成立的说明它本来就是通用描述。把握好数量之后，这几句反而会因为主体明确而读起来更有分量。实在拿不准就先只改讲来源那几句，其余保持原样，收益已经拿到大半。

## 这件事和内容里的品牌提及监测是同一回事吗？

不是同一回事，但相关。监测关心的是站外有多少地方提到了你，这里关心的是你自己写的内容里主体有没有丢。顺序上应该先把自己这一侧修好，否则监测出来的数字会一直偏低，而你会误以为是外部曝光不够。自有内容是唯一一处你能百分之百控制的地方，先把这里做扎实，再去看外部的数据才有意义。换句话说，标注用来解释原因，数名词用来发现问题，两件事不要用同一个工具做。两者的数据也别混在一张报表里，混了之后就分不清是内容问题还是曝光问题。

## 多语言站上先修哪门语言？

按两个条件排序：这门语言的无人称或被动写法有多常见，以及这个市场上关于你的信息来源有多少。前者决定问题的密度，后者决定单次损失的代价。芬兰语、爱沙尼亚语这类有专门形态的语言，加上信息来源本来就少的小市场，通常排在最前面。英语和几门大语种可以放后面，不是因为问题少，而是因为那些市场上还有别的来源可以补足信息。第一门语言的成本最高，往后每一门都会便宜很多，这也是先试点的意义。预算紧的时候先做一门语言的完整流程，跑通之后往下铺的边际成本很低。

## 用工具自动标注语态来排查行不行？

可以当辅助，但别当主判据。语态标注在不同语言上的覆盖质量差别很大，反身形式、名词化写法、主语省略这几类都可能被标成非被动，漏掉一大片。更稳的做法是直接数那几个必须出现的名词，这个办法不依赖任何语言学标注，跨语言表现一致，而且执行的人不需要理解结果。标注工具适合用来解释为什么丢了，不适合用来发现哪里丢了。省下来的时间可以花在真正需要判断的那几十段上，这才是人该做的部分。两个工具的定位不同，混用会让排查既慢又不全，分开用反而更省事。

## 权威参考资料



## 小语种的问答长尾没多少人搜，可整个语种里认真写完整回答的也没几家

- URL：https://zhangwenbao.com/minor-language-qa-long-tail-content-value-ai-era.html
- 分类：小语种SEO
- 发布：2023-12-04  |  更新：2026-07-27
- 摘要：英文长尾靠条数多取胜，这套模型换到小语种就垮了。讲清为什么要把评估从需求侧挪到供给侧、怎么用二十分钟量出一门语言的内容供给密度，以及三档供给各自对应什么动作。
- 关键词：长尾关键词,内容SEO,多语言SEO,小语种SEO

> **TLDR**：摘要：英文长尾的逻辑是单条量小但条数极多，靠数量取胜。换到小语种，词形变化把每条的量又摊薄一次，工具还测不到，条数和量同时缩水，这个模型就不成立了。但问答内容在小语种里仍然值得写，理由不在需求那一侧：这些语言的网页里，肯把一个问题从头到尾讲清楚的页面本来就没几个。

> 摘要：英文长尾的逻辑是单条量小但条数极多，靠数量取胜。换到小语种，词形变化把每条的量又摊薄一次，工具还测不到，条数和量同时缩水，这个模型就不成立了。但问答内容在小语种里仍然值得写，理由不在需求那一侧：这些语言的网页里，肯把一个问题从头到尾讲清楚的页面本来就没几个。

## 英文那套长尾算法搬到小语种，为什么会失灵？

## 长尾模型有两个没写出来的前提

英文世界讲长尾，讲的是一条曲线：头部几百个词占掉一半流量，剩下一半散在几十万个词里。

这条曲线成立要靠两个前提。第一个前提是尾部足够长，也就是不同写法的数量足够多。

第二个前提是每一种写法都有人搜，哪怕一个月只有三次。三次乘以几十万，仍然是个可观的数字。

这两个前提在英文里都成立，所以长尾策略在英文站上是个稳赚的买卖。

换到一门使用者只有八百万的语言，第二个前提先垮。一个月三次这种量级，在小盘子里直接变成零。

但真正致命的是第一个前提也会垮，而且垮的方式跟大多数人预期的相反。

直觉上会觉得语言越小，写法应该越集中，尾巴应该更短。实际情况更微妙：写法的种类不但没少，反而因为词形变化多出好几倍，可是每一种写法分到的搜索次数被切得更碎，碎到统计工具直接把它记成零。尾巴变长了，但整条尾巴的高度被压到了地面以下，这跟尾巴变短是两回事，处理办法也完全不同。

## 词形变化把每条的量又摊薄一次

拿一个具体的例子说。园艺工具里有个常见品类，中文叫修枝剪。

在英语里，用户搜的写法基本就是单复数两种，再加一两个同义说法。

在芬兰语这种有十五个格的语言里 (https://zhangwenbao.com/finnish-seo-fifteen-cases-consonant-gradation-keyword.html)，同一个名词能变出十几种形态，而且词干本身还会跟着变。

用户在搜索框里打的是哪一种形态，取决于他脑子里那句话的语法结构。

于是一个在英语里量级是一千的词，在这门语言里可能被切成十四份，每份七十。

七十这个数字在多数工具的显示门槛之下，于是它们统一显示为零或者没有数据。

工具返回的那个零是数据缺口不是需求缺口 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)，这条老结论在长尾这件事上表现得最刺眼：越是长尾，被摊薄得越厉害，被记成零的概率越高。也就是说工具的失明区域，跟你最想开发的区域，几乎完全重合。

词干还原本来是用来对付这件事的。公开的词干算法把一门语言的变形规则写成了可执行的步骤 (https://snowballstem.org/algorithms/spanish/stemmer.html)，把十几种形态归回一个词根。问题是关键词工具的量是按具体形态统计的，归并发生在你这一侧，工具那一侧的零早就已经报出来了。

## 工具的零不等于需求的零

这里要分清两种零。第一种是真的没人搜，第二种是搜的人数低于工具的统计精度。

两种零在界面上长得一模一样，都是一个横杠或者一个零。

区分它们的办法不在工具里，在你自己的日志里。站内搜索框的记录、客服的聊天记录、评论区的提问，都是一手材料。

保哥做园艺工具那个项目时，让团队把一年的客服对话导出来做词频，结果拉出三百多条问句，其中八成在关键词工具里查不到任何数据。

这三百条不是凭空想出来的，是真实用户一个字一个字打给客服看的。

所以工具说没有需求的时候，正确的反应不是相信，也不是不信，而是去找第二个数据源来交叉验证。

交叉验证还有一层意义：客服记录里的问法是最口语的，跟用户在搜索框里的打法高度接近，比正式的产品文案更接近真实查询。很多团队做小语种关键词表的时候，翻遍了竞品页面却从来没打开过自己的客服后台，这份材料就躺在公司内部，一分钱不要。

## 条数少了之后，整个模型的经济性就变了

假设你在英语里做长尾，投入一千篇内容，每篇每月带来十次点击。

换到一门小语种，同样一千篇，每篇每月可能只有一次点击。

如果内容的生产成本是一样的，这笔账立刻变得不划算。

而小语种的生产成本通常还更高，因为要找母语写手，或者要过一轮审校。

成本更高、单产更低，两头一挤，纯按流量算账的话结论就是不做。

所以很多团队做到这一步就停了，这个决策在自己的算法框架里是自洽的。

但这个框架本身有个盲点：它把内容当成一个只有流量产出的东西。一旦你把被引用、被复制、被当成参考答案这些也算成产出，账就完全不一样了，而这些产出恰恰跟你写得好不好、别人写得多不多有关，跟搜索量的绝对值关系不大。

把这笔账再拆一层会更清楚。英文市场对长尾的标准定义 (https://backlinko.com/hub/seo/long-tail-keywords)里，判断一个词属不属于长尾靠的是搜索量的绝对值。这个定义在小语种里直接失效，因为整门语言的搜索量都低于那个阈值，照它划的话所有词都是长尾，一个能用的分类都得不到。

## 换个方向问：这门语言里有多少人在认真写回答？

## 把问题从需求侧挪到供给侧

前面那笔账算的是需求：有多少人在搜。现在换一个问法，算一算供给：有多少人在写。

这个切换看着简单，结论会反过来。因为需求和供给在小语种里都很小，但缩水的比例完全不同。

需求侧缩水，是按使用人口的比例缩的。八百万人口的语言，需求大约是英语的百分之一。

供给侧缩水的比例要夸张得多。网页内容的语言份额统计 (https://w3techs.com/technologies/overview/content_language)里，排在十名开外的语言份额已经掉到千分之几。

而且网页数量还不等于回答数量。小语种的网页里，商品页、目录页、新闻页占了绝大多数。

把一个问题从头到尾讲清楚的页面，在这些语言里稀少到可以手工数完。

这就是本文的核心：需求侧按人口比例缩，供给侧按更陡的比例缩，两条线之间张开了一个口子。你要评估的不是这门语言的搜索量够不够养活一批内容，而是这个口子有多宽。口子越宽，同样一篇内容能占到的相对位置就越靠前。

这个切换还有一个附带效果：它把评估的主动权拿了回来。需求侧的数字要靠外部工具，工具说没有你就没辙；供给侧的数字自己就能测，打开搜索结果数一遍即可，不依赖任何人的数据源。对一个连关键词工具都覆盖不到的语言来说，能自己测出来的指标本身就是稀缺品。

## 供给侧稀缺度怎么量

量法不用复杂，二十分钟能做完。挑十条你的品类里最典型的问句。

每一条在目标语言的搜索结果里看前二十条，数一下有几条是在正面回答这个问题的。

正面回答的定义要卡死：有一段完整的文字直接说明结论，而不是一个商品列表或者一句宣传语。

十条查询乘以二十条结果是两百格，数出来的比例就是这门语言这个品类的供给密度。

英语里做同样的动作，这个比例通常在四成以上。小语种里能到一成就算高的。

我在几门欧洲小语种上做过这件事，最低的一门只有百分之三，两百格里六格。

这个数字要按品类分别测，不能一门语言测一次就套用到全站。同一门语言里，消费电子的供给密度可能不低，而园艺、家居维修这些品类几乎空白，因为写这些内容的人不在互联网内容产业里。供给密度是语言和品类的交叉属性，不是语言的属性。

## 稀缺度和搜索量是两条独立的轴

把这两个指标画成一个坐标系，横轴是搜索量，纵轴是供给稀缺度。

右上角是量大且没人写，这种格子基本不存在，存在也早被人占了。

右下角是量大但写的人也多，这是英语市场大部分品类的位置，竞争激烈。

左上角是量小但几乎没人写，这正是小语种问答内容的典型位置。

左下角是量小写的人也不少，这种组合意味着别人比你更懂这个市场，该退。

四个格子里，只有左上角适合用低成本的方式持续投入，而它恰好是纯按搜索量排序时最先被砍掉的那一格。

这个坐标系还有一个用法：把它跟生成式搜索的语种覆盖顺序 (https://zhangwenbao.com/sge-non-english-language-coverage-early-observation.html)叠起来看。已经被覆盖的语言，左上角的价值兑现得更快；还没被覆盖的语言，左上角的内容会先以常规形式积累，等覆盖过来再一次性兑现。两种情况都不构成不做的理由，只是回报时间不同。

## 富结果被砍掉之后，写问答的理由还剩什么？

## 那两次削减动了什么

今年八月和九月，搜索结果页上两类富结果被大幅削减。

八月那次动的是问答型标注的展示范围，从所有站点收窄到政府和医疗类站点。

九月那次动的是操作步骤型标注，桌面端的展示被整个取消。

对英语市场的内容团队来说，这两次改动砍掉的是一个非常具体的动机。

过去几年，很多站写问答段落的理由就是拿那个额外的展示位，占屏面积大，点击率高。

展示位没了，这个理由自然也就没了，于是一批团队开始把问答内容列进裁撤清单。

值得注意的是这两次削减都只动了展示层，没有动内容层。标注还在，页面上的问答段落也还在，被拿掉的只是结果页上那个额外的展现形式。这个区分很重要，因为把展示层的变化当成内容层的判决，是这一年里我见过最多的一次误读。

## 英文市场消失的那个动机，小语种从来没有过

把时间倒回去看，小语种站写问答内容的时候，很少是冲着富结果去的。

原因很朴素：那些额外的展示形式在小语种里的出现率本来就低得多。

标注要生效，需要搜索引擎对这门语言的解析足够有把握，而这份把握在小语种上一直是不足的。

所以小语种团队即使做了标注，看到富结果的概率也远低于英语站。

既然从来没吃到过这块红利，红利取消这件事对他们就没有实质影响。

这是一个少见的情形：一次让英语市场重新算账的改动，在小语种市场那边的输入项根本就是零，账不用重算。

这一点在内部沟通时要说清楚，否则总部按英语市场的结论下一刀切的指令，小语种这边跟着砍，砍掉的是自己本来就没吃到红利、但另有理由存在的那部分内容。这种因为口径不同而被误伤的情况，在跨市场的内容治理里出现得比想象中频繁。

## 小语种写问答的动机在别处

动机一共三条，跟富结果一条都不沾。

第一条是覆盖用户真实的问法。很多语言的疑问句形态跟陈述句差很远，不专门写就接不住。

第二条是填供给空白。前面那个供给密度的数字已经说明了空白有多大。

第三条是给机器提供可摘取的段落。生成式结果需要的是一段能独立成立的回答，而不是一整页商品。

三条动机里，第三条是这一年才明显起来的，前两条在此之前就一直成立。

换句话说，就算把生成式搜索这一层整个拿掉，前两条理由也足够支撑这件事。

把动机拆清楚有个实际好处：将来任何一次结果页改版，你都能对照这三条看它动的是哪一条。动了第三条就调整回答的写法，前两条没被动到就不用改战略。动机拆得越细，对外部变化的反应就越精确，也越不容易被裹挟着做整体性的决定。

## 怎么判断你的语种属于哪一档供给？

## 第一档：本地有活跃的问答社区

判定动作很简单：拿你测供给密度那十条查询，看结果里有没有反复出现同一个本地社区域名。

如果有，而且它们排在前几位，说明这门语言有成规模的原生问答供给。

这一档的典型代表是几门东亚语言和几门大的欧洲语言，本地社区体量都不小。

在这一档里写问答内容，你面对的是真实竞争，而且对手的内容是真人写的、带具体经历的。

硬碰硬地写通用问答，赢面不大。正确的做法是往社区覆盖不到的地方去。

社区覆盖不到的通常是三类：需要专业设备才能验证的、涉及最新法规的、需要长期跟踪才能回答的。

还有一类容易被忘掉：需要把两三个来源拼起来才能回答的问题。社区里的回答是一个人凭一次经验写的，很少有人会为了回答一个问题去查三份资料再交叉。这类需要整合的问题，正是内容团队相对个人回答者唯一稳定的优势，而它跟语言大小无关。

## 第二档：只有零散的论坛帖和评论区

这一档最常见。搜索结果里能看到讨论，但都散落在通用论坛、社交平台的截图、商品评论区里。

特征是内容存在但不成形：没有标题，没有结构，一个帖子里混着三个不相干的问题。

这一档是最好的机会区。需求被证实存在，供给却处于未组织状态。

你要做的不是创造需求，是把已经存在的散装讨论重新组织一遍。

方法上很省力：把论坛里出现频率最高的十个问题挑出来，每个写一段结构清楚的回答。

这批内容的可信度还有个天然来源，就是它源自真实讨论，不是凭空想的选题。

操作时有一条纪律要守住：只借问题，不搬答案。把别人帖子里的回答改写一遍发到自己站上，既有版权风险，也丢掉了这件事的全部意义。问题是公共的，答案必须是你自己的，最好还带上你这边能提供而个人回答者提供不了的东西，比如实测数据、多个型号的对比、或者官方口径的核对结果。

## 第三档：几乎没有原生问答内容

这一档的特征是，你测的十条查询里，有七八条的前二十位全是商品页和目录页。

连零散讨论都很少，用户似乎从来没在这门语言里公开问过这些问题。

这时要先排除一个可能：用户可能在用另一门语言问。多语言市场里这种情况很普遍。

比如某些市场的用户遇到技术问题时直接用英语搜，因为他们知道本地语言里没有答案。

如果确认是这种情况，那么写本地语言的问答内容确实收益有限，用户根本不在这门语言里提问。

如果不是，也就是用户确实在用本地语言问但找不到答案，那这就是最好的一档：需求存在，供给为零。

区分这两种情况的办法是看站内数据而不是外部工具。你的站如果同时有本地语言版和英语版，看看本地市场的用户实际访问的是哪一个版本、在哪个版本上停留更久、从哪个版本下单。这个判断只要有一个月的数据就能做出来，比任何外部推测都可靠。

## 三档各自的动作完全不同

第一档的动作是差异化：挑社区答不了的问题，用整合和实测建立优势。

第二档的动作是组织化：把散装讨论重新梳理成结构清楚的回答。

第三档的动作是先验证再投入：确认用户是否真的在用这门语言提问，确认了再动手。

三档的投入强度也不同。第二档投入产出比最高，第一档次之，第三档最不确定。

如果预算只够做一档，选第二档，几乎没有例外。

而多数团队的默认做法是按语言的市场规模排预算，排出来的顺序跟这个恰好相反。

按市场规模排预算之所以在这件事上会错，是因为市场规模同时决定了需求和竞争，两者相互抵消。而供给密度只决定竞争，不决定需求，所以它是一个更干净的排序指标。凡是同时影响正反两侧的指标，都不适合单独拿来排优先级。

三档之间是会迁移的，而且迁移方向通常是从第三档往第二档走。一门语言的互联网内容一旦开始积累，最先出现的就是零散讨论。所以这个分档每年要重测一次，去年判成第三档的语言今年可能已经进了第二档，而第二档正是投入产出比最高的那一档，错过它的窗口有点可惜。

## 疑问句在你的语言里会不会改写实词？

## 不改写的语言：加个疑问词就行

先说最省事的一类。有些语言的疑问句就是在陈述句前面加一个疑问词，其余部分原样不动。

印尼语属于这一类。问怎么样在句首加一个词，句子的其他成分基本不变。

印尼语的书写与语法概览 (https://omniglot.com/writing/indonesian.htm)里能看到，它的动词不随人称和时态变形，这在做关键词表时是巨大的便利。

这一类语言里，问答内容的关键词表可以直接从陈述型关键词表推出来。

做法是把疑问词当成前缀，跟原有的词组做笛卡尔积，再筛掉不通顺的组合。

一张两百行的陈述词表，配六个疑问词，能推出上千个候选，人工筛一遍留下三百个。

这类语言还有个额外的好处：陈述式的页面和疑问式的页面在字面上高度重合，同一个页面往往能同时接住两类查询，不必为问答内容单独建页。这也意味着在这类语言里，问答内容的边际成本特别低，几乎就是在现有页面上多加一个小标题的事。

要确认一门语言属不属于这一类，可以查它的语法概况。语言数据库里的条目 (https://glottolog.org/resource/languoid/id/indo1316)会标明它的形态类型。孤立语和分析型语言基本都落在这一类，这也解释了为什么东南亚几门语言的关键词工程量明显小于欧洲那几门屈折语。

## 改写的语言：动词形态跟着变

另一类语言里，把陈述句变成疑问句会牵动实词本身。

日语是最典型的例子。问句和陈述句在动词的形态上就不一样，礼貌层级还会再叠一层变化。

敬语层级会整段改写动词 (https://zhangwenbao.com/japanese-seo-keigo-politeness-levels-conversion-ranking.html)这件事，在疑问句上表现得更集中。

结果是，用户打出来的问句形态和你页面上写的形态，字面可能一个字都对不上。

这一类语言的问答关键词表必须单独建，不能从陈述词表推。

建表的原料只能来自真实语料：客服记录、站内搜索、社区帖子标题。

屈折程度高的语言在这里还要再加一层麻烦，因为疑问句里的名词可能还要换一个格。屈折语里锚文本的精确匹配本来就是假的 (https://zhangwenbao.com/minor-language-internal-link-anchor-inflection-variants.html)，到了问句上，连能不能对上都成了问题。

韩语是另一个例子。它的疑问句要换一套句尾形态，而且这套形态还跟对话对象的关系挂钩。依存句法项目里韩语的形态标注说明 (https://universaldependencies.org/ko/index.html)把这些变化列得很清楚，可以拿来估工作量。估出来的结论通常是：这类语言的问答词表得单独排一个人月，不能算进原有词表的维护里。

## 语序型：靠位置提问，正则筛不出来

第三类最麻烦。有些语言的疑问句不靠疑问词，靠语序调整或者句末的语气成分。

这类句子里可能一个疑问词都没有，只是把动词提到了前面。

用带疑问词的正则去筛报表，这一类问句会被整批漏掉。

漏掉的后果是你会低估这门语言的问答型流量占比，进而低估这件事的价值。

解决办法不是把正则写得更复杂，而是换一个入口：从站内搜索日志里看真实的句式分布。

站内搜索没有筛选规则的问题，用户打什么就记什么。

另一个务实的办法是承认这个偏差并把它写进口径。如果你知道这门语言的疑问句有三成不带疑问词，那么正则筛出来的比例乘一个固定的修正系数，虽然不精确，但至少前后一致，趋势判断不受影响。一个已知方向的系统偏差，远比一个不知道存不存在的偏差安全。

还有一个更隐蔽的漏法：有些语言把疑问语气放在句子最后一个音节上，写下来只是一个很短的助词。这个助词在分词时经常被当成噪声去掉，于是查询到了报表里就变成了纯陈述句。碰到这类语言，报表侧的筛选基本可以放弃，直接以站内搜索日志为准。

## 三类语言的关键词表要分开建

把三类归拢一下：不改写的可以推导，改写的必须采集，语序型的要靠日志。

三种建表方式的成本差别很大，从低到高大概是一比三比五。

做多语言排期时，这个成本差应该直接体现在工时估算里，而不是按语言数量平均分。

判断一门语言属于哪一类，只要找一个母语者问一个问题：把这句陈述变成问句，哪些词会变。

回答如果是不用变，第一类；如果指着动词说这个要变，第二类；如果说词不变但顺序要换，第三类。

一门语言三分钟出结论，十门语言半小时排完。

这个判据的可靠性来自它问的是母语者的直觉而不是语法知识。不需要对方懂语言学，也不需要查资料，任何一个说这门语言的人都能立刻回答。依存句法标注项目里各语言的形态特征说明 (https://universaldependencies.org/id/index.html)可以用来事后核对，但不必拿它当第一手判据，那样反而慢。

建表之前还有一步值得做：把语言和地区分开标注。同一门语言在两个地区的口语问法可能差得很远，而语言标签规范里语言与地区子标签的分离写法 (https://www.rfc-editor.org/rfc/rfc5646)正好给了你一个现成的结构。词表里多一列地区，将来要拆的时候不用重做。

## 这门语言的问句到底长什么样？

## 疑问词表怎么建

先列这门语言里最常用的六到八个疑问词，覆盖怎么、什么、多少、哪个、为什么、什么时候几类意思。

每个疑问词后面接的语法结构不一样，要分别记一个示例句。

然后把品类词代进去，看哪些组合读起来自然，哪些明显不通。

这一步必须母语者过一遍，机器判断不了自然不自然。半小时的事。

建完之后这张表几乎不会过时，疑问词是语言里最稳定的那一层，十年也不会变。

相比之下品类词每两年就要更新一次，所以两张表要分开维护，不要合成一张。

这张表还有个隐藏用途：它可以直接拿来做报表的筛选规则。把六到八个疑问词写进正则，就能把问答型查询从总曝光里分出来，这个比例是判断这门语言值不值得继续投入的核心指标之一，也是覆盖前那几条基线曲线 (https://zhangwenbao.com/sge-non-english-language-coverage-early-observation.html)里最先要存的一条。

如果手边没有母语者，还有个替代办法：去看公开的多语言问答数据集。按语言类型多样性挑语种建的那套问答数据 (https://github.com/google-research-datasets/tydiqa)里，每门语言都有大量真人写的问句，直接看它们的开头结构就能把疑问词摸个八九不离十。免费，而且比凭空想靠谱得多。

## 口语问法和书面问法的差距

多数语言里，人写下来的问法和嘴上说的问法不是一回事，差距的大小按语言而定。

差距小的语言，一套词表够用。差距大的语言，得建两套。

判断差距的办法是看同一个问题在社区帖子标题里和在正式文章标题里怎么写。

如果两者结构明显不同，说明这门语言的语域分层比较硬，得分开处理。

用户在搜索框里打的通常介于两者之间：比口语正式，比书面随意。

所以词表要以搜索日志里的实际写法为准，社区和文章只是两个参照极。

语音输入把查询整体推向口语那一端 (https://zhangwenbao.com/voice-search-query-characteristics-content-optimization-onpage.html)的趋势在小语种市场同样存在，而且因为这些市场的移动端占比更高，推动力比英语市场还大一些。这意味着口语那一套词表的权重会逐年上升，两套表的比重要每年重新分配一次。

两套词表并不意味着两套内容。多数情况下是同一篇回答，标题用书面问法，正文第一段里把口语问法原样复述一遍。这样两种打法都能对上，页面却只有一个。分成两个页面去接两种问法，是这件事上最常见也最费力不讨好的做法。

## 拼写错误和缩写要不要收

带变音符号的语言里，用户经常不打符号。这算不算错误，要不要收进词表。

我的做法是收，但单独标记，不跟标准拼法混在一起。

原因是这两类词的处理方式不同：标准拼法用来写标题和正文，非标准拼法用来做覆盖检查。

覆盖检查的意思是确认搜索引擎能把两种拼法归到一起，如果能，你就不用为它单独做页面。

缩写的情况类似。有些语言的社区里流行大量缩写，正式内容里从不出现。

缩写一般不进标题，但可以在正文里出现一次，作为一个理解上的桥。

这里有个反面案例值得说。有个团队为了覆盖非标准拼法，专门建了一批只改拼写的页面，结果这批页面互相竞争，把原本表现不错的标准拼法页面也拖了下去。覆盖变体的正确位置是同一页的正文里，不是一批新页面，这条在同语言内部的页面竞争 (https://zhangwenbao.com/multilingual-template-ten-languages-duplicate-content-risk.html)那一层已经讲得很清楚了。

## 一个问题该占一个页面，还是只占一段？

## 独立页的适用条件

独立成页的条件有三条，要同时满足。

第一，这个问题的完整回答需要超过八百字，而且展开之后信息密度不掉。

第二，这个问题在搜索日志里有稳定的、可识别的查询量，不是偶发的。

第三，回答的内容跟你现有的任何页面主题都不重合，塞进去会显得突兀。

三条里少任何一条，独立成页都是亏的：页面会太薄，或者会跟老页面互相抢。

小语种站尤其要克制，因为页面总数少的时候，每多一个薄页面对整站的稀释都更明显。

还有一条实操上的提醒：独立页一旦建了就要长期维护，而小语种站的维护人力通常是最紧的。判断一个问题该不该独立成页时，把两年后谁来更新它这个问题一起考虑进去，能砍掉一半的候选。

还有一条容易被忽视的判据：这个问题会不会随时间失效。涉及具体型号、当季价格、临时政策的问题，写成独立页之后过一年就成了负资产，改也不是删也不是。这类问题更适合放进集中页，改起来只动一段，不牵动整个页面的存在。

## 集中页的适用条件

集中页就是把十几二十个相关问题放在同一页，每个一段回答。

适用条件是这些问题彼此相关、单个回答都不长、而且用户经常一次问好几个。

典型的场景是配送、退换、保修这类政策型问题，用户脑子里本来就是一串。

集中页在小语种站里性价比最高，因为它用一个页面接住了一批长尾查询。

做集中页有个细节：每个问题要用独立的小标题，并且标题就是问句本身。

这样每一段都能被单独定位，也能被单独摘出来，不至于整页一锅粥。

集中页还有一个常被忽略的好处：它天然适合小语种的内容生产节奏。你不需要一次凑够一篇文章的量，攒够三五个问题就能先发一版，之后每季度往里加几条。这种可增量的形态，对一个只有半个人力的语言版本来说，比任何长篇规划都现实。

## 嵌在正文里的适用条件

第三种形态是把问答直接写进现有页面的正文，不单独立段也不建新页。

适用条件是这个问题跟页面主题强相关，而且回答只要两三句话。

比如商品页上关于尺寸怎么选的问题，写进商品描述里比单独建页合适得多。

这种做法的好处是零新增页面，坏处是可摘取性差一些，因为它没有独立的标题。

折中办法是给它一个小标题，标题写成问句，但不单独成页。

这样既保住了可定位性，又没有增加页面数量。

选这一形态还有个隐含前提：现有页面本身要有一定的权重和收录状态。如果这个页面自己都进不去索引，把回答塞进去等于埋掉。所以嵌入的对象要挑表现好的页面，别挑那些正等着被优化的页面。

嵌入的时候位置也有讲究。放在页面最底部的问答段落，被摘取的概率明显低于放在正文中段的。合理的位置是紧跟在与这个问题相关的那段描述之后，形成一个自然的追问。硬塞到页尾的那种，读者不看，机器也不容易判断它跟主题的关系。

## 三种形态的判定顺序

判定顺序是从省事的往费事的走，而不是反过来。

第一问：能不能嵌进现有页面。能就嵌，判定结束。

第二问：能不能跟其他问题合成一个集中页。能就合，判定结束。

第三问：三条独立成页的条件是否全部满足。全满足才建新页。

这个顺序能把新增页面的数量压到最低，而小语种站最怕的就是页面数量失控。

照这个顺序走，一百个候选问题最后大概只有五到十个会变成独立页面。

顺序反过来做的团队，通常会在半年后得到一百个只有三百字的页面，然后花另外半年把它们合并掉。这个来回我见过不止一次，而它完全可以靠一个三问的判定表避免掉，成本是开会时多花二十分钟。

这个判定表最好写在一张纸上贴出来，因为它真正的作用是拦住临时起意。选题会上有人提出一个问题很值得写一篇，判定表能立刻把讨论拉回到三个具体条件上，而不是变成对这个问题重不重要的主观辩论。省下来的会议时间比省下来的页面还多。

## 回答要写多长，才既被人读也被机器摘？

## 第一段就要把答案说完

不管后面写多少，第一段必须是一个能独立成立的完整回答。

独立成立的意思是：把这一段单独摘出来，读的人不需要看上下文也能明白。

所以第一段里不能出现这个、上面提到的、如前所述这类指代。

也不能只给一半答案然后说详见下文，这在可摘取性上等于没有答案。

结论要放在第一句，理由放第二句，边界条件放第三句。三句话结构最稳。

用户在网页上的阅读方式是扫而不是读 (https://www.nngroup.com/articles/how-users-read-on-the-web/)，这条老结论跟机器摘取的需求指向了同一个写法，算是难得的一致。

把结论前置这件事在有些语言里会有点别扭，因为它们的书面习惯是先铺陈后结论。这时候要做的不是照搬语言习惯，而是在结论前面加一个极短的引子，一句话十来个字，既照顾阅读习惯又不影响摘取。母语审校常会建议把引子加长，这一条要顶住。

## 后面几段解决为什么和例外

第一段给结论，后面的段落负责回答两件事：为什么是这个结论，什么情况下不成立。

为什么那一段要给出机制或者依据，不能只是把结论换个说法再说一遍。

例外那一段是小语种内容里最有价值的部分，因为它通常涉及本地的具体条件。

本地的税费规则、本地的配送时效、本地常见的电压和接口标准，这些在通用回答里永远不会出现。

写清楚例外，等于给这篇回答加了一个别人抄不走的部分。

而抄不走的部分，正是在被引用这件事上最容易胜出的部分。

例外这一段还有一个好处：它是判断内容有没有本地化到位的最直接的检验。一篇小语种问答如果通篇没有任何只在这个市场成立的信息，那它多半是从别的语言翻过来的，读者感觉得到，母语审校的验收清单 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)里也应该把这一条列成硬项。

## 长度按信息单元数控制，不按字符数

写多长这个问题，用字符数回答在跨语言的场景下总是错的。

同一段内容翻成不同语言，长度能差出四成，按字符数定的上限在一半语言上不适用。

换成数信息单元：一个结论算一个，一条依据算一个，一个例外算一个，一个数字算一个。

一段完整的问答回答，五到八个信息单元是合适的区间。

低于五个显得单薄，高于八个用户读不完，机器摘取时也容易只取到前半截。

这个口径的好处是它跨语言稳定，翻译不会改变事实的条数，验收时人工数一遍就行。

信息单元这套数法还能顺手解决另一个问题：不同语言版本之间的内容一致性检查。以前要靠对照译文，现在只要数两边的单元数对不对得上，差一个就说明有内容在翻译过程中掉了。这个检查一个不懂目标语言的人也能做。

顺便说一个容易被漏掉的单元：本地格式本身就算一个信息单元。价格用什么分隔符、日期怎么排、单位写不写，这些在区域数据的数字与货币格式定义 (https://www.unicode.org/reports/tr35/tr35-numbers.html)里都有标准答案，写对了读者会觉得这段话是本地人写的，写错了整段的可信度都要打折。

## 怎么验证这批内容有没有白写？

## 三个月内该看哪几个数

第一个数是这批页面的收录比例。小语种站的收录本来就慢，这个数先看。

第二个数是问答型查询带来的曝光量，用前面那张疑问词表做筛选。

第三个数是这批页面的平均排名位置，看它有没有在往上走。

三个数都不是流量，因为三个月内小语种问答内容的流量绝对值一定很难看。

用一个必然难看的数去做判断，结论只能是砍掉，而这个结论是被指标选择逼出来的。

零搜索量关键词到底有没有用 (https://zhangwenbao.com/zero-volume-keywords-true-value-aio-longtail-engineering.html)这个老问题，本质上就是在争论该用哪个指标来判它的死活。

第四个数可以看但不必强求：这批页面被站内其他页面引用的次数。如果你的内链是按主题自动生成的，问答页会自然地被引用进来，引用次数上升说明这批内容在站内的语义位置站住了。这个数比外部指标反应更快，两三周就能看到变化。

## 别用总流量判断

总流量在这件事上是最没用的指标，原因有三个。

第一，问答内容带来的流量在总量里占比很小，被大盘波动淹没。

第二，小语种站的总流量本来就受季节和汇率影响大，噪声比信号强。

第三，这批内容的价值有一部分不落在自身流量上，落在被引用和被复制上。

被复制这件事听着像坏事，其实是个正面信号：说明你的回答成了这门语言里的参考答案。

参考答案的位置一旦占住，后来者要么引用你，要么绕开这个问题。

要监测被引用和被复制，做法很土但有效：把回答里那句最独特的话拿去搜一遍，看有多少个域名出现了几乎相同的表述。每季度做一次，十分钟。数字在涨，说明你写的东西正在这门语言里扩散，哪怕自身流量还没起来。

## 留对照组的做法

选两个条件相近的品类，一个做问答内容，一个不做，同期观察。

条件相近的意思是流量量级接近、季节性接近、没有在跑其他改动。

三个月后比较两组在问答型查询上的曝光变化，差值才是这件事的真实效果。

没有对照组的话，任何变化都可以被解释成大盘波动，谁也说服不了谁。

对照组的成本是零，只是少做一个品类，而这一个品类的机会成本远小于结论不可信的代价。

选对照组时要避开正在做促销的品类，也要避开刚上新品的品类，这两类的自然波动太大。

对照组做完之后，那个不做的品类要补上，而且要记得补。我见过一个项目把对照组一直空着，两年后才想起来那个品类从来没做过问答内容，白白空了两年。对照组是实验设计，不是长期策略，实验结束就该收口。

对照组的结论还有一个额外用途：它是你下次申请预算时唯一拿得出手的东西。没有对照组，你只能说做了之后数据涨了；有对照组，你能说做了的那组比没做的那组多涨了多少。这两句话在预算会上的分量完全不一样，而成本差只是少做一个品类。

## 哪些语种现在就该停手？

## 停手的两个信号

第一个信号：用户在这门语言里根本不提问，他们用另一门语言问。

这个信号靠站内数据判断，看本地市场的用户实际访问哪个语言版本、在哪个版本停留更久。

确认之后，把问答内容做在他们实际使用的那门语言上，而不是名义上的本地语言。

第二个信号：本地问答社区已经把这个品类的常见问题答得又全又好。

这时候硬碰硬地写通用问答，投入产出比会很差，除非你能拿出实测或者整合类的内容。

两个信号里出现任何一个，就该重新评估，而不是继续按原计划铺量。

要强调的是停手不等于放弃这个市场。停的是通用问答这一种内容形态，其他形态照做。同一个词在两个市场问的不是一件事 (https://zhangwenbao.com/minor-language-search-intent-divergence-across-markets.html)，同理，同一种内容形态在两个市场的价值也可以差得很远，停掉一种形态是正常的排期调整，不是市场判决。

## 停手之后资源往哪挪

第一个去处是把资源挪到供给密度更低的品类上，还是同一门语言。

前面说过供给密度是语言和品类的交叉属性，同一门语言里不同品类能差好几倍。

第二个去处是挪到同一档里的另一门语言。第二档语言的机会普遍好于第一档。

第三个去处是把已有的问答内容做深，而不是做多。把十篇写成参考级，胜过写五十篇泛泛的。

保哥常说的一句话在这里同样成立：在供给稀缺的市场里，深度是唯一不会被稀释的东西。

三个去处按确定性排序，第一个最稳，第三个见效最慢但护城河最深。

资源挪动的时候有个纪律要守：挪走之前先把已发的内容整理成一份清单，标明各自的状态和最后更新时间。没有这份清单，半年后想回来接着做，会发现没人记得当初做到哪一步了，等于从零开始。

还有一个去处经常被忘掉：把资源挪回到架构和技术那一侧。国际化SEO的通用检查清单 (https://www.searchenginejournal.com/international-seo/)里那些跟语言无关的项目，比如版本标注、跳转逻辑、索引控制，在小语种站上出问题的概率一点不低，而且修好了对所有内容形态都有效，不像内容那样只惠及自己那一批页面。

## 常见问题解答

## 小语种的长尾内容还值得写吗？

值得，但理由跟英文市场不一样。英文长尾靠的是条数极多、每条量小、加起来可观，这个模型在小语种里不成立，因为词形变化把每条的量又摊薄一次，工具还测不出来。真正的理由在供给那一侧：这些语言的网页里，肯把一个问题从头到尾讲清楚的页面本来就没几个。需求按人口比例缩水，供给按更陡的比例缩水，中间张开的口子就是机会所在。

## 怎么量一门语言的内容供给有多稀缺？

挑十条品类里最典型的问句，每条看目标语言搜索结果的前二十位，数其中有几条在正面回答这个问题。正面回答要卡死定义：有一段完整文字直接给结论，商品列表和宣传语都不算。两百格数下来的比例就是供给密度。英语里通常四成以上，小语种能到一成就算高的。要注意这个数字必须按品类分别测，同一门语言里消费电子和园艺工具能差好几倍。

## 富结果被砍了，问答内容是不是该跟着砍？

英语市场砍的理由成立，小语种市场不成立。因为那两次削减动的只是展示层，而小语种站原本就很少吃到那块展示红利，取消对它们的输入项是零。小语种写问答的动机另有三条：接住跟陈述句差别很大的疑问句形态、填补供给空白、给机器提供可独立摘取的段落。三条都跟富结果无关，所以按英语市场的结论一刀切，砍掉的是本来另有理由存在的内容。

## 一个问题该独立成页还是并进现有页面？

按从省事到费事的顺序判定。先问能不能嵌进现有相关页面，能就嵌；再问能不能跟其他问题合成一个集中页，能就合；最后才看独立成页的三个条件是否全满足，也就是完整回答超过八百字且密度不掉、有稳定可识别的查询量、跟现有页面主题都不重合。照这个顺序，一百个候选问题最后大概只有五到十个会变成独立页面，其余都被前两步消化掉了。

## 各语言的疑问句差别有多大，词表能不能共用？

按疑问句会不会改写实词分三类。第一类只在句首加疑问词，其余不动，词表可以从陈述词表推导；第二类会改动词形态甚至名词的格，词表必须从真实语料单独采集；第三类靠语序或句末成分提问，句子里可能一个疑问词都没有，只能从站内搜索日志里看句式分布。判定方法是找母语者问一句：把这句陈述改成问句，哪些词会变。一门语言三分钟出结论。

## 回答写多长合适？

别用字符数，用信息单元数。一个结论算一个单元，一条依据算一个，一个例外算一个，一个具体数字算一个，五到八个是合适的区间。字符数在跨语言场景下必然失真，同一段内容翻成不同语言长度能差四成。信息单元这个口径跨语言稳定，因为翻译不会改变事实的条数，还能顺手做版本一致性检查：两边单元数对不上，就说明翻译过程中掉了内容。

## 三个月看不到流量，该不该停？

不该用总流量做这个判断。小语种问答内容三个月内的流量绝对值一定很难看，用一个必然难看的数去判死活，结论是被指标选择逼出来的。该看的是三个数：这批页面的收录比例、用疑问词表筛出来的问答型曝光量、这批页面的平均排名走向。同时留一个条件相近的品类当对照组，三个月后比较两组的曝光差值，那个差值才是真实效果。

## 权威参考资料



## 生成式搜索先铺到了印尼语和韩语，排在德语法语前面的理由不是人口

- URL：https://zhangwenbao.com/sge-non-english-language-coverage-early-observation.html
- 分类：小语种SEO
- 发布：2023-11-21  |  更新：2026-07-27
- 摘要：生成式搜索这一年扩语三次共进去七门语言，德语法语一门都不在。讲清这个顺序为什么跟母语人口和广告价值都对不上，以及语种未被覆盖的这段时间里最该动手做的是哪几件。
- 关键词：出海SEO,多语言SEO,小语种SEO,生成式搜索

> **TLDR**：摘要：生成式搜索这一年扩了三次语种，进去的顺序是英语、日语和印地语、然后是西班牙语葡萄牙语韩语印尼语。德语法语意大利语一门都不在里面。母语人口比德语少一半的印尼语排在前面，说明这个队列不按语言大小排，也不按广告收入排。你要判断的不是自己什么时候轮到，而是轮到之前该先把哪三条基线存下来。

> 摘要：生成式搜索这一年扩了三次语种，进去的顺序是英语、日语和印地语、然后是西班牙语葡萄牙语韩语印尼语。德语法语意大利语一门都不在里面。母语人口比德语少一半的印尼语排在前面，说明这个队列不按语言大小排，也不按广告收入排。你要判断的不是自己什么时候轮到，而是轮到之前该先把哪三条基线存下来。

## 三次扩语之间隔了多久，先进去的是哪几门语言？

## 五月那次公布，能用的只有一种语言

今年五月的开发者大会上，生成式搜索体验第一次露面。它当时挂在实验室里，需要报名排队，能用的地区只有美国。

语言这一栏写的是英语，而且是美国英语。英国英语、澳大利亚英语当时都不在名单上。

同一天发布的还有支撑它的那个大模型，官方材料里写着支持一百多种语言。两个数字放在一起，一边是一百多，一边是一。

做小语种的人第一反应通常是等。等它把语言补齐，再来考虑要不要动内容。

这个反应本身没错，错的是等的过程里什么都不做。因为等待期的长短，决定了你能不能拿到一份干净的对照数据。

保哥当时带的一个办公文具项目正好铺了六门语言，团队问的第一句话就是德语什么时候能用。答案后来证明是：那一年都没轮到。

把这两个数字的差距写清楚很重要：模型能处理的语言数量，跟产品愿意开放的语言数量，从第一天起就不是同一个量级。前者是能力问题，后者是运营决策。你在等的是后面那个数字，可它的变化速度跟前面那个基本无关，所以拿模型的语言列表去推产品的上线时间，推出来的结论一次也没准过。

## 八月加进来的两门是日语和印地语

八月中旬，生成式搜索第一次走出英语。官方那篇扩到印度和日本的公告 (https://blog.google/products/search/google-search-generative-ai-india-japan/)里，新增的两个市场分别配了印地语和日语。

这个组合当时让不少人意外。按常规的国际化排期，英语之后接的往往是西欧几门语言。

日语这一门有它的特殊性。日本市场的搜索行为高度移动化，而且长句提问的比例本来就比英语市场高。

印地语更值得看一眼。它的书写系统是天城文，跟拉丁字母毫无关系，属于技术难度更高的那一档。

换句话说，第二批进去的两门语言，一门是非拉丁书写系统，一门是黏着特征明显的语言。都不是最省事的那种选择。

如果你手上做的正好是日语这类多套文字并存的语言 (https://zhangwenbao.com/japanese-seo-hiragana-katakana-kanji-keyword-notation.html)，八月这一次就是你能拿到的第一份真实观察窗口。

把印地语放进第二批，还带出另一件事：印度是一个多语言市场，官方语言表里有二十多门，这次进去的只是其中一门。也就是说，扩语这个动作的粒度是语言而不是国家，同一个国家里可能有一门语言能用、另外十门不能用，这跟大多数人脑子里那张按国家点亮的地图完全不是一回事。印度那十一门语言分摊在九套书写系统上 (https://zhangwenbao.com/india-multilingual-seo-eleven-languages-nine-scripts-priority.html)的账，在这里又要重算一遍。

## 十一月一口气加了四门

十一月初的那次扩展动静最大。覆盖的国家和地区数量跳到一百二十以上，语言一次加了四门。

这四门是西班牙语、葡萄牙语、韩语和印尼语。加上原有的英语、日语、印地语，一共七门。

七这个数字值得停一下。全球网页内容里排前十的语言，有三门不在这张表上。

不在表上的那三门是德语、法语和俄语。其中德语和法语在网页内容语言份额统计 (https://w3techs.com/technologies/overview/content_language)里常年排在前五。

这就是本文想说的第一件事：内容供给量最大的那几门语言，不一定是被优先服务的那几门。

我拿这张七语列表跟团队的六语站点对了一遍，重合的只有西班牙语和葡萄牙语两门，剩下四门全落空。

三次扩语之间的间隔也值得记下来：五月到八月是三个月，八月到十一月又是三个月。节奏比多数人预期的快，但每一次加进去的语言数量差别很大，第一次是零、第二次是二、第三次是四。这种加速形态说明限制因素不在语言本身，而在配套的评测与安全流程能不能跟上，一旦流程跑顺了，语言就是批量往里灌的。

## 把三次时间点画成一条轴，能看出什么

把五月、八月、十一月三个点摆在一条轴上，语言数量分别是1、3、7。

这是一条明显的加速曲线，不是匀速。每次的增量在翻倍。

如果这条曲线继续下去，下一个批次的语言数量会落在十几门这一档。

但曲线只能用来估量级，不能用来估具体日期。它告诉你的是不会很久，不是哪一天。

更有用的是另一个读法：曲线的形状意味着你所在语种进入的时间，跟你的语种排第几关系不大。

因为批量灌进去的时候，第八门和第十八门之间可能只差一个星期。排队顺序在批量模式下会失去意义。

所以那年秋天保哥给团队的建议是：别再问德语排第几这个问题了，改问一句更有用的，德语版进去的那一周，我们有没有东西可以拿来对照。这个问法把一个无法回答的时间问题，换成了一个当天就能开始做的准备工作，而后者恰好是唯一能提前做的部分。

## 为什么先被覆盖的不是德语和法语？

## 按母语人口排，跟实际顺序对不上

先做个最朴素的检验：把七门语言按母语人口从多到少排，看看跟进入顺序对不对得上。

西班牙语母语使用者接近五亿，排在前面没有疑问。印地语和葡萄牙语也都是两亿以上的量级。

问题出在印尼语。它的母语使用者只有四千多万，比德语少了一半还多。

德语的母语使用者接近一亿，法语也在八千万以上。两门都比印尼语的母语盘子大。

如果按母语人口排队，印尼语该排在德语和法语后面。实际情况是它排在前面。

韩语的情况类似。八千万左右的使用者，跟法语差不多，也走到了前面。

有人会说印尼语要算第二语言使用者，加起来接近两亿。这个修正是对的，但它同时也说明第一个判据本身就不牢靠：一门语言的人口数字有母语口径和总使用者口径两种算法，两种算法排出来的名次能差出十几位，而一个能被口径改写名次的指标，本来就不适合当排序依据。

再补一个口径上的细节：一门语言的人口数字要看清统计的是哪一类使用者。标准印尼语在语言数据库里的条目 (https://glottolog.org/resource/languoid/id/indo1316)把它跟马来语族其他变体分得很细，同一个名字底下的范围可以差出好几倍。拿一个没写清口径的数字去论证优先级，论着论着就会发现两边说的根本不是同一门语言。

## 按搜索广告收入排，也对不上

第二个朴素检验：按市场的搜索广告价值排。德国和法国都是欧洲最大的几个广告市场。

按这个口径，德语和法语该排在印尼语前面，而且是排得很靠前。

实际顺序又对不上。所以商业价值这条线也不是主导因素。

这里可以顺手排除掉第三条线：技术难度。天城文和谚文都比德语难处理，却都先进去了。

三条最直觉的解释线索全部落空之后，问题才变得有意思起来。

剩下能解释的因素，得往产品之外去找。

把这三条线一起否掉，还有个副产品：它让你在跟总部汇报的时候不用编故事。很多团队在解释自己的语言为什么没被覆盖时，会下意识地找一个听着体面的理由，比如说这门语言的商业价值不够，说着说着自己也信了，结果做出一堆本不该做的收缩决策。承认原因不在你这一侧，是做出正确判断的前提。

顺着广告价值这条线还能再验一次。从搜索引擎份额的公开统计 (https://gs.statcounter.com/search-engine-market-share)看，德国和法国的搜索行为高度集中在单一引擎上，这本该是最容易做产品灰度的环境，结果反而排在后面。集中度这条线也否掉之后，能留在桌面上的解释就更少了。

## 监管确定性这条线，能对上一半

德国和法国属于欧盟。那一年欧盟关于人工智能的立法程序正在推进，规则的最终形态还没落定。

欧盟人工智能监管框架的官方说明页 (https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai)那时候写的还是提案阶段的内容，条款仍在谈判桌上。

在一个规则未定的市场先上一个生成式的产品，等于给自己埋一个不知深浅的坑。

这不是猜测某家公司的动机，而是一个可观察的相关性：七门语言对应的主要市场里，欧盟成员国的比重明显偏低。

把这条线单独拿出来，能解释德语法语意大利语荷兰语一起缺席这件事。

但它解释不了俄语的缺席，也解释不了为什么韩国比德国先进去。所以只能算解释了一半。

需要说明的是，这条线在实务上有个直接用途：如果你的语种主要市场在欧盟境内，那么把上线时间的预期整体往后推一到两个批次，比按语言排名去估更接近真实。这个推迟不是因为你的语言不重要，而是因为产品方要等的东西根本不在语言这一层。

## 移动增量市场这条线，能对上另一半

把七门语言对应的主要市场再看一遍：印度、日本、印尼、韩国、巴西、墨西哥、西班牙。

这里面有四个是移动互联网用户增量最大的那一批市场。印尼那年的数字报告 (https://datareportal.com/reports/digital-2023-indonesia)里，互联网用户数字仍在两位数增长。

德国和法国的互联网普及率早就接近天花板，增量几乎为零。

一个新产品要拿真实使用数据来调，去增量市场拿的数据密度更高，成本也更低。

把监管确定性和增量密度两条线叠起来，七门语言的名单基本能解释完。

这个解释框架有个好处：它可以直接拿来预判下一批。你只要问哪些语言的主要市场同时满足规则清晰和增量还在，答案就自己浮出来了。

顺带说一句，用这套框架去看东南亚会发现一个有趣的错位：印尼语和马来语的关系一直有争议 (https://zhangwenbao.com/indonesian-malay-seo-two-markets-vocabulary-split.html)，但产品这一侧的选择干脆利落，进去的是印尼语，马来语没进去。这说明产品方用的判据跟语言学界用的判据不是一套，前者看的是单一市场的用户规模，后者看的是语言本身的独立性。

## 覆盖顺序透露的是模型能力还是市场决策？

## 底层模型的语言覆盖远大于产品的语言覆盖

回到五月那个对比：模型侧写着一百多种语言，产品侧只有一种。

这个差值不是暂时的，它是常态。那一代大模型的官方介绍 (https://blog.google/technology/ai/google-palm-2-ai-large-language-model/)里，多语言能力被放在很显眼的位置。

模型能不能处理一门语言，跟产品愿不愿意在那门语言上开放，是两个独立的开关。

第一个开关早就开了，第二个开关的钥匙在别人手里。

这个区分对小语种团队很重要，因为它决定了你该盯哪个信号。

盯模型的语言列表没用，那张表早就把你包含进去了。要盯的是产品的可用地区与语言公告。

再往前推一层，模型侧的语言覆盖数字本身也需要打折看。一百多种语言里，训练语料充足的可能只有二三十种，剩下的靠跨语言迁移勉强撑住。所以模型列表里出现你的语言，只说明它见过，不说明它擅长。多语言模型铺到七十多种语言那次 (https://zhangwenbao.com/multilingual-bert-seventy-languages-minor-language-seo-watershed.html)已经把这个道理演示过一遍了。

## 产品先上哪门语言，是运营决策不是技术决策

技术决策的特征是有明确的先后依赖：A做完才能做B。运营决策的特征是可以随时插队。

扩语这件事表现出来的全是运营特征。批量、跳跃、跟难度无关。

意识到这一点之后，很多常见的推测方法就可以扔掉了。

比如按书写系统难度推，按语料规模推，按现有搜索份额推。这些推法在运营决策面前全部失效。

还剩下什么能推？只剩下那些会影响运营风险的因素。

规则确定性、市场增量、以及能不能招到足够多的本地评测人员，这三样是运营真正在算的账。

第三样最容易被忽略。一个生成式产品要在某门语言上开放，需要一支能读这门语言的评测队伍来打分和标注问题，这支队伍的规模决定了上线速度。这也解释了为什么使用者基数小但劳动力供给密集的语言，反而可能比使用者多但评测人力稀缺的语言更早进去。

## 这个差值决定了你该等多久

把模型覆盖和产品覆盖之间的差值当成一个可以估计的量，事情就好办了。

差值大的时候，等待期长，你有充足时间做准备工作。

差值在收窄的时候，等待期短，准备工作要提前启动。

怎么判断差值在收窄？看批量的大小。一次加四门比一次加两门，说明流程已经跑顺。

按十一月这个批量看，我给团队的判断是：第二年上半年会再来一批，规模在十门以上。

这个判断不需要内部消息，只需要把三个公开的时间点连成线。

更重要的是，这个判断的用途不是让你去猜日期，而是让你知道准备工作的截止线大概在哪。如果你估出来是半年，那么基线数据的采集就该在三个月内启动，留三个月的观测窗口才够画出一条有意义的曲线。准备工作的排期由估计值反推，比由确定日期反推更符合实际。

## 你的语种到底属于哪一种未覆盖？

## 三种状态怎么分

先把状态定义清楚，否则后面的观察全是糊的。第一种是已覆盖：这门语言在公告的名单里，而且实测能看到生成式结果。

第二种是未覆盖：不在名单里，实测也看不到。

第三种最麻烦：在名单里，但你测的那批查询一条都没触发。

第三种状态的存在，是因为生成式结果本来就不是所有查询都出。它对查询类型有偏好。

信息型和比较型的查询触发率高，导航型和明确的品牌词触发率低。

所以同一门语言，你测二十条品牌词得出的结论，可能跟测二十条怎么选类问句得出的结论完全相反。

这三种状态的实务差别很大。第一种要开始做适配，第二种要继续存基线，第三种要做的是换查询清单再测一遍。把第三种误判成第二种，等于白白晚半年动手，而这半年恰恰是竞争最松的时候。

记录的时候建议给三种状态各配一个记号，而不是写一段描述。文字描述会随着记录人当天的心情变长变短，记号不会。这张表最终要给三个月后的自己看，那时候你只关心哪一格变了，不关心当初用了什么形容词，而形容词恰恰是最容易在交接时被理解偏的东西。

## 第三种最容易被误读成第二种

误读的原因很朴素：大多数人测的第一批查询，是自己站上排名最好的那批词。

而排名最好的那批词，通常是商业意图明确的词。这类词恰好是触发率最低的一档。

测完一圈没看到，结论就成了这门语言还没开放。

正确的做法是反过来：先用最容易触发的那类查询确认语言状态，再用商业词看覆盖面。

最容易触发的是什么类型？以疑问词开头的、寻求解释的、涉及多个选项对比的。

用这类词做状态判定，一门语言只要测十条就能有结论。

这里有个反直觉的操作细节：状态判定用的查询清单，应该跟你的业务关键词表尽量脱钩。业务词表是按商业价值筛过的，天然偏向低触发的那一端，拿它做判定等于用一把偏心的尺子量东西。判定用的清单可以完全是通用生活问题，只要语言对就行。

## 判别只要两个动作

第一个动作：拿十条疑问句式的通用查询，在目标语言和目标地区各测一遍。

第二个动作：把结果记成三档，全出、部分出、完全不出。

全出对应已覆盖，完全不出对应未覆盖，部分出对应已覆盖但触发受查询类型限制。

两个动作加起来，一门语言二十分钟能做完。

做完之后要记的不是截图，是日期和查询原文。截图会过期，查询原文可以复测。

这份清单一旦定下来就不要再改。改了之后前后两次的结果就不可比了。

保哥在那个办公文具项目里让团队做了一张极简的表：语言、地区、日期、十条查询各自的三档结果。整张表一页纸，每两周更新一次。后来产品扩到德语那周，团队手上有连续四个月的空白记录做对照，谁都说不出这是巧合还是效果这种话。

## 早期观察为什么只能靠人工抽样？

## 那时候没有一份独立的报表

常规的搜索表现报表里，生成式结果带来的曝光和点击并没有单独一栏。它跟其他形态混在一起。

这意味着你在报表里看到的数字变化，无法归因到这个新形态上。

更麻烦的是，生成式结果会把原本在第一屏的自然结果往下推，于是点击率的变化里同时包含了两种效应。

一种是被引用带来的增量，一种是被挤压带来的减量，两者混在同一个数字里。

报表工具解决不了的问题，只能靠人工在结果页上直接看。

这不是倒退，很多新形态刚出现的时候都经历过这个阶段。精选摘要当年也是先有人工统计，后有报表字段。

值得多说一句的是，这个阶段的人工数据后来会变得特别值钱。等报表字段补上之后，你能拿到的历史数据从字段上线那天算起，而字段上线通常晚于形态出现好几个月。那几个月的空白，只有当时手工记过的人补得上。手工记录的价值不在当下，在于它是唯一能跨越工具空窗期的数据。

## 自动化抓取拿到的结果不稳定

有团队会想到用脚本批量抓结果页，这个思路在这个场景下不太灵。

生成式结果的加载方式跟普通结果不一样，它需要等待，而且不是每次请求都出。

同一条查询连续测三次，可能出两次不出一次。抓取脚本很难判断这次没出是真的没出，还是没等到。

再加上地区和登录状态的影响，脚本拿回来的样本噪声大到没法用。

如果你的技术栈本来就在处理前端渲染与抓取的差异 (https://zhangwenbao.com/js-rendering-ai-crawler-citation-rate-csr-ssr-isr-divergence.html)，会对这类不稳定性有直观理解。

所以早期阶段不建议投入工程资源做自动化，投入产出比很差。

更现实的做法是把自动化用在别处：让脚本负责生成查询清单、记录时间戳、整理表格，把判断出还是没出这件事留给人。人在这件事上的准确率接近百分之百，而脚本在这件事上的准确率可能只有七成，工序分工比全自动更快也更准。

## 人工抽样反而更可复现

人工抽样听着土，但它有一个自动化比不了的优点：口径写在纸上，谁来做结果都一样。

十条查询、两个地区、固定的时间段、固定的设备类型，这套口径写成半页纸，交接给任何人都能接着做。

脚本一旦换人维护，参数被改动一次，前后数据就不可比了。

可复现性在这个阶段比数据量重要。你要的不是一万条样本，是一条能持续四个月不变形的曲线。

十条查询每两周测一次，一年下来是二百六十个数据点，画曲线足够了。

而且这份数据是你独有的。竞品要么没做，要么从更晚的时间点才开始做。

这里可以用一个不太严谨但很好用的比喻：这份手工记录相当于给你的语种拍了一张覆盖前的底片。等到某天生成式结果真的铺过来，你手上有底片，别人只有当天的照片，而没有底片的人永远说不清变化是从哪一天开始的。

这套做法还有个组织层面的好处：它不需要立项，不需要排期评审，一个人当天就能启动。工程资源一旦介入，事情就得进需求池排队，排到的时候观察窗口早过去了。用低技术含量换启动速度，在窗口期本身就很短的事情上，几乎总是划算的一笔交易。

## 抽样口径怎么定才不会一周换一个说法？

## 查询清单一旦定下就不要再改

清单要在第一次测之前定好，条数不用多，十到二十条最合适。

选词的标准只有一条：这些词在未来一年里不会因为你的业务调整而变得无关。

所以不要选当季主推品的词，那类词过两个季度就没人搜了。

选那些品类里最基础、最常青的问法。它们的搜索量可能不是最高的，但足够稳定。

清单里要有意识地混进不同类型：解释型、对比型、操作型、价格型各占一部分。

类型混合的好处是，当某一类的触发率发生变化时，你能看出是整体变化还是局部变化。

清单固定这件事说起来简单，做起来最大的阻力来自内部。每隔一段时间就会有人建议加几条最近很火的词，理由听起来都很正当。这时候要守住的原则是：想加可以，另开一张表，主表一个字不动。两张表并行的成本远低于一张表被改乱的成本。

## 语种与市场必须拆成两个字段

这是记录格式上最要紧的一条。很多团队把它们合成一个字段，比如直接写西班牙。

合成之后你就永远分不清，某个结果是语言带来的还是市场带来的。

西班牙语在西班牙和在墨西哥是两行数据，不是一行。

同理，葡萄牙语在巴西和在葡萄牙也是两行。英语在美国、英国、菲律宾是三行。

这件事在跨国语言的资产盘点里 (https://zhangwenbao.com/russian-language-market-seo-decision-after-2022-geopolitical-shift.html)已经吃过一次亏，报表里语言和国家绑死的站，需要决策那天先花两周拆数据。

拆成两个字段的成本是零，合并之后再拆的成本是两周。这个账很好算。

补充一个容易漏的字段：结果页的界面语言。你用哪种界面语言去测，会影响结果的呈现，尤其在多语言市场。把它记成第三个字段，将来复盘时能省掉很多解释不清的波动。

字段该不该拆，有一条通用规则：凡是将来可能各自独立变化的两个属性，就不能合并。语言标签规范里语言子标签与地区子标签的分离 (https://www.rfc-editor.org/rfc/rfc5646)正是这个道理的标准写法，它把语言和地区设计成两段可独立取值的结构，而不是一个整体字符串。你的观察表照着这个结构建就不会错。

## 时间、设备、登录状态都要记

时间要精确到日期和大致时段。同一天上午和晚上的结果可能不同。

设备类型只分手机和桌面两档就够，但必须记。移动端的触发率通常跟桌面端不一样。

登录状态影响很大，测的时候统一用未登录状态，并把这一条写进口径。

地区的模拟方式也要写死。用什么方法模拟目标地区，中途不能换。

这四项加起来就是一条记录的元数据，比结果本身还重要。

没有元数据的观察记录，三个月后你自己都不敢用。

元数据这件事有一个朴素的检验方法：把你的记录交给一个完全没参与过的同事，让他照着重做一遍。如果他需要来问你任何一个问题，说明口径还有洞。这个检验只要做一次，之后的几个月都省心。

实际操作里最常被漏掉的是地区的模拟方式。有人这次用一种办法，下次换另一种，两次结果的差异就被当成了产品变化。把方法名和参数写进口径的第一行，每次记录之前扫一眼，这个错误就再也不会发生，成本是三十秒。

## 记的是出不出，不是好不好

早期观察最容易跑偏的地方，是把评价内容质量混进来。

生成的那段话写得准不准、有没有引用你的站，这些都是后面才该关心的问题。

第一阶段只记一件事：这条查询在这个语言这个地区，有没有出现生成式结果。

二元记录的好处是判断标准清晰，不同的人记出来的结果一致。

一旦引入好不好的判断，两个人记同一条查询就会出现分歧，数据的一致性立刻崩掉。

等语言正式覆盖之后，再启动第二阶段，那时候才轮到引用来源和内容质量。

阶段划分这件事，本质上是在控制指标的进入顺序。先上二元指标，等它稳定运行两三个月、口径没人再质疑了，再引入需要判断的指标。反过来做的团队，通常在第三周就因为标准打架而放弃了整套观察。

二元记录还有一个副作用是好的：它逼着你把观察和评价分开。不少团队的监测做不长，原因是每次记录都伴随一轮讨论，二十分钟的活干成两小时，两个月后没人愿意接手。只判断出还是没出的时候，讨论没有发生的余地，记完就散，这才跑得下去。

## 覆盖之前该先存下哪三条曲线？

## 第一条：问答型查询在你站上的占比

从搜索表现报表里把带疑问词的查询筛出来，算它们在总曝光里的比重。

这个比重就是你这门语言的问答型流量基线。

为什么要它？因为生成式结果对问答型查询的影响最大，它铺过来之后这一块会先动。

如果你没有覆盖前的比重，事后就说不清这一块是被吃掉了还是本来就在缩。

各语言的疑问词不一样，筛选规则要按语言分别写。德语要筛的是几个固定的疑问词开头。

日语的疑问表达跟词序有关，筛选规则会更复杂一点，但也做得出来。

这里有一个跨语言的陷阱要提前避开：有些语言的疑问句不靠疑问词，靠语序或者句末助词。按疑问词做正则筛出来的比重，在这些语言上会系统性偏低。解决办法不是把规则写得更复杂，而是在口径里注明这门语言的筛法是保守估计，前后一致地偏低不影响趋势判断。

问答型查询这个类别不是我们自己划的。学界评测信息寻求型问答时用的那套横跨多种语言类型的基准数据集 (https://aclanthology.org/2020.tacl-1.30/)，收的正是用户真心不知道答案才去问的那一类问题，跟为了找某个已知页面而输入的导航型查询区分得很清楚。按这个界线去筛你自己的报表，口径会稳很多。

## 第二条：精选摘要的占有率

统计你在这门语言里，有多少条关键词拿到了摘要位置。

这个数字之所以关键，是因为摘要位置和生成式结果的引用来源之间有明显关联。

覆盖之前的摘要占有率，是你判断自己起点高低的唯一依据。

占有率高的站，在覆盖之后被引用的概率通常也高一些。

占有率低的站，则要先补这一块，而这件事在覆盖之前就能做，不用等。

顺带说，八月和九月那两次富结果类型的削减，让FAQ与操作指南类的展示位少了一大块，摘要位置的相对权重反而上升了。

这条曲线还有一个附带用途：它是少数几个在覆盖前后口径完全一致的指标。别的指标都会因为结果页形态变化而失去可比性，摘要占有率不会，因为它统计的是关键词层面的归属，跟页面上摆成什么样无关。所以它天然适合当跨期对照的锚。

## 第三条：品牌词与非品牌词的点击结构

把这门语言的点击拆成品牌词和非品牌词两块，记下比例。

生成式结果对这两块的影响方向相反。品牌词受影响小，非品牌词受影响大。

如果你没有拆过，事后看到总点击下降，会误以为品牌也在衰减。

拆开之后你会发现，很多时候品牌词纹丝不动，掉的全在非品牌词那一侧。

这个结构对汇报很有用，它能把一个吓人的总数拆成两个可解释的分项。

小语种站的品牌词还有个特殊问题：品牌名在当地可能有好几种写法 (https://zhangwenbao.com/brand-name-transliteration-loanword-minor-language-search.html)，筛选规则要把变体都算进去。

拆分的口径要在一开始就写死到具体的匹配规则，包括品牌名的所有本地变体、拼写错误的常见形态、以及带产品线名称的组合词。这份规则表大概二三十行，一次写好之后每个季度补充一两条即可，比事后回头重新定义省力得多。

## 为什么这三条必须在覆盖之前存

因为覆盖是一次性事件，它没有预告，也不会给你补采数据的机会。

某个周二你的语言突然能用了，从那一刻起，之前的数据就再也拿不到了。

三条曲线都可以从现有报表里导出，工作量是一个人两天。

两天换一份不可再生的对照数据，这个交换在我看来没有犹豫的余地。

而且这三条曲线在没有生成式结果的情况下也有用，它们本来就是内容策略的基础指标。

所以这件事的下行风险是零：最坏的情况是你多了三张有用的报表。

再补一个操作建议：把这三条曲线的导出做成定时任务，每月一号自动跑一次并存成带日期的文件。人工导出总会在某个忙月被跳过，而缺一个月的曲线在画趋势的时候特别碍事。定时任务的搭建成本大概两小时，一次投入长期受益。

还有一个时间上的细节容易被忽略：三条曲线至少要有三个月的历史才能看出趋势，一个月的数据只是一个点。所以启动时间不能踩着预估的覆盖日期算，得再往前推三个月。按这个推法，如果你估计半年之内会轮到，那么本月就该动手，而不是下个季度。

## 同一门语言在两个市场的显示率为什么不一样？

## 西班牙语在西班牙和墨西哥不是一回事

十一月那次公告说的是西班牙语进去了，没说是哪个西班牙语市场。

实际测下来，两个市场的表现有差别。这个差别不来自语言本身，来自市场配置。

产品的地区开放是按国家和地区做的，语言开放是按语言做的，两个维度是交叉的。

所以会出现语言在名单里、你的目标国家不在名单里的情况，反过来也一样。

这就是为什么记录必须拆成语种和市场两个字段，合并了就分不清是哪一边的原因。

西班牙人和墨西哥人搜的本来就不是同一个词 (https://zhangwenbao.com/spanish-seo-es-es-latam-keyword-divergence.html)，现在连结果页形态也可能不同。

这里出现了一个新的组合维度。以前做多市场同语言，要处理的是词汇分叉和落地页分叉，现在多了一层结果页形态的分叉。三层叠在一起，意味着同一门语言的两个市场，从关键词表到落地页到结果页监测，全都得分开跑，共用的部分比过去更少了。

## 葡萄牙语的两个市场差别更明显

巴西和葡萄牙的差别本来就比西班牙和墨西哥大，人口体量相差一个数量级。

巴西属于移动增量市场那一档，葡萄牙属于成熟市场那一档。

按前面那套解释框架，两个市场的开放节奏本来就该不一样。

如果你的葡语站是按巴西口径做的，那么葡萄牙那边的观察要单独记。

按巴西身材裁的那件衣服穿到葡萄牙身上处处都紧 (https://zhangwenbao.com/portuguese-seo-brazil-portugal-two-markets-keyword.html)，这条老经验在结果页形态这一层又应验了一次。

两个市场用同一套观察表，得出的会是一个被平均掉的假数字。

平均值在这里的欺骗性特别强，因为它总是落在两个真实值中间，看着很稳定。等你按这个稳定的数字做了决策，才发现两边都不适用。这也是凡是跨市场的指标都要先看分布再看均值这条老规矩，在生成式结果这件事上的又一次生效。

从公开的数字报告看，巴西那一年的互联网用户结构 (https://datareportal.com/reports/digital-2023-brazil)跟葡萄牙完全不在同一个阶段，移动端占比、社交渗透率、每天上网时长三项都差得很远。这些差异会直接改变查询的句式长度和提问方式，进而改变触发概率，所以两地的观察绝不能合并成一行。

## 语种、市场、查询类型要拆成三个字段

把前面两节的结论合起来，观察记录的主键其实是一个三元组。

语种决定语言层的处理，市场决定地区层的开放，查询类型决定触发概率。

三者任意一个变了，结果就可能不同。合并任意两个，你就丢掉了一层解释力。

所以那张观察表的表头至少是：日期、语种、市场、查询类型、查询原文、结果三档、设备、界面语言。

八列听起来不少，但每次记录只需要填后面四列，前面四列是固定的。

表格建好之后，每两周花二十分钟填一次，一年就是一份别人拿不到的一手材料。

三元组这个说法值得记住，它可以复用到任何一个新形态的观察上。以后再出现什么新的结果页组件，你要问的第一组问题永远是：它按语言开放还是按地区开放，对查询类型有没有偏好，两者是不是交叉的。问清楚这三件事，观察口径就定下来了。

## 哪些动作现在做有用，哪些做了会白费？

## 现在做有用的三件

第一件是存基线，也就是前面那三条曲线，这件事只有现在能做。

第二件是把问答型内容的结构理顺，让每一个问题都有一段独立的、能被单独摘出来的回答。

这件事在没有生成式结果的时候也有价值，它本来就利于摘要位置。

第三件是把本地事实核对一遍：价格、配送时间、退换政策、联系方式，确保这些信息在页面上写得清楚且一致。

这三件的共同点是，无论生成式结果什么时候铺过来，它们都不会白做。

用投资的话说，这三件是无悔投入。做了不亏，铺过来的时候还能立刻兑现。

第三件事经常被低估。生成式结果在回答本地问题时特别依赖页面上的结构化事实，而多数小语种站的这类信息散落在四五个不同页面上，写法还不统一。把它们收拢到一处并保持一致，这件事的工作量不大，收益却横跨常规搜索和生成式结果两边。

## 现在做会白费的两件

第一件是照着英语市场的引用位打法改内容。那套打法是在已经有生成式结果的环境里摸出来的，你的语言还没有那个环境。

更麻烦的是，等你的语言真的开放了，形态可能已经跟英语市场当初不一样了。

第二件是提前做大规模的内容重写。重写的方向依据尚不存在，等于是在猜。

猜错的成本不只是白干，还包括把原本表现不错的页面改坏。

这两件事的共同特征是：它们的收益依赖一个尚未成立的前提。

无悔投入和赌注投入的区别，就在这个前提成不成立上。

顺便提一个更隐蔽的白费：给还没覆盖的语言单独立项、配人、定季度目标。项目一旦立起来就要交东西，交不出东西就会开始做那些看着像在推进的动作，最后产出一堆报告。等真正该动手的时候，团队的耐心和预算都已经用掉一半了。

判断一件事属于无悔投入还是赌注投入，有个很快的问法：假设生成式结果永远不铺到你这门语言，这件事还值得做吗？答案是肯定的就做，答案是否定的就先放着。这个问法比任何优先级矩阵都省事，而且不需要开会，一个人在工位上就能给所有待办分完类。

## 排期怎么排

把三件有用的事排进未来两个季度，每件配一个具体的人和一个交付物。

存基线的交付物是一份带日期的表格，不是一句已完成。

问答结构的交付物是改造完成的页面清单和数量。

本地事实的交付物是一份核对表，标明每一项在哪个页面、写的是什么。

三件事加起来的投入，大概是一个内容岗位两个月的部分时间，不需要额外预算。

这个规模的投入不用惊动总部，团队内部就能消化掉，这也是它容易落地的原因。

排期上有个小技巧：把观察记录这件事安排在每两周的固定时间，跟例会绑在一起。绑定到既有的节奏上，它就不会因为某个人休假而断掉。独立排期的低频任务，断掉的概率高得出奇。

交付物的定义要写得具体到可以被别人验收。已完成、已梳理、已优化这类说法三个月后没有任何信息量，而一份带日期的表格、一个页面清单、一张核对表，三个月后拿出来仍然能说明问题，也能直接接上下一阶段的工作，不用重新对齐认知。

## 怎么跟总部解释你这门语言还没轮到？

## 别把未覆盖说成落后

汇报时最忌讳的一句话是我们这门语言还落后。落后这个词暗示原因在你这一侧。

事实是原因在产品侧，跟你的内容质量、技术实现、团队能力都无关。

正确的说法是：这门语言目前不在产品的开放名单内，名单的扩展节奏是每三个月一批。

这句话把一个模糊的负面印象，换成了一个有节奏、有依据的客观描述。

接下来把三次扩语的时间点和语言数量摆出来，一张图胜过十页解释。

图上要标清楚你的语言不在其中，以及不在其中的语言还有德语和法语。

把德语和法语拉进来当同伴，是这张图里最有说服力的一笔。总部很难认为德国市场也是能力不行，于是原因自然就被归到产品侧去了。这不是话术，是把真实的分组关系呈现出来，只不过多数人不会主动去查这一层。

措辞这件事在跨国团队里尤其要紧，因为你的汇报材料会被转述好几手。第一手写的是暂未列入开放名单，转到第三手可能就成了这个市场不行。把产品方自己发的那份公告 (https://blog.google/products/search/generative-ai-search/)链接留在材料里，配一句可核对的原文，能挡住大部分走样。

## 要一个复检日期，不要一个结论

汇报的目标不是拿到一个决定，而是拿到一个下次再看的时间点。

结论在这个阶段没有意义，因为最关键的输入变量还没落地。

建议的说法是：三个月后按同一套口径复检一次，届时根据实际状态调整。

同时把这三个月里要做的三件无悔投入列出来，说明它们不依赖复检结果。

这样这次汇报就有了明确的产出：一个日期、三件事、一份口径。

保哥后来把这套结构总结成一句话：在信息不足的时候，正确的输出是复检日期加无悔动作，而不是一个假装确定的结论。

这个做法还有个隐性好处。三个月后复检的时候，你手上有一份连续记录，而当初问问题的那个人手上什么都没有。讨论的主动权会自然回到有数据的一方，这比任何汇报技巧都管用。

复检日期最好定在扩语节奏的下一个窗口之后一两周，而不是随手定在某个季度末。按每三个月一批的节奏推，窗口大致落在哪个月是估得出来的，把复检排在窗口之后，你才有新东西可讲，否则复检会变成把上次的话原样再说一遍。

## 常见问题解答

## 生成式搜索结果目前支持哪些语言？

按公开公告梳理，起点是美国英语，之后加入日语和印地语，再之后一次性加入西班牙语、葡萄牙语、韩语和印尼语，累计七门。德语、法语、意大利语、荷兰语、俄语都还不在名单上。需要注意的是语言开放和地区开放是两个独立维度，语言在名单上不代表你的目标国家一定可用，反过来也成立。判断自己的实际状态，靠公告不如靠十条查询实测二十分钟。

## 我的语言没被覆盖，是不是说明市场不重要？

不是。把七门语言对应的市场排一遍会发现，它们跟广告价值排名对不上，跟母语人口排名也对不上。印尼语的母语使用者比德语少一半以上，却排在德语前面。更能解释这份名单的是两条线：所在市场的规则确定性，以及移动互联网用户的增量密度。这两条都跟你的内容质量和商业价值无关，所以把未覆盖读成不重要，是一次典型的归因错误。

## 没被覆盖的这段时间，最该做的一件事是什么？

存基线。具体是三条曲线：问答型查询在总曝光里的占比、精选摘要的占有率、品牌词与非品牌词的点击结构。它们都能从现有报表里导出，一个人两天能做完，而一旦生成式结果铺过来，覆盖前的数据就永远补不上了。这三条曲线在没有生成式结果的情况下也是内容策略的基础指标，所以下行风险是零，最坏的结果是你多了三张有用的报表。

## 用脚本批量抓结果页来监测可行吗？

早期阶段不建议。生成式结果的加载方式跟普通结果不同，需要等待且不是每次请求都出，同一条查询连测三次可能出两次不出一次，脚本很难区分真的没出和没等到。再叠加地区模拟和登录状态的影响，样本噪声大到没法用。更现实的分工是让脚本负责生成清单、记时间戳、整理表格，把出还是没出的判断交给人，人在这件事上的准确率接近百分之百。

## 观察记录该怎么设计表头？

主键是语种、市场、查询类型这个三元组，三者任意合并都会丢掉一层解释力。完整表头建议是日期、语种、市场、查询类型、查询原文、结果三档、设备、界面语言，一共八列，其中前四列固定，每次只填后面四列。查询清单定下来之后不要再改，想加新词就另开一张表。二十分钟一次、每两周一次，一年下来就是一份竞品拿不到的一手材料。

## 怎么判断自己属于哪种未覆盖状态？

状态有三种：不在名单里且测不出、在名单里但你测的查询不触发、在名单里且能测出。第三种和第二种最容易混淆，原因是大多数人第一批测的是自己排名最好的词，而那类词通常商业意图明确，恰好是触发率最低的一档。正确顺序是先用十条通用疑问句确认语言状态，再用商业词看覆盖面。把第二种误判成第一种，等于白等半年。

## 该怎么跟总部解释这件事？

不要用落后这个词，它暗示原因在你这一侧。改用客观描述：这门语言目前不在产品开放名单内，名单每三个月扩一批。然后把三次扩语的时间点和语言数量画成一条轴，标出德语和法语同样不在其中。汇报的产出不该是一个结论，而是一个复检日期加三件不依赖复检结果的无悔动作。这样三个月后再讨论时，你手上有连续记录，别人手上没有。

## 权威参考资料



## 那页规格书在屏幕上是好好的泰语，机器复制走的是另一串字符

- URL：https://zhangwenbao.com/minor-language-pdf-text-layer-extraction-failure.html
- 分类：小语种SEO
- 发布：2023-10-18  |  更新：2026-07-30
- 摘要：有文本层不等于文字取得出来。讲清子集化换掉编号之后为什么还原不回字符、各书写系统坏起来的形态差在哪、生成端哪一步决定成败，以及小语种内容该不该装进可下载文件。
- 关键词：技术SEO,多语言SEO,内容本地化,小语种SEO

> **TLDR**：摘要：一份泰语规格书在屏幕上一切正常，复制粘贴出来却是一串问号，搜索引擎抓走的也是同一串。它不是扫描件，它有文本层，只是那一层跟眼睛看到的字没有对应关系。根因在导出：字体子集化之后换了一套私有编号，而把编号翻回文字的那张对照表是可选项，很多工具默认不写。拉丁字母几乎撞不上，非拉丁文字则必须靠它。本文讲清三类文件十秒怎么判、各书写系统坏起来长什么样、生成端哪一步决定成败、发出去的几百份还救不救得回来。

> 摘要：一份泰语规格书在屏幕上一切正常，复制粘贴出来却是一串问号，搜索引擎抓走的也是同一串。它不是扫描件，它有文本层，只是那一层跟眼睛看到的字没有对应关系。根因在导出：字体子集化之后换了一套私有编号，而把编号翻回文字的那张对照表是可选项，很多工具默认不写。拉丁字母几乎撞不上，非拉丁文字则必须靠它。本文讲清三类文件十秒怎么判、各书写系统坏起来长什么样、生成端哪一步决定成败、发出去的几百份还救不救得回来。

## 同一份文件，人眼读到的和机器取到的为什么会是两串字？

## 一家园艺机械站的收录页面上，摘要那一栏是空的

有个客户做园艺机械，割草机、打药机、修枝工具这几条线。

德国总部出图纸和文案，各地分站翻译落地，泰国和越南两个市场做了两年。

产品资料一律做成可下载文件挂在站上，规格书、安装说明、保养手册，一款机器三四份。

这批文件在站内的内部链接给得很足，收录也没问题，站长工具里能查到它们躺在索引里。

问题出在收录之后：搜索结果里这些文件的标题是文件名，摘要那一栏是空的，一个字都没有。

更奇怪的是同一批文件的德语版一切正常，摘要里能看到规格表的前两行，泰语版和越南语版则是清一色的空白。团队最先怀疑的是抓取权限，查了一圈响应头和robots规则，全都正常，文件也确实被抓走了。真正的差别不在传输这一层，而在文件内部：抓走的东西里根本没有可读的文字。

## 复制粘贴那一下把问题暴露得最干净

排查的转折点很朴素，把那份泰语规格书打开，框选一段，复制，粘贴到记事本里。

屏幕上选中的是一整行泰语参数，粘贴出来是一行方块加问号，长度还对不上。

换德语版做同样的动作，粘出来一字不差。

这时候结论已经出来了：不是抓取问题，是这份文件里的文字取不出来。

保哥后来把这一步固化成了排查的第一动作，成本是三秒钟，能替掉半天的传输层排查。

顺带说一句，这个动作还有个副作用很有意思：它同时验了用户体验。采购这类机械的人有个很常见的习惯，把规格表复制到自己的比价表格里，粘出来是乱码的话，他不会给你发邮件报告问题，他会换一家。

这个动作还有一个变体值得一起做：把复制出来的字符串丢进任意一个能显示码位的工具，看那些字符落在哪个区间。落在正常的本地文字区间说明只是显示问题，落在私有区或者兼容区就说明写进文件的根本不是用户会打的那批字符。

## 它不是扫描件，这一点最容易被判错

业内讲这类文件的时候，习惯只分两类：一类是原生文字，一类是扫描出来的图片。

扫描件里没有文字，只有像素，所以要先做识别才能被检索到，这条大家都知道。

但这份泰语规格书不是扫描件，它是从排版软件直接导出的，屏幕上放大到八倍字形依然锐利。

它有文字层，能被选中，能被复制，只是复制出来的东西跟屏幕上的字对不上。

换句话说，它落在两类之外的第三类里，而站内已有的那套判断办法只准备了两个格子。

这个第三类的麻烦程度介于两者之间，却比两者都难被发现。扫描件一眼就能看出来，选不中文字，谁都会立刻明白该做识别；原生文字文件复制出来是对的，也没人操心。只有第三类能骗过所有人的眼睛，因为它在人这一侧表现得完美无缺。

判错的代价是排查方向整个走偏。团队一旦认定它是扫描件，接下来的动作就是上识别工具，跑完发现结果比原文还差，于是得出这个格式不适合做优化的结论，把整批资产判了死刑。真正的问题只需要改一个导出选项。

## 把三类摆在一起，判断标准立刻变得可执行

第一类是纯扫描图片，选不中文字，机器什么都读不到。

第二类是原生文字且映射完整，选得中、复制得出、机器读到的跟你看到的一致。

第三类是原生文字但映射缺失或错误，选得中、复制出来是垃圾、机器读到的也是垃圾。

三类的处理办法完全不同，第一类要识别，第二类什么都不用做，第三类要重新导出。

把这三格画进内容验收表，是整件事里最便宜的一次改动，一张表加一列而已。

这张三分表还有一个用法是给供应商提要求。产品资料经常由代理商或者本地经销商提供，验收标准里写清楚交付的文件必须落在第二类，比写一句要求文件清晰可读有用得多，因为后者双方理解不一致，前者可以当场验。

## 文件里的字符流跟屏幕上的字形，是在哪一步脱钩的？

## 排版软件把字符换成了字形编号

文字从输入到显示，中间有一道很多人没意识到的工序，叫字形排布。

这道工序的输入是字符，输出是字形编号加位置，负责的是排版引擎和字体里的规则表。

阿拉伯语的一个字母在词首词中词尾长得不一样，这道工序决定用哪一个形状。

天城文的元音符号要跑到辅音前面去，也是这道工序调换的位置。

这些工作做完之后，文档里存的已经不是你打进去的那些字符，而是一串编号。

把这套流程讲得最清楚的是开源排布引擎的说明文档，它明确写着输出的是字形而不是字符，而字形跟字符不是一一对应的关系——一个字符可能对应多个字形，多个字符也可能合并成一个字形。这句话正是整件事的根源，只是它写在一份字体工程的文档里，做内容和做优化的人基本不会翻到。

值得强调的是这道工序本身完全正确，它是所有非拉丁文字能正常显示的前提。阿拉伯语字母不做位置变形就没法读，天城文元音不重排就是错的。问题从来不在这道工序，而在它的产物被当成最终结果直接存了下来，中间少了一步回填。

## 子集化又给编号换了一套自家的号码

为了让文件别太大，导出时通常只嵌入用到的那些字形，这一步叫子集化。

子集化之后，字形在这份文件里的编号会被重排成一套连续的内部号码。

这套号码是这份文件私有的，换一份文件，同一个字的号码就变了。

页面渲染只需要按号码去取形状，所以显示完全正常。

但取文字的程序拿到的是这串私有号码，它没有任何办法据此还原出原来是哪个字。

小语种站为控制体积做子集化，本身是对的，字形集体积在非拉丁文字上确实是首屏的大头，这笔账在网页字体的字形集在小语种站上有多重 (https://zhangwenbao.com/minor-language-web-font-glyph-set-first-screen-cost.html)那篇里算过。问题不在子集化，在子集化之后有没有补上那张翻译回来的表。

有一个现象可以佐证这套号码的私有性：把同一段文字分别导出成两份文件，用工具把内部编号打出来对比，两份的编号往往完全不同。同一个字在不同文件里是不同的号，这就是为什么外部工具不可能建一张通用的对照表来救。

## 把号码翻回文字的那张表是可选的

文件格式规范里为这件事准备了一个专门的结构，作用就是把内部号码映射回通用字符。

规范把它列为在需要抽取文字内容时应当提供的一项，而不是必须提供的一项。

于是它变成了一道选择题，交给导出工具的默认设置去回答。

有些工具默认写，有些默认不写，有些看你勾了哪个兼容级别才写。

而这道题的正确答案，跟你用哪种文字有直接关系。

这里有一个很容易被读反的地方：规范并没有写错，它写得很清楚，只是它把这件事定位成抽取文字时才需要的能力。二十年前，抽取文字确实是个边缘需求。今天，抽取文字就是被检索、被摘要、被引用的前提，它从边缘需求变成了主路径，而默认值还留在原地。

落到操作上，这一条意味着你不必去理解格式内部结构，只需要在导出环节确认这张表被写进去了。多数专业软件把它绑定在兼容级别或者标签选项上，勾了就有。真正危险的是那些没有任何相关选项的轻量工具，它们通常一律不写。

## 字体内部那张对照表只朝一个方向工作

字体文件里本来就有一张字符到字形的对照表，浏览器和排版引擎都靠它工作。

但这张表是单向的，它回答的是这个字该画成哪个形状。

反过来问这个形状原来是哪个字，表里没有这个方向的答案。

更麻烦的是替换规则会让多个字符合并成一个字形，反推在原理上就不成立。

所以取文字这件事没法靠字体自己解决，只能靠文件里另外补的那张表。

这条机制解释了一个长期让人困惑的现象：为什么同样一份文件，你用阅读器看得好好的，换一个工具抽文字就全是垃圾。因为看和抽走的是两条完全不同的路径，看走的是字形那条路，抽走的是字符那条路，而后一条路上的桥是可选建的。

顺带解释一个常见的误解：换一个更完整的字体救不了这件事。字体再完整，它提供的仍然只有单向映射。字体的完整度决定的是有没有字形可以显示，跟能不能把字形还原成字符是两个独立的问题，前者是显示层，后者是文档层。

## 你手上这份文件属于哪一类，十秒钟怎么判出来？

## 第一招是复制粘贴，三秒钟出结果

打开文件，框选一段正文，复制，粘贴到任意一个纯文本编辑器里。

粘出来跟屏幕上一致，说明映射完整，这一份不用管。

粘出来是问号、方块、乱码或者一片空白，说明映射缺失或错误。

完全选不中，那是扫描件，走识别那条路。

注意别粘到聊天窗口里试，那些地方会做自动清洗，看到的结果不可信。

做这一步的时候别只测一段。文件里不同区块可能出自不同的生成路径，正文是模板套出来的、表格是从表格软件粘进来的、页眉是图片，三者的表现常常不一样。至少测正文一段、表格一格、标题一行，三处都过了才算这一份没问题。

## 第二招是在阅读器里搜一个词

用阅读器自带的查找功能，输入正文里明明存在的一个词。

搜得到，说明文字层可用；搜不到，说明这一份取不出文字。

这一招比复制更接近搜索引擎的行为，因为它走的也是文字检索那条路。

做非拉丁文字的时候要挑一个不含数字和拉丁字母的纯本地文字词。

混着拉丁字母的词经常能搜到一半，那半个结果会把人误导到相反的结论上。

## 第三招是命令行批量抽文字

手上有几百份文件的时候，前两招显然不够用，得让机器跑。

开源的文档处理工具都提供把文字抽成纯文本的命令，一行就能跑一份。

把整个目录跑一遍，输出为空或者输出里非本地文字的比例过高的，就是问题文件。

这一步不需要写复杂逻辑，统计输出里落在本语言字符区间的字符占比就够用了。

占比阈值不用纠结，正常文件通常压倒性地高，问题文件通常接近于零，中间地带很少。

顺带提一句选型：能抽文字的开源库有好几套，行为略有差异，同一份文件有的能抽出来有的抽不出来。做批量体检的时候固定用一套就行，目的是找出问题文件，不是评测工具。

输出结果建议留档而不只是看一眼比例。抽出来的纯文本本身就是一份可搜索的语料，把它跟站内搜索日志里的高频词比对一遍，能顺手回答另一个问题：这批资料里到底有没有覆盖用户真正在搜的那些词。一次跑批，两个结论。

## 第四招是直接看搜索引擎那一侧的结果

前三招看的是文件本身，第四招看的是文件被读成了什么。

在搜索引擎里用文件地址查一下，看它给出的标题和摘要。

摘要空白或者摘要里全是乱码，说明抓走的东西同样不可读。

这一招的好处是它给的是最终结论，而且不依赖你本地装了什么工具。

它的缺点是慢，得等收录，所以适合复盘不适合上线前的验收。

## 判完之后要把结论落到一张表上

体检不落表，三个月后又要重做一遍，这是所有一次性排查的共同命运。

表里至少留四列：文件地址、语言、判定类别、处理动作。

再加一列生成来源，写清楚这份文件是从哪个软件哪条流水线出来的。

最后这一列是整张表里最值钱的，因为同一条流水线出来的文件通常一起坏。

修的时候也一起修，改一次导出设置能一次性带走几十份，比逐份处理省得多。

还有一列值得加：这份文件在站内有没有对应的网页。有网页的那些文件即使暂时修不好，检索这一侧的损失也有限；没有网页又不可读的文件，等于这部分内容在站上完全不存在。这一列直接决定修复的先后顺序。

## 每套书写系统坏起来，长的样子各不相同

## 阿拉伯语和波斯语：变形之后的形状被当成字符存了进去

阿拉伯字母按位置变形，同一个字母有独立、词首、词中、词尾四种形状。

通用字符集里为这些形状单独收录过一个兼容区，是历史遗留，正常文本不该用。

某些导出路径会把变形后的形状写进字符流，于是抽出来的是兼容区里的那些码位。

这种文本看着像本地文字，实际上跟用户在搜索框里打的字符串完全不是一批。

更糟的是它连不成词，检索匹配率接近于零，而肉眼几乎看不出问题。

阿拉伯语站上另一类高频问题是方向与折行，那属于版式层，跟这里说的字符层是两码事，阿拉伯语从右往左最容易翻车的那几处 (https://zhangwenbao.com/arabic-seo-rtl-layout-msa-dialect-keyword.html)那篇讲的是前者，这一篇讲的是后者。两层都会让页面看起来出问题，但排查顺序必须是先字符后版式，反了会被表象带偏。

这一类的判别有个很省事的标志：抽出来的文本用普通的搜索框搜不到，但把它当字符串在文件里搜却能搜到。原因是两边用的码位不同，用户打的是正常字母，文件里存的是变形形状，两者在人眼里长得一模一样。

## 希伯来语：顺序和元音标记两头都可能出事

抽出来的希伯来语文本有时候是反着的，一整行从右往左倒排成字符序列。

这是因为导出时按视觉顺序写入，而不是按逻辑顺序。

视觉顺序的文本在屏幕上看没问题，进了检索就是一串谁也匹配不上的字符串。

另一头是元音标记，某些学术类和宗教类资料带标记，抽出来标记跑到了不该在的位置。

希伯来语本身不写元音这件事已经够让选词头疼了，希伯来语的三个辅音词根能对上七八个搜索词 (https://zhangwenbao.com/hebrew-seo-unvocalized-script-root-letters-keyword.html)那篇算过这笔账，再叠一层顺序错乱就更没法查。

视觉顺序这个问题在老系统导出的文件里尤其常见，因为早期的排版方案就是靠预先把字符倒排来实现从右往左显示的。遇到明显是几年前生成的资料，这一项要单独测，不能用新文件的测试结果代表整批。

## 天城文和泰米尔文：屏幕上的顺序跟存储顺序本来就不一样

印度诸文字里，某些元音符号写在辅音左边，但在存储里它排在辅音后面。

排布引擎负责把它挪到左边显示，这是正常且正确的行为。

出事的是某些导出路径把挪完之后的显示顺序当成存储顺序写了进去。

结果是抽出来的字符串顺序被打乱，读起来像把每个音节都拆了重装。

印度市场的语言本来就摊在好几套书写系统上，印度十一门语言分摊在九套书写系统 (https://zhangwenbao.com/india-multilingual-seo-eleven-languages-nine-scripts-priority.html)那篇算过预算要按后面那个数字走，这一层的体检同样要按书写系统而不是按语言排。

## 泰语：上下叠的那两层记号最容易掉

泰语的声调符号和某些元音符号叠在辅音上下方，一个音节可能摞三层。

抽文字时这几层有时候整层丢失，有时候顺序错乱，有时候被替换成近似字符。

丢掉之后剩下的辅音串依然是合法的泰语字符，所以任何合法性检查都会放行。

泰语的麻烦还叠了一层：它本来就不写空格，切词全靠词典。

记号一丢，词典就更切不动了，泰语标题里找不到一个空格，切在哪儿由引擎说了算 (https://zhangwenbao.com/thai-seo-no-spaces-word-segmentation-keyword.html)那篇讲的分词困境会在这里被放大一倍。

还有一种更隐蔽的形态是记号还在但顺序错了。泰语的声调符号和元音符号有规定的存储次序，次序不对的字符串在屏幕上看不出差别，在检索里却是另一个词。这类问题只能靠跟原稿逐字比对发现，抽样时要专门挑带声调的词。

## 中日韩：全角半角和竖排是两个独立的坑

中日韩文字很少出现整片不可读，更常见的是局部替换。

全角的字母数字被抽成半角，或者反过来，导致规格型号对不上。

竖排文件抽出来的行序有时候是错的，尤其是竖排和横排混在同一页的时候。

日语还有一个专属问题，注音那一层会被拼进正文里，这件事单独讲过一遍。

页面上的注音层跟这里说的取文字问题是同一族的：显示是一回事，取值是另一回事，日语页面上那行给孩子读的小字被程序当成了正文 (https://zhangwenbao.com/minor-language-ruby-annotation-phonetic-layer.html)那篇拆的是同一个机制在网页上的版本。

规格型号是这一类里损失最大的地方。型号本来就是用户最常直接复制的字符串，全角半角一混，复制出来的型号在搜索框里查不到任何东西。做工业品和电子品类的，这一项要单独抽检，而且要挑带字母数字混排的那些型号。

## 越南语：两种码位写法会同时出现在一份文件里

越南语的带记号字母有两种存储方式，一种是单个组合好的码位，一种是基字母加记号。

两种在屏幕上完全一样，在检索里是两个不同的字符串。

同一份文件里两种混着出现是常态，因为它取决于文字是从哪儿粘进去的。

抽出来之后如果不做归一，同一个词在你的语料里会被数成两个词。

越南语用户还有一半人根本不打声调符号，越南语要接的是两拨人，一半打声调另一半从不打 (https://zhangwenbao.com/vietnamese-seo-tone-marks-syllable-spacing-keyword.html)那篇讲过匹配层要做双轨，那套双轨在处理文件抽出来的文本时同样得走一遍。

归一这件事要放在抽取之后立刻做，别等到进了索引再补。做法是把抽出来的文本统一转成同一种写法，转换规则是现成的标准算法，任何一门语言的开发库里都有。这一步跑完，同一个词才会在你的统计里只出现一次。

## 拉丁字母为什么几乎从来不出这个事？

## 它的编号跟通用字符集天然对得上

拉丁字母的编码历史让它占了个便宜：常用字母的码位跟老的单字节编码基本一致。

字体的默认编码方案也是围绕这一批字母建的，导出工具对它的处理路径最成熟。

于是即使那张翻译回来的表没写，工具也常常能靠标准编码猜对。

猜对的前提是这个字符在标准编码表里有位置，非拉丁文字大部分没有。

所以同一个工具，处理英语文件时表现完美，处理泰语文件时全军覆没。

## 唯一露过头的是那两个连字

拉丁世界唯一大规模遇到这个问题的地方，是排版连字。

某些字体会把相邻的两个字母合并成一个字形，最常见的是fi和fl这两组。

合并之后如果映射没补上，抽出来的是兼容区里的那个连字符号，而不是两个字母。

于是一个正常的英文词在检索里断成两截，中间多了一个谁也不认识的字符。

这件事在英语出版圈是个众所周知的老问题，解法也早就有了。

有意思的是这个老问题的规模：英语里受影响的只有几组字母，占全部文本的比例极小，改不改都不影响大局。所以它一直被当成一个排版细节而不是一个类别。等同一个机制换到非拉丁文字上，受影响的是全部文本，而方法论那一侧还停在把它当细节的阶段。

顺带记一个可以直接拿去用的检查项：在抽出来的英文文本里搜一下有没有出现连字的那几个码位。有的话说明这条生成链路会把合并后的字形写进字符流，那么同一条链路生成的非拉丁文字文件几乎必然有更严重的问题，可以直接排到修复队列前面。

## 德语的长复合词会把这件事放大

德语的复合词长，一个词里出现连字组合的概率自然比英语高。

词一旦在中间断开，剩下的两截都不是真实存在的词。

德语站上还有另一类看不见的断词字符，那是前端为了排版塞进去的，机制不同但后果相似。

两件事叠在一起，同一个词能被切出三四种不同的碎片。

那一类字符的排查办法在为了让德语长词在手机上不撑破，前端往标题里塞了个看不见的字符 (https://zhangwenbao.com/minor-language-line-break-soft-hyphen-invisible-character.html)那篇里写过，扫描脚本可以直接复用，只是扫描对象从页面换成了文件。

德语还有一个叠加因素是断词符号。长复合词在窄栏里会被自动断开并插入连字符，某些导出路径会把这个排版用的连字符当成正文字符写进去。于是一个词在字符流里带着一个原文没有的符号，检索时自然对不上。

## 所以这件事从来没被当成一个类别

整套文档优化的方法论是拿英语写出来的，这一点在很多地方都成立。

英语作者遇到的是几组连字，于是文档里写的是注意连字。

非拉丁文字作者遇到的是整份文件不可读，而文档里没有对应的条目。

这不是谁疏忽，是样本决定的：写规范的人没见过整片失效的情形。

你能做的是把它补成一个类别写进自己的验收表，别指望通用清单里会有这一条。

把它写进自己的验收表时，措辞要具体到可执行。写检查文件可读性没有用，写抽取文本中目标语言字符占比不低于某个阈值才有用。前者是态度，后者是判据，而这件事在人眼里完全不可见，只有判据能拦住它。

## 生成端的哪一步真正决定了这份文件能不能被读？

## 排版软件导出时的那两三个开关

专业排版软件的导出对话框里，跟这件事相关的选项通常有三处。

一是兼容级别，选较新的级别通常会把映射表一起写进去。

二是是否创建带标签的结构，打了标签的文件在文字抽取上明显更稳。

三是字体嵌入方式，完整嵌入比子集化保险，代价是文件变大。

三处的默认值都不是为非拉丁文字准备的，所以模板要在项目开始时就定好。

## 用浏览器打印成文件的那条路要单独测

很多站的资料是用网页模板生成再打印成文件的，这条路省事，也确实常用。

它的表现取决于浏览器和系统字体，同一份网页在两台机器上能导出两种结果。

最常见的翻车是服务器上没装对应语言的字体，回退到了一个覆盖不全的字体。

屏幕上看是方块，导出的文件里那些字符干脆就没有。

这条链路的体检必须在真实的生成环境上做，本机测通不算数。

这条链路还有一个容易忽略的细节：网页上用的字体如果是通过网络加载的，生成环境能不能访问到那个地址直接决定结果。很多批量生成任务跑在没有外网的机器上，字体加载失败之后静默回退，生成的文件在测试环境完全正常。

## 模板引擎批量生成的那条链路问题最集中

规格书这类文件通常是从数据库里取数据套模板批量生成的，一次生成几百份。

批量生成的好处是一致，坏处也是一致：错了就是几百份一起错。

这类链路里最常见的问题是字体配置写死在模板里，加语言的时候没人改。

加一门语言相当于加一套文字，而模板里那行字体配置还停在项目启动那天。

模板这件事在多语言站上是个通用风险源，一个模板生成十种语言，信息层十份一模一样 (https://zhangwenbao.com/multilingual-template-ten-languages-duplicate-content-risk.html)那篇讲的是内容侧的塌陷，这里是渲染侧的塌陷，两者共用同一个根因：模板的变量位留够了，语言参数没留够。

批量链路的修复反而是最划算的，因为改一处配置能一次带走几百份文件。所以体检表里那一列生成来源要填得尽量细，细到能定位是哪个模板哪个版本。填到这个粒度，修复工作量往往从几百份文件塌缩成三五处配置。

## 字体选择比导出设置更早决定结果

导出设置能补救的前提是字体本身规矩。

字体规矩的意思是它的字符到字形映射完整，没有大量私有区字符。

有些装饰性字体和老字体把字符塞在私有区，那部分从原理上就还原不回来。

私有区的字符在任何标准里都没有含义，抽出来只能是问号。

所以字体选型要在项目最前面做，做完之后拿一份真实内容跑一次完整体检。

选型阶段有个成本很低的验证动作：用候选字体排一段真实内容，导出一份文件，跑一遍抽取。这一步花不了半小时，却能在项目启动前就排除掉那些注定要返工的字体。等到几百份资料都做完再发现字体有问题，返工成本是另一个量级。

## 打标签这件事顺带解决了另外两个问题

带标签的文件会记录内容的逻辑结构，标题是标题，表格是表格。

这件事最初是为无障碍做的，读屏软件靠它决定读的顺序。

顺带的好处是抽文字时的顺序也跟着变可靠，多栏排版尤其明显。

规格书通常是多栏加表格，不打标签抽出来的顺序经常是串的。

所以给非拉丁文字资料打标签是一次投入换三份收益：无障碍、抽取顺序、检索质量。

要注意打标签不能替代映射表。带标签的文件结构清楚，但如果映射表缺失，抽出来的仍然是垃圾，只是垃圾排得整整齐齐。两件事各管一段：标签管顺序和结构，映射表管字符本身，缺哪一个都不行。

## 已经发出去的那几百份，还救得回来吗？

## 先按能不能拿到源文件分两堆

能拿到源文件的那堆最好办，改导出设置重新生成就行。

拿不到源文件的那堆要走识别，把文件当图片重新读一遍。

识别的准确率在非拉丁文字上参差不齐，规格表这类结构化内容尤其容易串行。

所以第二堆的处理成本比第一堆高一个数量级，能找到源文件就别省这个力气。

分堆之前先排优先级，按下载量和入口链接数排，别按文件数量平摊人力。

找源文件这件事值得多花点力气。产品资料的源文件通常散在设计外包、代理商和历任负责人的硬盘里，翻一遍的成本是几天，而它决定了后面是走几分钟的重新导出还是走按份计价的识别。这笔账在文件数量上百的时候差距非常明显。

## 第三条路是把文字搬到网页上

有一类文件既拿不到源文件，识别成本又不划算，比如老型号的资料。

这时候更划算的做法是把关键内容重新写成网页，文件本身保留供下载。

网页承接检索，文件承接下载，各干各的活。

这条路的额外好处是网页可以随时更新，而文件一旦发出去就很难追回。

做这件事的时候别把网页做成纯粹的下载页，那样等于把内容又埋了一次。

搬的时候优先搬三样东西：规格参数表、常见问题、以及型号和配件对照。这三样是用户最常搜也最常复制的内容，搬完之后即使原文件仍然不可读，检索这一侧的损失也基本被兜住了。其余的图示和安装步骤可以留在文件里。

## 要不要换地址，这一步别急着动

修好之后原地替换是首选，地址不变，已有的链接和收录都保得住。

只有在文件名本身就有问题的时候才考虑换地址，比如文件名是一串编码。

换地址要配跳转，规则跟页面搬家是同一套，这里不展开。

文件名该用本地文字还是拉丁转写，小语种地址用本地字母还是拉丁转写 (https://zhangwenbao.com/minor-language-url-native-script-vs-latin-transliteration.html)那篇给过判据，结论在文件上同样成立。

顺带提醒一句，替换之后记得让抓取重新跑一遍，否则索引里那份不可读的版本会继续挂着。

## 修完之后怎么确认真的修好了

验收动作跟体检动作是同一套，复制粘贴加命令行抽文字。

抽出来的文字要跟原稿逐字比对一段，别只看有没有输出。

有输出但内容错乱的情况在多栏排版里很常见，光看非空是判不出来的。

最后再等一轮收录，看搜索结果里的摘要有没有变成正常文字。

这一轮验完，才算真的闭环，前面几步都只是自己这边的确认。

建议把验收做成一份可复跑的脚本而不是一次性的人工核对。脚本每月跑一次全量文件目录，输出不合格清单。资料这类资产的特点是持续新增，一次性清理干净之后，半年内又会因为新链路上线而重新长出问题文件。

## 小语种内容到底该不该装进这种格式？

## 哪几类内容天生适合

需要精确排版并且要被打印出来的内容，天生适合这个格式。

安装图、接线图、尺寸图、保修卡，这些东西的价值就在于版式固定。

合规文件和认证证书也是，它们需要的是不可篡改的呈现而不是检索。

这类内容不用纠结检索问题，它们本来就不承担获取流量的任务。

但它们仍然要做体检，因为用户复制型号和参数是很常见的动作。

## 哪几类放进去等于把流量埋了

选型指南、对比说明、常见问题、保养建议，这几类是典型的埋流量。

它们的内容天生适合被检索，放进文件之后要多过一道抽取的关。

而这道关在非拉丁文字上的通过率，前面已经讲得够多了。

更现实的一点是，用户在手机上打开这类文件的体验普遍很差。

小语种市场的移动端占比通常更高，这笔账在移动端还要再乘一次。

判断某一类内容该不该放进文件，有个很直接的问法：这份内容存在的目的是让人读到，还是让人打印出来。目的是被读到的，就该以网页为主；目的是被打印或者归档的，才该以文件为主。这个问题问出来，多数分类当场就有答案。

## 一份内容两种载体怎么分工

最稳的做法是网页承载全文，文件承载可打印版本。

两者内容一致，网页在前，文件作为下载入口挂在网页里。

这样检索走网页，打印走文件，两条路互不打架。

要避免的是只有文件没有网页，那等于把内容押在抽取这一道关上。

也要避免网页只放一句简介加一个下载按钮，那样检索侧拿到的信息量近乎为零。

## 下载量和自然流量是两笔账

文件的下载量往往很好看，尤其是工业品类。

但下载量高不等于这批内容在获取新访客，很多下载来自已经找到你的人。

要判断它有没有带来新访客，得看有多少访问是从搜索结果直接落到文件上的。

这个数在非拉丁文字站上通常低得吓人，而原因往往就是本文讲的这一件事。

把这个数单独拉一列出来看，是说服团队投入修复的最快办法，比讲原理管用得多。

拆这个数的时候顺便看一眼落地路径：从搜索结果直接落到文件上的访问，有没有后续的站内浏览。多数情况下这个后续转化很低，因为用户落在一份文件里之后没有导航可用。这也从另一个角度说明为什么把内容锁在文件里不划算。

## 标题、文件名和语言标记这三处该怎么填？

## 文档标题跟文件名不是一回事

文件内部有一个标题属性，搜索结果里优先显示的是它而不是文件名。

这个属性经常是空的，或者留着模板里的默认值，比如未命名文档。

填它的成本几乎为零，收益是搜索结果里那一行字变成人话。

批量生成的链路上，这个属性应当跟着数据一起填，别留给人工。

顺带一提，很多批量生成的文件标题写的是数据库里的产品编码，那跟未命名的差别不大。

批量生成的时候，这个属性最好按一个固定模板填：产品名加文档类型加语言。这样搜索结果里那一行既能读懂又有区分度，用户在下载文件夹里也能一眼分清同一款产品的三四份资料。成本是模板里加一行拼接。

## 文件名走拉丁转写这条老规矩

文件名用本地文字会在地址里变成一长串编码，日志和外链里全是乱码。

这条规矩在页面地址上已经成立多年，在文件上完全一样。

文件名走转写，标题属性用本地文字，两处分工正好互补。

这跟商品图那六个能写字的位置是同一套思路，同一张商品图的文件名和替代文本要用两套字母写同一个词 (https://zhangwenbao.com/minor-language-image-alt-text-non-latin-script-search.html)那篇把位置分层讲得最细，文件资产可以照着那张表再画一张。

## 语言标记至少有三处要填

文件内部有语言属性，页面上的链接可以带语言提示，页面本身也有语言声明。

三处填一致，抓取那一侧判断语言的把握就大得多。

短文本页面本来就容易被判成另一门语言，文件也一样，抽出来的文本越少判错概率越高。

判断语言归属其实可以靠字符层的证据，两种语言都看得懂的用户而你的站只能有一套地址 (https://zhangwenbao.com/ukrainian-russian-seo-bilingual-market-content-split.html)那篇里讲过怎么用几个互不重叠的字母做语言识别，同一套办法用在文件抽出来的文本上一样成立，前提是那串文本本身是可读的。

这几处填不一致的时候，最容易出问题的是文件内部那一处，因为它经常保留着模板的默认值，通常是英语。一份泰语资料的内部语言标记写着英语，抽出来的文本又不可读，两个错误叠加，判定结果基本上就是随机的。

## 结构化数据那一侧要不要动

产品页上如果引用了这些文件，可以在标记里给出下载地址和格式。

标记里的语言字段按国际格式填，正文按本地习惯写，这两件事的方向是相反的。

这条反直觉的规矩在正文越本地化越好，结构化数据里却要反着写回国际格式 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)那篇里拆过，文件字段照着同一套走就行。

不建议为不可读的文件补一堆标记，那是给一份读不出内容的资产加装饰。

顺序应该是先修文件，再补标记，反过来做等于把资源花在最没有杠杆的地方。

## 程序读到一串垃圾字符，比什么都读不到更糟

## 空白至少是诚实的

扫描件读不出内容，抓取那一侧拿到的是空，处理逻辑很干脆：没有内容。

没有内容意味着这份资产不参与匹配，损失是它本可以带来的那部分流量。

损失明确，边界清楚，也容易被发现。

不可读的文字层则不同，它给出的是一串看起来像文本的字符。

看起来像文本的东西会被当成文本处理，这才是问题的开始。

这条对比可以推广成一条更一般的判断：在内容质量的排查里，缺失通常比错误好处理，因为缺失是自证的而错误需要被识别。凡是产物看起来完整、格式合法、只是含义不对的问题，都要专门设计判据去逮，指望它自己暴露是不现实的。

## 一串乱码会被当成内容对待

抓到的字符会进入索引，会参与语言判定，会被当成这个页面的内容特征。

一份泰语规格书抽出来是兼容区字符，语言判定可能给出一个莫名其妙的结论。

更麻烦的是同一批文件抽出来的乱码高度相似，因为它们出自同一套内部编号。

高度相似的内容会触发重复判定，于是几百份资料被折叠成一份。

而你在报表上看到的现象是这批文件的收录量莫名其妙地掉，原因却根本不在内容上。

重复判定这一层的连锁反应最容易被误诊。报表上看到的是这批资料收录量下滑，最自然的猜测是内容质量或者抓取预算，很少有人会想到根因在字符层。这也是为什么值得把文件的抽取体检做成常规项，它能在诊断链条的最前端就把这条路排除掉。

## 跟注音层那件事的差别在哪儿

注音那件事是同一个位置摞了两串字，两串都是真的字，只是不该拼在一起。

这件事是同一个位置只有一串字，而这串字跟屏幕上显示的没有关系。

前者是多了一层要分流，后者是这一层根本对不上要重做。

两者的共同点是所有以合法性为判据的检查都会放行，因为产物在格式上完全合法。

这条规律在小语种的技术层问题里反复出现：真正难查的从来不是格式错误，而是格式正确但含义错位的东西，机器不报错，人也看不出来，只能靠专门设计的判据去逮。

两件事还有一个共同的实操结论：判断显示正常与否毫无意义，必须去看取值那一侧。网页上的做法是读取节点的文本内容，文件上的做法是抽取纯文本，动作不同但问的是同一个问题——机器眼里这一页到底写了什么。

## 哪些事不归这一层管

文件加载慢、体积大、移动端阅读体验差，这些是资产管理和性能的事。

要不要用下载表单换取联系方式，那是获客策略的事。

文件的版本管理和过期资料下架，那是内容运营的事。

这一篇只回答一件事：这份文件里的文字，机器能不能正确地取出来。

把这件事跟上面几件分开，排查的时候才不会在第一步就走进另一个部门的地盘。

## 常见问题解答

## 不懂泰语，怎么自己判断一份泰语文件有没有问题？

完全不需要懂那门语言。打开文件，选中正文里的一段，复制，粘贴到纯文本编辑器里，然后做一件事：把粘贴出来的字符串跟屏幕上的字对一下长度和形状。你不需要认识那些字，只需要判断它们看起来是不是同一批符号。粘出来是问号、方块或者空白，就是有问题；粘出来是一串跟屏幕上长得一样的字符，就没问题。

更省事的办法是让机器判：把文件抽成纯文本，统计输出里落在泰文字符区间的字符占多大比例。正常文件这个比例压倒性地高，问题文件接近于零。这个判据对任何一门你不认识的语言都成立，需要的只是知道那门语言的字符区间，查一次通用字符集的分区表就有。

## 为什么同一份文件在阅读器里看得好好的，抽出来就是乱码？

因为看和抽走的是两条不同的路。看这条路只需要知道每个编号该画成什么形状，字体里带着这个信息，所以永远不会出错。抽这条路需要知道每个编号原来是哪个字符，这个信息不在字体里，得靠文件生成时另外补一张对照表。这张表在规范里是抽取文字时才需要提供的，很多导出工具默认不写。

所以显示正常完全不能作为文件健康的证据。这也是为什么这类问题能活很久：负责做资料的人天天在看这些文件，从来没觉得有什么不对。要发现它，必须有人做一次显示之外的动作，而复制粘贴恰好是成本最低的那个动作。

## 用识别的办法统一处理一遍，是不是更省事？

不建议当成首选。识别是把文件当图片重新读一遍，它能绕开映射缺失的问题，但会引入新的错误，尤其是在规格表这种密集数字和型号的内容上。串行、认错小数点、把型号里的字母数字混淆，这几类错误在识别结果里很常见，而它们恰好落在最不该出错的地方。

正确的顺序是先分堆：能拿到源文件的重新导出，这条路准确率是百分之百；拿不到源文件又确实值得救的，才走识别，而且识别完要人工抽检关键数值。识别更适合处理真正的历史扫描件，对本文讲的这一类问题，它是备选方案不是主方案。

## 把资料全部改成网页，是不是就一劳永逸了？

检索这一侧确实一劳永逸，但会丢掉这个格式真正的价值。安装图、尺寸图、保修卡这类内容的价值在于版式固定和可打印，改成网页反而是降级。工业品类的采购流程里，把一份规格书打印出来带进会议室仍然是常见动作，这件事没法用网页替代。

更合理的形态是两者并存且分工明确：网页承载全文并负责检索，文件承载可打印版本并挂在网页里。要避免的两种极端是只有文件没有网页，以及网页上只放一句简介加一个下载按钮。后一种看起来两者都有，实际上检索侧拿到的信息量跟没有网页差不多。

## 这件事跟字体子集化冲突吗，为了修它要不要放弃子集化？

不冲突，两件事可以同时做。子集化解决的是体积，映射表解决的是可读性，一份文件完全可以既做了子集化又带着完整的映射表。所以不需要为了修这个问题去放弃体积优化，需要的只是在导出设置里把那张表打开。

要注意的是有些老工具确实做不到两者兼得，遇到这种情况优先保可读性。理由很简单：资料文件的体积问题主要影响下载速度，而下载发生在用户已经找到你之后；可读性问题影响的是用户能不能找到你。两个问题的先后顺序很清楚，先解决把人带进来的那个。

## 带标签的文件和普通文件，在检索上的差别有多大？

差别主要体现在结构复杂的文件上。单栏纯文字的文件，打不打标签抽出来的结果差不多。多栏排版、带表格、图文混排的文件差别就很明显，不打标签抽出来的顺序经常是串的，一段话的后半句接到了另一栏的开头。规格书恰好是结构最复杂的那一类，所以它从打标签里得到的收益最大。

另外打标签这件事本来是为无障碍做的，读屏软件靠它决定朗读顺序。所以这一次投入同时买到三样东西：无障碍合规、抽取顺序正确、检索质量提升。在需要满足无障碍要求的市场里，这笔投入本来就要花，顺带把检索这一侧的问题解决掉，性价比是整件事里最高的。

## 怎么防止新做的资料再犯同样的问题？

把它变成流水线的一道自动检查，而不是一份人工清单。具体做法是在文件发布的环节加一步：抽文字，统计目标语言字符占比，低于阈值直接拦下不许上线。这一步跑一份文件不到一秒，接进现有的发布流程几乎没有成本，而它能一劳永逸地挡住整条链路上所有的回归。

人工清单在这件事上不可靠，原因是这个问题在人眼里完全不可见。清单上写着检查文件可读性，执行的人打开文件看了一眼，觉得没问题，就打了勾。要让检查真的发生，判据必须是机器能执行的那种，而这个判据恰好非常好写。



## 德语商品页上那个短横替掉了半个词，分词器切出来的是不存在的词

- URL：https://zhangwenbao.com/minor-language-coordination-ellipsis-list-keyword.html
- 分类：小语种SEO
- 发布：2023-08-17  |  更新：2026-07-28
- 摘要：商品页密度最高的句法结构是列举，而列举会为了不重复把词写残，被写残的那半截恰好是用户在搜的那个词。讲清补充连字符为什么删不得、芬兰语的列举把词拉开多远、阿拉伯语连词怎么吃掉一个词，以及不动正字法把词补回来的三个位置。
- 关键词：关键词研究,多语言SEO,内容本地化,小语种SEO

> **TLDR**：摘要：德语商品页写“夏季和冬季款”时，正字法要求把前一个词写成一个短横加半截词。于是完整复合词在整页上一次都没出现，而用户搜的正是那个完整词。这个短横删不得，删了就是错别字。芬兰语的列举把形容词和名词拉开两个词，阿拉伯语的连词直接粘掉一个词头，模板里写死的那个逗号在每门语言里规则都不同。本文把列举结构造成的关键词缺口拆成四类，给出不动正字法也能把词补回来的三个位置。

> 摘要：德语商品页写“夏季和冬季款”时，正字法要求把前一个词写成一个短横加半截词。于是完整复合词在整页上一次都没出现，而用户搜的正是那个完整词。这个短横删不得，删了就是错别字。芬兰语的列举把形容词和名词拉开两个词，阿拉伯语的连词直接粘掉一个词头，模板里写死的那个逗号在每门语言里规则都不同。本文把列举结构造成的关键词缺口拆成四类，给出不动正字法也能把词补回来的三个位置。

## 商品页上最常见的那个句法结构，为什么最容易出问题？

## 从一个德国母婴站的季节配件说起

那是一家做德国市场的母婴用品站，主推婴儿车配件。

其中一类是脚套，分夏季款和冬季款两种。

德语商品标题写的是Sommer- und Winterfußsäcke。

这一行读起来毫无问题，德国同事也确认写法完全规范。

可是搜索表现一直不对劲：冬季款的词有排名，夏季款几乎为零。

后来把整页的源码搜了一遍才发现，Sommerfußsack这个完整词在页面上一次都没有出现过。页面上出现的是Sommer- 加一个短横，然后跳到了und。而用户在搜索框里打的，从来都是那个完整的复合词。整整一个季度，这条产品线在德语搜索里等于不存在。

最讽刺的是，这个写法不仅没错，还是德语正字法明确要求的那一种。

这个站后来把德语站上所有带省略连字符的标题都导了一遍，一共一百四十多条，其中六十几条的省略半截都是有独立搜索量的完整词。也就是说这不是一条产品线的偶发问题，是整个德语站的系统性缺口，只是从来没有人从这个角度数过。

## 列举在商品页上的密度有多高

先说清楚这件事的量级，不然听着像个边角问题。

把一个典型的商品详情页拆开数一遍，列举结构的密度高得吓人。

标题里有并列的品类，属性区有并列的颜色和尺码。

卖点段落里有并列的材质，适用场景那一段几乎整段都是列举。

配送与保障那一块，也是一串用顿号或者逗号连起来的短语。

粗略数下来，一个商品页上百分之四十以上的名词短语都出现在某种并列结构里。这个比例在分类页和筛选页上还要更高，因为那两类页面的正文本来就少，剩下的几乎全是列表。换句话说，列举不是一种偶尔出现的句式，它是商品页的主要句式。

一种句式如果占了页面上大半的名词，它一旦出问题，问题就不会是局部的。

还有一个容易被忽略的加权因素：列举结构最集中的地方，恰好是页面上权重最高的几个位置。标题、属性区、面包屑这些地方字数少、被引用多，一处缺口的影响远大于正文段落里的同类缺口。密度高再叠上位置好，损失就被放大了两次。

顺便说一句，列举密度还能当成一个粗糙的风险指标用。把各个模板的正文抓下来，数一数并列连词和分隔符的出现频次，频次最高的那几个模板就是这类缺口最集中的地方。排查从它们开始，比按品类逐个翻页面效率高得多。

## 这不是排版问题也不是翻译质量问题

这类现象很容易被归到两个错误的抽屉里。

第一个抽屉叫排版：有人会说这是前端的显示格式，改样式就行。

可这个短横不在样式表里，它在字符串里，是正文的一部分。

第二个抽屉叫翻译质量：有人会说是译者偷懒省了字。

可事实正相反，写完整反而是不规范的。

把两个抽屉都排除掉之后，剩下的那个位置很不舒服：这是一个人人都做对了、但结果对你不利的情形。母语审校验收清单那篇 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)讲过一句读着自然不能当作验收通过的判据，这里是同一条规律的另一个面：一句写得完全规范，同样不能当作验收通过的判据。

规范和有效，在这一层第一次公开地分了家。

把它归错抽屉的代价不只是修不好，还会把责任推给不该负责的人。归到排版就去找前端，前端查完样式表说没问题；归到翻译就去找译者，译者拿出规则集说写法没错。两轮下来问题还在，团队里却先积了一层互相怀疑。

## 判据：页面上的字符串和页面表达的概念对不对得上

这类问题需要一把简单的尺子，不然每次都要争论。

这把尺子只有一句话：页面上出现的字符串，和页面想表达的那个概念，是不是同一串字符。

正文里可以模糊，标题里可以简略，这两处从来不要求严格相等。

但用户在搜索框里打出来的那一串，是要跟索引里的字符串对上的。

列举结构是唯一一类会让这两者系统性不相等的句法结构，而且不是偶然不相等。

是规范要求它们不相等。这一点跟别的坑都不一样：别的坑修一修就好了，这个坑修了会变成新的错。颜色范畴与属性值那篇 (https://zhangwenbao.com/minor-language-color-category-attribute-value.html)讲过枚举值是全站唯一一处必须严格相等的地方，而列举结构恰好是把严格相等打破得最理直气壮的地方。

两条规律撞在一起，撞点就在商品页上。

这把尺子还有一个附带好处，它能顺手识别出另一批表面无关的问题。凡是页面上用缩写、代称、省略指代来避免重复的地方，都会在同一把尺子下现形。重复本身在写作上是缺点，在检索上却常常是优点，这个矛盾在中文站上一样存在。

## 德语那个短横为什么不能删？

## 补充连字符是正字法规定的写法

德语里这个短横有正式名字，叫补充连字符。

它的作用是在并列的复合词里，替掉重复的那一半。

Sommer- und Winterfußsäcke的意思是夏季脚套和冬季脚套。

两个复合词的后半截都是Fußsäcke，重复写一遍在德语里被视为累赘。

于是前一个词只保留自己独有的那半截，剩下的用一个短横顶替。

这个规则写在德语正字法官方规则集 (https://www.rechtschreibrat.com/regelwerk/)里，不是某本风格指南的偏好，而是所有德语出版物共同遵守的硬规则。Duden的补充连字符词条 (https://www.duden.de/rechtschreibung/Ergaenzungsstrich)把用法和例子列得很清楚，包括前置省略和后置省略两种方向。

换句话说，这不是一个可以商量的写法。

省略的方向还分两种，前面省和后面省。Sommer- und Winterfußsäcke是省后半截，而Fußsäcke für Sommer und -winter这类写法则是省前半截，短横挂在词的左边。两种方向造成的残片形状不同，写检查脚本时得同时考虑，只匹配一种会漏掉一半。

## 删掉它是错别字，保留它是缺半个词

知道了这条规则之后，第一反应通常是把它改掉。

把Sommer- und Winterfußsäcke改成两个完整词并列，看起来就解决了。

问题是这么写在德语读者眼里是明显的笨拙，接近于错别字。

一个卖婴儿车配件的品牌，在标题上写出这种句子，信任感是要打折的。

所以这里没有一个两边都赢的改法，只有取舍。

更准确地说，这是一个把语言规范和检索需求摆在同一根轴上的局面：往任何一边挪都要付出另一边的代价。比较级与最高级那篇 (https://zhangwenbao.com/minor-language-comparative-superlative-keyword-forms.html)里出现过一次类似的对立，那次是搜索侧和合规侧在同一串字符上给出相反的评分，这次是搜索侧和语言规范。

凡是双方都在引外部依据的争论，都不是判断问题，只能找第三种做法。

真要衡量这个取舍，可以把它换算成一个能比较的数：改成完整并列之后，读者的观感损失是长期而弥散的，而不改的搜索损失是可以直接用那个词的搜索量估出来的。一边模糊一边清晰的时候，人总倾向于向清晰的那边妥协，这恰恰是最该警惕的地方。

## 母语审校为什么一次都不会提这件事

这条最容易让人意外。

母语审校的任务是判断这句话对不对、地道不地道。

而补充连字符的写法，既对又地道，属于标准答案。

审校员看到它只会打勾，不会觉得这里有任何需要说明的地方。

他甚至意识不到这是一个可以被提出来的问题。

这跟否定词缀那篇 (https://zhangwenbao.com/minor-language-negation-affix-exclusion-keyword-trap.html)里的情形是同一类：凡是完全合规的写法，都不会触发任何一道质量关卡。质量关卡查的是错误，而这里没有错误，只有一个缺口。缺口和错误在流程上是两种东西，前者需要有人专门去找。

顺便说一句，这也是为什么这类问题往往是做SEO的人先发现的。

想把这件事纳入审校流程，靠加一条规则是没用的，因为审校员没有判断依据。可行的做法是把问题换个问法：不要问这句写得对不对，而是把那个完整词直接列给他，问这个词在这一页上出现过没有。问法一换，他立刻能回答，而且答案是二值的。

## 页面上没有的那个词，用户为什么在搜？

## 用户搜的是完整复合词

用户不会在搜索框里打出补充连字符。

他要买夏季脚套，打的就是Sommerfußsack。

没有人会打Sommer- und Winterfußsäcke去搜一个具体的东西。

这个不对称是这类问题的根源：写作端用省略式，检索端用完整式。

德语的复合词构词能力越强，这个不对称就越明显。

德语复合词那篇 (https://zhangwenbao.com/german-seo-compound-words-umlaut-eszett-keyword-research.html)讲过德国人管这东西叫另一个词，那说的是选词层面的错位。这里的错位更靠后一步：词选对了，形态也对了，但那串字符被一个规范化的省略吃掉了一半。

选词错了还能查出来，这种缺口在词表里是查不出来的。

这个不对称还有一层：写作端的省略是为了避免重复，而检索端的重复恰恰是必要的。写作追求的简洁和检索需要的冗余，在复合词发达的语言上第一次直接冲突。英语站上很少遇到，因为英语的并列多是两个独立单词，省不掉什么东西。

## 分词器切出来的那个残片是什么

从索引侧看，这件事更清楚。

分词器读到Sommer- und Winterfußsäcke这一串。

短横在多数分词器眼里是词边界，于是它切出Sommer这个片段。

这个片段在德语里是一个真词，意思是夏天。

而Sommerfußsack这个组合，索引里根本没有。

更麻烦的是切出来的东西看起来一点都不可疑。Elasticsearch的分词器参考 (https://www.elastic.co/guide/en/elasticsearch/reference/current/analysis-tokenizers.html)里，标准分词器对连字符的处理就是按词边界切开，这个行为本身没有任何毛病。首字母缩略语那篇 (https://zhangwenbao.com/minor-language-acronym-initialism-local-forms-inflection.html)讲过分词器把非字母字符当词边界这条规律，那次这条规律帮了倒忙，这次它同样帮了倒忙，只是方向反了过来。

你得到的不是一个坏词，而是一个正确的、无害的、完全不是你要的词。

这里还有一个更让人无从下手的地方：切出来的那个残片经常是本语言里的高频词。夏天这个词在德语站上到处都是，它在索引里的存在感不但不低，反而很高。于是你既看不到缺失，也看不到异常，只能看到一堆完全正常的高频词。

## 精确匹配、短语匹配和词干还原都救不了

接下来通常会有人问：加个词干还原是不是就好了。

答案是不行，而且理由值得说清楚。

词干还原处理的是同一个词的不同形态，比如单复数、格尾。

Sommer和Sommerfußsack不是同一个词的两种形态，是两个不同的词。

复合词拆分能帮上一点忙，但它的方向是把长词拆短，不是把短片段拼长。

换句话说，所有归一化手段都是做减法的，而这里需要的是加法。Solr的语言分析文档 (https://www.solr.apache.org/guide/solr/latest/indexing-guide/language-analysis.html)里德语的复合词处理器也是同一个取向，它能把Fußsäcke从长词里分出来，却没法把Sommer和Fußsack重新拼回去，因为它无从知道该拼哪一个。

工具的默认取向永远来自它诞生时的那个场景，这一条在关键词工具无数据那篇 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)里已经验证过一次。

有人会想到用同义词表把残片映射到完整词，这条路在小范围内可行，但扩展性很差。因为映射关系依赖上下文：同一个Sommer- 在脚套页面上该映射成脚套，在睡袋页面上该映射成睡袋。一旦要按页面维护映射表，成本就超过了直接补一份完整写法。

这里还能引出一条更一般的判断：凡是需要靠上下文才能还原的信息，都不适合放进索引层去解决。索引层能做的是稳定的、与上下文无关的变换，一旦规则开始依赖页面语境，它的维护成本就会随页面数量线性增长，而收益却不会。

## 报表上看到的是搜索量正常但页面不出现

这类缺口在报表上的样子很有辨识度。

关键词工具会告诉你Sommerfußsack有搜索量，而且不低。

你的站有对应的商品，分类也对，页面也被收录了。

可这个词的展现次数接近于零，排名根本进不了前一百。

如果只看展现和点击，很容易误判成竞争太激烈。

识别办法其实很朴素：把那个词原样丢进站内搜索，如果自己的站都搜不到，那就不是竞争问题。站内搜索用的是同一套分词逻辑，它给出的空结果比任何外部工具都直接。这个动作十秒钟就能做完，却能把一整类误判挡在外面。

保哥后来把这一步固定成了新站上线前的例行检查，代价小到没有理由不做。

这种缺口在报表上还有一个更细的特征，值得记下来：同一个复合词族里，被省略的那一半排名极差，而没被省略的那一半排名正常。冬季款有排名夏季款没有，两个词的商业价值和竞争度却相差无几，这种不对称本身就是最强的信号。

## 跟看不见的软连字符比，这个坑差在哪儿？

## 一个能删一个不能删

德语站上还有另一个跟短横有关的坑，两者很容易混。

那个坑是前端为了让长词在手机上不撑破，往词中间塞了一个不可见字符。

两件事都跟连字符有关，都发生在德语长词上，都影响关键词匹配。

但它们在一个最关键的地方正好相反。

软连字符是可以删的，删掉之后页面完全正确，只是排版可能难看一点。

补充连字符不能删，删掉之后页面就有语法瑕疵了。软连字符那篇 (https://zhangwenbao.com/minor-language-line-break-soft-hyphen-invisible-character.html)的结论是把不该出现的字符拿掉，本篇的结论只能是把该出现的字符留着，另外再补一份完整写法。同一类现象，两个相反的解法。

分清楚这一点，能省下很多把两件事混着修的力气。

这两个坑还有一个共同的迷惑点，它们都会让人先怀疑编码或者字体。看到词被切开的第一反应往往是字符集出了问题，于是去查数据库排序规则、查页面编码、查字体是否缺字形，一圈查下来什么都正常，才想到去看那个短横到底是什么东西。

## 一个在样式层能修一个只能在内容层修

还有一个差别在修补发生的位置。

软连字符那件事，正解是把断行交回给样式表。

换句话说，那个问题可以整体挪到样式层解决，字符串本身恢复干净。

补充连字符没有这条路，因为它承载的是语义不是版面。

它替掉的是半个真实的词，不是一个换行提示。

这就把可选的修补位置压到了内容层：要么改正文，要么在正文之外另找一个能放完整写法的地方。字符层、标记层、样式层这三层的撤销成本依次降低，而本篇这个坑一开始就落在最贵的那一层上。

知道自己在哪一层，比知道怎么修更重要。

这条分层判断可以推广到别的现象上：拿到一个跟字符有关的问题，先问它被删掉之后页面还对不对。删了仍然对的，属于表现层，成本低；删了就错的，属于内容层，只能靠增补。这一个问题就能把绝大多数字符类问题分到正确的处理路径上。

## 两者共用的判别办法

虽然解法相反，识别这两类问题的办法是同一个。

把页面正文原样复制出来，扔进一个纯文本编辑器。

然后搜索你希望这个页面命中的那个完整词。

搜不到，就说明页面表达了这个概念却没有写出这串字符。

至于原因是不可见字符还是省略连字符，看一眼那个位置就知道了。

这个检查的好处是不需要懂德语。执行的人只要会复制粘贴和按查找键，判据是二值的，没有任何主观空间。审校验收那篇 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)提过一个原则，能交给不懂那门语言的人做的检查，才是能长期跑下去的检查。

凡是需要语感才能执行的规则，最后都会名存实亡。

这个检查还可以顺手做成批量的：把一批页面的正文抓下来存成纯文本，再拿一份必须命中的完整词清单逐行查找，输出没命中的行。二十行脚本就能跑完整站，而且完全不涉及语言判断。人只需要看那份没命中的清单，逐条判断该走哪一类修补。

## 芬兰语的列举把两个词拉开了多远？

## 每一项都要带格尾

换一门语言，列举的坑就换一种长相。

芬兰语里说黑色和白色的鞋，形容词要跟着名词一起变格。

写成mustat ja valkoiset kengät，三个词的词尾是一致的。

如果放进内格，整串就变成mustissa ja valkoisissa kengissä。

三个词全都换了词尾，中心词也不例外。

这意味着黑鞋这个组合在页面上从来不是两个相邻的词。芬兰语十五个格那篇 (https://zhangwenbao.com/finnish-seo-fifteen-cases-consonant-gradation-keyword.html)讲的是单个词的形态爆炸，这里叠加了一层：形态爆炸之后，列举又把爆炸过的词彼此推远了。

一个词形对不上还能靠词干还原兜，两个词被拉开就没得兜了。

这里要注意一个反直觉的地方：芬兰语的形容词跟着变格并不是可选的修辞，而是强制的语法一致。写成不变格的形式不是风格问题而是语法错误。所以这条跟德语那个短横一样，属于不能靠改写规避的类型，只能在别处补。

## 邻近度算法假设它们相邻

这一层的损失落在匹配算法上。

短语匹配要求词按顺序相邻，中间隔一个词就不算命中。

邻近度打分宽松一些，但距离越远权重越低。

mustat kengät这个组合被ja valkoiset挤开了两个位置。

用户搜的却正是这两个词紧挨着的形式。

这是个很容易被算成运气不好的损失。锚文本变格那篇 (https://zhangwenbao.com/minor-language-internal-link-anchor-inflection-variants.html)说过屈折语站的精确匹配那一栏数字是假的，那里的原因是词形变了，这里的原因是词被隔开了。两个原因加在一起，屈折语的短语匹配基本可以当成不存在。

报表上你只会看到一个偏低的数字，看不到它是被哪一种机制吃掉的。

还有一层损失落在用户自己身上：他在站内搜索里打黑鞋，如果站内搜索也用短语匹配，同样搜不到。于是这类页面在外部搜索和站内搜索上同时失分，而站内搜索的空结果率是个能直接看到的指标，往往比外部排名更早暴露问题。

## 列举越长，中心词离第一个修饰语越远

这个距离还会随着列举变长而变长。

列两种颜色，中心词离第一项两个位置。

列四种颜色，就变成六个位置。

而商品页上的颜色列举，四五项是很常见的。

芬兰语的官方逗号规则 (https://kielitoimistonohjepankki.fi/haku/pilkku)里，并列成分之间用逗号，最后一项前用ja，这跟德语的写法一致。

于是有一条很反直觉的推论：列举写得越完整，第一项跟中心词的匹配就越差。为了信息完整而多列几项，反而在检索侧扣分。这不是让人少写，而是说明这类信息不该只放在一串列举里。

顺带一提，这也解释了为什么筛选器里的属性值单独存一份是有必要的。

把这条推论写成可执行的规则就是：属性类信息不要只靠一串列举承载，同一份信息至少要有一处以中心词加单个修饰语的形式出现。这个要求听起来像是让人写重复的话，但重复的那一份可以放在结构化数据或者筛选值里，不必出现在正文上。

这条推论还解释了一个常见的困惑：为什么内容写得越详尽，某些长尾词的表现反而越差。答案是详尽通常意味着把更多信息压进同一句话，而压得越密，词与词之间的距离就越远。详尽和可匹配在这一层是有张力的，不是同一个方向。

## 阿拉伯语的连词为什么会吃掉一个词？

## 连词不加空格粘在下一个词头上

阿拉伯语给出了这一类问题里最极端的一个版本。

阿拉伯语表示和的连词是一个单独的字母，写作 و。

但它不像英语的and那样独立成词，它直接连写在后一个词的前面。

鞋这个词写作 الأحذية，加上连词就变成 والأحذية。

中间没有空格，视觉上就是一个更长的词。

结果是列举里的第二项、第三项，每一项的词头都多了一个字母。阿拉伯语SEO那篇 (https://zhangwenbao.com/arabic-seo-rtl-layout-msa-dialect-keyword.html)整理过六个最容易翻车的地方，那些都跟方向有关，这一条跟方向无关，纯粹是构词。

用户搜的当然是不带连词的那个形式。

这个连写规则不只作用于连词，阿拉伯语里还有好几个单字母前缀是同样的写法，比如表示介词的那几个。也就是说列举只是暴露它的场合之一，凡是句子里出现这类前缀的位置，都会产生同样的粘连。列举之所以最明显，是因为列举里这类前缀出现得最密集。

## 分词器把它当成一个新词

分词器面对这一串，没有任何理由把开头那个字母切下来。

它看到的是一串连续的阿拉伯字母，中间没有空格也没有标点。

于是索引里多了一个 والأحذية，而 الأحذية 少了一次出现。

专门为阿拉伯语写的分析器会处理这类前缀，但默认分析器不会。

而多数站点上线时用的正是默认分析器。

这一条的普遍形态是：凡是靠空格判断词边界的机制，在把功能词连写进实词的语言里，都会把功能词算进实词。OpenSearch的文本分析文档 (https://www.opensearch.org/docs/latest/analyzers/)里，语言专属分析器和默认分析器的差别在阿拉伯语这类语言上体现得最明显。

差别不在精度高低，而在于有没有那一步。

判断自己的站有没有踩这个坑，办法很直接：把同一个词带前缀和不带前缀的两种形式分别丢进站内搜索，看结果数是不是一样。如果带前缀的那个返回零条，而不带的那个正常，就说明分析器没有做前缀剥离这一步。这个测试三十秒能做完。

## 跟标点制造词边界正好方向相反

把这条跟前面德语那条并排放，会看到一个漂亮的对称。

德语那个短横，制造了一个不该有的词边界，于是词被切碎了。

阿拉伯语这个连词，消灭了一个该有的词边界，于是词被粘长了。

一个多切一刀，一个少切一刀。

两者的共同点是：分词器都完全按规则执行，没有一步做错。

由此可以提炼一条更一般的判据：在评估一门语言的列举结构之前，先问它是靠什么字符把并列项分开的，以及那个字符在别处还有没有别的身份。德语用的是空格加短横，短横还兼着省略的差事；阿拉伯语用的是一个直接连写的字母，它根本不占一个位置。

把这个问题问清楚，后面所有决定都会跟着变简单。

这对反向的例子还能推出一条更省事的做法：与其逐条排查每门语言的列举写法，不如先把每门语言的并列连接手段列成一张表，写清楚它占不占一个独立的位置。占位置的语言风险在切碎，不占位置的语言风险在粘连，两类的修补方向完全不同。

把这张表建起来还有个额外好处，它能让新语言上线的评估变成半小时的事。要开一门新语言的时候，先填这张表的三列：并列用什么连接、连接词占不占位置、列举项要不要变形。三列填完，这门语言在列举结构上的全部风险就已经摆在桌面上了。

## 模板里写死的那个逗号，该由谁决定？

## 德语und前不加逗号是规则

列举还有一个更少人注意的层面，是分隔符本身。

英语世界为了要不要在and前面加逗号吵了几十年。

德语没有这个争论，因为规则很明确：und前面不加逗号。

法语的et前面同样不加。

芬兰语的ja前面也不加。

Duden关于逗号的词条 (https://www.duden.de/rechtschreibung/Komma)里把并列连词前不加逗号列为基本规则之一。这一条本身不值几个钱，值钱的是它带出来的一个事实：分隔符的规则由语言决定，而模板是全站共用的。

一个由代码写死的标点，撞上了一条按语言变化的规范。

这条规则在页面上的可见后果比想象中大。中文和英文的商品模板习惯在最后一项前加一个连词再加逗号，德语页面照搬之后，多出来的那个逗号在德国读者眼里是一个明确的标点错误。它不影响检索，但会让整页显得不是本地人做的。

## 日语中黑和中文顿号不是同一个符号

换到东亚语言，分隔符的分歧更大。

中文列举用顿号，写作、这个符号。

日语在外来语并列时习惯用中黑，写作・这个符号。

两者长得不像，码位不同，用法也不完全重叠。

日语里顿号也用，但用在不同的场合。

日语写法那篇 (https://zhangwenbao.com/japanese-seo-hiragana-katakana-kanji-keyword-notation.html)讲过同一个概念的三套写法不是同一批人在搜，分隔符也有类似的分层效应。一个中日共用的商品模板如果把分隔符写死成半角逗号，两个市场的页面看起来都会有点怪，而怪的方向还不一样。

这类小事不会有人来投诉，它只是让页面显得不是本地人做的。

这两个符号还有一个技术上的差别值得记：中黑在很多分词器里被当作词内字符处理，而顿号被当作分隔符。也就是说用中黑连起来的两个外来语词有可能被切成一个长词，而用顿号连起来的会被正常切开。选错符号不只是观感问题。

## 模板变量拼出来的列举串

真正的麻烦出在模板拼串的那一行代码上。

典型写法是把属性数组用一个固定分隔符连起来。

这一行在英文站上跑了很多年，从来没出过事。

它默认了三件事：分隔符是逗号、最后一项前面有个and、各项之间不需要变形。

这三件事在德语上错两件，在芬兰语上三件全错。

更隐蔽的是，这行代码没有语言参数，所以它不是通用的，它是选了默认值的，而默认值来自英语。这条规律在大小写折叠那篇 (https://zhangwenbao.com/minor-language-case-folding-lowercase-turkish-dotless-i.html)里第一次成立，在拼列举串这件事上第二次成立。

凡是没有语言参数的函数，都值得单独看一眼。

这一行代码还有一个更隐蔽的默认：它假设列举项的顺序是无所谓的。而在不少语言里，最后一项因为紧挨着连词，形态会跟前面几项不同。数组顺序一变，需要变形的那一项就换了人，模板却完全不知道自己漏掉了什么。

## 分隔符应该跟语言走还是跟模板走

知道有问题之后，还得决定改到什么程度。

把分隔符做成按语言配置，成本不高，一张表就够了。

但列举的整体写法要不要按语言改，是另一回事。

比如最后一项前用连词还是用符号，属于语言习惯。

再比如每一项要不要变格，那已经不是分隔符能解决的了。

保哥的做法是分两档：分隔符和连词进配置表，需要变形的列举一律不用模板拼。前者一次改完永久生效，后者交给内容侧写死在文案里。这条线画在哪里，取决于那门语言的列举项要不要跟着变形。

芬兰语、波兰语这类语言，模板拼列举基本上是走不通的。

这条线还有一个实际的划法，就是看这门语言的列举项要不要变形。不变形的语言可以放心用模板拼，只要把分隔符和连词做成配置；要变形的语言，模板拼出来的每一句都有语法瑕疵，不如一开始就交给文案写死。判断只需要问译者一句话。

## 拆成列表项之后，每一项就没有上下文了

## 列表项之间不共享中心词

还有一种常见的改法，是干脆把列举拆成列表。

把黑色白色灰色三项各放一行，看起来清爽多了。

移动端阅读体验确实更好，这一点没有争议。

但拆开之后，每一项都变成了一个独立的文本块。

黑色这一行里，没有鞋这个词。

MDN关于无序列表元素的说明 (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ul)里强调每个列表项是一个独立的内容块，这在结构上是优点，在检索上却意味着上下文被切断在了每一项的边界上。原本一句话里的修饰关系，拆完之后要靠读者自己补。

人补得上，机器不一定。

这个副作用在移动端尤其明显，因为移动端的列表往往还会折叠，只展开前三项。于是被折起来的那几项在页面源码里虽然存在，实际被抓到的上下文更少。可读性优化和可检索性优化在这里第一次分道扬镳，而前者通常有人负责，后者没有。

## 抽取式摘要拿到的是孤立词

这个副作用在被抽取的时候最明显。

一段被抽出来当答案的内容，往往只包含列表里的几项。

孤立的黑色两个字，脱离了它修饰的那个名词。

如果这一段被单独展示，读者看不出在说什么。

更糟的是这一段有可能根本不会被选中，因为它信息密度太低。

解法不是不用列表，而是让每一项自己带上中心词，或者在列表前那一句里把中心词说全。这个取舍在结构化数据那篇 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)里也出现过，正文越本地化越好，机器读的那一份反而要写得笨一点。

笨一点的写法在这一层是优点。

要判断自己的列表会不会出这个问题，有个很土的办法：把任意一个列表项单独抄出来，念给一个没看过这个页面的人听，问他这在说什么。答不上来的，就说明这一项脱离上下文之后不成立。这个测试不需要任何工具，两分钟能测完一整页。

## 什么时候该用列表什么时候不该

这就需要一条能当场判断的标准。

如果每一项本身就是完整概念，用列表没问题。

比如配送方式、支付方式，每一项拿出来都能读懂。

如果每一项是修饰语，脱离中心词就没意义，那就不该拆。

颜色、尺码、材质这几类都属于后者。

一句话概括：列表适合并列的实体，不适合并列的属性。属性天生依附于别的词，把它单独立成一行，等于人为制造孤儿。这条判据不需要懂目标语言，看中文原稿就能判。

能在中文稿阶段判掉的问题，永远比翻完再修便宜。

这条判据还能反过来用，帮着决定哪些内容值得单独建页。凡是列表项本身就是完整概念的，它往往有独立的搜索需求，也就有独立成页的价值；凡是必须依附中心词才成立的，单独建页只会得到一批内容单薄且互相重复的页面。

这条判据在中文站上同样成立，只是表现得没那么剧烈。中文的属性词脱离中心词之后仍然勉强能读懂，所以问题被掩盖了。到了变格语言和复合词语言上，同样的写法会把损失放大好几倍，而写法本身是从中文原稿一路继承下来的。

## 三类修补：补写法、拆句子、绕开列举串

## 第一类：正文保留规范写法，另补一份完整写法

回到德语那个短横，正解已经很清楚了。

正文里的Sommer- und Winterfußsäcke一个字都不动。

另外找一个位置，把Sommerfußsack完整写一次。

这样规范和检索各拿各的，不需要互相让步。

关键是那个位置要既真实又不别扭。

能用的位置比想象中多：商品的完整名称字段、面包屑的末级、图片的替代文本、结构化数据里的商品名。图片替代文本那篇 (https://zhangwenbao.com/minor-language-image-alt-text-non-latin-script-search.html)讲过同一张图的文件名和替代文本要用两套字母写同一个词，这里是同一个思路的另一种用法。

补一份，不是改一份。

补的时候有一个细节要守住：补进去的那个完整词必须是真实自然的用法，不能是把省略号强行还原出来的怪词。德语复合词的拼接有连接音的规则，还原时少一个字母就成了另一个不存在的词。这一步必须由母语者确认，是整套流程里唯一必须找人的环节。

## 第二类：把并列拆成独立短句

第二类修补适合正文段落里的列举。

如果一句话里塞了三个并列的复合词，读起来也累。

拆成两三个短句，每句只讲一件事。

拆完之后每个复合词都能写全，短横自然就没了。

这个改法的额外好处是段落变短，移动端更好读。

但它有边界：标题和属性区不能这么改，因为那两处本来就要求紧凑。所以第二类只在正文里用，第一类才是标题区的解法。两者分工明确，混用会让标题变得啰嗦。

凡是解法都有适用范围，写清楚适用范围比写解法本身更有用。

拆句子还有一个附带收益：拆开之后每个复合词都能带上自己的形容词和限定语，句子的信息密度反而提高了。原本挤在一串列举里的三个卖点，拆成三句之后各自都有了展开的空间，正文长度增加的同时可读性并没有下降。

## 第三类：筛选器和结构化数据不走列举串

第三类是从源头上绕开。

筛选器背后的取值，本来就不该来自正文里的那串列举。

它应该来自一份独立的属性表，每个值单独一行。

结构化数据里的字段同理，一个值一个字段。

这样正文怎么写都不会影响到机器读的那一份。

这条其实是在说一件更基本的事：凡是需要严格相等的数据，都不该从自然语言里现场解析。正文是给人读的，解析正文来填结构化字段，等于把语言习惯的所有不确定性引进了数据层。

把两条管道分开，是这一类问题最省事的一劳永逸做法。

这一类修补的真正难点不在技术，而在于说服。把筛选值从正文解析改成独立字段，通常要动数据模型，排期上不好插队。可以先用一个折中办法：保留现有解析逻辑，但给需要严格相等的那几个属性单独建表，先覆盖高价值的品类，再逐步扩大。

## 怎么在不动正字法的前提下把词补回来？

## 三个可以放完整写法的位置

把第一类修补说得再具体一点。

第一个位置是商品名称字段，也就是数据库里那个完整品名。

它通常不出现在标题上，但会进结构化数据和站内搜索索引。

第二个位置是详情段落的第一句，那里可以自然地把完整词说一遍。

第三个位置是常见问题区，用户会用完整词提问，答案里自然也带着它。

这三个位置的共同点是：写完整词在那里不显得奇怪。不奇怪很重要，硬塞进标题会让德国读者一眼看出这是给机器看的。前面提过的那家母婴站最后用的是第一和第三个位置，一个季度之后那条产品线的展现量回到了正常区间。

没有做任何违反正字法的事，词就补回来了。

这三个位置还有一个共同的实操优势，就是它们都不在设计稿的管辖范围内。改标题要过设计和品牌两道关，改商品名称字段和常见问题区不用，内容团队自己就能改完。选修补位置时把审批成本一起算进去，落地速度会差出好几倍。

这三个位置里，常见问题区其实是最被低估的一个。用户提问时用的一定是完整词，答案里跟着复述一遍也完全自然，不会有任何生硬感。等于是让用户的提问习惯替你把那个缺失的字符串补回了页面上，成本几乎为零。

## 一份可以交给非母语者执行的检查表

最后把整篇压成一份能执行的东西。

第一步，列出这一批页面必须命中的完整词，一行一个。

第二步，把页面正文复制成纯文本，逐个查找。

第三步，查不到的词，看它在页面上是以什么形式出现的。

第四步，按四类归档：省略连字符、连词粘连、列举拉开、拆成列表。

第五步，前两类走补写法，后两类走改句式或者绕开列举串。这五步里没有一步需要判断地不地道，全部是查找和归类。搜索意图分歧那篇 (https://zhangwenbao.com/minor-language-search-intent-divergence-across-markets.html)提过一个原则，能被非母语者执行的检查才有可能长期跑下去，这份表就是照着那个原则写的。

需要母语者的地方只剩最后一步：确认补进去的那个完整词写法没错。

这份表最好固定跑在两个时间点上：一是新品上架时，二是每次批量导入商品数据之后。这两个时刻是缺口被批量制造出来的时刻，事后再排查等于把同样的活干两遍。把它挂进上架流程的检查清单里，比单独安排一次全站排查有用得多。

## 什么时候该承认这条不值得修

也不是每一处都值得动手。

如果那个被省略的半截词本身没有搜索量，修了也没有收益。

如果那个词已经在页面别处出现过，那就不存在缺口。

如果整个品类在这门语言上都不是重点市场，优先级自然靠后。

判断只需要两个数：那个完整词的搜索量，和它在你站上的出现次数。

两个数都拿到之后，决定就变成了机械动作：有量且为零的先修，有量但已出现的跳过，没量的一律不动。这样一批页面里通常只有一两成需要处理，而那一两成往往贡献了这一类缺口的大部分损失。

把力气花在能算出收益的那部分，比全站排查省事得多。

还有一种情况也该放过，就是那个完整词的搜索意图跟你的页面根本不匹配。有些被省略的半截词搜索量不低，但搜它的人想要的是另一类东西。这时候把词补进去，得到的是一批高展现低点击的曝光，对整页的表现反而是负担。

## 常见问题解答

## 补充连字符只在德语里有吗？

不只德语，但德语最典型。荷兰语、瑞典语、丹麦语这些日耳曼语族的语言都有复合词并列时省略共同部分的写法，规则细节各有不同。荷兰语的写法跟德语几乎一致，瑞典语和丹麦语则更倾向于直接写完整词。差别的根源在于各自的复合词长度分布，词越长省略的收益越大，规范也就越倾向于允许省略。判断一门语言要不要做这项检查，可以先看它的商品标题平均有多长。如果标题里经常出现十五个字母以上的名词，多半就有这个问题。判断标准可以再简单一点：只要那门语言的商品标题里经常出现两个复合词并列，就值得查一遍。

## 把完整词硬塞进标题会不会有风险？

会让本地读者觉得别扭，这本身就是风险。更稳的做法是放在商品名称字段和常见问题区，那两处写完整词是自然的。标题是整页可见度最高的位置，塞进去的每一个词都会被读者读到。硬把完整词加上去，德语读者第一眼看到的就是一个啰嗦的标题，品牌感会往下掉。更划算的做法是把标题交给语言规范，把完整词交给那些用户不太会逐字阅读的位置。这个分工的前提是那些位置真的会被索引，所以配置之前要先确认它们没有被排除在抓取范围之外。另外要留意的是，商品名称字段在有些系统里并不进索引，配置之前先确认它会被抓到。

## 复合词拆分器能不能解决这个问题？

不能。拆分器的方向是把长词拆短，而这里需要的是把残片补长，两者方向相反。拆分器的训练目标是把复合词切成有意义的成分，它面对Sommer- 这个残片时并不知道后面本该跟着什么。理论上可以从上下文推断，但那已经不是分词的活了。更根本的问题在于，即使推断对了，索引里存的仍然是推断结果而不是页面上的字符串。一旦推断规则改动，整批索引的行为就跟着变，这种不可控性比缺口本身更麻烦。实践中更稳的做法是把拆分器当成诊断工具用，看它把哪些词切成了什么，而不是指望它修复缺口。

## 芬兰语的列举问题有没有省事的解法？

没有通用解法，只能不用模板拼串，把需要变形的列举写死在文案里。芬兰语的困难在于列举项必须跟着中心词一起变格，这是语法强制而不是风格选择。模板拼串永远拼不对，因为模板不知道整个短语要落在哪个格上。可行的路只有两条：需要变形的列举由文案直接写死，或者干脆改写成每项一句的短句。前者适合标题和属性区，后者适合正文段落，两者可以在同一个页面上并用。还有一个折中办法，是把最常搜的那几个组合单独写成短句放进详情段落，不必处理全部列举。

## 阿拉伯语的连词粘连要怎么处理？

换成语言专属分析器，它会处理这类前缀。默认分析器不会做这一步。换成语言专属分析器是最省事的办法，主流检索引擎都内置了阿拉伯语分析器，它会把连写的功能词前缀剥掉。要注意的是切换分析器需要重建索引，不能热切。另外还要确认站内搜索和外部检索用的不是同一套逻辑，很多站只改了其中一边。改完之后拿带前缀和不带前缀的两种形式各搜一次，结果数一致才算生效。如果暂时改不了分析器，退而求其次可以在结构化数据里把每个属性值单独存一份，绕开正文解析。

## 列表和逗号串到底哪个更好？

看每一项是不是完整概念。是实体就用列表，是属性就别拆。判断标准是每一项能不能脱离中心词独立成立。配送方式、支付方式这类本身就是完整概念，用列表更清楚；颜色、尺码、材质这类是属性，拆开就成了孤儿。还有一个折中做法，是在列表前那一句里把中心词说全，让后面的每一项都有依托。这样既保住了移动端的可读性，也不至于让抽取出来的片段没头没尾。实在拿不准的时候，可以两种形式并用：列表前那一句把中心词说全，列表里保持简洁，两边的好处都能拿到。

## 这类缺口占关键词损失的比例大概是多少？

没有普适数字，要按站测。办法是把必须命中的完整词列一遍，数出其中在页面上根本不出现的比例。这个比例跟语言和品类都相关，没有可以直接搬用的数字。测法是先列出这一批页面必须命中的完整词，再统计其中在页面正文里根本不出现的比例。德语站上这个比例通常在两成到四成之间，芬兰语更高，英语站几乎为零。拿到自己站的数字之后，再乘上这些词的搜索量总和，就能算出这一类缺口值不值得专门排一轮。拿到比例之后还要再看一步，就是这些缺失词的搜索量集中度，如果集中在少数几个词上，修补的性价比会高得多。

## 权威参考资料



## 为了让德语长词在手机上不撑破，前端往标题里塞了个看不见的字符

- URL：https://zhangwenbao.com/minor-language-line-break-soft-hyphen-invisible-character.html
- 分类：小语种SEO
- 发布：2023-06-14  |  更新：2026-07-28
- 摘要：软连字符和零宽空格肉眼看不见，却写进了HTML，标题去重、关键词核对、结构化数据全会读到它。讲清排版层三种修补分别落在字符层、标记层还是样式层，各自的污染范围有多大，以及一条十分钟扫全站的检测思路。
- 关键词：技术SEO,多语言SEO,小语种SEO

> **TLDR**：摘要：德语的长复合词在手机上会把布局撑破，最省事的修法是往词中间插一个软连字符；泰语没有空格，最省事的修法是插零宽空格。这两个字符肉眼看不见，却实实在在地写进了HTML，于是标题去重脚本、关键词表、结构化数据和搜索引擎读到的都是被切开的两个词。本文把排版层的三种修补和它们各自的污染范围拆开，给出一条十分钟能扫全站的检测正则。

> 摘要：德语的长复合词在手机上会把布局撑破，最省事的修法是往词中间插一个软连字符；泰语没有空格，最省事的修法是插零宽空格。这两个字符肉眼看不见，却实实在在地写进了HTML，于是标题去重脚本、关键词表、结构化数据和搜索引擎读到的都是被切开的两个词。本文把排版层的三种修补和它们各自的污染范围拆开，给出一条十分钟能扫全站的检测正则。

## 为什么德语页面在手机上会横向溢出？

## 复合词的长度分布跟英语完全不是一回事

德语的复合词是把几个名词直接拼在一起，中间不加空格。

常用商品词里二十个字母以上的很普遍，三十个字母也不罕见。

英语表达同样的概念会拆成三四个词，中间有空格。

空格是断行机会，有空格的文本可以在任何一处折行。

没有空格的一长串字符，浏览器默认不会从中间切开。

这是排版引擎的正确行为，不是缺陷。默认的断行规则只允许在词与词之间断开，而复合词在语法上就是一个词，引擎没有理由也没有依据知道该在哪个音节之间切。于是这一整串字符会被当成一个不可分割的盒子，宽度超过容器就直接顶出去。

还有一个容易被忽略的因素是德语的复合能力是开放的，新的组合随时可以造出来而不需要进词典。也就是说你没法通过统计现有词表的长度分布来给宽度封顶，因为下一个上架的商品可能带来一个更长的词，容器必须按弹性来设计而不是按一个固定的最大值。

## 容器宽度是按英语文案标定的

大多数模板的容器宽度是在英语版本上试出来的。

试的时候用的是英语商品名，最长的那个也就十来个字母。

换成德语内容之后，同一个容器要装两倍长的字符串。

芬兰语、匈牙利语、荷兰语都有同样的问题，程度不同而已。

问题最先出现在窄的那几个位置：卡片、按钮、面包屑、筛选项。

这一层的根因不在断行也不在字体，在于宽度预算这件事从来没有按目标语言重新算过。检查办法很直接：把每种语言的商品名按字符数排个序，取最长的那几个，逐个塞进最窄的那个组件里看会不会顶出去，一小时能扫完全站的关键组件。

这件事在设计评审阶段几乎不可能被发现，因为评审时用的是设计稿里的示例文案，而示例文案默认是英语的。要让它显形，最省事的做法是让设计师在稿子里放一条真实的德语商品名，只要放一条，问题当场就会暴露出来。

## 溢出最先出现在哪几类组件上

商品卡片的标题区是第一个，因为它宽度固定且通常只给两行。

筛选面板是第二个，那一栏的宽度往往只有一百多像素。

面包屑是第三个，它是单行的，一旦超宽就会把整页撑出横向滚动。

表格的表头是第四个，列宽被内容撑开之后整张表都会变形。

按钮上的文字是第五个，它超出之后会直接盖住旁边的元素。

这五个位置有一个共同点，就是它们的文案通常来自数据库字段而不是手写的页面文案。手写文案的作者能看到效果，会自己调整措辞；数据库字段是批量灌进去的，没有人逐条看过它在页面上长什么样。阿拉伯语在窄屏上的类似情况另见阿拉伯语网站搬进手机之后要重验的那份清单 (https://zhangwenbao.com/arabic-rtl-mobile-first-narrow-screen-pitfalls.html)。

还有一类位置比这五个更隐蔽，就是那些默认隐藏、只在特定状态下才展开的组件，比如下拉菜单、悬浮提示、移动端的折叠筛选。它们不在常规的页面截图里，测试时也很少被逐个展开，往往要等用户反馈才会被发现。

## 一个数字：最长的那个词有多少字符

做这件事之前先取一个数，就是你的商品名字段里最长的那一条。

这个数字一拿出来，很多讨论就不需要发生了。

英语站上这个数字通常在三十以内，德语站上经常超过五十。

拿这个数字去乘以字号，就能算出它需要多宽的容器。

算出来的宽度如果超过手机屏幕，那这条内容必然要断行。

顺便建议把这个数字加进上线前的检查项，每次新增语言或者新增品类都重新取一次。它是一个成本几乎为零的先行指标，比等到用户反馈横向滚动条要早得多。字体本身带来的开销另见网页字体在小语种站上占掉的首屏成本 (https://zhangwenbao.com/minor-language-web-font-glyph-set-first-screen-cost.html)。

取这个数的时候顺便看一眼它的分布，别只看最大值。如果只有极个别几条特别长，那可能是数据录入问题而不是语言问题，改那几条比改整套模板划算得多；如果长条目占了一两成，那就是实打实的语言层特征，必须在版式上解决。

## 前端最常用的三种修补，分别落在哪一层？

## 字符层、标记层、样式层

第一种修补是往词里插一个软连字符，也就是往字符串里加字符。

第二种是插一个换行机会标签，加的是HTML标记不是字符。

第三种是给容器加断行相关的样式规则，不动内容一个字。

三种办法在页面上的视觉效果可以做到几乎一样。

但它们进入内容的深度完全不同，这个差别决定了后果。

第一种的字符会成为文本节点的一部分，凡是读取文本的程序都会读到它；第二种是元素，多数取文本的接口会把它跳过，但不是全部；第三种完全不进入内容，只影响渲染。三者的污染范围从大到小排成一条清晰的梯度。

这三层的顺序不是随便排的，它同时也是撤销成本从高到低的顺序。字符层最难撤，因为它散落在数据里；标记层次之，因为它集中在模板里；样式层最容易，因为它只在一两个文件里。选型时先想撤销成本，往往能避开后面最贵的那笔账。

## 判别法：写在字符串里还是写在样式表里

面对任何一个排版修补，问一句它最终写在哪里就够了。

写进样式表的，内容不受影响，改起来也不影响别的东西。

写进字符串的，它就是内容的一部分，会被一起存、一起传、一起索引。

这条判别法不需要懂排版，也不需要懂那门语言。

它只需要你去看一眼这个修补最后落在了哪个文件里。

这条判别法能推广到很多地方：为了对齐而在文案里打的空格、为了显示好看而在数字里加的分隔符、为了防止折行而插的不换行空格，全都属于写进字符串的那一类。凡是为了让眼睛舒服而改动了字符串本身的动作，机器都会一起读到。

这条判别法还有一个变体，就是问它会不会跟着复制粘贴一起走。会跟着走的说明它在文本节点里，不会跟着走的说明它在样式或者标记里。这个测试连开发工具都不用开，选中文字复制到记事本里看一眼就知道。

## 三种修补的可逆性完全不同

样式层的修补随时可以撤，改一行CSS就回到原样。

标记层的修补要改模板，范围可控但需要发一次版。

字符层的修补一旦进了数据库，撤销就变成一次数据清洗。

而数据清洗的麻烦在于你得先找出所有被改过的记录。

那些字符肉眼看不见，肉眼核对这条路是走不通的。

更麻烦的是这类字符往往不只在一个地方。商品名改了，同一份内容还被复制到了标题标签、结构化数据、导出的商品数据源、发给平台的数据文件里，清洗的时候每一处都要单独处理，漏一处就会留下一个长期不一致的字段。

还有一种情况比数据清洗更麻烦，就是那些字符已经进了外部系统。你把商品数据源推给了平台、推给了比价站、推给了合作方，那边的库里也存了一份，而你没有权限去清。这时候唯一能做的是修正上游之后重推一次，然后等对方更新。

## 软连字符进了标题之后会发生什么？

## 标题去重脚本会把它当成一个新词

大部分站都有一套检查标题重复的脚本，按字符串比对。

插了软连字符的标题跟没插的那条，字符串不相等。

于是脚本认为这是两条不同的标题，不报重复。

反过来，你想找某个词的所有页面时，搜出来的结果会少一批。

少的那一批正好是被排版处理过的那些，通常是最重要的几个页面。

这类问题的隐蔽性在于两个方向的错都不会报错：该报重复的没报，该搜到的没搜到，两个结果看起来都像是正常的。要发现它，只能主动去做一次不可见字符的扫描，没有任何现成的告警会替你发现。

这类问题的排查还有一个特征：它通常是在做别的事情时顺带发现的。有人在核对某个数字对不上，一路查下去才发现字符串里多了个东西。所以主动扫一遍的价值不只是修掉现有问题，更是省掉将来某次排查中被它绊住的那几个小时。

顺带一提，同一类比对失败在词形层面也会发生，只是原因完全不同：那边是同一个词的两种形态对不上，这边是同一个形态多了个看不见的字符。用户实际在打的那个形态另见用户搜的那个短词你的词典里查不到 (https://zhangwenbao.com/minor-language-clipped-short-forms-keyword-coverage.html)。

## 复制粘贴出来的关键词对不上

做关键词核对的时候，习惯是从页面上把词复制下来贴进表格。

复制的时候软连字符会跟着一起被复制，你看不见它。

贴进表格之后跟工具导出的词一比对，显示不匹配。

你会以为是自己抄错了，重新抄一遍，还是不匹配。

这个循环能耗掉半小时，而问题从头到尾都不在你这一边。

可以直接查Unicode官方关于不显示字符的说明 (https://www.unicode.org/faq/unsup_char.html)确认这一族字符的行为定义，它们被设计成在多数情况下不产生可见字形，而这个设计目的正是它们难以被人工发现的原因。

顺手提一个能省事的习惯：核对关键词的时候别用眼睛比对，用一个能显示字符数的地方粘一下。两个看起来一样的字符串如果字符数不同，问题立刻定位到了字符层，不需要再去怀疑是不是自己抄错了。

## 结构化数据的name字段被一起污染

商品的结构化数据通常直接取商品名字段的值。

字段里有什么就输出什么，包括那些看不见的字符。

于是搜索引擎读到的商品名跟你以为的不是同一个字符串。

这会影响实体匹配，也会让平台侧的数据校验偶尔报错。

报错的时候提示往往很模糊，只说值不合法，不说哪里不合法。

更稳妥的做法是在输出结构化数据之前做一次显式的清洗，把这一族字符全部剥掉。清洗必须发生在输出层而不是存储层，因为页面渲染那一侧还需要它们。结构化数据字段的填法另见小语种结构化数据的语言与地区字段怎么填 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)。

结构化数据这一层还有一个特殊之处，就是它的错误反馈是延迟且模糊的。页面渲染错了你马上能看见，结构化数据里带了脏值可能几个月都没有任何提示，直到某天平台侧的校验规则收紧才集中爆发出来。

## 搜索引擎读到的到底是几个词

软连字符的定义是一个只在断行处显示的连字符。

不在断行处的时候，它既不显示也不应该影响词的完整性。

按规范理解，它不该把一个词切成两个。

但这依赖于处理它的每一个环节都正确实现了规范。

你的CMS、你的搜索引擎、你的数据导出脚本，未必每个都实现了。

断行算法本身的定义可以查Unicode标准附件14中关于软连字符的一节 (https://www.unicode.org/reports/tr14/#SoftHyphen)，那里说明了它的断行类别和预期行为。规范写得很清楚，但规范约束不了那些自己写了一个正则去切词的中间环节，而真实链路上这样的环节比你以为的多。

实际上要不要担心这一条，取决于你的链路上有多少个自己写的中间环节。全套用成熟框架的站风险低，中间夹了自研的导出脚本、清洗脚本、数据源生成器的站风险高，因为每一段自研代码都是一次重新实现规范的机会。

## 零宽空格为什么在东南亚语言的站上到处都是？

## 泰语的断行边界必须靠人插进去

泰语句子里没有空格，词与词之间没有任何可见标记。

浏览器要断行就需要知道词边界，而词边界要靠词典来判断。

浏览器对泰语的词典支持这些年好了很多，但不是所有环境都有。

在支持不好的环境里，长句子会整条溢出容器。

最直接的修法就是在词与词之间插一个零宽空格。

这个字符宽度为零，肉眼完全看不出来，但它给了浏览器一个断行机会。作为排版手段它非常有效，问题跟软连字符一样，它进了内容。泰语的分词问题整体另见泰语标题里找不到一个空格，切在哪儿由引擎的词典说了算 (https://zhangwenbao.com/thai-seo-no-spaces-word-segmentation-keyword.html)。

要注意浏览器对泰语断行的支持是这些年逐步补上的，早期那批插进去的字符很多是当年确实需要的。所以清理这类历史数据之前，先确认目标浏览器的现状，别拿今天的支持情况去否定当年的决定。泰语与另两门东南亚语言的差别另见越南泰国印尼在语言层为什么一处都不能共用 (https://zhangwenbao.com/southeast-asia-seo-vietnam-thailand-indonesia-language-layer.html)。

## 粘贴动作是这类字符的主要来源

并不是所有零宽字符都是前端主动插的，很多是被带进来的。

从设计稿、从文档、从翻译工具里复制文本，会连着不可见字符一起复制。

运营在后台粘贴商品描述的时候，这些字符就进了数据库。

这条来源比前端主动插入更常见，也更难管，因为它不走代码评审。

而且它是零星发生的，同一批商品里有的有有的没有。

这条来源的处理办法只有一个，就是在入库那一层做过滤。让后台的保存动作自动剥掉这一族字符，比事后清洗省事一个数量级，因为它把问题挡在了唯一一个所有内容都必经的地方。

这条来源还有一个特别难查的变体，就是翻译服务商交付的文件。译文经过多个工具流转，每一道都可能留下自己的痕迹，而交付验收通常只看语言质量不看字节。把字符检查加进交付验收的清单里，比事后清洗划算得多。翻译交付的验收另见小语种母语审校的验收清单怎么列 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)。

## 泰语那半边的细节交给分词那一篇

零宽空格在泰语上还牵涉到关键词表怎么建、日志怎么清洗。

那些内容属于分词问题的范畴，跟本文讲的排版污染是两条线。

本文关心的是这个字符怎么进来的、会污染哪些字段、怎么扫出来。

它在泰语、日语、中文、高棉语上的表现是同一个机制。

所以处理办法可以共用一套，不需要按语言各写一份。

这个划分也解释了为什么本文把德语和泰语放在一起讲：两门语言的语言学问题完全不同，一个是复合词太长，一个是没有词边界，但它们逼出来的工程修补是同一个动作——往字符串里塞一个看不见的字符，于是产生的下游问题也完全一样。

这个共通性还带出一个实用的推论：你不需要为每门语言各写一套检查，一套字符层的扫描就能覆盖所有语言。真正需要按语言分别处理的是解法那一侧——德语靠断词词典，泰语靠分词算法，而检测那一侧完全可以共用。

把检测和解法拆开还有一个组织上的好处：检测可以由一个人一次性做完并且长期复用，解法需要按语言找不同的人。混在一起排期的话，整件事会被最难的那门语言拖住，而检测本来当天就能出结果。

## 这些字符怎么检测出来？

## 一条正则就能扫全站

需要扫的字符是有限的几个，写成一个字符类就够。

软连字符、零宽空格、零宽连接符、字节顺序标记，加上不换行空格。

把这几个码位放进一个字符类，在全站的文本字段里扫一遍。

扫描本身不到一分钟，麻烦的是决定扫哪些字段。

最少要覆盖商品名、标题标签、描述、分类名和筛选项取值。

不换行空格值得单独说一句，它是这几个里唯一有宽度的，肉眼能看出是个空格但看不出它跟普通空格的区别。它造成的问题跟零宽字符一样：字符串比对不相等，而你完全看不出为什么。

扫描的时候建议把结果按字段分组统计，而不是只给一个总数。哪个字段脏得最厉害，通常就指向了某一个具体的操作习惯或者某一个具体的导入通道，顺着这条线往回找，往往一次就能把源头堵掉。

扫描完成之后建议把结果存一份基线，后面每次巡检跟基线比差值。绝对数量本身意义不大，因为总有一些是有意插入的，真正需要关注的是这个数字有没有在悄悄增长。

## 数据库层怎么查

直接在数据库里查比导出来查更快，也更容易重复执行。

多数数据库支持按十六进制匹配，可以直接找特定字节序列。

要注意字符集，同一个字符在不同编码下的字节序列不一样。

查之前先确认这张表的编码，别在这一步上白折腾半小时。

查出来的结果最好带上主键，方便后面定位和批量处理。

建议把这条查询存成一个固定的脚本，纳入每周的巡检。这类字符是持续流入的而不是一次性的，做一次清洗解决不了问题，需要的是一个能反复跑的检查。

如果没有直接查库的权限，退一步可以从站点地图里逐页抓取标题和结构化数据来扫，覆盖面稍窄但足够发现问题。这条路的额外好处是它扫的是线上真实输出，能顺带发现那些在渲染环节被加进去的字符。

## 导出关键词表时的清洗顺序

清洗要放在导出之后、比对之前，这个顺序不能颠倒。

先清洗再导出的话，你就不知道原始数据里到底有没有问题。

正确的做法是导出原样，另存一份清洗后的，两份都留着。

比对用清洗后的那份，排查问题用原样那份。

两份的差异条数本身就是一个有用的数字。

这个数字可以直接当作数据质量指标汇报。它不需要解释技术细节，一句话就能说明白：我们的商品名字段里有多少条含有看不见的字符，这个月比上个月多了还是少了。

还有一个细节是清洗规则本身要版本化。今天你剥掉五个字符，半年后有人发现还有第六个，如果没有记录哪一批数据是用哪一版规则清过的，你就说不清一份旧导出该不该重跑。

还有一个实务上的建议是把清洗前后的差异条目单独导一份出来给人看一眼。多数时候扫出来的都是噪音字符，但偶尔会混进一两条是有意插入的，那种如果被一起清掉，线上立刻就会出现溢出。

## 为什么不该在存储层清洗

直觉上最省事的做法是在入库时把这些字符全部去掉。

但页面渲染那一侧确实需要它们，去掉之后布局又会撑破。

所以正确的分层是存储原样，输出时按用途分别处理。

给浏览器的保留，给结构化数据和数据源的剥掉。

这样两边的需求都满足，也不会出现改一处影响另一处的情况。

不过这条有个前提，就是这些字符确实是有意插进去的。如果它们是从粘贴动作里混进来的噪音，那入库时就该直接剥掉，因为它们本来也没有排版价值。判断该不该在存储层清洗，看的是这个字符是不是被有意加进去的，有意的保留分层，无意的直接过滤。

存储原样还有一个附带的好处，就是它保留了证据。哪天要追查某个字符是什么时候进来的、是谁的操作带进来的，只有原样数据能回答这个问题，清洗过的库里这条线索已经没有了。

分层处理的前提是链路上真的有一个可以插手的输出层。很多老系统的模板直接从数据库取值往页面上打，中间没有任何可以加过滤的地方，那种情况下只能退回去做存储层清洗，同时接受布局要另想办法。

## CSS层的解法能覆盖到哪一步？

## overflow-wrap管的是什么

这个属性告诉浏览器，当一个词放不下的时候允许强行断开。

它是兜底手段，保证的是不溢出，不保证断得好看。

断点可能落在一个奇怪的位置，读起来不自然。

但对比横向滚动条，断得不好看是个可以接受的结果。

它的最大优点是不需要知道语言，对任何文本都有效。

具体行为可以查MDN文档中overflow-wrap属性的说明 (https://developer.mozilla.org/en-US/docs/Web/CSS/overflow-wrap)，那里区分了几个取值的差别，其中一个只在没有其他断行机会时才生效，正好符合兜底的定位。

需要提醒的是这个属性对某些语言的效果有限，尤其是那些本来就没有空格的语言。它解决的是一个长词放不下的情况，而不是一整句话没有任何断点的情况，后者仍然要靠别的手段。

另外这个属性只作用于它所在的容器和后代，所以要覆盖全站得想清楚挂在哪一层。挂在最外层最省事但影响面最大，挂在每个组件上更精确但容易漏，多数团队最后会选一个折中的中间层。

## word-break为什么更危险

这个属性的某些取值会让浏览器在任意字符之间断行。

对中日韩文本这是合理的，因为那些语言本来就可以任意断。

对拉丁字母文本这会让词被随意切成两半，可读性很差。

更糟的是它会作用在整个容器上，不区分里面是什么语言。

多语言站上一旦全局用了它，别的语言就会一起遭殃。

各取值的适用范围可以查MDN文档中word-break属性的说明 (https://developer.mozilla.org/en-US/docs/Web/CSS/word-break)。实践上的建议是别在全局样式里用它，需要的话按语言选择器限定作用范围，这样才不会伤到别的语言。

一个常见的误用是为了修某一个页面的溢出，直接把这个属性写进了全局样式表。当时确实修好了，半年后有人报告英文页面的单词被切成两半，排查半天才发现是当初那一行。全局样式里的语言相关属性，几乎总是会在别的语言上出事。

## 容器宽度才是根因

前面这些属性都是在处理症状，根因是容器给的宽度不够。

如果一个组件在德语下总是溢出，最好的解法是把它做成弹性的。

让宽度跟着内容走，或者给一个更宽的下限。

这个改动比调断行规则更彻底，也不需要为每种语言单独配置。

代价是设计稿要重新对一遍，这通常是阻力所在。

值得注意的是，把断行规则调好只是让文字不溢出，它不会让一个两行高的卡片装得下四行文字。真正的容量问题还是要在版式上解决，断行属性只能保证不出现横向滚动条这一条底线。

把根因和症状分清楚还有一个好处，就是它决定了谁来改。容器宽度是设计和产品的事，断行属性是前端的事，字符层是内容和数据的事。三件事混在一起讨论，通常的结果是谁都觉得该别人改。

另一个常见的分工误区是把这件事整体丢给前端。前端能修的只有中间那一层，容器宽度要产品点头，字符层要内容侧配合，只推给一个角色的结果通常是他选了见效最快也污染最大的那个办法。

## 还有一档解决的是别的问题

另有一类属性负责让多行文本的每行长度更均衡。

它优化的是观感，不是溢出，两者的目标不一样。

把它当成溢出的解法会失望，因为它不保证不溢出。

它的价值在标题这类短文本上，能让两行的长度看起来更协调。

在小语种上它的效果比英语更明显，因为词长差异更大。

把这三档分清楚很有用：一档保证不溢出，一档保证断得合语法，一档保证看着舒服。三者可以叠加使用，但不能互相替代，混淆它们的职责是很多样式反复调不好的原因。相关规范可以参考CSS文本模块三级规范 (https://www.w3.org/TR/css-text-3/)。

这一档在多语言站上还有一个值得注意的地方：它的效果好坏取决于文本的词长分布，词长差异越大效果越明显。德语这类语言用了之后观感提升很直接，而中文日文这类每个字宽度相同的语言几乎看不出差别。

要不要用这一档，判断标准是这段文字会不会被读者当成一个整体来看。标题、卡片名、按钮文案属于这一类，正文段落不属于，正文本来就是连续阅读的，行长是否均衡几乎无人察觉。

## 连字断词功能为什么在你的站上不生效？

## lang属性没写对是最常见的原因

自动断词功能必须知道文本是什么语言才能查对应的词典。

知道的唯一途径就是元素上的语言属性。

属性没写、写错、或者写在了错误的层级，功能就静默失效。

静默这一点很关键，它不会报错，只是不断词。

于是你会以为浏览器不支持，实际上是它不知道该用哪本词典。

语言属性的正确写法可以查MDN文档中lang全局属性的说明 (https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/lang)，以及W3C国际化问答中关于在HTML里声明语言的一篇 (https://www.w3.org/International/questions/qa-html-language-declarations)。后者还讲清了页面级声明和局部声明的关系，多语言混排的页面尤其需要看这一段。

还有一种更隐蔽的写法错误是语言属性写在了外层，而内层某个组件被脚本重新渲染时丢掉了继承关系。这种情况在单页应用里比较常见，页面初次加载没问题，交互之后就静默失效了。

还有一种情况是属性写对了但值不规范，比如写了一个非标准的语言标签。浏览器匹配不上就退回默认行为，表现跟没写一样。写值的时候照着标准的语言子标签来，别自己造。

## 浏览器的连字词典覆盖有限

就算语言属性写对了，功能也要看浏览器带没带这门语言的词典。

主流语言普遍支持，小语种的覆盖情况参差不齐。

而且不同平台上的同一个浏览器，覆盖范围可能不一样。

所以这个功能只能当成锦上添花，不能当成唯一的方案。

兜底那一层必须用不依赖语言的属性来保证。

属性本身的支持情况和取值可以查MDN文档中hyphens属性的说明 (https://developer.mozilla.org/en-US/docs/Web/CSS/hyphens)。实际部署的时候，正确的组合是自动断词打开、兜底属性也打开，前者负责好看，后者负责不出事。

判断某门语言能不能指望这个功能，最简单的办法是拿一个长词在目标浏览器里试一次。这比去查支持表更可靠，因为支持表往往滞后，而且不区分同一浏览器在不同操作系统上的差异。

## 字体跟断词没有关系

排查这类问题时经常有人怀疑是字体的问题。

字体决定的是字符长什么样，不决定在哪里可以断开。

换字体解决不了溢出，也解决不了断词不生效。

唯一相关的地方是字宽，字体宽一点内容就更容易溢出。

但那是宽度问题，跟断行规则是两件事。

把这条说清楚能省掉很多来回。排查顺序应该是先看容器宽度、再看断行属性、再看语言属性，字体排在最后而且基本不会是答案。

唯一需要注意字体的场合是字形缺失，也就是这门语言的某些字母字体里没有。那会导致显示成方框，但那是另一类问题，跟断行没有关系。字形覆盖的问题另见网页字体在小语种站上占掉的首屏成本 (https://zhangwenbao.com/minor-language-web-font-glyph-set-first-screen-cost.html)。

还有一个相关但常被混为一谈的现象是等宽与非等宽字体下的排版差异。等宽字体会让长词占得更宽，更容易触发溢出，但它同样不改变断点位置，所以它影响的是什么时候溢出，不是从哪里断开。

## 怎么验证它到底生效没有

最快的验证办法是把容器宽度调到很窄，看长词有没有被断开。

断开且带连字符，说明自动断词生效了。

断开但没有连字符，说明生效的是兜底那一档。

没断开直接溢出，说明两档都没生效。

三种结果对应三种不同的排查方向，一眼就能分清。

这个办法的好处是它不需要任何工具，把浏览器窗口拖窄就能看。建议把它写进上线前的检查清单，每种语言各测一个最长的商品名，三分钟能测完。

拖窄窗口还能顺带看出另一件事：这个组件在极窄宽度下的整体表现。很多溢出问题其实是布局在窄屏下没有正确折叠造成的，跟断行无关，而这个测试能一次性把两类问题都暴露出来。

如果需要给别人看证据，把窄宽度下的截图和正常宽度下的截图并排放。这种对比图比任何文字描述都有说服力，尤其是在需要说服设计师改容器宽度的场合。

## 哪些位置绝对不能出现不可见字符

## 标题、地址和结构化数据三处零容忍

标题标签的内容会被搜索引擎当成一个整体理解。

地址里出现这类字符会被编码成一串百分号序列，很难看也容易出错。

结构化数据的字段值会被机器直接读取，不经过任何渲染。

这三处的共同点是它们的读者只有机器，不存在排版需求。

既然没有排版需求，插进去的字符就纯粹是负担。

要在这三处保证干净，最可靠的做法是在生成它们的那一步统一过滤，而不是指望上游字段本身是干净的。过滤函数写一次，三处共用，成本极低。地址里的字符编码问题另见小语种URL用本地字母还是拉丁转写 (https://zhangwenbao.com/minor-language-url-native-script-vs-latin-transliteration.html)。

这三处还有一个共同的特点，就是它们都是被复制到别处的源头。标题会被复制到分享卡片，地址会被复制到外链，结构化数据会被复制到各种聚合服务，一处脏了就会被复制到十几个地方去。

另一类值得一起纳入零容忍范围的是那些用来做匹配的属性字段。它们跟标题一样只有机器读，而且一旦带上脏值，筛选结果的数量就会莫名其妙地对不上。属性字段里的另一类语义陷阱另见无糖和含糖在小语种词表里只差三个字母 (https://zhangwenbao.com/minor-language-negation-affix-exclusion-keyword-trap.html)。

## 关键词表和日志也要保持干净

关键词表如果混进了这类字符，去重和分组都会出错。

日志里混进去会让同一个查询被统计成两条不同的记录。

两者的后果都是数据不准，而且不准的方式很隐蔽。

清洗这两处的成本很低，导入的时候加一行处理就行。

不清洗的代价是后面所有基于这些数据的结论都要打折扣。

顺便提一句，做跨语言的数据合并时这一步尤其重要。不同来源的数据用了不同的不可见字符习惯，合并的时候会产生大量看起来重复实际不相等的行，而这种行在人工核对时几乎不可能被发现。

日志这一侧还有个具体的表现值得记住：同一个查询词因为不可见字符被拆成两条记录之后，两条的量都不够高，于是在按量排序的报表里双双沉底，你会以为这个词没什么人搜。拆分不只让数据不准，它还会让一个重要的词整个消失在视野之外。

## 可以放的地方只有正文里的长词

剩下唯一合适的位置是正文段落里那些确实很长的词。

那里的读者是人，排版效果有实际价值。

而且正文文本一般不会被当成标识符去做精确比对。

就算被索引进去，一个正文词的影响也远小于标题。

所以这个位置的收益大于风险，可以放。

不过更好的选择仍然是用样式层解决。只有在样式层确实做不到、而那个词又确实会撑破布局的情况下，才退而使用字符层的办法，并且要在文档里记一笔为什么这么做。

还有一个判断标准是这段文本会不会被当成标识符使用。正文段落基本不会，而商品名、分类名这些会被拿去做匹配和聚合的字段就必须干净，哪怕它们看起来也只是给人读的文本。

另外正文里用这个办法之前，先确认这一段会不会被摘出去当成摘要或者卡片描述。一旦被摘走，它就离开了正文语境进到了一个只有机器读的位置，原来的收益大于风险的判断也就不成立了。

## 一套断行方案的选型顺序

## 四步选型

第一步，先看容器能不能加宽或者做成弹性的，能就直接解决。

第二步，加上不依赖语言的兜底断行属性，保证不出现横向滚动。

第三步，把语言属性写对，打开自动断词，让断点尽量落在合理位置。

第四步，只对仍然放不下的极少数词，才考虑往字符串里插东西。

四步走完，需要动字符串的情况通常一个都不剩。

这个顺序的逻辑是从污染范围最小的手段开始试，一步一步往上加，只有前一步真的解决不了才用下一步。绝大多数团队的问题是直接跳到了第四步，因为那是最快看到效果的一步。

四步里最容易被跳过的是第三步，因为它需要改模板加语言属性，而这件事看起来跟断行没有直接关系。跳过它的代价是自动断词永远不会生效，你的页面永远停留在能看但不好看的状态。

四步里第一步的性价比最高但推动最难，因为它牵涉设计改稿。越靠前的步骤解决得越彻底，也越难推动，而越靠后的步骤越容易做，留下的隐患也越多，这条规律在很多技术选型上都成立。

## 一张能贴在评审清单上的表

表要有四列：手段、作用层、污染范围、允许使用的位置。

作用层这一列只有三个取值，样式、标记、字符。

污染范围写清楚它会影响哪些下游字段。

允许使用的位置直接写页面区域名，别写抽象描述。

这张表贴在前端的代码评审清单里，比写在文档里有用得多。

做这张表的时候记得把不换行空格也列进去。它经常被当成一个排版技巧而不是一个字符，很多团队的规范里根本没有提到它，结果它是这几个里出现频率最高的一个。

表里还建议加一行说明谁有权批准使用字符层的手段。不设这个门槛的话，某个赶工期的下午总会有人直接往字符串里塞点东西，而那种改动一旦上线就很难被发现，更别说被撤回。

表做完之后建议在团队里过一遍，重点不是让大家记住内容，而是让大家知道有这么一张表存在。真正会去查它的场合是某个人正准备往字符串里塞东西的那一刻，那时候他得想得起来有这么个东西。

## 换行规则本身在不同语言里差在哪？

## 有空格的语言和没空格的语言

有空格的语言，断行机会天然存在，问题只在词太长。

没有空格的语言，断行机会要靠算法或者人工产生。

前者的解法偏排版，后者的解法偏文本处理。

两类语言的投入完全不同，不能用同一套方案覆盖。

混排页面上两类语言同时出现时，还要注意规则会互相影响。

另有一类语言介于两者之间，比如藏文和高棉文，它们有词但空格的用法跟拉丁语系不同。这类语言的处理需要单独确认，别想当然地归到某一边。跨书写系统的整体情况另见印度十一门语言分摊在九套书写系统上的预算怎么算 (https://zhangwenbao.com/india-multilingual-seo-eleven-languages-nine-scripts-priority.html)。

混排页面上还有一个具体的坑：中英混排时英文单词是一个不可断的整体，而中文可以任意断，于是一段混排文本的断点分布会很不均匀，行末容易出现大片空白。这跟溢出是两个问题，但经常被一起报上来。

## 同一套算法在不同语言上的落点

断行算法本身是跨语言通用的，它按字符类别决定哪里能断。

每个字符属于哪一类，是在字符属性表里定义好的。

所以不同语言的差别不在算法，在它们用了哪些字符。

标点符号的类别定义尤其重要，中日韩的标点有专门的规则。

这些规则的目的是避免行首出现不该出现的标点。

完整的规则和字符类别定义在Unicode标准附件14断行算法 (https://www.unicode.org/reports/tr14/)里，中文版的通俗解释可以看W3C国际化文章断行的方法 (https://www.w3.org/International/articles/typography/linebreak)。后者用图示讲了不同书写系统的断行差别，是这一族资料里最好读的一份。

还有一类字符的类别定义容易被忽略，就是各种破折号和连接号。它们看起来相似，断行类别却不同，有的允许在后面断有的不允许，而内容编辑在录入时几乎不可能分清用的是哪一个。

还有一类需要留意的是数字和单位之间的连接。为了不让数值和单位被拆到两行，很多人会插一个不换行空格，这个做法本身是对的，但它同样是往字符串里加字符，同样会被下游读到。

## 常见问题解答

## 我们站上没有德语，还需要管这件事吗？

看两个条件。第一个是有没有构词能力强的语言，芬兰语、匈牙利语、荷兰语、瑞典语都会产生很长的词。第二个是有没有不带空格的语言，泰语、日语、中文都属于这一类。两个条件都不满足的话，溢出问题会轻很多，但粘贴带进不可见字符这条来源仍然存在，因为它跟语言无关，只跟内容编辑的操作习惯有关。所以最少要保留入库过滤那一步，其余的可以先不做。换句话说，溢出问题按语言判断要不要做，字符污染问题按操作习惯判断，两条线要分开评估。

## 怎么在十分钟内判断自己站上有没有这个问题？

两个动作。第一个是把浏览器窗口拖到最窄，逐页看有没有出现横向滚动条，有的话记下是哪个组件。第二个是在数据库里跑一条正则，扫商品名和标题字段里有没有那几个不可见字符，有结果就说明已经有人在用字符层的办法了。两个动作加起来十分钟，结论足够支撑要不要立项。如果两个都干净，这件事可以先放着，加一条巡检就行。两个动作都不需要开发配合，自己就能做完，这是它值得优先跑一遍的原因。

## 已经插进数据库的那些字符，要不要全部清掉？

先分清来源再决定。前端为了排版有意插的，短期内不要动，因为清掉之后布局会立刻撑破，正确顺序是先把样式层的方案做好，再清字符。从粘贴动作混进来的噪音字符可以直接清，它们没有任何作用。区分的办法是看位置：出现在长复合词中间的多半是有意的，出现在词首、词尾或者标点旁边的基本都是噪音。清理的顺序永远是先补上替代方案再动原有数据，反过来做会让线上立刻出问题。

## 软连字符会不会直接影响排名？

直接影响很难证实，也没必要在这个层面纠结。真正确定的影响是链路上的其他环节：你的关键词核对会出错、去重脚本会漏、结构化数据会带上脏值、导给平台的数据源可能被拒。这几件事每一件都会实实在在地消耗时间或者造成损失，理由已经足够充分。把精力放在这些可验证的后果上，比争论搜索引擎到底怎么处理这个字符更有意义。把讨论从推测搜索引擎的行为，转到可以直接验证的下游后果上，推动起来会顺利得多。

## 自动断词打开之后，需要担心断点断错吗？

正常情况下不用，因为浏览器用的是这门语言的连字词典，断点符合正字法。个别专有名词和新造的复合词可能断得不理想，但它出现的概率不高，而且视觉上只是不够优美，不会造成误解。真正需要小心的是把兜底属性用成了主力，那一档是按字符强行断的，断点完全不管语法，出现在正文里会比较扎眼。所以这两档的分工要保持清楚。所以配置的时候要明确区分主力和兜底，别让兜底那一档承担了主要的断行工作。

## 这件事该归前端还是归SEO？

发现和定标准归SEO，落地归前端。原因是这个问题的后果落在内容和数据侧，前端从他自己的视角看不到那些后果，他只会看到布局修好了。反过来SEO没有能力去改样式和模板。比较有效的协作方式是把那张四列表交给前端，让它成为代码评审的一条检查项，这样不需要每次都由人去提醒。把判断标准写下来，比每次靠沟通要稳定得多。协作的关键是把判断写成检查项，而不是每次都靠某个人记得提醒。

## 这跟去掉变音符号、大小写转换那些坑是同一类吗？

都属于字符层的动作，但方向相反。去变音和转小写是主动删掉或者改写信息，目的是让匹配更宽松；插不可见字符是主动增加信息，目的是让排版更好看。前者造成的是过度合并，后者造成的是不该有的分裂。两类问题的排查工具可以共用一套，都是在字节层做比对，但监控的指标要分开：前者看误合并率，后者看字段里的异常字符数。一句话概括就是：一个让不同的东西变成相同的，一个让相同的东西变成不同的。

## 权威参考资料



## 一个模板生成十种语言，字符层看不出重复，信息层十份一模一样

- URL：https://zhangwenbao.com/multilingual-template-ten-languages-duplicate-content-risk.html
- 分类：小语种SEO
- 发布：2023-05-24  |  更新：2026-07-27
- 摘要：十个语言版本从字符层看零重复，从信息层看是同一份残缺内容复制了十遍。讲清跨语言重复与同语言重复为什么要分开判、模板骨架占比为什么必须按语言重算，以及为什么要留两个对照组。
- 关键词：内容SEO,出海SEO,多语言SEO,小语种SEO

> **TLDR**：摘要：一个模板套十种语言，团队第一反应是担心这十份页面互相重复。这个担心基本落空，因为近重复检测比对的是字符和词，十种语言的字符串毫无交集。真正会出事的是另外两处：同一门语言里按城市和品类铺开的那几百页，以及模板本身的信息缺口被原样复制了十份。

> 摘要：一个模板套十种语言，团队第一反应是担心这十份页面互相重复。这个担心基本落空，因为近重复检测比对的是字符和词，十种语言的字符串毫无交集。真正会出事的是另外两处：同一门语言里按城市和品类铺开的那几百页，以及模板本身的信息缺口被原样复制了十份。

## 十个语言版本会不会被判成互相重复？

## 团队最先担心的往往是错的那件事

多语言项目立项时，重复内容几乎总是被提起的第一个风险。

提法通常是这样的：十个版本内容结构一模一样，会不会被判成复制。

接下来的半年，团队会在跨语言标注上花掉大量精力。

每一页配好互指的语言标注，每一组配好默认版本。

这些活儿该做，但它们解决的不是重复内容问题。

语言标注解决的是版本歧义，跟重复判定是两条不同的线。

这个误解的源头是把两件事混成了一件：语言标注告诉搜索引擎哪一份该给哪一批用户，重复判定决定的是哪一份值得被收录，前者是分发问题，后者是取舍问题，做对了前者不代表后者就不会出事。

这个担心还有一个副作用，它会把资源投向错误的优先级。语言标注是一次性配置，做完就稳定；页面差异度却需要持续维护。把半年的注意力放在前者上，等于让后者在无人看管的状态下长了半年，等发现的时候已经是几百页的存量问题。

## 近重复检测比对的是哪一层

要判断跨语言会不会触发重复，得先知道检测在哪一层做。

主流做法是把页面切成词或者字符片段，算指纹再比相似度。

这套算法的输入是字面形态，不是语义。

德语页面和法语页面即使讲的是同一件事，字面重合度也接近于零。

就算两边都保留了品牌名和型号，那点重合也远远达不到阈值。

所以十个语言版本互相之间几乎不可能被判成重复。

值得一提的是，跨语言的语义相似度在技术上是能算的，把不同语言映射到同一个向量空间的方法早在几年前就成熟了，用知识蒸馏把单语句向量扩展到多语言的做法 (https://arxiv.org/abs/2004.09813)就是其中一条路线，但这类模型在排重环节的角色跟字面指纹完全不同，它更多用在检索和匹配上。

顺带说清楚一件相关的事：同一门语言写给不同国家的页面，字面重合度是很高的，那才是真正需要处理的情形。西班牙语覆盖十几个市场，葡萄牙语覆盖两个，这类页面之间既有语言相同又有内容雷同，判定风险跟纯粹的十语版本完全不是一个量级。

## 所以这条风险可以划掉，换个地方担心

结论很干脆，跨语言重复这件事不用担心。

该担心的是接下来两节要讲的那两处，它们的杀伤力大得多。

一处是同一门语言内部的页面互相重复。

另一处是十份内容各自都薄，而且薄在同一个位置。

前者会触发实实在在的收录取舍，后者不触发任何判定，只是一直没有效果。

两者的共同点是，都不会因为你把语言标注做得更完美而好转。

本站早年写过一篇讲重复内容治理的文章，同域跨域与参数变体那六类排查 (https://zhangwenbao.com/content-duplicate-issue.html)覆盖的是单一语言内部的情形，本篇要补的正是它没有展开的那一层：当页面被复制到多门语言上时，问题的形态会变，但判定的机制并没有变。

这里也顺便回答一个常被问到的问题：把同一篇文章翻译成十种语言，算不算低质量的批量内容。判断标准不在翻译这个动作，而在每一份译文对它的目标读者是不是有用。翻得好、有针对性调整的版本，跟原创内容一样有价值；机器批量产出、连本地价格都没换的版本，问题也不在它是译文。

## 那真正的风险落在哪里？

## 同一门语言里的笛卡尔积

先说第一处，它才是真正会触发判定的地方。

模板化的站点很少只做十个语言版本，通常还会乘上城市、品类或者型号。

十门语言乘二十个城市乘三十个品类，页面数就是六千。

其中同一门语言下面的那六百页，才是互相竞争的那一批。

它们的字面重合度极高，因为只有几个变量位在变。

这一批页面里，搜索引擎最多只会留下一小部分。

换句话说，语言这一维是安全的，其余每一维都是危险的，而团队的注意力恰好全给了唯一安全的那一维，规范标签在多种跨页场景里的用法 (https://zhangwenbao.com/canonical-tag-mechanism-cross-domain-self-conflict-diagnosis.html)要处理的正是这几维，跟语言维没有关系。

处理这批页面还有一条容易被跳过的前置动作：先算一算它们的实际需求量。很多城市乘品类的组合根本没有人搜，页面生成出来只是徒增维护面。小语种关键词工具没数据时的补数办法 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)在这里正好反过来用一次，不是找需求，是证伪需求，把没有需求的组合从生成规则里剔掉。

## 小语种的变体空间更小，稀释更快

第二个因素让情况在小语种上更糟。

同一个意思，英语里可以有七八种表达方式换着写。

很多小语种的商业文体没有那么多现成的同义说法。

可替换的部分变少，模板骨架在页面里的占比就变高。

骨架是导航、页脚、政策链接、模块标题这些每页都一样的内容。

骨架占比一高，主体内容就被稀释，页面之间的差异也随之变小。

这两件事是连着的：可替换表达越少，模板化页面之间的差异就越小，触发取舍的门槛也就越低，主体内容占比与模板稀释那篇 (https://zhangwenbao.com/main-content-ratio-boilerplate-dilution-page-layout.html)算的那笔账，在小语种站上要按更严的标准重算一遍。

还有一个加剧因素来自翻译本身。译者面对一批高度相似的源文，倾向于用同一种句式处理，因为那样最省事也最一致。于是原文里本来还有的那点差异，翻完之后进一步收窄。翻译流程天然是一个把差异磨平的流程，这一点在做模板站时必须提前对译者说明。

## 两层判定表怎么用

把这两处整理成一张两层的表，用起来最省事。

横向那一层是跨语言，判定结论是不触发，处理方式是做好语言标注。

纵向那一层是同语言内，判定结论是会触发，处理方式是控制变量位与规范标签。

每次新增一批页面，先问它是横着长还是竖着长。

横着长基本没风险，竖着长必须先算差异度。

这个问题两分钟就能回答，却能挡掉大部分误判。

表的第三行可以写上例外情形：同一门语言在多个国家使用时，比如西班牙语覆盖十几个市场，那些页面既是横向也是纵向，它们互相之间字面高度重合，是这套判定里唯一需要两层同时看的情形。

这张表还能用来做一件事：给新同事解释为什么某些页面要合并而另一些不用。多语言站的页面治理很容易被理解成一刀切的规则，实际上它是两套判据。把表贴在项目文档的第一页，能省掉后面无数次同样的讨论。

## 模板骨架占比为什么必须按语言重新算一遍？

## 同一个阈值在十种语言里不等价

很多团队会给模板定一个骨架占比的上限。

比如规定骨架不得超过页面文字的三成。

这个阈值定在英语页面上，然后被原样套到其余九门语言。

问题在于，同一段内容翻译成不同语言，长度差别可以到四成以上。

骨架和正文的长度是分别变化的，两者的比例自然也跟着变。

于是英语页面刚好合格，德语页面早就超标了。

更麻烦的是这种超标不会有任何提示，它只表现为某几门语言的页面长期表现偏弱，而团队会把原因归结到市场竞争或者关键词难度上，很少有人回头去量一遍骨架占比。

要验证自己有没有踩到这一条，有一个五分钟的动作：把同一个模板在十种语言下渲染出来的页面各取一份，统计骨架文字与正文文字的字符数比例。比例的极差如果超过一倍，说明这个阈值在你的语言组合上根本不成立，得换指标了。

## 三类语言各有各的偏移方向

偏移的方向也不一致，至少有三类。

复合词语言把一整个短语压成一个词，字符数少但信息量不变。

不用空格分词的语言，按词计数和按字符计数得到的结论完全不同。

屈折语的同一个词在不同位置形态不同，去重统计会把它们算成不同的词。

三类偏移方向不同，不能用一个修正系数一起解决。

所以要么按语言分别定阈值，要么换一个不受这些影响的指标。

字符宽度这件事本身也有讲究，全角与半角在版面上占的空间不同，东亚字符宽度的标准定义 (https://www.unicode.org/reports/tr11/)就是为了解决这类计数口径问题而写的，做跨语言字数统计之前值得先读一遍它的分类。

还有第四类偏移来自书写系统本身。同样一句话，用汉字写和用拉丁字母写，字符数可以差三倍以上，而信息量完全相同。这一类偏移的幅度最大，也最容易被忽略，因为它不像语法差异那样有明显的表现，只是让所有基于字符数的统计集体失真。

要看清一门语言的形态到底会怎么变，最省事的参照是跨语言的句法标注项目，用同一套标注体系覆盖上百种语言的树库 (https://universaldependencies.org/)里能直接看到每门语言的词形变化标签有多少种。做模板设计之前扫一眼目标语言的标签集，心里对复杂度就有数了。

## 字符数是个不称职的代理指标

退一步说，字符数本来就不是我们真正关心的东西。

我们关心的是这一页有没有提供足够的独有信息。

字符数只是这件事的一个代理指标，而且是个跨语言不成立的代理。

本站在讲图片替代文本的时候得出过同样的结论。

那条广为流传的字符数上限，本质约束的是信息量而不是长度。

这里遇到的是同一个陷阱的另一个版本，只不过这次的阈值是我们自己定的。

自己定的阈值反而更危险，因为它带着内部规范的权威，没有人会去质疑它的适用范围，非拉丁字母站点的图片文本那篇 (https://zhangwenbao.com/minor-language-image-alt-text-non-latin-script-search.html)里那句把代理指标换成本体的建议，在这里可以原样再用一次。

代理指标失效这件事有个共同的识别方法：问一句这个数字到底在替谁说话。字符数替的是信息量说话，页面停留时间替的是内容有用程度说话，关键词密度替的是主题相关性说话。凡是代理，就一定有失效的边界，而跨语言几乎总是那条边界所在的位置。

## 改用信息单元来数

替代方案是数信息单元，不数字符。

一个信息单元是一条读者拿得走的事实：一个参数、一条政策、一个适用条件。

数法很粗糙，但它跨语言稳定，因为翻译不会改变事实的条数。

给模板页定一个下限，比如独有信息单元不少于八条。

这个下限对十门语言同时成立，不需要按语言修正。

验收时也好操作，让人拿笔数一遍就行，不用写脚本。

把指标从字符数换成信息单元数，还有一个额外好处：它会自动逼出内容缺口。数着数着发现一个页面只有三条独有事实，那说明问题不在翻译也不在模板，而在于这一页本来就没什么可说的。

信息单元这个口径还有一个延伸用法：拿它给页面排优先级。同类页面里独有信息单元最多的那几页，通常也是自然表现最好的那几页，这个相关性在多数站上都成立。所以数完之后不要只用来卡下限，也可以用来找出应该被当成模板范本的那几页。

## 模板里的占位符会在哪几门语言上崩掉？

## 复数形态是第一个坑

模板里最常见的一个写法是数量加名词。

英语只要处理单数和复数两种形态，写个条件判断就够。

换到别的语言，形态数量会变。

有的语言有三类，有的语言有四类，阿拉伯语有六类。

按英语的两分法写死的模板，在这些语言上会有一半的情形出错。

出错的表现不是报错，是语法不通顺，而这恰好是最难被自动发现的一类错误。

这件事早有现成的标准可以照抄，通用区域数据库里的复数规则 (https://cldr.unicode.org/index/cldr-spec/plural-rules)把每门语言的复数类别整理成了可查的规则集，前端和内容模板都应该直接消费它，而不是各自写一套判断。

复数这一栏还有一个特别容易翻车的地方：零。英语里零后面跟复数，有的语言零算单数，有的语言零有专门的形态。而零恰好出现在库存为空、评价数为零这类页面上，那正是用户最挑剔的时刻。规则集里对零是单列的，模板取用时别自己合并。

## 数字、货币与日期的格式

第二类占位符是格式化输出。

千分位用逗号还是点、小数点用点还是逗号，各语言不同。

货币符号在前还是在后、跟数字之间有没有空格，也各不相同。

日期的年月日顺序更是每个市场一套。

这些细节单看都很小，但它们出现在价格旁边，也就是用户最敏感的位置。

格式错了，页面立刻显得像机器批量生成的，信任度直接掉一截。

同样地，这些规则也不需要自己整理，区域数据标记语言里关于数字格式的部分 (https://www.unicode.org/reports/tr35/tr35-numbers.html)把小数分隔符、分组方式、货币位置全都定义好了，模板要做的只是正确地取用它们。

格式这一类还有一个跟检索直接相关的影响：用户搜索时会按自己习惯的格式打数字。型号里的小数点、尺寸里的分隔符、容量里的单位写法，各地都不一样。页面上只写一种格式，就接不住按另一种格式搜索的那批查询，这一层在关键词表里通常整块缺席。

## 性数一致会让替换失效

第三类问题在拉丁语族和斯拉夫语族特别明显。

形容词要跟名词的性和数保持一致。

模板里写的是形容词加占位符名词，名词一换，形容词就得跟着变。

意大利语和波兰语那几篇里详细讲过这个机制。

结果是同一个模板在这些语言上会产出大量语法不对的句子。

而这种错误母语者一眼就能看出来，比拼写错误更伤害专业感。

可行的绕法有两个：一是把占位符挪到句子末尾或者独立成行，让它不再跟前面的词发生一致关系；二是给每个品类词预先标注好性别属性，让模板按属性取对应的形容词形态，两种做法在工程量上差着一个数量级。

一致关系还有一个连带的问题：定冠词。很多语言的冠词形态跟着名词的性和数变，而模板里的冠词往往写死在句子里。名词一换，冠词就错。这类错误比形容词更隐蔽，因为冠词短、不显眼，母语者读到时会觉得别扭却说不上哪里怪。

这一类问题还有一个工程上的解法：把带一致关系的句子整句抽成可翻译单元，而不是把占位符嵌在句子中间。译者拿到的是完整句子的十种情形，各自写对即可。凡是语法上会互相影响的成分，就不该被占位符切开，这条原则比任何补救措施都省事。

## 称谓与语域也是占位符

还有一类占位符不那么明显，就是对用户的称呼。

正式与非正式的第二人称在很多语言里是两个词。

模板里写死一种，等于给十个市场定了同一个语气。

而各市场的电商语气习惯并不相同，有的偏亲近，有的偏正式。

日语的情况更极端，档位变了整句动词都要改写。

所以称谓这一项不能当成词汇替换，要当成句式选择来处理。

语气这件事本身值得单独规划，品牌语气的四个维度 (https://www.nngroup.com/articles/tone-of-voice-dimensions/)提供了一套可以打分的框架，把每个市场在四个维度上的取值定下来，再决定模板里那一栏用哪种形态，比凭感觉挑要稳。

称谓这一栏还有一个折中办法：整站避开第二人称。把面向用户的句子改写成无人称或者以商品为主语的形式，一次性绕开正式与非正式的选择。代价是文案会稍微客观一些、少一点亲近感，但对模板站来说，这个代价通常远小于在十个市场分别维护两套语气。

## 十份内容为什么会同时残缺？

## 缺口是跟着模板一起复制的

现在说第二处真正的风险。

模板决定了每一页会写哪些字段，也就同时决定了不写哪些。

没被模板收进去的信息，十个语言版本里一份也不会有。

比如模板里没有安装条件这一栏，那十个市场的用户都查不到这件事。

缺口不是翻译造成的，是设计模板那一刻就定下来的。

而翻译流程永远不会发现它，因为翻译只对着已有的字段工作。

这就是模板化最贵的那笔隐性成本：它把内容策划的一次疏漏，原样放大成了十个市场的同一个疏漏，而每个市场的团队都会以为这是全站的统一规范，没有人有权限也没有动力去质疑它。

发现缺口的另一个办法是横向对比。挑三家当地的头部同行，把他们商品页上出现的字段逐个列出来，跟自己的模板字段清单做差集。差出来的那几项，往往就是当地用户默认应该有的信息。这个动作每半年做一次，比任何一次内部头脑风暴都有效。

## 一处改动，十处同时生效

模板的传播路径是一对多，这既是优点也是缺点。

优点是修复快，改一处，十个市场当天全好。

缺点是出错也快，改错一处，十个市场当天全坏。

更麻烦的是，坏掉的形态在十个市场是同一种。

你没有一个正常的对照，无法判断变化到底是模板引起的还是市场本身波动。

数据上看到的是十条曲线同时下弯，看起来像行业整体变化。

这一点在做归因时特别致命，因为归因的前提是有变量和对照，而全量同步上线的模板变更把对照组也一起改掉了，剩下的只有一个整体趋势和一堆猜测。

一对多还有一个副作用体现在排期上。模板变更因为影响面大，通常需要更长的评审链条，于是小改动也会被拖成大项目。久而久之团队就不愿意动模板了，宁可在个别页面上打补丁。补丁越多，模板与实际页面的偏离越大，最后没有人说得清线上到底长什么样。

## 十个市场都不反馈，不代表没问题

还有一层更安静的失效方式值得单说。

模板缺了某个字段，用户在十个市场都查不到那件事。

但没有一个市场的用户会专门来告诉你这里少了什么。

他们只会去别处找答案，而这个动作在你的数据里什么都不留下。

于是十个市场同时安静，团队理解成十个市场都没问题。

反馈的缺失被当成了正面信号，这是模板化最容易骗过人的地方。

要把这层沉默打破，唯一可靠的输入是客服工单和站内搜索的无结果查询，前者记录用户问了什么，后者记录用户找了什么却没找到，两份数据合起来，就是模板字段清单里缺失项的直接证据。

无结果查询这份数据还有一个用法：它能告诉你哪些字段的缺失是跨市场共通的，哪些是某个市场独有的。共通的应该补进模板，独有的应该留给该市场的自由段落。非洲那几个市场的语种选择 (https://zhangwenbao.com/africa-market-language-selection-swahili-hausa-francophone.html)里提到的第二档做法，本质上也是在做同一件事：把共通的和独有的分开安置。

## 该给模板变更留几个对照组？

## 十个版本上线八个，留两个

解法很朴素，别一次全推。

模板变更先在八个语言版本上线，留两个不动。

观察两到四周，比较两组的变化方向。

确认没有负面影响，再把剩下两个补上。

这个做法在产品团队里叫分批发布，在内容团队里几乎没人做。

原因也很实在，内容团队的工具链通常不支持按语言分批。

所以真正的门槛不在方法而在系统，如果模板是一份全局配置，那就得先给它加上按语言开关的能力，这件事的工程量不大，但它决定了后面所有模板决策能不能被验证。

分批发布还有一个更简单的替代方案，适合工具链暂时不支持按语言开关的团队：按时间错开。先上线八个语言版本，两周后再上线剩下两个。虽然不如同期对照严谨，但至少保留了一段可以比较的时间窗，比全量同步上线什么都看不出来强。

## 留哪两个当对照

对照组的选择有讲究，不能随便挑两个最小的市场。

要挑流量稳定、季节波动小、且跟主市场同属一个语言家族的。

流量太小的市场噪声大，看不出差别。

波动大的市场会把模板效应淹没在季节性里。

比较理想的是选一个中等规模市场，加一个跟它结构相似的邻近市场。

两个对照互相印证，比单个对照可靠得多。

还要避开一种情况：把正在做别的实验的市场当对照组。多语言站上同时跑着好几条改动线是常态，对照组一旦跟别的实验重叠，两边的结论都会作废，所以对照组的选择要跟其他团队对一次表。

还有一种对照组的挑法值得考虑：挑一个跟主市场语言相同但国家不同的版本。这样两组之间的语言变量被固定住了，剩下的差异更容易归因到模板本身。跨国语言那一篇 (https://zhangwenbao.com/russian-language-market-seo-decision-after-2022-geopolitical-shift.html)里语言层与市场层分离的思路，在选对照组这件事上同样好用。

## 观测窗口与判据

观测多久，看什么。

窗口一般取两到四周，太短受抓取节奏影响，太长会被其他变更污染。

主看两个指标：展示量的相对变化和点击率的相对变化。

用相对值而不是绝对值，可以消掉整体大盘的波动。

判据是两组的差值超过历史波动区间才算有效。

差值在噪声范围内，就当作没有影响，直接全量。

这一整套做法本质上是把工程界的灰度发布搬到内容侧，唯一需要额外注意的是抓取延迟：内容变更的生效速度比代码慢得多，窗口的起点应该从这批页面被重新抓取算起，而不是从上线那天算起。

观测期间还要注意别做别的改动。多语言站上同时跑着的改动线往往不止一条，一旦观测窗口里插进了别的变更，两组的差异就说明不了任何问题。可行的做法是在项目管理工具里给这两个语言版本挂一个观测中的标记，让其他团队看得见。

另一家搜索引擎的站长文档同样值得对照着看，它对多语言站点的收录说明 (https://yandex.com/support/webmaster/)在某些市场比主流引擎的口径更直接。做对照实验时如果目标市场的主流引擎不止一个，观测指标要按引擎分开取，否则两条曲线叠在一起什么都看不出来。

## 哪些页面适合用模板，哪些不适合？

## 先量一个结构稳定度

模板不是原罪，用对地方它是效率工具。

判断适不适合，看一个指标：这类页面的信息结构稳不稳定。

结构稳定的意思是，每一页要说的字段完全相同，只有取值在变。

参数表、配送政策、尺码对照都属于这一类。

结构不稳定的意思是，每一页该说什么由具体对象决定。

品类导购、选购建议、故障排查都属于这一类。

判断方法也很土：拿五个同类页面的提纲摆在一起，如果小标题能一一对上，就是结构稳定；如果每一页的小标题都不一样，那说明这类内容的价值恰恰在于差异，套模板等于把价值抹掉。

结构稳定度还有一个更细的分级值得区分：字段固定但取值需要解释的那一类。比如材质、认证、适用场景，字段是固定的，取值却需要一两句说明才有意义。这一类介于两者之间，正确做法是模板给出字段和取值，再留一个短的说明位，让写稿的人补上那句话。

## 结构稳定的页面模板化收益最大

结构稳定这一类，模板化几乎没有副作用。

因为用户来这类页面就是为了查一个具体数值。

他不需要观点，也不需要论证，只要求准确和好找。

这类页面翻译成十种语言也很安全，术语一致反而是优点。

需要注意的只有格式化那几项和复数形态。

把这一类页面全部交给模板，是这套方法里唯一无争议的部分。

甚至可以再进一步，把这类页面的内容源做成结构化数据，让页面和结构化标注共用同一份数据源，小语种结构化数据那篇 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)讲的字段写法可以直接对接，两边同源之后不一致的风险也一起消失了。

这类页面还有一个额外优势：它们对搜索意图的匹配特别准。用户来查一个具体参数，页面上正好只有参数，没有任何绕弯子的内容，跳出反而是正常行为而不是负面信号。国际化站点的入门指引 (https://www.searchenginejournal.com/international-seo/)里也把这类结构化信息页当成多语言站最先该铺开的一层。

这类页面还适合作为新增语言的第一批内容。结构固定、术语可控、风险低，用它来验证整条多语言生产线是否通畅，比拿一篇需要论证的长文去试要稳妥得多。先用最不容易出错的内容跑通流程，再让复杂内容进场，这个顺序能省掉大量返工。

## 需要论证的页面别交给模板

另一类要坚决挡住。

凡是需要摆事实讲道理、需要给建议的页面，模板都会毁掉它。

因为论证的价值在于针对性，而模板的本质是消除针对性。

这类页面套模板之后，读起来会像一份填空作业。

更实际的问题是，它接不住长尾查询，因为长尾查询问的正是那些差异。

这类内容宁可少做几个市场，也不要十个市场都发一份空壳。

这条线的判断可以借用一个很简单的问法：这一页如果只改标题里的一个词，其余全不动，还成立吗？成立说明它本来就没什么针对性，不成立才说明它值得单独写。

还有一类页面同样不该模板化，就是承载专业判断的内容。这类内容需要作者身份和经验来支撑，套模板之后连署名都变得可疑，因为读者会发现同一个人在十个语种下写出了结构完全一致的判断。本地作者署名与资质那篇 (https://zhangwenbao.com/minor-language-eat-local-author-byline-credential-signals.html)讲的信任建设，会被模板化直接抵消掉。

## 中间形态怎么处理

现实里更多的是中间形态。

页面有一半是固定字段，另一半需要针对性内容。

处理办法是把两部分在模板层就分开。

固定部分走模板，针对部分留成必填的自由段落。

关键在于把自由段落设成必填，且规定最少信息单元数。

不设下限的自由段落，最后会被填成一句正确的废话。

这个设计还有个副产品：它把模板从内容的替代品变成了内容的脚手架，写稿的人不用再操心结构，只需要往那几个自由段里填真正有价值的东西，交付质量反而比完全自由的写作更稳定。

自由段落的下限还要配一个上限。不设上限，写稿的人会把这个位置当成自由发挥区，写着写着变成品牌软文，跟页面主题脱节。合理的范围是两百到四百字，写满即可，多写的部分应该另开页面而不是塞进模板。

自由段落还要解决一个协作问题：谁来写。多语言站的自由段落如果统一由总部写完再翻译，那它跟模板没有本质区别；只有让本地团队自己写，这个位置才有意义。国际化站点的实践清单 (https://ahrefs.com/blog/international-seo/)里反复强调的本地投入，落到具体页面上就是这一段。

## 翻译记忆和机器翻译会把什么放大？

## 记忆库会把错误固化下来

模板化的站点几乎都会配翻译记忆。

相同句子只翻一次，之后自动复用，成本确实降下来了。

代价是一旦某个句子的译法有问题，它会被复用到所有页面。

而且越是高频的句子，错得越广。

纠错的时候也麻烦，改了记忆库，已经生成的页面不会自动更新。

所以要有一个反向的更新流程，改一次记忆库就回刷一次受影响的页面。

记忆库的另一个隐患是它会掩盖语域问题：同一句话在商品页和政策页里的合适说法可能不同，而记忆库只认句子不认语境，于是把商品页那种轻松的说法搬进了法务条款里。

记忆库还有一个使用上的纪律：句子的切分粒度要合理。切得太碎，复用率高但语境全丢；切得太粗，复用率低失去意义。做模板站建议按完整句子切，不要按短语切，因为短语级复用最容易在不同语境里产生不合适的搭配。

## 术语一致不等于说法地道

术语库和记忆库解决的是一致性，不是自然度。

十个市场的同一个部件叫同一个名字，这是好事。

但这个名字可能是当初随手定的，当地人根本不这么叫。

一致地错，比不一致地对更难被发现。

因为所有检查工具都在查一致性，没有工具查地道程度。

这件事只能靠人，而且只能靠有零售经验的母语者。

验收口径要提前定清楚，母语审校验收清单那篇 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)里那条读着自然不能当作验收通过的判据在这里要反过来用一次：模板站的问题往往不是读着不自然，而是读着太顺以至于没人怀疑它是不是当地人的说法。

要发现一致地错，有一个便宜办法：把术语库里的词拿去当地平台搜一遍，看结果数量。搜出来商品寥寥的那几个词，多半就是没人这么叫的词。这个检查不需要懂这门语言，看数字就行，一小时能过完一整份术语表。

还有一个反向的检查也值得做：把当地平台上该品类销量最高的几个商品标题抄下来，看里面出现的词有几个在你的术语库里。命中率低于一半，说明术语库是从总部视角建的，不是从当地买家视角建的，这时候该做的是重建而不是修补。

## 质量红线怎么划

机器翻译在模板站上的角色需要划一条线。

固定字段和结构稳定的页面，机翻加轻度校对是可以接受的。

涉及承诺、责任、金额的段落，必须人工确认。

需要论证的自由段落，不适合机翻，因为它会把逻辑关系译平。

这条线不是质量洁癖，是风险分级。

翻错一个参数是体验问题，翻错一句退货条款是法律问题。

本站关于机器翻译的那篇给过一套更完整的分级，机器翻译直接发布的风险与质量红线 (https://zhangwenbao.com/machine-translation-direct-publish-search-risk-quality-line.html)里的判据可以直接搬进模板站的发布流程，作为哪些字段允许自动生成的准入条件。

风险分级还应该覆盖一类经常被忽略的内容：结构化数据里的字段值。它不显示在页面上，出错也没有用户会反馈，但它直接参与搜索端的理解。机器翻译产出的字段值同样要过人工确认，尤其是可用性、价格与配送时间这几项。

## 上线之后怎么发现十份内容一起坏了？

## 三条跨语言一致性检查

问题既然是一对多复制的，检查也该按一对多设计。

第一条，抽同一个页面的十个语言版本，比对信息单元条数是否一致。

条数不一致，说明某几门语言的模板渲染出了问题。

第二条，比对每个版本的数字与货币格式是否符合当地写法。

第三条，比对页面长度的相对比例，某一门语言异常短就要查。

三条都能写成脚本，跑一次几分钟。

这三条的共同特点是它们不需要懂任何一门目标语言，比对的是结构而不是语义，所以可以交给任何一个工程同学定期跑，而不是排队等母语审校的档期。

三条之外还可以加一条更基础的：查每个语言版本的页面是否都能被正常抓取。模板站上偶尔会出现某一门语言的整个目录因为一处配置错误而被挡住的情况，而这类问题在报表里表现为该语言表现极差，很容易被误判成内容问题。另一家搜索引擎的站长指南 (https://www.bing.com/webmasters/help/webmaster-guidelines-30fba23a)里对多语言站的抓取建议可以拿来做交叉核对。

## 抽样口径怎么定

全量比对没必要，抽样就够。

建议按模板类型抽，每种模板抽三到五个页面。

因为同一模板产出的页面，出错方式高度一致。

抽样的关键是覆盖所有模板类型，而不是覆盖更多页面。

每季度跑一次，新增模板类型时额外跑一次。

抽样结果要留档，方便跟上一次比。

抽样时还有一条容易忽略的原则：要专门挑取值处于极端的那几页，比如价格最长的、参数最多的、名称最短的，模板的破绽几乎总是在极端取值上先露出来，而随机抽样恰好最不容易抽到它们。

抽样还要覆盖不同的内容成熟度。刚上线的页面、上线半年的页面、被人工改写过的页面，三者的问题形态并不相同。只抽新页面会漏掉退化问题，只抽老页面会漏掉新模板的缺陷。三档各抽一两个，样本量不用大，覆盖面才是关键。

抽样还有一个维度容易被忽略：语言的资源丰富程度。高资源语言的自动化处理质量普遍更好，低资源语言的出错率明显更高，大规模跨语言模型在低资源语言上的表现差异 (https://arxiv.org/abs/1911.02116)在实验里体现得很清楚。所以抽样时低资源语言应该多抽一到两份。

## 报警阈值与响应

检查跑出来的差异，要有一个处理规则。

信息单元条数差一条以内，记录不处理。

差两条以上，当作模板故障排查。

格式错误一律立即修，因为它出现在价格旁边。

页面长度比例偏离历史均值三成以上，人工看一眼。

规则写死之后，这件事就能交给流程而不是靠人惦记。

把阈值写进文档还有一个好处，它让这套检查有了可讨论的基准：下一次有人觉得某个市场表现异常，可以先问一句最近一次一致性检查是什么时候跑的、结果如何，而不是从头猜起。

阈值定完还要定归属。每一类报警对应哪个角色处理，要写清楚：格式类归前端，字段缺失归内容，抓取异常归技术。没有归属的检查最后都会变成一封没人回的邮件，这一点跟检查本身设计得多精细无关。

## 怎么收口，怎么排期？

## 六周整改路线

把前面的动作排成一条可执行的线。

第一周盘点模板类型，按结构稳定度分成适合与不适合两堆。

第二周处理占位符，复数、数字格式、日期、称谓四类逐一验。

第三周算骨架占比与信息单元数，给每类模板定下限。

第四周处理同语言内的页面竞争，该合并的合并，该加规范标签的加。

第五周给模板加按语言分批发布的开关，选定两个对照组。

第六周把三条一致性检查写成脚本并排进季度日程，整个流程到这里才算闭环，因为前五周做的是一次性整改，第六周做的才是不让它退化的机制。

这条路线还有一个前提没写进周次里：得先有人能说清楚线上到底有几套模板。听起来荒唐，但模板站运行两三年后，这个问题往往没人答得上来，因为历史上打过的补丁和临时分支都散落在各处。第一周的盘点如果做不出一份完整清单，后面五周都是在猜。

盘点模板的时候顺带确认一件事：每套模板对应的语言标签是否都填对了。标签写错的模板会把整批页面的地区归属带偏，而这类错误在页面上完全看不出来。语言子标签的官方注册表 (https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry)是唯一的核对依据，逐个比对一次也就半小时。

## 三条不依赖语言能力的检查

验收同样要有机械判据。

第一条：随机打开五个模板页，数独有信息单元，少于八条不通过。

第二条：查同一门语言下变量位只差一个的页面有多少，超过阈值要处理。

第三条：查十个语言版本的数字格式是否各自符合当地写法。

三条都不需要读懂内容，看结构和数字就行。

把它们写进上线检查单，比任何一次培训都管用。

这几条也适合交给不熟悉多语言业务的新同事执行，正因为它们不依赖语言能力，执行者反而不容易被内容本身带偏，这一点在做质量检查时是优点而不是缺点。

这三条检查还可以再配一条外部视角的：把页面地址交给不熟悉业务的人，让他找一个具体信息，比如某个型号的保修期。找不到就是缺口。这条不算严格意义上的机械检查，但它能发现前三条发现不了的那类问题，也就是信息都在、却没人找得到。

## 长期维护的三条制度

最后说三条能长期生效的制度。

第一，模板变更永远留对照组，不搞全量同步上线。

第二，模板的字段清单每半年评审一次，专门找缺了什么。

第三，新增语言时先跑一遍占位符检查，不要默认它跟现有语言一样。

三条制度的成本都极低，但它们挡住的是十倍放大的错误。

保哥这些年见过太多多语言站，翻译预算给得很足，模板评审一次没做过，结果十个市场共享同一份想不起来该补什么的字段清单，一补就是十份，一漏也是十份。

三条制度之外还有一条建议：给模板本身建一份变更日志。谁在什么时候改了哪个字段、影响了哪些语言版本，都记一行。这份日志在出问题时的价值极高，因为多语言站的异常排查最难的一步永远是确定变化发生在什么时候，有日志的话这一步只要一分钟。

最后提醒一句排期上的现实：这套制度里最难落实的不是检查也不是对照组，而是第二条那个半年一次的字段评审。它没有截止日期压力，也没有人会因为跳过它而立刻出事，所以它必须被挂到某个固定节奏上，比如跟着季度复盘一起做，否则第一次跳过之后就再也不会有第二次。

## 常见问题解答

## 十个语言版本会被搜索引擎判成重复内容吗？

基本不会。近重复判定比对的是字面形态，不同语言的字符串重合度接近于零，就算保留了品牌名和型号，也远远达不到触发阈值。真正会触发判定的是同一门语言下面按城市、品类、型号铺开的那批页面，它们只有几个变量位不同，字面重合度极高。所以跨语言标注做得再完美也解决不了重复问题，因为这两件事从一开始就不在同一条线上。

## 骨架占比的阈值可以十种语言通用吗？

不能。同一段内容翻译成不同语言，长度差别可以到四成以上，而骨架和正文的长度是分别变化的，比例自然跟着变。复合词语言、不用空格分词的语言、屈折语各有各的偏移方向，一个修正系数解决不了。可行的办法有两个：要么按语言分别定阈值，要么把指标从字符数换成信息单元数。后者跨语言稳定，因为翻译不会改变事实的条数，验收时人工数一遍就行。

## 模板里的复数怎么处理才不出错？

不要自己写条件判断，直接消费现成的复数规则数据。英语只有两种形态，很多语言有三到四种，阿拉伯语有六种，按两分法写死的模板在这些语言上会有一半情形语法不通。区域数据库把每门语言的复数类别整理成了可查的规则集，前端框架和内容模板都能直接对接。这类错误的麻烦之处在于它不报错，只是读起来不通顺，自动化检查很难发现，所以要从源头避免而不是事后排查。

## 为什么要留两个语言版本不更新？

为了保留对照组。模板变更是一对多生效的，十个市场同时改完之后，如果数据下滑，你无法判断是模板引起的还是大盘波动。留两个版本不动，两到四周后比较两组的相对变化，就能得到结论。选对照组要挑流量稳定、季节波动小、且没有在跑其他实验的市场，规模太小的市场噪声大看不出差别。这套做法本质上是把灰度发布搬到内容侧。

## 哪些页面根本不该用模板？

需要摆事实讲道理、需要给出建议的页面都不该用。判断方法很简单：把五个同类页面的提纲摆在一起，如果小标题能一一对上，说明结构稳定，适合模板；如果每一页的小标题都不一样，说明这类内容的价值就在差异本身，套模板等于把价值抹掉。参数表、配送政策、尺码对照是模板的理想对象，选购建议、故障排查、品类导购则应该单独写，宁可少做几个市场也别十个市场都发空壳。

## 翻译记忆库对模板站是利是弊？

成本上是利，质量上有隐患。相同句子只翻一次再复用，费用确实下来了，但一旦某个句子译得不合适，它会被复用到所有页面，而且越高频错得越广。另一个隐患是语域：记忆库只认句子不认语境，可能把商品页那种轻松的说法搬进法务条款。使用记忆库的前提是配一条反向流程，改了记忆库就回刷受影响的页面，同时对承诺、责任、金额相关的句子做人工确认。

## 已经上线的模板站，从哪一步开始整改？

先量再改。第一步是盘点模板类型并按结构稳定度分成两堆，这一步能立刻告诉你哪些页面是错配的。第二步验占位符，复数、数字格式、日期、称谓四类逐一过，这是投入最小、效果最直接的一步。第三步才是处理同语言内的页面竞争。顺序不能颠倒，因为在占位符还在出错的情况下去调整页面结构，你分不清表现差是结构问题还是渲染问题。

## 权威参考资料



## 小语种内容的参考资料栏，约鲁巴语八成条目有，里面一条都没有

- URL：https://zhangwenbao.com/minor-language-content-citation-density.html
- 分类：小语种SEO
- 发布：2023-03-14  |  更新：2023-03-14
- 摘要：30门语言各抽70条实测公共内容的引用密度：带出处率1.4%到90.0%，约鲁巴语空参考栏占有栏87.3%，豪萨语与约鲁巴语同国对照差4.3倍。
- 关键词：内容质量,多语言SEO,内容运营,小语种SEO

> **TLDR**：摘要：30门语言各抽70条公共内容，逐条数底下有没有可核查的出处。带出处的比例从阿姆哈拉语的1.4%排到英语的90.0%，老挝语14.3%、约鲁巴语15.7%。约鲁巴语更极端的是另一个数：78.6%的条目有参考资料栏，而栏里一条出处都没有，空栏占有栏的87.3%。最硬的对照来自同一个国家的两门语言——尼日利亚的豪萨语带出处67.1%、空栏2.9%，约鲁巴语15.7%、空栏68.6%。

> 摘要：30门语言各抽70条公共内容，逐条数底下有没有可核查的出处。带出处的比例从阿姆哈拉语的1.4%排到英语的90.0%，老挝语14.3%、约鲁巴语15.7%。约鲁巴语更极端的是另一个数：78.6%的条目有参考资料栏，而栏里一条出处都没有，空栏占有栏的87.3%。最硬的对照来自同一个国家的两门语言——尼日利亚的豪萨语带出处67.1%、空栏2.9%，约鲁巴语15.7%、空栏68.6%。

## 你引用的那条小语种资料，底下垫着什么？

## 这个动作每个做多语言的人都做过

要写一篇某个小语种市场的内容，第一步通常是去查这门语言里已有的资料。查到一条，读一遍，觉得说得挺清楚，就顺手当成事实用了。

这件事的隐蔽之处在于，出错的那一刻你毫无感觉。一条没有出处的资料读起来跟一条挂着二十个引用的资料没有任何差别，中文读者甚至看不出那门语言的页面上少了一列东西。

这一步在英语环境里风险不大，因为英语资料底下通常挂着一串出处，你不放心可以顺着点进去看。换到小语种，很多人不会去点——一来看不懂，二来默认它跟英语版一样有。

保哥自己踩过一次。当时照着一条本地资料写了某个市场的退货规定，发出去之后被本地同事指出来那个说法早就改了。回头去看那条资料，底下什么都没有，只有一个标着参考资料的空栏。

这一篇就量这件事：30门语言的公共内容里，有多少条底下真的垫着可核查的东西。用的是跟上一篇体裁那一列 (https://zhangwenbao.com/minor-language-content-genre-composition.html)完全同一批抽样的同一批条目，两列可以逐行对着看。

## 为什么这件事在生成式搜索之后更要紧

以前这是个人工核查的问题：你信不信一条资料，取决于你愿不愿意花时间去点那几个链接。现在多了一层，因为模型也在读同一批内容。

还有一个方向的影响也值得记：你自己的内容如果挂了出处，在一个普遍没有出处的语言环境里就显得格外突出。这是本篇最后一节要展开的那件事，先在这儿留个引子。

模型读一条内容的时候，不会区分它底下有没有出处。一条有二十个引用的条目和一条一句话加空参考栏的条目，在训练语料里长得一样重。

这条线的底子在多语言模型铺到七十多种语言那一篇 (https://zhangwenbao.com/multilingual-bert-seventy-languages-minor-language-seo-watershed.html)里就埋下了：模型在小语种上的表现主要靠跨语言迁移，而迁移过来的不只是语法，还有那门语言语料本身的样子。语料底下没垫东西，迁移过来的也就是一片没垫东西的说法。

要说清楚的是，模型给出答案时挂的是哪门语言的来源，跟这门语言里的内容自己引了谁，是两个不同的问题。前一个问的是检索侧，后一个问的是供给侧。本篇只做后一个，因为它不依赖任何一家产品当时的行为。

## 出处这件事跟内容质量不是一回事

得先把话说清楚：一条内容有出处不代表它写得对，没出处也不代表它写错了。出处只回答一件事——这条内容能不能被第三方核查。

公共百科自己把这件事写成了核心方针，官方的说法是可供查证优先于真实性 (https://en.wikipedia.org/wiki/Wikipedia:Verifiability)：读者要能追到出处，而不是要求写的人保证自己说得对。

这条方针在英语版执行得相当到位，在别的语言版本执行到什么程度，就是本篇要量的东西。同一套规则，30门语言的落实程度差了64倍。

顺带说一句，这跟母语审校验收那一篇 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)里讲的读着自然不能当验收判据是同一族的道理：读着可信和能被核查，是两个不同的东西。

## 本文量什么、不量什么

量三样：一条内容里有几个脚注引用、有没有一个专门放出处的区块、这个区块里是不是空的。三样都从截断时点的原始文本里数，不看渲染结果。

另外要说清楚的是时间口径。所有数字取的都是2022年12月31日那一版的内容，不是今天的状态。这么做是为了让这批数跟上一篇的抽样落在同一个时点上，代价是它反映不了这之后几个月的变化。

不量出处本身的质量。一条引用挂的是政府公报还是某个博客，这次不区分。这一层只回答有没有，不回答好不好。

也不量商业站。这批数据来自公共百科，它反映的是这门语言的社群在无偿状态下的引用习惯。商业站的引用密度是另一回事，而且通常更低。

还有一件事这次特意不做：不按出处密度给语言打分。原因在第七节——这把尺子在被机器灌过的语言上会给出最好看的分数，单独拿去排名会排出反的顺序。

## 出处这件事怎么在外面量出来？

## 数的是原始文本不是渲染结果

公共百科的每条内容底下都有一份可以直接取到的原始文本，脚注在里面是一个成对的标签，长什么样在脚注的官方帮助页 (https://en.wikipedia.org/wiki/Help:Footnotes)上写得很清楚。

还有一个副作用是省了大量流量。原始文本通常只有渲染页面的十分之一大小，三十门语言两千一百次请求下来，总量还不到抓一遍首页的开销。

为什么不数渲染出来的页面？因为渲染会把模板展开，一个引用可能变成好几个节点，也可能因为模板出错整个消失。原始文本里一个引用就是一个标签，数起来干净。

更实际的原因是可截断。要让这批数据坐在2022年12月31日这个时点上，必须取那一天那一版的文本，而渲染结果只有当前版本。

取历史版本这一步是整套采集里最贵的：多个页面加上时间参数会被接口直接拒掉，只能一页一次。30门语言每门70条，两千一百次请求跑了不到二十分钟，但这个上限决定了子样本只能取70条而不是240条。

## 抽样跟上一篇完全一致

体裁那一列抽了240条，出处这一列取的是其中的前70条。所以两列的样本是嵌套的，任何一门语言的出处数据都能直接对到它的体裁数据上。

为什么不把出处这一列也做满240条？因为取历史版本只能一页一次，240条乘30门是七千二百次请求，时间成本翻三倍而结论一个字都不会变。把省下来的时间花在原文复核上，收益高得多。

这件事的好处在第八节会体现出来：能直接算出各体裁的带出处率，而不用另外抽一批样本再去对齐。

抽样方法沿用上一批：在页面编号的整数空间里随机取，用创建日志的75分位当截断水位，再抽45条逐页复核代理误差。30门语言的越界数全部是0。

70条这个样本量决定了能说到多细。一个真实占比50%的指标，70条样本的误差大约在正负12个百分点，所以本篇所有对比都压在差距20个百分点以上的地方。

## 参考栏这个东西不能认模板名

第一版直接搜了参考栏最常见的那个模板名，越南语测出来2.9%——而同一批条目里87.1%有脚注引用。一门语言九成条目有引用、却只有百分之三有参考栏，这显然不成立。

打开一看，越南语用的是本地化的模板名，我搜的那个拉丁写法在越南语版里根本不存在。这是这批数据里第二把失效的尺子，而且它失效的方式是安静地给出一个假零。

改法是不认模板名：只看文末那个区块标题下面有没有正文。如果一个区块底下除了一个模板调用之外几乎什么都没有，那它就是一个参考栏的壳，管它叫什么名字。

改完之后越南语94.3%、英语77.1%、约鲁巴语78.6%，数值才互相说得通。由此固化一条：任何跨语言的存在性检测，都不能认某一门语言的模板名。

## 三个指标各回答什么

带出处率回答的是：随机翻开一条，底下有东西的概率。这个数最直接，也是本篇的主指标。

三个数里最容易被误用的是密度，因为它看起来最专业。汇报的时候如果只能给一个数，给带出处率；如果能给两个，第二个给空参考栏率，别给密度。

出处密度回答的是：有出处的那些条目，出处密不密。它用每千字节几个引用来算，好处是跟条目长短无关，坏处在第七节。

空参考栏率回答的是：格式做了、动作没做的比例。这个数是本篇最有画面感的一个，因为它量的是一种很具体的形态——栏在，里面什么都没有。

三个数要一起看。带出处率低有两种可能：一种是这门语言压根没有引用的习惯，另一种是有习惯但没执行。空参考栏率一出来，两者立刻分开。

## 三十门语言的带出处率排出来是什么样？

## 两头的跨度是64倍

最高的一头：英语90.0%、越南语87.1%、孟加拉语80.0%、瑞典语77.1%、缅甸语75.7%、泰米尔语74.3%、尼泊尔语70.0%。

还有一件事从这张排名里看不出来：低的那一头并不都是同一种低法。有的是压根没有引用的习惯，有的是有习惯但没执行，后面第四节的空参考栏率专门把这两者分开。

最低的一头：阿姆哈拉语1.4%、老挝语14.3%、约鲁巴语15.7%、冰岛语22.9%、高棉语27.1%、僧伽罗语31.4%、阿尔巴尼亚语32.9%。

中位数落在50%附近，也就是随机翻开一条，有一半的概率底下什么都没有。这个中位数比开工前的预期低得多，保哥当时写的是小语种大概在30%到50%之间，实测最低那一头直接掉到个位数。

阿姆哈拉语那1.4%的意思是：70条抽样里只有1条带出处。这个数低到得单独验一遍才敢用。

## 阿姆哈拉语那唯一一条是什么

打开看了。那一条叫淋巴丝虫病，一篇医学词条，4843字节，挂着22条引用。

顺带说一句为什么是医学词条。这一类内容在任何语言里都是被翻译得最勤的一档，因为背后有公共卫生机构在推。所以那22条引用大概率不是本地社群加的，是从别的语言版本一起搬过来的。

而阿姆哈拉语这70条的字节中位数是332。也就是说除了这一条之外，其余69条基本都是三百来字节的短条，一句话到两句话的规模。

这就把结论的性质改了。原来的说法是这门语言的人不写引用，实测的说法应该是：这门语言的内容里，只有个别条目被认真写过，而被认真写过的那一条引用给得非常足。

两个说法的落地动作完全不同。前者意味着这门语言的资料整体不可信；后者意味着你能不能用这门语言的资料，取决于你碰到的是不是那少数几条。而随机碰到的概率是七十分之一。

## 相关系数这次对了

带出处率跟条目总量的相关系数是正0.658，秩相关正0.593。这是本批唯一一条方向猜对的预期——内容量大的语言，引用规范执行得确实更到位。

顺带把内容池的另外几列也对了一遍：跟名录型占比的相关是正0.255，跟机器判不出类型的比例是负0.392。这两条都不强，但方向都有解释，后面两节各展开一次。

说唯一不是自谦。这一批一共写了12条开工前的预期，最后错了9条。这一条能对，是因为它背后的机制最简单：写的人多，里面就有更多懂规矩的人。

但0.658也不算强，意味着还有大约一半的差异要靠别的东西解释。那个别的东西在下一节。

顺带把两条预期的相关也算了：跟译入率 (https://zhangwenbao.com/minor-language-content-translated-share.html)的相关只有正0.285，弱到不能用。翻译工具会不会把源语言的引用带过来，这条假设没被数据支持。

## 下面这张表把三个数放在一起

挑了跨度最大的几门，全部是70条子样本、截断2022年12月31日。条目总数那一列跟上一篇同源，取自各语言公共百科的同一份统计 (https://meta.wikimedia.org/wiki/List_of_Wikipedias)。

语言 | 条目总数 | 带出处 | 出处中位数 | 有参考栏 | 栏里是空的 | 

英语 | 7218435 | 90.0% | 4 | 77.1% | 2.9% | 

越南语 | 1304103 | 87.1% | 1 | 94.3% | 8.6% | 

缅甸语 | 111575 | 75.7% | 1 | 47.1% | 12.9% | 

豪萨语 | 106850 | 67.1% | 1 | 42.9% | 2.9% | 

乌兹别克语 | 353367 | 44.3% | 0 | 68.6% | 34.3% | 

斯瓦希里语 | 121657 | 34.3% | 0 | 65.7% | 32.9% | 

约鲁巴语 | 38802 | 15.7% | 0 | 78.6% | 68.6% | 

老挝语 | 5597 | 14.3% | 0 | 21.4% | 10.0% | 

阿姆哈拉语 | 15708 | 1.4% | 0 | 7.1% | 5.7% | 

出处中位数那一列有十几门语言是0，意思很朴素：随机翻开一条，最可能的情况是一条引用都没有。

## 参考资料栏在，栏里为什么是空的？

## 约鲁巴语那一格

约鲁巴语70条里有55条带参考栏，而带出处的只有11条。48条是有栏没内容，占有栏条目的87.3%。这是全表最极端的一格，也是这次数据里最有画面感的一个发现。

三条打开之前保哥其实做了个预判：以为会看到那种正文很长、只是没人补引用的条目。结果三条的正文加起来还不到一千字节，这个预判错得挺彻底。

按纪律打开了三条原文看，形态完全一样。第一条讲北非，437字节，正文是一个地图模板加一张国家列表，然后一个标着参考资料的小节，小节里只有一个模板调用。

第二条讲铊，313字节，正文就一句话：铊是化学元素，符号Tl，原子序数81。然后同样一个空的参考资料小节。

第三条讲一个地方政府辖区，285字节，正文两句，一句说它在哪个州，一句说首府是哪儿，中间还留着一行写着村庄列表的空标题。然后还是那个空参考栏。

## 这是格式学会了动作没做

这三条的共同点不是内容少，是内容少却把格式摆得很齐。有分类链接、有信息框模板、有分节标题、有参考资料栏，唯独没有那件真正费事的事。

换个角度看，这也说明模板这套东西的传播效率有多高。一个参考栏模板能在几年里铺满一门语言的大半条目，而给这些条目逐条补出处的工作量，是几万个人时。

保哥觉得这个形态特别值得记，因为它在别的地方也能见到。一个页面上标题层级、结构化数据、面包屑全齐，正文两百字；一份产品页把参数表列得整整齐齐，每一格填的是待补充。

格式是可以复制的，动作不能。一个模板被复制一千次的成本几乎是零，而给一千个条目各找一条出处的成本是一千次。

所以空参考栏率量的其实不是引用习惯，是模板扩散速度和人工投入之间的差额。这个差额越大，这门语言的内容看起来越正规、底子越空。

## 三十门语言的空栏排名

约鲁巴语68.6%之后是乌兹别克语34.3%、斯瓦希里语32.9%、阿尔巴尼亚语28.6%、尼泊尔语18.6%、格鲁吉亚语17.1%、阿塞拜疆语17.1%、波斯语14.3%。

英语那2.9%也值得说一句：英语版有专门的机器人在巡查空的参考栏并挂上提示模板，所以那个低数字里有一部分是被清理出来的，不完全是自然状态。

最低的一头是德语和荷兰语0.0%、冰岛语1.4%、英语2.9%、豪萨语2.9%、僧伽罗语2.9%、瑞典语2.9%、泰米尔语4.3%。

把空栏占有栏的比例也算了：约鲁巴语87.3%、阿姆哈拉语80.0%、乌兹别克语和斯瓦希里语各50.0%、阿尔巴尼亚语48.8%、老挝语46.7%。这一列超过40%就说明模板铺得比人跑得快。

荷兰语那个0.0%有个特殊原因：荷兰语版几乎不用独立的参考小节，有参考栏的只有1条。所以它的0.0%不是执行得好，是这个形态在那门语言里不流行——分母只有1的比例不能拿去比较，这一条必须写出来。

## 空栏这个数怎么用

实操上它是一个很好的先看一眼的指标，因为它比带出处率更容易解释给不懂技术的人听。

带出处率50%听起来像个中等成绩；空栏占有栏的比例50%听起来就完全不一样了，它的意思是这门语言里每两个摆出引用架势的条目就有一个是空架子。

判读线可以定得很粗：空栏占有栏低于10%，这门语言的资料可以按常规核查流程走；10%到40%要逐条点开看；超过40%就默认没有出处，把核查成本按从零调研排。

还有一个用法是识别工具痕迹。空栏率突然很高，往往说明有人用工具批量建过条目，而工具会把模板一起复制。这跟编辑人数那一篇 (https://zhangwenbao.com/minor-language-content-volume-editor-count.html)里的灌注识别是同一族信号。

## 同一个国家的两门语言，为什么差这么远？

## 豪萨语和约鲁巴语摆在一起

这次数据里最干净的一组对照来自尼日利亚。豪萨语和约鲁巴语都是这个国家的主要语言，使用者都以千万计，做非洲市场绕不开这两门。

顺带排除一个常见的解释：这不是宗教或者殖民历史造成的书面传统差异。两门语言的书面标准都是十九世纪定的，用的都是拉丁字母，起点上没有系统性差别。

两门语言的数摆出来是这样：条目总数10.7万对3.9万，带出处67.1%对15.7%，空参考栏2.9%对68.6%。带出处率差4.3倍，空栏率差24倍。

而体裁那一列反过来：人物占比约鲁巴语65.2%比豪萨语59.6%还高一点。所以这不是一门语言写得多另一门写得少的问题，两门写的东西形状差不多。

差的是底下垫没垫。同一个国家、同一个时期、同一套规则，一门执行了，一门只把格式抄了过去。

## 这条跟别的批次对得上

这个差异不是孤证。编辑人数那一篇 (https://zhangwenbao.com/minor-language-content-volume-editor-count.html)量过十年趋势：豪萨语的编辑活动涨了254%，约鲁巴语跌了58%，两门语言的方向完全相反。

体裁那一篇也对得上：约鲁巴语的条目字节中位数是236，全表最低，比阿姆哈拉语的332还短。一句话的条目配一个空参考栏，正好是本节那三个原文样本的形态。

还有更早的一条：页面阅读中位数那一篇 (https://zhangwenbao.com/minor-language-page-reader-median.html)把约鲁巴语整门剔了出去，因为它的热门榜前十二名全是单个拉丁字母的页面。

四个批次、四套完全不同的采集方法，指向同一个结论：约鲁巴语的内容池里，人做的那部分明显比机器做的那部分少。这种跨方法的一致性，比任何单一指标都值得信。

## 做非洲市场的人该怎么用这一条

直接的用法是：这两门语言不能按同一套流程做内容调研。

还有一个实操细节：这两门语言的内容在同一个检索工具里出来的时候长得一样，不点开看不出区别。所以最好在调研清单上直接按语言标好核查等级，别指望现场判断。

豪萨语的公共资料可以当线索用，查到一条觉得有用，底下大概率能点出去核对一遍。约鲁巴语的资料只能当线索的线索，看到什么都得另外找一手来源确认，不要拿它当依据写进正式内容。

这跟非洲选语种那一篇 (https://zhangwenbao.com/africa-market-language-selection-swahili-hausa-francophone.html)的判据能接上：那一篇说别先看人口，先看有没有人拿这门语言写价格和退货政策。这一篇补一句——还要看写下来的东西底下有没有垫东西。

斯瓦希里语在这次数据里的位置也值得一提：带出处34.3%、空栏32.9%，比约鲁巴语好但明显不如豪萨语，属于要逐条点开看的那一档。

## 成对样本比相关系数好用

整篇算了四五个相关系数，最强的那个是0.658。它能告诉你方向，说服不了任何人。

而豪萨语对约鲁巴语这一组，两个数摆在一起谁都懂：同一个国家的两门语言，一门六成七有出处，一门六成九是空架子。相关系数负责严谨，成对样本负责被记住。

这一批还找到几组类似的：格鲁吉亚语对亚美尼亚语，条目总数19.8万对33万，带出处40.0%对61.4%；马其顿语对阿尔巴尼亚语，16.3万对10.6万，52.9%对32.9%，空栏12.9%对28.6%。

这些成对样本的共同点是体量接近、地理相邻、结果差一大截。它们能把内容量这个变量按住，剩下的差异只能由别的东西解释。

## 名录型条目是不是真的没有出处？

## 这条预期错得最厉害

开工前保哥写的预期里有一条特别笃定：那些能从一张表成批生成的条目，比如物种、行政区划、年份页，肯定一条出处都没有，因为它们本来就是机器导进来的。

实测：名录型条目带出处51.0%，人写的条目带出处54.3%。两者只差3.3个百分点，基本一样。

更打脸的是分体裁的排名。带出处率最高的一档不是人物也不是概念，是生物分类单元，75.5%。天体那一档倒是低，29.4%，但那是另一个原因。

这条错得离谱，但错得有价值，因为它把出处这个指标的性质暴露出来了。

## 为什么物种条目引用最全

打开看就明白了。物种条目是从分类学数据库导进来的，而分类学数据库里每一条记录本来就带着定名文献——谁在哪一年发表了这个物种。

同一个机制在别的地方也见过。行政区划条目在有普查数据的国家通常带一条人口统计出处，在没有的国家一条都没有——差别不在写的人，在那个国家有没有公开一张能引的表。

导入脚本把这条文献一起带了过来，于是每一条物种条目天然带一个引用。不是有人给它加了出处，是它来的地方本来就带着出处。

天体那一档就没这个待遇，29.4%。因为小行星条目通常只有编号和轨道参数，没有一份对应的定名文献可以自动挂上去。

这两档一高一低，说明的是同一件事：名录型条目有没有出处，取决于导进来的那张表上有没有那一列，跟这门语言的社群一点关系都没有。

## 那这个指标还能用吗

能用，但要知道它在量什么。带出处率量的是一门语言的内容里有多少能被核查，这个定义本身没问题——一条自动带来的引用也是引用，读者一样能顺着点出去。

更稳的做法是只在人写口径上算这个数，也就是先剔掉名录型条目再算带出处率。这次两个口径都算了，人写口径下的排名跟全样本口径基本一致，说明主结论不靠这道处理撑着。

要小心的是别把它解释成社群的认真程度。名录型占比高的语言，带出处率会被这批自动引用抬上去，看起来比实际的人工投入好。

相关系数也证实了这一点：名录型占比跟带出处率的相关是正0.255。弱，但方向是正的——水分越大的内容池，出处这一列反而更好看。

所以正确的读法是把两列并排放：名录型占比那一列 (https://zhangwenbao.com/minor-language-content-genre-composition.html)先读，再读带出处率。名录型占比越高，带出处率要打的折越大。

## 剩下几档的排名

把全部样本按体裁合并算，带出处率从高到低是：生物分类单元75.5%、事件70.5%、组织机构69.0%、建筑与设施66.2%、人物56.2%、作品56.1%、聚居地与行政区54.3%、自然地理50.0%、概念与术语43.2%。

概念与术语这一档43.2%排在最后一档，比人物还低13个百分点。这对做独立站的人不是好消息，因为概念与术语正好是你唯一能挂靠的那一格。

开工前还有一条预期也错了：以为人物条目的出处会明显多于地名条目，因为写人容易被质疑。实测人物56.2%对聚居地54.3%，差2个百分点，没有意义。

最低的三档是天体29.4%、消歧义与维护页14.7%、时间单位11.4%。后两档低是应该的，它们本来就不承载事实，是纯导航页。

## 出处密度这个数，为什么不能单独排名？

## 密度榜首是瑞典语

出处密度用每千字节几个引用来算，好处是不受条目长短影响。按这个数排下来，第一名是瑞典语2.14，第二名豪萨语1.26、立陶宛语1.27，英语只有1.20排第四。

这是本批第三次遇到一个太顺的解释。上一批那次更惊险：算出来的参照国排名每一条都能编出理由，打开条目才发现全是机器导进来的名录。太顺这件事本身就该当成一个警报。

瑞典语的引用密度比英语还高八成，这个结果第一眼看上去挺合理——北欧国家嘛，做事严谨。这种解释听起来太顺了，顺到得停下来查一下。

把瑞典语密度最高的六条打出来看：33 Orionis是一颗恒星、Phyllium exsectum是一种竹节虫、Lepidasthenia digueti是一种多毛类、Strombus pugilis是一种海螺、Peruansk basilika是一种植物。

全是机器生成的物种和天体条目，每条两三千字节，带9到16个引用。瑞典语的密度冠军不是社群严谨，是那批被灌进去的条目每条自带一串定名文献。

## 这跟别的批次的结论合上了

瑞典语被机器灌过这件事，本站量过两次。编辑人数那一篇 (https://zhangwenbao.com/minor-language-content-volume-editor-count.html)算出瑞典语的名录型内容主体不是人写的，阅读中位数那一篇 (https://zhangwenbao.com/minor-language-page-reader-median.html)算出瑞典语随机一页一年只有6个人打开。

本篇的名录型占比也对得上：瑞典语65.8%，其中生物分类单元一档就占整个样本的50.0%。一门语言的公共内容里一半是物种词条。

所以三个批次的结论叠在一起是：这门语言的内容量一半是机器灌的，灌进来的东西没人读，而正是这批没人读的东西把出处密度这个指标顶到了全表第一。

这是本批第三次遇到同一类现象——爬虫占比那一篇 (https://zhangwenbao.com/minor-language-crawler-share-traffic-report.html)里也是这样：一个看起来在变好的数字，背后是机器那一半在涨。

## 密度这把尺子的正确用法

密度不能单独排名，但它跟带出处率并排看的时候能分出两种情况。

带出处率高、密度也高：这门语言的内容普遍有引用，而且引得不止一条。英语属于这一档，90.0%配1.20。

带出处率不高、密度却很高：说明有出处的那一小批引用给得特别足，而大多数条目什么都没有。立陶宛语47.1%配1.27、爱沙尼亚语44.3%配1.14，都属于这一档，是典型的两极分化。

带出处率和密度都低：老挝语14.3%配0.10、阿姆哈拉语1.4%配0.06。这一档没什么可解释的，就是没有。

## 还有一个更朴素的替代指标

如果嫌密度太绕，有个更直接的：出处中位数。随机翻开一条，底下有几个引用。

要注意中位数为0不等于这门语言完全没有带出处的内容，它只说明带出处的条目不到一半。两个数一起给才完整：中位数0加带出处率44.3%，意思是四成多的条目有出处，但不到一半。

这一列有十几门语言是0，包括印尼语、立陶宛语、乌兹别克语、爱沙尼亚语、格鲁吉亚语、蒙古语、斯瓦希里语、阿尔巴尼亚语、僧伽罗语、高棉语、冰岛语、约鲁巴语、老挝语、阿姆哈拉语。

而英语是4、瑞典语6、泰米尔语3、孟加拉语3。这一列比密度那一列好懂：0的意思是随机翻开一条，最可能的情况是什么都没有。

汇报的时候建议用这个数，因为它不需要解释口径。跟不做技术的人讲每千字节1.2个引用，对方多半没反应；讲随机翻开一条底下是空的，对方立刻懂。

## 没人标类型的东西，是不是底下也没垫东西？

## 两条腿在这里合上

体裁那一篇最强的一条发现是机器不认率——一门语言的内容里有多大一块，机器连它属于哪一类都判不出来。高棉语50.8%、缅甸语44.6%、阿姆哈拉语42.9%、僧伽罗语41.2%。

把这两列画成散点也能看出来：右下角是空的，也就是几乎没有哪门语言在类型标注很差的同时出处又很好。缅甸语是唯一一个明显的例外，原因在本节最后一段。

把这一列跟带出处率做个相关：负0.392。方向是对的，强度一般。真正说明问题的是条目级的口径。

把所有语言的样本合并，按条目分三堆：机器不认那一堆带出处34.4%，名录型51.0%，人写54.3%。机器不认那一堆比另外两堆低了近20个百分点。

这两件事本来毫无关系——标一个类型是在结构化数据那一侧做的动作，加一条引用是在正文里做的动作，工具不同、界面不同、甚至通常不是同一批人。可它们同进同退。

## 因为它们是同一个动作的两面

写一条内容需要一个懂这门语言的人；给它标类型、给它找出处，需要一个愿意做整理的人。写作和整理是两件事，而小语种缺的往往是后者。

这条能解释很多之前散着的现象。约鲁巴语的空参考栏、高棉语的无类型条目、阿姆哈拉语那69条三百字节的短条，形态各不相同，背后是同一件事没做。

也能解释为什么这两个指标跟内容量的相关都不算强：内容量量的是写了多少，而这两个指标量的是整理了多少。写的人多不一定整理的人多，这两批人的增长曲线不是一条。

由此得本批的一句话：你看到的内容量，不告诉你这些内容是什么形状的，也不告诉你它底下垫没垫东西——而后两件事是同一批人做的，通常一起缺。

## 对做站的人意味着什么

第一个后果是核查成本。机器不认率高的市场，你不但要自己核查每一条本地资料，还没法用任何依赖类型筛选的工具去批量过滤。两个成本叠在一起。

第二个后果反而是机会。整理这件事在你自己的站上是完全可控的：结构化数据那一篇 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)讲的标注动作，加上正文里认真挂几条出处，成本不高。

在一个整个语言环境都没人做整理的地方，把整理做全，你的页面在机器眼里就是少数几个能被判断类型、能被追到来源的对象。这个位置在英语市场花钱都买不到。

第三个后果是别指望本地竞品给你打样。这几门语言里的本地站通常也没做这些，你照着抄等于把空白抄一遍。

## 这条能不能证伪

能。如果整理这件事真的是同一批人做的，那么在同一门语言内部，标了类型的条目应该比没标类型的条目更可能带出处。

合并样本的口径已经验了：机器不认那一堆34.4%，其余两堆51.0%和54.3%。方向对上了。

但有一处对不上，得说出来：缅甸语的机器不认率44.6%排第二高，带出处率却有75.7%排第五高。这一门明显违反这条规律。

翻开缅甸语的样本能看到原因：那批没有数据项的条目全是某某村加某某镇区的格式，而缅甸语版给这批村庄条目配了统一的来源模板，一条条目一条出处。又是一次导入带来的出处，跟社群整理无关——所以这个反例不推翻规律，它推翻的是拿单一指标下结论这件事。

## 这一条怎么改你的内容核查流程？

## 三档核查强度

把带出处率和空栏占有栏比例合起来读，能给出一条能直接排进流程的分档。

分档只是起点，实际排期还要看这批内容承担多重的责任。同一门语言里，一篇品牌故事和一页退货政策该按不同的强度核查，后者错一个数字就是真金白银的赔付。

第一档，带出处率高于65%且空栏占有栏低于15%。本地资料可以当依据用，按常规流程核查即可。英语、越南语、孟加拉语、缅甸语、泰米尔语、豪萨语落在这一档。

第二档，带出处率在35%到65%之间。本地资料只能当线索，每条都要点开看底下挂的是什么。波兰语、马其顿语、波斯语、阿塞拜疆语、荷兰语、印尼语、立陶宛语落在这一档。

第三档，带出处率低于35%或者空栏占有栏高于40%。默认这门语言的公共资料没有出处，涉及事实的内容一律另找一手来源。约鲁巴语、老挝语、阿姆哈拉语、冰岛语、高棉语、僧伽罗语、阿尔巴尼亚语、乌兹别克语、斯瓦希里语落在这一档。

## 哪几类内容必须走最严的那一档

不用所有内容都按最严的来。真正需要严格核查的是可证伪的那几类：数字、编号、日期、法规名、机构名、计量单位。

这几类的共同点是错了以后能被人一眼指出来，而且会连累整页的可信度。相比之下，一段描述性的介绍写得笼统一点，风险小得多。

实操上可以这么做：内容写完之后把这几类信息单独拉一张清单，逐条标注来源。清单上没有来源的那几条，要么去找到来源，要么把那句话删掉。

这个动作跟机器翻译直接发布那一篇 (https://zhangwenbao.com/machine-translation-direct-publish-search-risk-quality-line.html)里的验收清单是同族的，只是入口不同：那一篇的入口是译文，这一篇的入口是本地公共资料。两者的失败模式一样，都是读着很顺、底下是空的。

## 本地资料查不到出处的时候找谁

第三档市场最实际的问题是：本地公共资料指望不上，那一手来源去哪找。

顺序上建议这样：政府和监管机构的官方网站排第一，行业协会排第二，本地大型企业的公开文件排第三，本地主流媒体排第四。前两类的问题是更新慢，后两类的问题是有立场。

还有一类经常被忽略：这门语言的英语版官方资料。很多小市场的政府网站有英语版，内容比本地语言版还全。用英语版核对事实、用本地语言写内容，这个组合在第三档市场里最省力。

最后一类是人。第三档市场里，找一个本地从业者问二十分钟，效率高过查两天资料。这笔钱在预算里通常没有一栏，得自己加进去。

## 自己站上该反过来做什么

知道了整个语言环境的出处密度很低，你自己站上的动作应该是反着来：把出处做得比本地平均水平高一大截。

具体做法不复杂：涉及数字和法规的地方挂一条官方来源链接，产品参数注明依据的标准编号，作者信息写全。这几样加起来的成本不到一篇内容的一成。

收益在于，一个所有条目都没出处的语言环境里，一个有出处的页面是极少数。无论是读者还是抓取内容的模型，都能把这个差别看出来。

本站在本地作者与资历信号那一篇 (https://zhangwenbao.com/minor-language-eat-local-author-byline-credential-signals.html)里讲过署名这一层，出处这一层跟它是配套的：署名回答谁写的，出处回答凭什么这么写。

## 自己跑一遍要准备什么？

## 最小版本二十分钟

不需要写代码。打开那门语言的公共百科，连点30次随机页面，每次记两个字：底下有没有引用，有没有一个专门的参考栏。

三十条记完，算两个比例。有引用的低于10条就落第三档，有参考栏但没引用的超过12条也落第三档。这两个判据只要中一个就按第三档处理。

不懂那门语言完全不影响，因为脚注在渲染出来的页面上长得都一样：正文里一个上标数字，页面底部一列带编号的条目。看得见那一列就是有，看不见就是没有。

顺带记一下条目长度。三十条里超过一半是两三行就结束的，这门语言的资料基本没有当依据的价值，不用再往下量了。

## 想更准就取原始文本

要做语言之间的排序，30条不够，得提到70条以上，而且最好取原始文本来数，因为渲染页面上有些引用会被模板吃掉。

取原始文本的接口在版本接口的文档 (https://www.mediawiki.org/wiki/API:Revisions)里，加上时间参数就能取到任意时点那一版。要注意的坑是多个页面加时间参数会被直接拒，只能一页一次。

数的时候只认脚注标签本身，别去数参考栏里的条目，因为参考栏的内容是模板展开出来的，原始文本里看不到。脚注标签数出来的是实际挂了几条，这才是你要的数。

参考栏的检测千万别认模板名，本篇第一版就栽在这里。改成看文末区块底下有没有正文，跨语言才可比。各语言版本对格式的要求本来就不统一，引用格式指引 (https://en.wikipedia.org/wiki/Wikipedia:Citing_sources)里说明的那套写法只是英语版的约定。

## 加一列会更有用

有余力的话加一列体裁，也就是上一篇那套做法。因为带出处率必须按体裁打折——名录型占比高的语言，这个数会被自动引用抬上去。

再加一列条目字节中位数。这一列几乎零成本，却能把两种低出处率分开：条目普遍很短的语言是没人写，条目不短却没出处的语言是写了没整理。

三列合起来才能给出一个能拿去开会的判断：这门语言的资料能不能用、为什么不能用、要补的是哪一件事。

最后提醒一句复算频率。这个数变得比体裁快，因为一次批量导入或者一个模板改动都能让它跳一大截。做决策之前现算一次，别用一年前的数。

## 常见问题解答

## 公共百科的出处密度，能代表这门语言里所有资料的可靠程度吗？

不能。公共百科的引用要求是它自己的方针，商业站、政府站、媒体站各有各的习惯，通常比它更松。这套数能代表的是一个下限判断：连要求最明确的地方都做不到，别的地方大概率更差。把它当作要不要额外安排核查预算的探针用，是合适的。

## 为什么不直接看页面底部有没有参考文献列表，那样不是更快？

因为参考文献列表是模板展开出来的，摆一个空模板跟真的挂了引用，在页面上都会渲染出一个小节标题。约鲁巴语78.6%有参考栏、只有15.7%有引用，就是这么来的。要判断有没有出处，得看正文里的上标数字，或者直接数原始文本里的脚注标签。

## 阿姆哈拉语只有1.4%，这个数是不是采集出问题了？

验过了。那70条里带出处的那一条是一篇医学词条，4843字节挂22条引用；其余69条的字节中位数是332，基本都是一两句话。所以不是采集漏了，是这门语言的内容里被认真写过的条目本来就极少。这条也提醒一件事：一门语言的资料能不能用，取决于你随机碰到的是不是那少数几条。

## 名录型条目的出处是自动带来的，那这个指标还有意义吗？

有，但要打折。带出处率的定义是有多少内容能被核查，一条自动带来的引用也确实能点出去，所以定义没错。要小心的是别把它解释成社群有多认真——名录型占比跟带出处率的相关是正0.255，方向是正的。正确读法是先看名录型占比，再看带出处率，前者越高后者要打的折越大。

## 出处密度和带出处率不一致的时候，该信哪个？

信带出处率，密度只当补充。因为密度的分母是字节数，会被两类东西扭曲：一是机器灌的短条目自带引用会把密度顶高，二是长条目里引用集中在几段会把密度拉低。带出处率没有这两个问题。要给不做技术的人汇报，用出处中位数最直接，0的意思是随机翻开一条底下什么都没有。

## 知道了这个数，具体能省下什么？

能省的是把核查成本排错位置的代价。第一档市场按常规流程走，第三档市场要在排期里单独留出找一手来源的时间。最贵的错误是按第一档的流程做第三档的市场：内容写完发上去，本地同事看到之后指出说法过时，改一遍的成本比一开始多留三天高得多。

## 这套方法能不能用在自己的品类上？

能，而且更值得做。把随机抽样换成按品类关键词检索，取前三十条，量同样两个数。因为限定了品类，结论直接对应你要写的那批内容。要注意的是检索结果带排序偏好，通常比随机样本好看，所以判读线要比本文严一档。

## 权威参考资料



## 小语种内容体裁拆开看：人物近一半，品类词那格跟内容量无关

- URL：https://zhangwenbao.com/minor-language-content-genre-composition.html
- 分类：小语种SEO
- 发布：2023-01-19  |  更新：2023-01-19
- 摘要：30门语言各抽240条实测公共内容的体裁构成：人物占比7.5%到65.2%，概念与术语跟内容总量相关为零，机器判不出类型的比例秩相关负0.757。
- 关键词：竞品分析,多语言SEO,内容运营,小语种SEO

> **TLDR**：摘要：把30门语言的公共内容各抽240条逐条判类型，人物传记在人写口径下从缅甸语的7.5%一直排到约鲁巴语的65.2%，差8.7倍。跟内容总量的关系弱得可以忽略，跟体裁均衡度的关系干脆是零（−0.036）。真正跟内容量强相关的是另一格：机器连这条内容属于哪一类都判不出来的比例，高棉语50.8%、缅甸语44.6%、阿姆哈拉语42.9%，秩相关−0.757。这一格决定的不是你能看到什么，是机器能不能把你的内容归进它的答案里。

> 摘要：把30门语言的公共内容各抽240条逐条判类型，人物传记在人写口径下从缅甸语的7.5%一直排到约鲁巴语的65.2%，差8.7倍。跟内容总量的关系弱得可以忽略，跟体裁均衡度的关系干脆是零（−0.036）。真正跟内容量强相关的是另一格：机器连这条内容属于哪一类都判不出来的比例，高棉语50.8%、缅甸语44.6%、阿姆哈拉语42.9%，秩相关−0.757。这一格决定的不是你能看到什么，是机器能不能把你的内容归进它的答案里。

## 内容量这个数，能不能告诉你这些内容是什么形状的？

## 竞品表上那一列到底是什么

做多语言市场排期，几乎每张表上都有一列叫内容量。它可能来自公共百科的条目数，也可能来自某个抓取工具给的收录量，反正是一个能排序的整数。这个数用起来非常顺手，因为它只有一列。

顺手的代价是它把一堆不同的东西压成了同一个数。十万条内容可以是十万篇产品评测，也可以是十万个人名，也可以是一张行政区划表被导了一遍。三者在这一列里长得一模一样。

保哥这几年反复吃过这个亏。看到一门语言内容量不小就以为竞争激烈，进去才发现能跟自己抢位置的内容一条都没有；也见过反过来的，数字很难看的市场里其实躺着一整片没人写的品类词。

前面几篇把这个数拆过几刀了：按写内容的人数重算一遍 (https://zhangwenbao.com/minor-language-content-volume-editor-count.html)，按有多少是从别的语言搬来的重算一遍 (https://zhangwenbao.com/minor-language-content-translated-share.html)，按讲的是哪儿的事重算一遍 (https://zhangwenbao.com/minor-language-content-local-topic-share.html)。这一篇再挖一格：这些内容是什么形状的。

## 同样十万条，写的可以全是人

形状这个说法有点虚，落到能量的东西上就是体裁。一条内容讲的是一个人、一个地方、一家机构、一件事、一样东西，还是一个概念，这五六档就够把大部分内容分完。

为什么这件事对做内容的人重要？因为你能挂靠的位置只在其中几档里。做独立站的人需要的是品类词、属性词、用法词这一档，而人物传记那一档再多也接不住一个购买意图。

更麻烦的是这两档在内容量这一列里是互相掩护的。人物条目最容易写、最容易批量建、也最容易被翻译过来，于是一门语言的数字可以靠这一档撑得很好看，而你要的那一档一条都没有。

这不是猜测，是这次实测里跨度最大的一条：人物在人写口径下最低的缅甸语是7.5%，最高的约鲁巴语是65.2%。同样是几万到十几万条的量级，一门语言里三分之二在写人，另一门里十四分之一。

## 这跟写的是哪儿的事不是一回事

上一篇量的是地理成分，答的是这些内容讲的是本地还是外国。这一篇量的是体裁成分，答的是这些内容讲的是什么类型的东西。两者可以任意组合。

举个具体的：一门语言可以有大量本地题材，而这些本地题材全是本地政客的生平；也可以有大量外国题材，而这些外国题材全是外国品牌和产品。地理那一列和体裁这一列谁也推不出谁。

把两列并起来读才有用。本地题材占比高、而体裁又落在概念和品类上，那才是真正值得投入的市场；本地题材占比高但全是人物，那说明这门语言的公共内容在写历史不在写生活。

这次的数据正好支持这个组合读法，因为两篇用的是同一批抽样、同一批条目。参照国那一篇 (https://zhangwenbao.com/minor-language-content-foreign-reference-country.html)的分母跟本篇完全一致，两张表可以逐行对着看。

## 本文量什么、不量什么

量的是三样：一门语言的公共内容按体裁怎么分布、剔掉能成批生成的那部分之后分布变成什么样、以及有多大一块连类型都判不出来。

不量内容质量。一条人物传记写得好不好、一条品类条目准不准，这次一个字都不碰。体裁这一层只回答形状，不回答好坏。

也不量商业内容。公共百科不是电商站，它的体裁分布不等于这门语言整个互联网的体裁分布。它能代表的是一件事：这门语言的社群，在没人给钱的时候愿意写什么。

还有一件事这次故意不做：不按体裁给语言排优先级。排序需要把体裁跟需求侧对上，而需求侧那半边在关键词工具没数据那一篇 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)里已经讲过怎么补，两件事分开做更干净。

## 怎么把一门语言的内容按体裁拆开？

## 先要一批能逐条判出类型的内容

体裁这件事最怕的是人工判读，三十门语言几千条内容，靠人读一遍既慢又不可复现。所以必须找一个机器可读、跨语言统一的类型标注。

公共百科背后那套结构化数据正好提供了这个东西。每个条目对应一个数据项，数据项上有一个属性专门回答这是什么，官方文档把它叫做实例属性P31 (https://www.wikidata.org/wiki/Property:P31)，取值是另一个数据项的编号。

好处是这个属性跨语言共享。老挝语的鼠标条目和英语的mouse条目挂在同一个数据项上，类型标注只有一份。所以体裁这一列不受语言影响，量的是同一把尺子。

坏处是它的取值有几千种。这次的样本里出现了1529种不同的P31取值，直接数没有意义，因为乌兹别克语的法国市镇和缅甸语的村在两个不同编号上，讲的却是同一类东西。

## 抽样：在页面编号空间里随机取

要拿到一批有代表性的条目，最省事的做法是在页面编号的整数空间里随机取。取一个数，问一下这个编号对应哪个页面，不存在就跳过。

这个做法比按分类树遍历干净得多。分类树本身是人整理的，遍历它等于把整理者的偏好一起抽进来；编号空间是页面创建时按顺序发的，跟内容是什么无关。

每门语言取240条有效样本，30门共7200条。样本量决定了能说到多细：240条的样本里，一个占比10%的类别的误差大约在正负4个百分点，所以本文所有结论都只压在差距大于10个百分点的对比上。

随机种子按语言名固定，这样任何人拿同一份脚本能抽到同一批条目。可复现这件事在这类研究里比精度更值钱，因为读者对结论的第一反应通常是想自己验一遍。

## 截断：先拿编号当水位，再逐页复核

这批数据要能坐在一个具体的时间点上，所以得把抽样截到2022年12月31日。做法是先从页面创建日志里取那个时点附近的编号，当成一条水位线。

上一批在这里踩过坑：页面编号不是严格递增的，页面移动和批量导入都会打乱顺序，拿日志里最大的那个编号当水位，老挝语有26%的样本落在截断点之后。

修法是取75分位而不是最大值，再从每门语言里抽45条逐页去查首版时间，把这把代理尺子的误差实测出来。这次30门语言的越界数全部是0，说明75分位这条线是稳的。

顺带说一句，超大规模的语言查不出创建日志，接口会返回空且要等三十秒。英语这一门是靠二分搜索编号水位定下来的，26次请求定到7261万左右。

## 判类型：一条属性链往上爬到根

1529种取值要归档，办法是顺着子类属性往上爬。法国市镇的上一级是市镇，市镇的上一级是行政区划实体，爬到这里就归进聚居地与行政区这一档。

爬的深度限制在六跳，每跳最多跟四条分支，依据是官方对实例属性与子类属性的使用指引 (https://www.wikidata.org/wiki/Help:Basic_membership_properties)——两者混用会让链条无限延长。这次一共缓存了6629个编号的父级关系，六跳之后还有极少数爬不到根，单独列出来人工看，不塞进其他这一档蒙混过去。

根类一共设了14档：消歧义与维护页、生物分类单元、天体、时间单位、人物、组织机构、聚居地与行政区、自然地理、建筑与设施、作品、事件、交通与线路、语言与族群、概念与术语。

爬不到根的那批看下来大多是很细的概念，比如正整数、化学元素、政治思想、职位。它们在总量里只占不到2%，不影响任何一条主结论，但把它们单列出来这件事本身是必要的。

## 分子分母来自同一批抽样

上一批在分母上翻过一次大车：分子从一个接口取、分母从另一个接口取，两个口径差了1.27到2.38倍，越南语因此被算成73.85%，真值只有47.43%。

所以这次从头到尾只有一批抽样。体裁那一列和后面那篇的出处那一列，用的是同一批240条里的同一批编号，任何一个占比的分子和分母都能追到同一次查询。

这条听起来像常识，但它在实际操作里特别容易破功，因为不同的接口给数据的粒度不一样，人总会忍不住去拿那个更全的。判据很简单：分子分母追不到同一次查询就别做除法。

本文所有百分比的分母都写在表头上，不写在正文里。读者要复核的时候，先看分母是240还是70，再看数字。

## 第一版数据为什么整表作废？

## 有一格高得不对劲

第一版30门跑完，表格里有一格特别扎眼：没有对应数据项的条目占比，波斯语63.3%、乌兹别克语61.7%、孟加拉语61.2%。小语种缺结构化标注这件事说得通，保哥当时的第一反应是这条正好印证了低资源语言的标注稀薄。

然后看到了英语那一行：59.6%。

英语的公共内容里，六成条目没有对应的结构化数据项，这在任何一个懂这套系统的人看来都不可能。一个能解释所有小语种的漂亮结论，被大语言那一行当场证伪。

这里有一条上一批固化下来的动作救了场：把最集中的那一格里的原始记录打二十条出来看，比多跑三个模型有用。

## 打开二十条看一眼

打出来的英语条目标题是这样几条：Dharma talks、ISight Camera、Arkansas Highway 7T、F5 Networks Inc、Liverpool Exchange station、Christopher Ernst Friedrich Weyse。

读了三条就明白了。Dharma talks对应的正文页叫Dharma talk，少一个复数s；F5 Networks Inc的正文页叫F5, Inc.；Christopher那条是把名字里的Christoph拼成了Christopher。这些全是重定向，不是条目。

重定向没有对应的数据项，因为需要标注的是它指向的那个页面，不是它自己。所以这一格量到的不是标注稀薄，是我把跳转页当成了内容。

逐条验了一遍：七条抽样全部返回重定向标志为真、数据项为空。英语随机编号空间里将近六成是重定向，这个比例本身合理，因为英语的重定向数量确实比条目数还多。

## 少写了一个参数

根因是接口参数写少了一个。取页面属性的时候只请求了属性这一项，而页面信息接口的文档 (https://www.mediawiki.org/wiki/API:Info)写得很清楚，重定向这个标志属于页面信息，不属于页面属性。

于是返回结果里根本没有那个键，我写的判断分支永远走不到，重定向被原样留了下来。这个失败形态特别恶心的地方在于：接口返回200，字段齐全，链路一切正常，只有那一个键悄悄不在。

改法是一行：请求里把页面信息一起要过来。改完之后英语的无数据项从143条掉到0条，30门语言全部归位。

代价是抽样效率掉了一半多，因为要多抽一倍多的编号才能凑够240条有效样本，探测上限从4500提到20000，英语单门耗时从三分半涨到接近四分钟。这个代价必须付，因为省下的那三十秒会污染整张表。

## 上一批为什么没撞上

这件事最值得记的不是坑本身，是上一批为什么没事。

上一批的抽样条件里有一句：必须有对应的数据项才留作样本。当时加这句是为了后面判国别方便，属于顺手加严。而重定向恰好没有数据项，于是被这句话顺手挡掉了。

这次为了统计有多少条目没有数据项，我必须把这道过滤放开——过滤一放开，它原本顺带挡掉的东西就一起涌进来了。加严的时候是一个理由，挡掉的却是两件事，而只有一件事写在注释里。

由此固化一条判据：一个顺手加严的过滤条件被放开时，要重新验一遍它原本顺带挡掉了什么。这类过滤在数据管线里到处都是，而它们挡掉的东西通常没人记录。

## 这条判据可以直接拿去用

把这条翻译成做站的场景就很熟悉了。你的抓取脚本里有一句只要状态码200的过滤，它顺带挡掉了重定向、软404和那批返回200的错误页。有一天你为了统计错误页把这句去掉，报表立刻变成另一个样子。

同一族的还有：只要有标题的、只要长度大于500字节的、只要在站点地图里的。每一句都在挡两件以上的东西，而通常只有一件被记下来。

实操上有个成本很低的做法：任何一条过滤规则，写的时候在旁边记一行它挡掉了什么，能记几件记几件。三个月后改这段代码的人会感谢你。

另一个做法是每次改过滤条件都重跑一次总量对账。第一版跟第二版的样本总数是一样的240，但类型分布整个换了一遍——只看总数对不出来，得看分布。

## 三十门语言的体裁拆下来是什么样？

## 先把能成批生成的那一批分出去

上一批立过一条规矩：量任何这门语言写什么之前，先把名录型条目剔出去。物种、天体、行政区划、车站、年份、消歧义页，这些都能从一张表成批生成，留在分母里会把结论量成谁家的表格被导过一遍。

这次照做。名录型占比越南语83.3%、荷兰语71.7%、瑞典语65.8%、乌兹别克语61.7%、约鲁巴语53.3%，而最低的豪萨语21.7%、高棉语20.0%、僧伽罗语23.3%、泰语24.2%。

跟内容总量的相关系数是正0.509，秩相关正0.546。规模越大的语言，内容量里的水分越大——这条跟上一批算出来的方向一致。

越南语那83.3%值得单拎出来说一句：其中生物分类单元一档就占了整个样本的65.8%。一门语言的公共内容里三分之二是物种词条，这不是内容池，这是一本分类学手册。

## 跟上一批的数据对得上吗

这次是完全独立的第二次抽样：不同的截断点、不同的随机种子、不同的归类实现。两批各自算出来的名录型占比放在一起对了一遍。

10门语言的相关系数是正0.954，秩相关正0.939。越南语75.9对83.3、瑞典语67.7对65.8、荷兰语67.3对71.7、约鲁巴语49.1对53.3，高的那几门几乎逐个对上。

低值那几门系统性偏高9到15个点，原因是两批的归类实现不同：上一批列举名录类型，这一批爬属性链归根，后者把更多东西归进了聚居地和物种。绝对值不能跨批直接比，但排序和方向完全一致。

这一步花了不到二十分钟，换来的是整篇的可信度。一个只跑过一次的指标和一个被独立重跑过的指标，读者对它们的信任是两回事。

## 人写口径下的第一大类

剔掉名录型之后，30门语言里绝大多数的第一大类都是人物。这条倒是符合开工前的预期，也是这次唯一符合预期的体裁类结论。

人物占比的中位数落在34%附近。往上是约鲁巴语65.2%、豪萨语59.6%、波斯语51.5%、德语50.7%、波兰语50.0%、英语46.8%。

往下是缅甸语7.5%、高棉语13.5%、僧伽罗语14.1%、阿姆哈拉语15.6%、泰语22.5%、冰岛语25.6%、马其顿语26.5%。

最高和最低差8.7倍。这个跨度比内容总量本身的跨度还有意思，因为总量差几百倍是显然的，而形状差近九倍是没人事先告诉你的。

## 中间那一段的形状

把六档并排看，中间那一段的语言长得相当像：人物三成上下，概念与术语一成半到两成，作品一成上下，机构和事件各几个点。表里那一列条目总数全部取自各语言公共百科的同一份统计 (https://meta.wikimedia.org/wiki/List_of_Wikipedias)，同一时点取数，避免各查各的。

下面这张表挑了差异最大的几门，全部是人写口径，也就是剔掉名录型之后的占比。

语言 | 条目总数 | 人物 | 概念与术语 | 作品 | 机构 | 体裁均衡度 | 

约鲁巴语 | 38802 | 65.2% | 9.8% | 8.9% | 3.6% | 0.50 | 

豪萨语 | 106850 | 59.6% | 9.0% | 3.2% | 10.1% | 0.57 | 

英语 | 7218435 | 46.8% | 7.8% | 18.8% | 11.7% | 0.69 | 

立陶宛语 | 226416 | 29.2% | 29.2% | 8.3% | 8.3% | 0.77 | 

泰语 | 185817 | 22.5% | 20.3% | 11.0% | 18.1% | 0.83 | 

缅甸语 | 111575 | 7.5% | 4.5% | 4.5% | 0.8% | 0.68 | 

均衡度那一列是把人写口径下八个档位算了一个归一化的分散程度，1代表八档完全平均，0代表全部挤在一档。最均衡的是泰语0.83、冰岛语0.80、高棉语0.80，最不均衡的是约鲁巴语0.50。

## 写人的那一半，为什么小语种反而更少？

## 相关系数的方向跟预期反了

开工前保哥的预期写得很直白：小语种里人物传记占比会明显更高，因为写一个人门槛最低，一个村里的老师、一位地方歌手，只要有人认识就能写出三百字。

实测是反的。人物占比跟条目总量的相关系数是正0.448，秩相关正0.495——大语言的人物占比更高，不是更低。

更打脸的是最低的那一头：缅甸语7.5%、高棉语13.5%、僧伽罗语14.1%、阿姆哈拉语15.6%，四门全是这次样本里内容量最小的那一批。写人门槛最低这个直觉，在这四门语言上一点都没兑现。

相关系数只有0.448，说明这不是一条强规律，只能说方向被弄反了。真正有信息量的是最低那四门的共同点。

## 最低的那五门有什么共同点

把这几门的全样本分布拉出来看，缺的不是写人的意愿，是别的东西把位置占满了。缅甸语的样本里聚居地与行政区占34.6%，而且这一档打开看全是某某村某某镇区这样的条目名。

阿姆哈拉语更极端：时间单位这一档占21.2%，也就是纯年份和日期页。老挝语时间单位占16.7%。这两门语言的公共内容里，五分之一是一个个孤零零的年份页。

高棉语和僧伽罗语的位置被另一样东西占了——后面第七节会专门讲，就是那批连类型都判不出来的条目，两门各占一半左右。

所以最低那几门不是不写人，是分母里塞满了别的。把这几门语言的内容量当成竞争强度看，你以为在跟人比写作，实际在跟一张村庄名录比条数。

## 约鲁巴语和豪萨语是个例外吗

相关系数说大语言人物占比更高，可最高的两门恰恰是约鲁巴语65.2%和豪萨语59.6%，都是不折不扣的小语种，条目总数三万八和十万七。

打开这两门的人物条目看，形态非常一致：短，几乎全是一两句话。约鲁巴语条目的字节中位数是236，一句话都写不满。

这就把机制说清楚了。人物条目之所以能在这两门语言里占到六成，不是因为社群偏爱写人，是因为一句话就能构成一条人物条目，而一句话构不成一条品类条目。某某是尼日利亚的一位政治家，这句话本身就是完整的；汽车是一种交通工具，这句话谁看了都觉得没写完。

这条解释在非洲市场选语种那一篇 (https://zhangwenbao.com/africa-market-language-selection-swahili-hausa-francophone.html)里能对上：两门语言的内容量看着不小，能拿来做商业参照的部分极薄。

## 写人为什么是最先被写的那一类

体裁这件事背后是一条投入曲线。写一个人只需要知道这个人是谁、干过什么；写一个品类需要知道它有几种规格、怎么用、跟别的比差在哪。前者靠记忆，后者靠整理。

公共内容的写作者是志愿者，志愿投入天然偏向靠记忆能完成的那一类。这跟品类词缺口那一篇 (https://zhangwenbao.com/minor-language-content-gap-category-words.html)的结论是同一个机制的两面：那一篇发现最普通的词反而最晚有人写，这一篇发现最容易写的人物条目最先把位置占满。

商业投入的偏向正好相反，商业内容围着可测的搜索量转，人物那一档在电商语境里没有搜索量。两批人各写各的，中间那条品类和概念的带子就一直空着。

这个空带子对做独立站的人是好消息还是坏消息，取决于你打算怎么用它。当参照材料用是坏消息，因为没得参照；当竞争位置看是好消息，因为没人占。

## 这个解释能不能证伪

能。如果人物占比高真的只是因为一句话能成条，那么人物占比高的语言，它的条目字节中位数应该明显更低。

实测对上了：约鲁巴语字节中位数236、阿姆哈拉语332、老挝语891，这三门的条目短得离谱；而英语4827、孟加拉语7878、泰米尔语5019。

但对不上的地方也得说：豪萨语人物占比59.6%，条目却不算特别短。所以一句话能成条只解释了一部分，另一部分应该跟社群里谁在写有关，那一层在编辑人数那一篇 (https://zhangwenbao.com/minor-language-content-volume-editor-count.html)里量过。

一条只能解释一半的机制，比一条能解释一切的机制可信。上一批就吃过这个亏：一个指标把所有数据都解释得服服帖帖，最后发现是它本身有问题。

## 品类和概念那一格，跟内容量有关系吗？

## 相关系数是零

概念与术语这一档，是做独立站的人真正能挂靠的那一格。它包含品类词、材料词、用法词、疾病名、技术名这些东西。

它跟内容总量的相关系数是负0.089，秩相关负0.108。又一个零。这已经是这条轴上第四次量出零了——上一批的本地题材占比跟总量是正0.100，上上批的译入率跟总量是正0.010。

零的意思很实在：你没法从内容量这一列推出概念这一格有多满，只能单独去量。这也正是这条轴一直在挖的东西——内容量能回答的问题比大家以为的少得多。

顺带把另一条也量了：体裁均衡度跟内容量的相关是负0.036，秩相关负0.123。大维基并不更均衡，这条预期也错了。

## 最高的三门不是你以为的那三门

概念与术语占比最高的三门是立陶宛语29.2%、马其顿语25.7%、爱沙尼亚语24.7%。往下是斯瓦希里语21.0%、阿塞拜疆语20.8%、尼泊尔语20.6%、荷兰语20.6%、泰语20.3%。

这个榜单跟任何一份按内容量排的表都不像。立陶宛语条目总数22万，在30门里排中游偏上，可它的概念那一格是全表第一。

成对样本更说明问题：爱沙尼亚语26万条概念占24.7%，立陶宛语22.6万条占29.2%，两门体量几乎一样、结论也一致；而波斯语108万条只有16.4%，德语314万条只有15.1%。体量差十倍，概念那一格反而更薄。

最低的一头是缅甸语4.5%、泰米尔语之外的英语7.8%、豪萨语9.0%、高棉语9.4%、约鲁巴语9.8%。英语出现在这一头，是这次最需要解释的一个数。

## 英语那一格为什么最薄

英语的概念与术语占比7.8%，在30门里排倒数第三。第一反应当然是这不可能——英语的品类内容显然比任何一门小语种都厚。

把英语那一格的原始记录打出来就懂了：Pecoraite是一种矿物、Ronifibrate是一种药物、10-hydroxytaxane O-acetyltransferase是一种酶、Desoxy是一类化合物。全是极专业的长尾学术词，一个日常品类词都没有。

不是英语缺品类词，是分母太大。英语721万条内容里，日常品类词那几千条在随机抽样里根本碰不到，被几十万条专业术语稀释成了背景噪声。

对照老挝语那一格：鼠标、橡皮、维生素B2、埃博拉、哲学。缅甸语那一格：汽车、F-16、奥林匹克国家公园。小语种的概念这一格里全是最基础的词，因为它们也只写到这一层。

## 占比是形状，不是数量

这里必须停一下，因为一个百分比在不同规模上不是同一件事。

算一遍绝对量：英语全样本口径下概念占5.0%，乘以721万条大约36万条；老挝语全样本13.8%，乘以5597条大约772条。占比差2.8倍，绝对量差466倍。

所以这张表能回答的是形状问题：这门语言的社群把力气花在哪一档上。它回答不了数量问题：这门语言有多少条概念内容可供参照。

两个口径必须一起报，少一个这张表就会被拿去支持相反的决定。只报占比会得出老挝语的概念内容比英语还厚，只报绝对量会得出小语种一无所有——两个结论都是错的。

## 两个口径要一起报

实际用法是这样：先看绝对量决定这门语言值不值得当参照源，再看占比决定你的内容该往哪一档挤。

绝对量大的语言，你能从它那里抄到品类结构、属性名、常见问法；绝对量小但占比高的语言，说明这门语言的社群确实在往概念这一档写，只是量还没上来，你进去是跟一群认真的人做邻居而不是跟一台机器抢位置。

绝对量小且占比也低的那几门，比如缅甸语4.5%乘以11万条约5000条，说明这门语言的公共内容基本不覆盖概念层。这时候你写的每一条品类内容都没有本地参照，得从头做原始调研。

这一层跟按成本排语言优先级那一篇 (https://zhangwenbao.com/minor-language-seo-priority-language-cost-model.html)能接上：那一篇算的是每门语言要花多少钱，这一篇告诉你这笔钱里有多少要花在没有参照的从零调研上。

## 机器连这是个什么都不知道，占多少？

## 这一格是怎么冒出来的

修完重定向那个坑之后，剩下的没有数据项的条目就是真的没有了。同时还有另一批：有数据项，但数据项上没填类型属性。两者合起来是同一件事——机器不知道这条内容属于哪一类。

这一格本来只是个残差项，是那种放在表格最右边、写完就没人再看的列。第一次注意到它，是因为把它跟内容总量做了个相关，出来的数把整张表里别的相关系数都比下去了。

相关系数负0.629，秩相关负0.757。这是本批30门语言、十几个指标里相关性最强的一条，比人物占比的0.448、名录型占比的0.509都强得多。

换句话说：一门语言的内容里有多大一块机器认不出类型，几乎可以从它的内容量直接推出来。而这条推得动的规律，恰好在体裁这张表上是残差项。

## 三十门语言排下来

最高的是高棉语50.8%、缅甸语44.6%、阿姆哈拉语42.9%、僧伽罗语41.2%。这四门里，机器判不出类型的条目占了整个抽样的四成到五成。

往下断崖式下跌：老挝语17.9%、斯瓦希里语13.8%、冰岛语13.3%、尼泊尔语12.5%、泰米尔语12.5%、乌兹别克语12.1%。

最低的一头是越南语1.2%、瑞典语1.7%、荷兰语2.5%、波兰语3.3%、约鲁巴语3.8%、英语4.2%、德语4.2%。

高棉语和越南语差42倍。两门都是东南亚语言，条目总数差107倍，而这一格差了42倍——这条比内容量本身更能说明两个内容池的差距。

## 打开看是些什么东西

缅甸语这一格里没有数据项的那67条，全部是某某村加某某镇区的格式。它们是真条目不是重定向，有正文有分类，只是从来没有人在结构化那一侧给它们建过对应的数据项。

另一半是有数据项但没填类型的。这一类更微妙：有人建了数据项，把这个条目跟别的语言的对应条目连了起来，但没有人回答过这是什么这个问题。

高棉语50.8%里的大部分属于后一种。这意味着有人做了跨语言对齐这件相对费事的工作，却没做填一个类型这件几乎不费事的工作。

保哥觉得这个顺序本身就是个信号。跨语言对齐通常是工具自动做的，填类型需要一个人判断这条内容讲的是什么。机器能做的那一半做完了，需要人判断的那一半没做。

## 这是本批相关性最强的一条

为什么这一格跟内容量的关系比什么都强？因为它量的不是写作，是整理。

写一条内容需要一个懂这门语言的人；给一条内容标类型需要一个懂这套结构化系统的人。后者的人数比前者少得多，而且不随内容量线性增长。内容量小的语言，社群里往往一个这样的人都没有。

这条也解释了为什么它比人物占比更规律。人物占比受社群偏好影响，而社群偏好是文化的，各门语言各不相同；标类型这件事没有文化差异，纯粹看有没有人干。

值得一提的是相关的方向：内容越多这一格越小。所以它不是内容量的副产品，更像是同一件事的另一个侧面——一个内容池的成熟度，写了多少是一个读数，整理了多少是另一个读数，后者更难伪造。

## 这件事跟结构化数据是同一个动作

做SEO的人对这件事其实很熟，只是换了个场景。你在自己的页面上标一段结构化数据，告诉搜索引擎这是一篇文章、这是一个产品、这是一个组织，做的正是同一个动作：告诉机器这一页是什么类型 (https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data)。

差别只在于，你的站上这件事是你自己做的，而一门语言的公共内容池里这件事得有人替所有条目做。没人做的结果是，这门语言的内容对机器来说是一片没有标签的文本。

这在生成式搜索的语境里后果很直接。模型要把一条内容放进答案里，先得判断它讲的是不是问题问的那类东西；类型标注缺失的内容，只能靠正文本身去猜，猜错的概率明显更高。

本站的小语种结构化数据那一篇 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)讲的是你自己页面上该怎么标，这一节讲的是你所在的那个语言环境整体标到什么程度。前者你能控制，后者决定你标了之后有没有对照物。

## 这张表怎么改你的选题清单？

## 三档判读线

把三个数合起来读，能给出一条能直接用的分档：人物占比、概念占比、机器不认率。

第一档，人物占比低于35%且概念占比高于20%。这门语言的公共内容确实在往概念层写，你能拿到品类结构和常见问法的参照。立陶宛语、爱沙尼亚语、泰语、马其顿语落在这一档。

第二档，人物占比高于50%。这门语言的内容量主要由人物条目撑起来，做品类内容基本没有本地参照，但也几乎没有竞争。约鲁巴语、豪萨语、波斯语、德语、波兰语落在这一档。

第三档，机器不认率高于30%。这一档最需要单独对待，因为它的问题不在内容多少，在这些内容机器读不明白。高棉语、缅甸语、阿姆哈拉语、僧伽罗语落在这一档。

## 人物占比高的市场先做什么

第二档市场的第一个动作不是写内容，是先确认一遍你的品类词在这门语言里到底怎么说。因为没有本地概念内容，你连一个可以对照的说法都拿不到。

这时候母语审校那一篇 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)里的验收动作要提前用，不能等内容写完再审。词表定错了，后面所有内容都跟着错。

第二个动作是把品类页做厚。这一档市场里没人写过品类内容，一篇写全了的品类页在很长时间里没有对手。这种位置不常见，遇到了别只发五百字。

第三个动作是别指望内链密度。这门语言里没有可以链过去的概念页，你的站内链结构得自己从头搭一套。

## 概念那一格薄的市场怎么切

概念占比低于10%的那几门，实操上要把预算结构改一改：调研的比重要往上提，写作的比重相对下调。

原因是没有参照材料的时候，写作本身不慢，慢的是确认。一个属性叫什么、一种规格本地怎么表述、一个用法本地人认不认，这些在有参照的语言里查十分钟，在没参照的语言里得问人。

保哥的经验值是这样：有参照的市场，调研跟写作的时间大概三七开；没参照的市场，六四开都算顺利。把这个比例提前写进排期，比事后解释为什么延期有用得多。

另一件事是把调研成果沉淀成内部词表。这一档市场每查清一个词都是一次性成本，查完不记下来，下一篇还得再查一遍。

## 机器不认率高的市场要加一步

第三档市场要多做一件事：自己页面上的结构化标注要比别的市场做得更全、更早。

逻辑是这样：整个语言环境里类型标注是缺的，那么你的页面一旦标全，在机器眼里就是这门语言里少数几个能直接判断类型的对象。在一个没人标的环境里标全，收益比在一个人人都标的环境里标全高。

具体做什么并不复杂：产品页标产品、文章页标文章、公司信息标组织、面包屑标层级。这几样在任何一个电商系统里都是现成的，问题只在于小语种站点上线时经常被跳过。

顺带说一句，这一档市场的内容也别指望能靠机器读懂。你要做本地竞品调研的时候，任何依赖类型筛选的工具在这几门语言上都会漏掉一半。

## 排期上怎么占位

三档市场的排期节奏不一样。第一档能按常规节奏走，因为参照材料齐；第二档要在前面加两周的词表确认；第三档除了词表确认还要加一轮结构化标注的开发排期。

如果同时做多个市场，最忌讳的是按同一个模板同时启动。三档市场用同一个甘特图，最后延期的一定是第三档，而延期的原因会被写成本地团队响应慢。

还有个排序上的建议：先做第一档拿到经验，再做第二档，最后做第三档。第一档市场做出来的品类页结构，在第二档市场能直接复用；第二档的词表确认流程，在第三档能直接复用。

反过来先啃最难的那一档，通常的结果是把整个多语言项目拖成一个所有人都不愿意接手的摊子。

## 半天能跑完的最小版本长什么样？

## 三十条就够

不需要240条。要判读一门语言落在哪一档，随机抽30条逐个打开看一眼就够了，因为三档之间的差距大到20个百分点以上，30条的误差撑不破这个间距。

操作也简单：打开那门语言的公共百科，连点30次随机页面，每次记一个字母——人物记P，地方记L，机构记O，作品记W，事件记E，概念记C，看不懂或者一句话说不清的记X。

三十条记完数一下。P超过15条落第二档，C超过6条落第一档，X超过9条落第三档。整个过程二十分钟，比任何一份市场报告都快。

记X那一档特别关键，别嫌它不精确。你作为一个不懂这门语言的人判不出类型，跟机器判不出类型，成因高度重合：都是因为这条内容没提供足够的类型线索。

## 不用爬属性链的简化做法

如果想稍微正式一点，又不想写爬属性链的代码，有个折中办法：只判五档，而且只看条目开头那句话。

公共百科的条目第一句几乎都是某某是某某这种句式，把是后面那个词翻译一下就知道类型。这一步用任何一个翻译工具都能做，不需要懂那门语言。

这个做法的误差在哪：一句话里同时出现两个类型词的时候会判错，比如某某是一位画家创办的美术馆。实测下来这类情况在10%左右，不影响分档。

还有一种更省事的：直接用数据项那一侧的类型属性，不爬父级，只统计取值本身。这样会得到一堆很细的类别，但只要你关心的是有没有类型这件事，细不细都不影响。

## 加一列会更准

手上有余力的话，加一列条目字节数。这一列几乎不花成本，却能把两个不同的一档分开。

因为人物占比高有两种成因：一种是社群真的在认真写人物，条目又长又全；另一种是一句话成条，人物只是最容易凑数的那一档。字节中位数一列出来，两者立刻分开。

参考值：这次30门语言的条目字节中位数，最低是约鲁巴语236、阿姆哈拉语332、老挝语891，最高是孟加拉语7878、泰米尔语5019、英语4827。低于1000基本就是一句话条目为主。

再加一列的话就是下一篇要讲的出处密度，那一列回答的是这些内容底下垫没垫东西，跟本篇的形状那一列正好凑成一对。

## 多久重算一次

体裁分布变得很慢，一年重算一次足够。它反映的是社群的写作偏好，而偏好通常以年为单位变化。

机器不认率那一列变得快一些，因为它受工具影响：某个批量标注工具在某门语言上跑一轮，这个数能一下降十几个点。做第三档市场决策之前建议现算一次，别用一年前的数。

还有一种情况必须重算：这门语言的公共内容池里出现了一次批量导入。这件事在名录型占比那一列上会突然跳一个台阶，而它会把体裁分布整个搅一遍。

识别方法在编辑人数那一篇 (https://zhangwenbao.com/minor-language-content-volume-editor-count.html)里写过：单月新建量跳一个数量级而人数没跟着动，就是被灌过了。

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

## 内容质量不归这一层

体裁只回答形状，不回答好坏。一门语言人物占比高，不代表它的人物条目写得差；概念占比高，也不代表它的概念条目就靠谱。

质量那一层要另外量，而且量法完全不同——本站在机器翻译直接发布那一篇 (https://zhangwenbao.com/machine-translation-direct-publish-search-risk-quality-line.html)里讨论过质量线该画在哪，那套判据跟体裁没有交集。

把两者混着用会得出很奇怪的结论，比如认为人物占比高的语言内容质量差。实际上这次样本里写得最认真的几条恰恰是人物传记。

唯一能连起来的一点是：体裁分布极度不均衡的语言，通常整体投入也偏低。但这是相关不是因果，别拿去当质量代理。

## 写的是哪儿的事那半边已经写过

地理成分那一列在上一篇量完了，本地题材占比从乌兹别克语4.3%到泰米尔语68.6%，中位数27%。那一列跟本篇这一列是正交的两个维度。

要一起用的话，最有价值的组合是本地题材占比高加概念占比高：这门语言的社群在用自己的语言写自己身边的东西，而且写的是概念不是人物。这种组合在这次数据里不多。

另一个值得注意的组合是本地题材高加人物高：说明这门语言在写本地的历史人物，属于文化保存型的内容池。做生意的人从这种内容池里拿不到什么，做品牌故事的人反而能。

两列一起看的具体方法在上一篇的落地节里写过，这里不重复。

## 谁写的、从哪儿来的那半边也写过

内容是谁写的在编辑人数那一篇，内容是不是搬来的在译入率那一篇 (https://zhangwenbao.com/minor-language-content-translated-share.html)。这两列跟体裁的关系这次也顺手量了一下。

译入率跟人物占比、跟概念占比都看不出稳定关系。这条其实符合直觉：翻译工具不挑体裁，它把源语言里有什么就搬什么过来。

值得记一句的是翻译痕迹那一篇 (https://zhangwenbao.com/minor-language-translation-trace-shell-not-text.html)的结论在这里依然成立：正文层量不出来的东西，壳上能看出来。类型标注就属于壳的那一层。

四列合起来是一套完整的内容池画像：有多少、谁写的、写的是哪儿的、写的是什么形状的。再加下一篇的底下垫没垫东西，就齐了。

## 百科数据代替不了商业调研

最后这条得说三遍。公共百科反映的是无偿投入的偏好，你的目标客户在电商站上搜什么、在本地论坛上问什么，是另一套完全不同的数据。

本篇这套数能干的事只有一件：在你还没有任何本地资源的时候，快速判断这门语言的公共内容能不能当参照物用。能，就省一大笔调研费；不能，就把这笔钱提前排进预算。

不能干的事包括：估搜索量、判竞争强度、选品、定价。这几件每一件都有专门的做法，硬拿体裁分布去套只会得到听起来很顺但站不住的结论。

上一批的教训还热着：第一版算出来的参照国排名，每一条都能编出一套很顺的解释，打开条目一看全是机器导进来的名录。能编出解释这件事，从来不是结论成立的证据。

## 常见问题解答

## 公共百科上的体裁分布，能代表这门语言的整个互联网吗？

不能，而且差得很远。公共百科反映的是无偿投入的偏好，商业站的内容分布跟它几乎没有可比性。这套数据唯一能代表的是：这门语言的社群在没人给钱的时候愿意写什么。把它当参照物可得性的探针用是合适的，当市场画像用就错了。

## 为什么不直接数各个分类下有多少条目，那样不是更简单？

因为分类树本身是人整理的，遍历它等于把整理者的偏好一起抽进来。更实际的问题是各门语言的分类树深浅完全不同，小语种的分类往往只有一两层，大量条目根本没归进任何分类。在页面编号空间里随机抽，抽到的是页面本身，跟有没有人整理过无关。

## 机器判不出类型的那一格里，会不会大部分其实是很小众的东西？

不是。打开缅甸语那67条看，全是某某村加某某镇区这种格式，是标准的行政地名，一点都不小众。高棉语那一半更明显，大多是有数据项、跨语言也连上了，就是没人填过类型。这一格量的不是内容有多冷门，是有没有人做过整理这个动作。

## 人物占比高到底是好事还是坏事？

要看你拿它干什么。当参照材料用是坏事，因为你要的品类结构和属性名在人物条目里一个都没有；当竞争位置看是好事，因为品类这一格空着没人占。实操上建议这样处理：人物占比高的市场，把调研预算提上去、把内容深度做厚，两件事一起做才吃得到那个空位。

## 第一版把重定向当成条目那个错，会不会还有别的地方也踩了？

同族的风险确实存在，所以这次每个占比都把分母写进了表头，方便逐条复核。更通用的做法是：任何一条过滤规则，在旁边记一行它挡掉了什么。第一版那个错的根源不是写错了参数，是加过滤的时候只记住了一个理由，而那句话实际挡掉了两件事。

## 三十条的最小版本，误差能有多大？

30条样本下，一个真实占比40%的类别，测出来大概率落在30%到50%之间。这个精度不足以支撑两门语言之间的细微对比，但足以分档，因为三档之间的间距在20个百分点以上。要做语言之间的排序就得把样本量提到200条以上。

## 这套方法能不能用在自己的品类上，而不是整个语言？

能，而且更好用。把随机抽样换成按品类关键词检索，量同一批指标：这门语言里跟你品类相关的内容，有多少是人物、有多少是概念、有多少连类型都没标。样本会小很多，但因为限定了品类，结论直接可用。唯一要注意的是检索出来的结果带排序偏好，不再是随机样本，所以只能横向比语言、不能纵向比品类。

## 权威参考资料



## 日本用户挑毛巾搜的是手感，那个词在你的属性表里连一格都放不下

- URL：https://zhangwenbao.com/minor-language-onomatopoeia-texture-attribute-keyword.html
- 分类：小语种SEO
- 发布：2022-11-15  |  更新：2026-07-29
- 摘要：用声音直接说出手感的那类词是个还在产出新词的开放集合，词表法从原理上就穷举不完。讲清它为什么在英语站上不成立、该从评论和站内日志怎么采、放页面哪几处，以及审校为什么总把它删掉。
- 关键词：多语言SEO,日本市场,内容本地化,小语种SEO

> **TLDR**：摘要：日语用户挑毛巾、挑面包、挑面霜，搜索框里打的往往不是材质和克重，而是ふわふわ、もちもち这类由声音直接说出手感的词。这类词在日语和韩语里数量惊人、还能被随时新造出来，可它们在你的商品属性表里连一格都没有，在关键词工具里查不到量，在翻译环节会被换成一个平淡的形容词，最后还会被母语审校以不够正式为由删掉。本文讲清楚这类词是什么、为什么它是一个开放集合因而无法靠词表穷举、该从评论和站内搜索里怎么采、采回来放页面哪几个位置，以及哪些品类做了才有回报。

> 摘要：日语用户挑毛巾、挑面包、挑面霜，搜索框里打的往往不是材质和克重，而是ふわふわ、もちもち这类由声音直接说出手感的词。这类词在日语和韩语里数量惊人、还能被随时新造出来，可它们在你的商品属性表里连一格都没有，在关键词工具里查不到量，在翻译环节会被换成一个平淡的形容词，最后还会被母语审校以不够正式为由删掉。本文讲清楚这类词是什么、为什么它是一个开放集合因而无法靠词表穷举、该从评论和站内搜索里怎么采、采回来放页面哪几个位置，以及哪些品类做了才有回报。

## 用户打进搜索框的那个词，你所有的表里都没有它

## 先看一条真实的查询串

做日本市场的家纺客户给我看过一批站内搜索词。排在前面的不是浴巾、不是纯棉、也不是尺寸，是ふわふわ タオル。

翻成中文大概是蓬松松软的毛巾。这个ふわふわ不是形容词，它是一个用声音直接把手感说出来的词。

他们站上有毛巾的克重、支数、材质、产地、尺寸、颜色，十几个属性字段填得整整齐齐。唯独没有一个字段能装下这个词。

更尴尬的是，商品详情页的正文里其实写了柔らかい（柔软），母语译者翻得没有任何问题。可用户就是不搜那个词。

我当时的第一反应跟大多数人一样：这是不是个别用户的口语化表达？后来把三个月的日志拉出来数了一遍，这类词占了站内搜索总量的两成多，而且分布在毛巾、床品、地垫三个子类里，每一类的头部词都不一样。

两成多是什么概念。它比颜色词多，比尺寸词多，仅次于品类词本身。而这批词在这家客户的关键词表里，一个都找不到——不是排得靠后，是根本没被收录进去过，因为建表的时候没人想到要去那儿捞。

顺便说一句，这批词在日志里几乎不重样。同一个手感，三个用户能打出三种写法，有人用平假名有人用片假名，还有人在中间加了个长音符。数出来的两成多，其实是几百条各不相同的字符串合起来的。

## 属性表里有克重有材质，就是没有手感

商品属性字段是怎么来的？多半是从供应商的规格表里搬过来的，或者按平台的类目模板填的。

这两个来源有一个共同点：它们描述的都是客观参数。克重是秤称出来的，支数是纺出来的，材质是化验出来的。

手感不是。手感是手摸上去那一下，是一个主观感受，没有任何仪器能给它出一份报告。

于是它落在了所有结构化字段的外面。你的筛选器可以按克重筛，按材质筛，就是没法按ふわふわ筛。

可对买毛巾的人来说，手感恰恰是第一决策变量。克重多少他没概念，材质是不是长绒棉他也分不清，但他知道自己想要一条摸上去蓬松的毛巾。他会拿这个词去搜，因为这是他脑子里对这件商品的真实表述方式。

这就形成了一个很别扭的错位：你收集了一堆可以量化却不影响决策的参数，而真正影响决策的那个维度，因为量化不了，被整条数据链路排除在外。用户不得不用一个你系统里不存在的词，来找一件你其实有货的商品。

这条错位还有一个更麻烦的推论：因为字段里没有它，所以数据仓库里也没有它，报表里自然也不会出现它。一个维度只要没被记录，它在公司内部就等于不存在，谁也不会在季度复盘里提起一个从来没有出现在任何一张表上的东西。

## 这类词到底算不算关键词

我知道有人会说，这是长尾里的长尾，值不值得花这个功夫。

判断标准很简单，看它出现在查询串的哪个位置。修饰词跟在品类词后面，那是长尾；修饰词打在品类词前面，还带着明确的选购意图，那是筛选。

ふわふわ タオル是后者。用户已经决定买毛巾了，他在筛。这种词的转化率通常比泛品类词高出一截。

而且它有一个很难得的性质：竞争极稀。你的竞品多半也没做，因为大家的属性表长得都一样。

要判断值不值得，我一般让客户拉两个数：这类词在站内搜索里的占比，以及带这类词的会话跟不带的会话在加购率上的差距。第一个数决定盘子有多大，第二个数决定它是不是真的在筛而不是在闲逛。两个数都过得去，这件事就该排进这个季度。

还有一个信号值得看：这类词的查询往往不带价格词也不带品牌词。用户不是在比价，也不是在找某个牌子，他在找一种感觉。这种查询的商业价值通常被低估，因为它在归因模型里长得不像购买意图。

## 这类词在日语里到底是什么东西？

## 擬音語和擬態語不是一回事

日本国立国语研究所有一个专门讲这个的科普站，把它们分成了两类。

一类是擬音語，模拟真实存在的声音，比如水滴的声音、敲门的声音。这类词英语里也有，dog barks的woof就是。

另一类是擬態語，模拟的不是声音，是状态和感觉。ふわふわ没有任何声音，它描述的是一种蓬松的样子。

做电商真正要盯的是第二类。因为商品的卖点里，声音占的比重很小，状态和触感占的比重极大。

这个区分不是学院派的咬文嚼字，它直接决定你去哪儿采词。擬音語跟着场景走，你在商品视频的文案里能碰到；擬態語跟着感官走，它藏在用户写的评价里，藏在他跟朋友描述这件东西的那句话里，而这两处恰恰都不在你的商品数据源里。

顺带一提，这两类词在写法上也有分工的倾向：模拟声音的更常用片假名，模拟状态的更常用平假名。这个倾向不是硬规则，但它能帮你在采词时快速给候选分类。

## 它们有多少个，词典收了多少

常见的说法是日语里这类词有两千上下，日常高频的四百到七百个。

这个数字听着不多，可它有个前提：只统计已经被收录的。

词典能收的是已经稳定下来的那批。而这类词随时能被造出来新的，造出来母语者立刻就懂，不需要查任何东西。

所以两千这个数字的真实含义是：截止到某本词典编完的那一天，被认为值得记录的有两千个。

换个角度看这件事就清楚了：如果你手里有一份两千条的表，你会以为自己覆盖了全部。可实际情况是你覆盖了历史沉淀下来的那一部分，而用户此刻正在用的那批词里，有一部分从来没进过任何一本词典，也永远不会进。

词典还有一层滞后：等一个词稳定到被收录，它往往已经过了传播最快的那几年。你从词典里拿到的是昨天的热词，而评论区里正在冒出来的才是今天的。

## 为什么日语韩语特别多，德语英语特别少

这不是巧合。一门语言用什么手段描述感受，跟它的构词习惯是绑在一起的。

日语和韩语给这类词留了固定的形态模板：两拍重复、加り结尾、加っ促音。套进模板就是一个合法的新词。

德语走的是另一条路，它靠加后缀造形容词，flauschig（毛茸茸的）、kuschelig（暖和好抱的）都是形容词，走的是形容词的语法位置。

英语更极端，它基本上把这块工作全交给了形容词，fluffy、soft、crispy，一个都不是能产的拟声形态。

所以同一件商品的同一个卖点，在日语里是一个独立的、有自己形态特征的词类，在德语里是一个普通形容词，在英语里是一个更普通的形容词。这就是为什么这个问题在英语SEO的教材里连一个段落都找不到——那门语言里根本没有这个东西可讲。

这条对应关系有个实用价值：它能提前告诉你目标语言值不值得做这件事。查一下那门语言有没有专门的拟声词构词模板，有就说明这是一个成规模的词类，没有就说明感官表达被分摊给了形容词，那你按普通修饰词处理即可。

顺着这条线还能推一步：靠形容词表达感官的语言，形容词本身会跟着名词做性数变化，于是同一个手感词在页面上会长出好几个形态。这一层在意大利语SEO选词的性数一致 (https://zhangwenbao.com/italian-seo-gender-agreement-elision-keyword-research.html)那篇里讲过，处理逻辑跟这里正好互补。

## 为什么英语站上从来没人讨论过这件事？

## 英语的拟声词为什么不能产

英语当然有拟声词，buzz、hiss、crash都是。

但它们是一个封闭的、数量有限的小集合，而且几乎全是动词或名词，很少作修饰语用。

你没法在英语里临时造一个拟声词来形容毛巾，造了对方也听不懂，只会觉得你在发明外星语。

日语可以。你造一个新的四拍重复词丢给日本人，他大概率能猜出你想说的质感是什么方向。

语言学里有个专门的术语叫ideophone，指的就是这类靠声音直接表达感官印象的词，跨语言研究显示它在非洲、亚洲、南美的很多语言里都是一个成规模的开放词类，而在英语这样的欧洲语言里则退化得只剩零星几个残余。英语是个例外，不是常态——只不过我们的整套SEO方法论都是拿这个例外写出来的。

国立国语研究所那个面向公众的擬音語擬態語专题站 (https://www2.ninjal.ac.jp/Onomatope/)里有个很有意思的角度：它把这类词当作日语的一项日常表达能力来介绍，而不是当作一个需要专门学习的词汇表。这个态度本身就说明了它在这门语言里的地位。

## 翻译的时候它被译成了什么

假设你有一份英文商品文案，写着super soft towel。

译者把它翻成とても柔らかいタオル，语法零错，语义零偏差，任何一道翻译质检都会放行。

可用户搜的是ふわふわ。你的页面上一次都没出现过这个词。

反过来也一样。如果日语原文里有ふわふわ，往英文译的时候只能译成fluffy或者soft，那个词的形态特征、那种绵软的音感，全都丢在半路上了。

这件事跟我在直译出来的小语种关键词为什么没人搜 (https://zhangwenbao.com/keyword-literal-translation-legacy-cost-non-english.html)里讲的直译遗产不完全是一回事。直译的问题是选错了词，这里的问题更深一层：源语言里压根没有那个词，所以译者不可能译出它，只能译出一个功能相近但用户不会拿来搜的替代品。

有一个反向的检查办法：把你日语页面上的商品描述丢给机器翻译译回英文，再跟英文原稿比对。如果两份文本高度重合，说明日语版几乎是原稿的镜像，一个本地原生的词都没长出来。

## 零翻译损失不等于零检索损失

这是我想让每个做多语言站的人记住的一句话。

翻译质量的评判标准是忠实与通顺，检索的评判标准是命中用户实际打出来的字符串。

这两套标准大部分时候是一致的，正因为大部分时候一致，人们才会默认它们永远一致。

而拟声拟态词恰好是它们分岔的地方之一。译文完美，检索为零，两个结论同时成立，谁也没错。

我在日语SEO怎么选词 (https://zhangwenbao.com/japanese-seo-hiragana-katakana-kanji-keyword-notation.html)那篇里讲过三套文字的写法分歧，那件事还能靠列一张写法对照表兜住。这件事兜不住，因为你不知道要对照的那个词长什么样，它甚至可能还没被造出来。

这个分岔点还有一个特征：它只在译入语言比源语言表达手段更丰富的方向上出现。从表达手段少的语言译到多的语言，会丢东西；反过来则不会，因为多出来的那部分本来就无处安放。

## 这类词最要命的那个性质是什么？

## 新的可以随时被造出来，而且立刻被听懂

这是它跟其他所有词类最大的区别。

普通名词要进入一门语言，得经过使用、传播、被媒体采用、最后被词典收录这一整套流程，快则几年。

拟态词不用。一个日本主妇在评价里写下一串以前没人写过的四拍词，读到的人当场就懂，因为形态模板本身携带了意思的方向。

你可以把它理解成一套构词的语法：重复表示持续，浊音表示重和粗糙，清音表示轻和细腻。规则在，材料随便配。

这带来一个很反直觉的结论：这个词类没有完整名单，因为它不是一个名单，是一台还在运转的机器。你今天导出的任何一份表，都只是这台机器过去某个时段的产出记录，而不是它的产品目录。

这套模板还有方向性。浊音一般对应重、粗、大，清音对应轻、细、小，同一个词换一个音就能把质感调一档。所以用户在搜索框里换掉一个音，找的其实是另一件商品。

## 所以词表这条路从原理上就走不通

我们做关键词的人有个根深蒂固的习惯：遇到问题先建表。

屈折语的词形多，那就把所有词形列出来；写法有分歧，那就把所有写法列出来。列全了，问题就解决了。

这个习惯之所以一直有效，是因为我们碰到的都是封闭集合。名词的格是有限的，一门语言的字母是有限的，颜色词也是有限的。

拟态词不是。你没法列全一个开放集合，这不是勤奋能解决的问题，是集合的性质决定的。

承认这一点其实是件好事，它把目标从穷举改成了覆盖率。你不再追求一份完整的表，而是追求一条能持续把新词捞上来的管道，并且接受任何时刻手上这份表都是不完整的。这是两种完全不同的工作方式，前一种有交付日期，后一种只有复核周期。

跨语言研究里把这类词叫作ideophone，世界语言结构地图集关于重叠构词的章节 (https://wals.info/chapter/27)能看到重叠作为能产手段在亚洲语言里有多普遍。这份分布图的用处是帮你预判：新开一个市场之前，先看看那门语言在这张图上落在哪一格。

## 这跟颜色范畴那件事差在哪儿

我在你的色卡上蓝和绿是两格 (https://zhangwenbao.com/minor-language-color-category-attribute-value.html)那篇里讲过属性值的范畴错位：不同语言把颜色光谱切成的格数不一样，所以一对一的翻译表结构上就是错的，得改成多对多映射。

那件事里两边都是封闭集合，只是切法不同。你数清楚目标语言有几个基本色词，就能把映射表建出来，建完它是稳定的。

这件事不一样。一边是你的属性字段，封闭且有限；另一边根本不是集合，是一台可以持续产出的机器。

所以两件事的解法完全不同。颜色那件事的交付物是一张映射表，这件事的交付物是一条采集管道加一个复核节奏。

把这两件事混为一谈，最典型的症状是：团队花两周做了一份两百条的拟态词映射表，交付、验收、归档，然后半年不动它。半年后你去看，表里的词还在用，但用户新用起来的那一批一个都没进去，而这一批往往正好是新品带起来的。

还有一个判别办法：问自己这份交付物有没有一个可以宣布完成的时刻。有，那大概率是封闭集合；没有，只有下一次复核，那就是开放集合。两种东西如果排进同一个项目计划里，后者一定会被前者的进度条压死。

## 接受不完整之后，工作方式变成什么样

目标从收全变成不断进货。

你需要三样东西：一个固定的采集来源清单，一个把新词并进现有词表的判重规则，一个决定谁值得落地的门槛。

采集来源下一节会展开。判重规则要留意形态变体，长音符、促音、片假名平假名互换都会造出同一个词的不同写法。

门槛我一般定得比较宽：只要在两个独立来源里都出现过，就先收进表里观察，不急着改页面。

这套做法的好处是，它不依赖任何一次性的大工程，也不需要一个懂语言学的专职人员。它只需要每个月有人花两小时把评论区新冒出来的词捞一遍，而这两小时的产出，往往比一次全站文案重写更能改变实际的进站词结构。

这套做法对团队结构的要求也低一些。它不需要一个懂语言学的专家常驻，只需要一个愿意每月花两小时看评论的人，加上一个能在半小时内回答准不准的母语顾问。

## 哪些品类的用户真的会用它搜？

## 食品：口感几乎全靠它表达

这是密度最高的品类，没有之一。

面包的もちもち（有弹性有嚼劲）、饼干的サクサク（酥脆）、果冻的ぷるぷる（弹颤），这些词在日本的食品包装上是印在正面的主视觉文案。

换句话说，整个行业已经默认口感描述用这套词，只有做跨境电商的外来者还在用柔软、酥脆这类翻译腔的形容词。

更要命的是，食品的复购决策高度依赖口感，用户搜的时候会直接把口感词打进去，因为那是他上次吃到的那个感觉。

如果你只做一个品类的这件事，做食品。它的词密度最高、用户表述最统一、竞品最少想到，而且这些词天然带着强烈的购买意图——搜口感词的人不是在做调研，是在找上次那个味道。

还有一个特别的地方：食品的这类词经常直接印在包装正面，也就是说线下货架上的竞争早就在用这套词了。你只要把线下包装上的词抄进线上页面，就已经追平了大半。

## 纺织与家居：手感是第一决策变量

毛巾、床品、地毯、抱枕、睡衣、袜子，这几类的共同点是买之前摸不到。

摸不到，就只能靠文字想象。而能把触感说清楚的词，恰恰就是这一类。

ふわふわ、さらさら（干爽顺滑）、もこもこ（厚绒蓬松），每一个都对应一种明确的触感预期。

这里有个容易被忽略的点：同一件商品在不同季节要押不同的词。夏天的床品押さらさら，冬天押もこもこ，是同一批货，卖点词要换。

所以这类词的排期最好跟着季节走，而不是跟着上新走。我见过客户把一整年的商品文案一次性写完发上去，结果夏天的页面上挂着冬天的手感词，转化差得莫名其妙，查了三个月才查到这一层。

这一类还有个隐藏用法：把手感词写进商品图的说明文字里。用户在图片搜索里找家纺的比例不低，而图片那一侧的文字竞争远比正文稀薄。

## 化妆护肤：肤感词自成一套体系

しっとり（润泽不干）、さっぱり（清爽不腻）、べたつかない（不黏腻），这三个词几乎构成了日本护肤品的产品分类轴。

注意最后那个是否定形式，它对应的是一整类用户的核心顾虑。

这一类跟食品和纺织有个区别：护肤品的肤感词已经高度标准化，几乎每个品牌都在用同一批词，所以它的竞争比前两类激烈。

但也正因为标准化，它更容易做。你不需要去发现新词，只需要确认自己有没有把这批标准词写进页面。

做这一类之前建议先做一次竞品覆盖率盘点：把日本本土前十个品牌的商品页拉下来，数一数每个肤感词出现了几次，然后跟自己的页面比。差距通常会大得让人不好意思，因为对方是把这批词当作分类轴在用，而你是把它当形容词在用。

另外要注意否定形式。不黏腻、不紧绷这类说法在护肤品里的搜索量常常高于对应的肯定说法，因为用户是带着顾虑来的，他找的是排除项而不是卖点。

## 哪些品类做了也没什么回报

3C、汽车配件、工业品、B2B耗材，这几类基本可以跳过。

原因很直接：这些品类的决策靠参数，用户搜的是型号、规格、兼容性。

没有人会用一个拟态词去搜内存条。就算有人这么写，那也是在描述使用体验，不是在筛商品。

判据可以简化成一句话：这件商品的购买决定，有多大比重来自身体感受？比重高就做，比重低就别浪费时间。

还有一类要单独说：母婴用品。它的决策者是家长，使用者是婴儿，家长挑东西时对触感的敏感度极高，所以这一类的密度接近纺织，值得放进第一批。

不过有个边界情况：这些品类的配件和耗材有时会沾上感官维度，比如键盘的手感、椅子的坐感。真要做，就只做这几个沾边的子类，别整个类目铺开。

## 这些词该从哪儿采回来？

## 第一矿：自己站上和竞品站上的商品评论

评论区是这类词最集中的地方，原因很简单：写评论的人是在描述真实感受，不是在写文案。

他不会考虑正式不正式，也不会考虑品牌调性，他就是想把摸到的那一下说出来。

采法很土但有效：把评论正文拉下来，按四拍重复、促音结尾、り结尾这几个形态特征做正则筛，筛出候选，人工过一遍。

不懂日语也能做前半段，形态特征是纯字符层面的规律，写个正则就够了。人工那一遍再找母语者，半天能过掉几千条。

特别提醒一句：竞品评论的价值往往比自己站上的高，因为自己站上的评论已经被自己的文案带偏了——用户会不自觉地重复你页面上的词，而竞品评论里的词是他自己的。

采评论还有一个技术前提：评论内容得能被批量导出。如果你的评论组件是第三方服务且不提供导出，那就先解决这件事，否则整座矿只能靠人工翻页，成本立刻高一个量级。

## 第二矿：站内搜索日志

站内搜索是唯一一处用户拿自己的词直接跟你说话的地方。

我在站内搜索数据怎么挖关键词 (https://zhangwenbao.com/site-search-query-mining-keyword-research-first-party-data.html)里讲过这块第一方数据的价值，对这类词来说它的价值还要再高一档。

因为这类词在外部关键词工具里几乎查不到量，站内日志是少数几个能给出真实频次的来源。

要注意的是零结果查询。用户搜了一个拟态词、你的站返回空白，这条记录比任何一份词表都值钱，它同时告诉了你需求和缺口。

把零结果查询按频次排个序，前二十条基本就是你这个季度该补的内容清单。这个动作花不了一小时，却是我在所有客户那里回报率最高的动作之一，尤其在日本市场。

还有一个容易被忽略的字段：搜索之后有没有点击。搜了这个词但一次都没点的记录，说明你返回了结果，只是结果跟用户想要的不是一回事，这类记录比零结果更值得看，因为它暴露的是匹配质量而不是覆盖缺失。

## 第三矿：搜索建议与相关搜索

在日语搜索框里输入品类词，看它给出的补全建议，这一步几乎不花钱。

要点是输入法状态。用假名输入和用汉字输入，给出的建议不一样，两种都要试。

另外记得试试只输入拟态词的前两拍，比如ふわ，看看它会补出哪些品类。这一步能反向告诉你哪些品类的用户在用这个词。

这个方法的局限也很明显：它只能给你已经有一定量的词，新冒出来的词进不了补全。

所以三个矿要一起用。评论给你新词和长尾，站内日志给你真实频次，搜索建议给你已经成气候的那批。三者的交集是必做项，评论独有的那部分是观察项。

补全建议还有一个用法是做时间对比。同一个前缀隔半年再试一次，新冒出来的补全项往往就是这半年里流行起来的说法，这是少数几个能免费拿到趋势信号的地方。

## 采回来的词该放进页面的哪几个位置？

## 标题里放不放

可以放，但有前提：这个词得是这件商品真实成立的卖点。

拟态词的表现力太强，用错了不是不精确，是当场翻车。你把一条普通毛巾写成ふわふわ，用户收到货摸到那一下，退货理由里会原样写着这个词。

所以我的建议是，标题里的这类词必须由懂商品的人签字，不能由写文案的人自己定。

位置上放在品类词前面最自然，跟用户的查询语序一致。

还有一个细节值得留意：标题在搜索结果里会被截断，而这类词往往在最前面，所以它反而是最不容易被截掉的那一部分。这跟大多数修饰词的处境正好相反，也算是个意外的便宜。

还有个细节：这类词放进标题之后，别在同一个标题里再堆第二个同类词。两个感官词并列会互相削弱，读起来像形容词大赛，而用户一次只想要一种手感。

## 属性区与筛选器

这是最值得动的地方，也是最难说服开发的地方。

加一个手感筛选项，值域是三到五个拟态词，听上去很不严谨，实际上非常好用。

难点在于这个字段没有数据来源。供应商不会给你，平台类目模板里也没有，只能自己给每个SKU打标。

打标的办法是拿评论倒推：某个SKU的评论里哪个词出现最多，就打哪个标。这比让运营凭感觉打靠谱得多。

做完之后会有一个副产品：你手里第一次有了一份商品与感官词的对照表。这份表能直接喂给文案、喂给广告词、喂给站内推荐，价值远超过一个筛选器本身。

做筛选器还有一个前置判断：值域最好控制在三到五个。感官维度不像尺码那样有客观刻度，选项一多用户就分不清差别，筛选器反而变成了一道额外的选择题。

## 正文与评论摘要

正文里放这类词有个天然的合理位置：使用场景描述。

与其在参数区硬塞，不如写一段洗过三次之后还是ふわふわ的这种句子，既自然又能命中。

评论摘要是另一个好位置。如果你的商品页有评论标签或者评论关键词云，把这类词提上去，等于让用户替你写了这批关键词。

这一招的额外好处是它绕开了品牌调性的审查——那是用户说的，不是品牌说的。

顺带说一句，如果你的评论区是外部服务商提供的组件，先确认那段内容会不会被搜索引擎抓到。我见过好几个站的评论全在异步加载的框里，用户看得见，抓取看不见，那整座矿就白挖了。

评论摘要这一招还有个延伸：把高频感官词做成可点击的筛选标签。用户点进去看到的是同一手感的商品集合，这等于用用户的语言给你的商品重新分了一次类。

## 结构化数据里填不填

不填。

结构化数据里的属性字段要的是可比对的规范值，一个主观感官词填进去没有任何意义，还可能触发格式校验。

我在小语种页面的正文越本地化越好，结构化数据里却要反着写回国际格式 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)里讲过这个原则：正文往本地化走，标记往标准化走，两个方向不能混。

这类词是正文那一侧的东西，它的位置在标题、在描述、在评论、在筛选器的界面文案，唯独不在机器读的那份规范值里。

唯一的例外是商品描述字段本身。如果你的描述字段是给聚合平台用的，那它其实是正文的延伸，该写还是要写。

还有一个边界要说清楚：如果你的商品数据要同步到比价平台或者聚合站，那边的字段规范由对方定，感官词能不能进、进哪个字段，得按对方文档来，不能照搬自己站上的做法。

## 机器和工具会怎么对待这批词？

## 分词器会把它切成什么

四拍重复的形态对分词器不算难题，主流的日语分词器基本都能整体切出来。

麻烦出在新词上。词典里没有的组合，分词器会按两拍两拍地切开，切完的两半都不是词。

这跟泰语SEO的标题里找不到一个空格 (https://zhangwenbao.com/thai-seo-no-spaces-word-segmentation-keyword.html)里讲的切分依赖词典是同一个机制，只不过泰语是整句都要切，日语这边只有这一类新词会中招。

后果是站内搜索会失灵：用户搜一个新拟态词，你的索引里被切成了两个碎片，怎么也匹配不上。

务实的应对是给站内搜索单独维护一份同义词表，把新词和它对应的稳定词绑在一起。这份表不需要很大，几十条就能覆盖绝大多数流量，而且维护成本低到可以让运营自己改。

判断分词器有没有切错，有个不需要日语能力的土办法：把词丢进自己的站内搜索，再把它拆成前后两半分别搜。如果两半都能搜到一堆不相干的商品，说明索引里它已经被拆开了。

## 关键词工具给的量为什么是零

两个原因叠在一起。

一是工具的日语数据本来就稀，二是这类词的量分散在几十种写法和组合上，每一种都低于工具的显示阈值。

于是你查到的是一片零，很容易得出这个方向没需求的结论。

这正是小语种关键词工具返回的那个零是数据缺口 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)里讲过的那类零：它是工具的能力边界，不是用户的行为边界。

要拿到真数，只能靠第一方来源。站内搜索日志、搜索建议出现与否、评论里的词频，三个都是替代指标。它们给不出绝对搜索量，但足够排出优先级，而排优先级才是你真正需要的。

还有一个替代指标是竞品覆盖度。如果本土前十个品牌里有七八个都在用某个词，那它的真实需求一定不小，否则这些天天看数据的本土团队不会集体押它。

## 写法变体比你想的多

同一个拟态词至少有三种常见写法：平假名、片假名、以及带长音符的变体。

平假名是最常见的，片假名用于强调，长音符版本在年轻人的写法里更多见。

这跟日语SEO怎么选词？汉字、平假名、片假名不是同一批人在搜 (https://zhangwenbao.com/japanese-seo-hiragana-katakana-kanji-keyword-notation.html)里的写法分歧是同一层问题，只是这里的变体维度更细。

处理办法也一致：页面上选一种主写法，站内搜索和匹配层做归一，把三种写法都指向同一个索引项。

顺便说一句，促音那个小っ的有无也会造出变体，而且这两个变体在语感上真的不一样，一个更利落一个更绵长。到底该用哪一个，这种事没法靠规则判，只能问母语者，或者看用户实际打的是哪个。

这些变体在归一时有个顺序建议：先归假名种类，再归长音符，最后归促音。前两者几乎可以无脑合并，促音那一层要留意，因为它偶尔真的会改变语感的方向。

## 机器翻译会把它抹平

把一段带拟态词的日语丢给机器翻译，出来的英文里那个词会变成一个普通形容词。

反过来，把英文往日语译，机器几乎不会主动造出一个拟态词，因为源文里没有触发它的东西。

所以只要你的内容生产链路是英文先行、翻译跟上，这批词就永远不会自己长出来。

这不是机器翻译质量差，是这条链路的结构决定的。机器翻译发上线省下的那道审校 (https://zhangwenbao.com/machine-translation-direct-publish-search-risk-quality-line.html)那篇讲的是漏检风险，这里是另一回事：不是译错了，是有一整类词从来没有机会进入译文。

要让它长出来，只有一条路：在日语侧单独做一次以感官词为中心的内容补写，把它当成本地原创而不是翻译任务。这件事没法外包给翻译流程，得从内容排期里单开一格。

顺带说一个观察：这类词在译入方向上的缺失，在AI生成的内容里同样存在，而且更隐蔽。模型能写出通顺的日语，但如果提示词里没有这批词，它默认也会走形容词那条路。

## 为什么这批词经常刚写进去就被删掉？

## 母语审校会觉得它不够正式

这是最常见的死法。

你好不容易把词写进了商品文案，母语审校一看，觉得这个词太口语、太幼稚、不适合品牌，一笔改成了柔らかい。

他没有做错任何事。从写作规范的角度，他改得完全正确。

问题在于他手里的判据是文章好不好，你要的判据是用户搜不搜。这两把尺子在这个词上给出相反的结论。

解法不是跟审校吵架，是把这批词提前放进不许动的清单里，并且写清楚理由。审校简报里多这一行，能省掉后面十次来回。

沟通时有一个说法很好用：这批词不是我们要用的语气，是用户已经在用的词。把它从品味问题转成事实问题，讨论就短得多。

## 品牌调性与法务那一关

高端品牌尤其容易卡在这儿。品牌手册里往往写着要保持克制、优雅、专业，而这类词天生就是活泼的。

我的经验是别在原则上争论，直接拿数据谈：这个词一个月带来多少次站内搜索，其中多少次返回了空结果。

法务那边通常没什么问题，除非这个词构成了功效宣称。食品的口感词一般安全，护肤品的部分肤感词要小心，因为它可能被读成功效承诺。

这一点跟那个词你不好意思写，用户也不好意思打 (https://zhangwenbao.com/minor-language-euphemism-restricted-category-keyword.html)里的受限品类是同一个道理：词本身没问题，出问题的是它在特定品类里被读出的含义。

所以护肤这一类，最好在开工前就让法务把词表过一遍，把要慎用的那几个标出来。这个动作花半小时，能避免上线后整批下架重写。

另外提醒一句，广告平台的审核口径跟自然搜索不一样。某个感官词在商品页上完全没问题，投放素材里用可能会被判成功效宣称，两边的词表最好分开维护。

## 谁来拍板

我的建议是，这类词的最终决定权应该在做搜索的人手里，但需要商品端和审校端各出一票否决。

搜索侧负责证明用户在搜，商品端负责确认商品配得上这个词，审校端负责确认写法自然。

三方都过了才上线。看着麻烦，实际每个词平均只花几分钟。

比起上线之后因为描述与实物不符引来的退货和差评，这几分钟便宜得不像话。

更重要的是，这个流程一旦跑顺，它就成了一条制度化的通道。以后每个月新采上来的词都从这条通道过，不再需要每次都跟人解释为什么要用一个听起来这么幼稚的词。

三方会签听着重，实际可以异步跑。开一个共享表格，每人一列打勾，谁有异议在备注里写一句，两天内没人反对就默认通过。真正需要坐下来讨论的，一个季度也就那么两三个词。

## 一份两天能跑完的采词与落地流程

## 第一天：把词捞出来

上午从三个矿各采一遍：自己站和竞品站的评论、站内搜索日志、搜索建议。

下午做形态筛选和判重，把长音符、促音、假名互换的变体归到同一条。

输出是一张候选表，每行五列：主写法、变体写法、出现来源、出现次数、对应品类。

这一天不需要母语者全程在场，只需要在最后一小时请他把明显不成立的条目划掉。

如果你手上有零结果查询数据，把它单独标一列。这一列的优先级最高，因为它同时证明了两件事：有人在搜，而你的站接不住。

第一天还有个可选动作：把候选词按品类做交叉统计，看哪个品类的词最密集。这张交叉表往往会直接告诉你下一步该先动哪个类目，比凭感觉排优先级靠谱。

## 第二天：定落地位置

上午挑出前二十条，按品类分组，逐条决定它进标题、进属性、还是只进正文。

下午做两件事：给站内搜索加同义词表，给前二十条对应的商品打上手感标。

页面文案的改写不必在这两天完成，那是内容排期的事。

但站内搜索的同义词表当天就能上，它的见效速度最快，往往一周内就能看到零结果率下降。

整个过程最容易被拖长的一步是给商品打标，因为SKU多的时候工作量确实大。这里的取巧办法是只给销量前两成的SKU打，剩下的等有评论了再补，反正没评论的商品你也推不出这个标。

打标这件事还有个偷懒但有效的办法：让客服在处理退换货时顺手记一笔用户提到的手感词。退货理由里的感官描述精准得可怕，因为那是期待和实物对不上的地方。

## 验收看哪几个数

第一个数：站内搜索的零结果率，尤其是这类词的零结果率。

第二个数：带这类词的进站查询数量，从近似零涨到多少。

第三个数：手感筛选器的使用率，如果加了的话。

不建议看整站排名，因为这类词太分散，任何一个单独的词都撑不起报表。

汇报的时候我一般把它们合成一个指标：感官词覆盖的商品数占比。这个数从零涨到三成，比任何单词排名都更能说明这件事在往前走，也更容易让不懂日语的老板看懂。

另外建议记录一个过程指标：词表里有多少条已经完成了三方会签。这个数能让上面看到这件事在推进，而不是等最终转化数据出来之前一片空白。

## 什么情况下别做这件事

品类不对就别做，前面说过了。

还有一种情况：你的日语内容整体还是机器翻译直发的状态。那先解决那件事，这件事排在后面。

顺序不能反。在一堆机翻文案里插几个精心挑选的拟态词，就像给一件皱巴巴的衬衫别上胸针，谁都看得出别扭。

最后一种情况是团队里完全没有能接触到母语者的通道。这件事的每一步都需要母语者点头，哪怕只是兼职的、按小时计费的。没有这个通道，采回来的词你不敢用，做了也是白做。

还有一种情况值得多说一句：如果你这个类目的商品本身没有手感差异，比如全是同一家工厂的贴牌货，那这批词做了也只是让页面更好看，用户来了摸到的还是同一种东西，复购不会变。

## 常见问题解答

## 不懂日语，怎么判断一个拟态词该不该用？

不懂日语也能判断三件事里的两件。第一件是有没有人搜，这个看站内搜索日志和零结果查询就行，纯数据活。第二件是竞品用不用，把日本本土前十个品牌的商品页拉下来数词频，也不需要语言能力。第三件才需要母语者：这个词用在这件商品上准不准。所以你要做的是把前两件做完，带着一张已经排好序的短表去找母语者，只让他回答准不准，而不是让他从零开始给你推荐词。

这样一次咨询半小时就够，成本低到可以每月都做一次。当然，如果预算允许，最省事的做法是直接请一位母语的品类买手做半天顾问，他既懂词又懂商品，能一次性把准不准和配不配得上两个问题一起回答掉。

## 这类词能不能直接从日语词典里抄一份表？

可以抄，但只能当起点。词典收录的是已经稳定下来的那批，通常两千条左右，而它是一个还在持续产出新词的开放词类，任何词典都只能记录到编纂截止那一天为止。更关键的是词典不会告诉你哪个词对应哪个品类、哪个词是当下正在流行的写法。所以正确的用法是拿词典表做判重和形态校验的底表，真正决定优先级的数据得从评论、站内搜索和搜索建议这三个来源采。

只抄词典的团队通常会得到一份看着很全、用起来命中率很低的表。另外提醒一点，词典表里的词往往偏文学化，有相当一部分在商品语境里根本不会出现，直接全量导进关键词表会稀释你的优先级排序。

## 韩语市场要不要做同样的事？

要，而且韩语这类词的数量比日语还多。韩语的拟声拟态词同样靠元音和辅音的对立表达轻重、明暗、粗细，形态规则清楚，能产性一样强。做法可以整套照搬：从评论采词、按形态特征筛、给商品打感官标、给站内搜索配同义词表。唯一要额外注意的是韩语的分写规则会影响匹配，这一点在韩语SEO改标题那天只挪了一个空格 (https://zhangwenbao.com/korean-seo-spacing-particles-keyword-research.html)那篇里讲得比较细，采词的时候要把带空格和不带空格的写法都收进来。还有一个额外收益：日语和韩语两个市场的感官词表可以互相参照，同一件商品在两地被强调的手感维度往往高度重合，虽然词完全不同。

## 印尼语和马来语的重叠词是同一回事吗？

不是。印尼语和马来语的重叠主要承担语法功能，比如把词整个重复一遍表示复数，那是形态问题不是感官问题。日语韩语的拟态词重叠承担的是语义功能，重复本身在表达持续和反复的感觉。两者在字符层面看起来像，处理方式完全不同：前者要防的是分词器和自动补全把生造形态当成真词，这一点在印尼语SEO和马来语能不能合并成一套 (https://zhangwenbao.com/indonesian-malay-seo-two-markets-vocabulary-split.html)里有展开；后者要做的是把它当作可检索的属性词采集进来。所以看到重叠形态先别急着归类，先问一句这个重复是在表达语法关系还是在表达感觉，答案不同处理路线就完全不同。

## 关键词工具查不到量，怎么跟老板证明这件事值得做？

用第一方数据代替搜索量。最有说服力的组合是三个数：这类词在站内搜索里的占比、其中零结果查询的条数、以及带这类词的会话与不带的会话在加购率上的差距。第一个数说明盘子大小，第二个数说明现在漏了多少，第三个数说明这批流量的质量。这三个数都来自你自己的站，不依赖任何外部工具，也不用解释为什么工具查出来是零。

汇报的时候把它们合成一句话：站内每五次搜索里有一次用的是我们页面上根本没有的词，其中多少次直接返回了空白页。如果这三个数一时拿不到，退一步也行：截几张竞品商品页的截图，把对方标题里的感官词圈出来给老板看，视觉冲击往往比表格更快。

## 把这类词写进标题，会不会有夸大宣传的风险？

有，而且这是它跟普通关键词最大的区别。这类词的表现力极强，用户会拿收到的实物跟这个词直接对照，对不上就是差评和退货。所以落地流程里必须留一道商品端的否决权：搜索侧证明有人搜，商品端确认这件商品配得上这个词，两票都过才写进标题。护肤和食品还要多过一道法务，因为部分感官词在这两个品类里可能被读成功效承诺或者品质承诺，触发当地的广告表述规则。

正文里用相对安全，标题里用要谨慎。另外建议在商品页上给这类词配一句具体的补充说明，比如说明这个手感是在洗过几次之后仍然保持的，把主观词锚定到一个可验证的条件上，退货风险会明显下降。

## 做完之后多久复核一次？

建议按季度复核，新品季和换季前各加一次。复核的动作很轻：把上个季度的评论重新采一遍，看有没有新词进来，看老词的频次有没有掉。这类词有明显的季节性和流行度波动，夏天押干爽顺滑的词，冬天押厚绒蓬松的词，同一批商品的卖点词要跟着换。另外每次上新品之后一个月是采词的黄金窗口，因为用户描述新东西的时候最容易造新词。把复核排进日历，比指望某一次大工程一次性做完靠谱得多。复核时还有个动作值得加进去：回看上个季度定下来的词，有没有哪个已经很久没人搜了。表只进不出，用不了几年就会膨胀到没人愿意维护。



## 那个词你不好意思写，用户也不好意思打，可你们绕开它的方式不一样

- URL：https://zhangwenbao.com/minor-language-euphemism-restricted-category-keyword.html
- 分类：小语种SEO
- 发布：2022-10-26  |  更新：2026-07-29
- 摘要：写页面的人往上躲进医学词，搜东西的人往下躲进日常说法，两边绕开的方向正好相反。讲清委婉语为什么不能当同义词处理、各语言的躲法为什么互不通用、平台受限词表怎么把被搜的词一起拦掉，以及两档词该怎么摆进页面。
- 关键词：关键词研究,多语言SEO,内容本地化,小语种SEO

> **TLDR**：摘要：有那么几个品类，页面上的词读起来像从产品说明书里抄的，而用户在搜索框里打的完全是另一批词。原因不是没做本地化，是这类东西谁都不愿意直呼其名——写页面的人往上躲进医学词，搜东西的人往下躲进日常说法，两边躲的方向正好相反，中间那个直白的词谁都不用。更麻烦的是，每门语言各自发明了自己的躲法，翻译过去的委婉语在目标语言里通常不是委婉语，是怪话。这一篇讲这类词该怎么找、怎么摆、怎么跟平台那份受限词表共处。

> 摘要：有那么几个品类，页面上的词读起来像从产品说明书里抄的，而用户在搜索框里打的完全是另一批词。原因不是没做本地化，是这类东西谁都不愿意直呼其名——写页面的人往上躲进医学词，搜东西的人往下躲进日常说法，两边躲的方向正好相反，中间那个直白的词谁都不用。更麻烦的是，每门语言各自发明了自己的躲法，翻译过去的委婉语在目标语言里通常不是委婉语，是怪话。这一篇讲这类词该怎么找、怎么摆、怎么跟平台那份受限词表共处。

## 为什么这几个品类的关键词表，看着像照产品说明书抄的？

## 从一家德国中老年护理用品站说起

先说一个真实的项目。

那是一家做德国市场的中老年护理用品站，主推失禁护理垫和护理裤。

德语页面是找母语译者做的，术语一个不差，语法挑不出毛病。

上线半年，自然流量始终贴着地面走。

竞品的页面在他们看来写得还不如自己，排名却稳稳压着。

把两边的词摊开一比，问题一眼就看出来了：他们的页面通篇在用一个精准的医学名词，而竞品页面上那个词几乎不出现，出现的是几个听起来含糊得多的说法。不是翻译错了，是选的那一档词根本没人用来搜东西。

保哥后来把这类项目单独归了一类，因为它们的病症高度一致：内容质量越高，词选得越正式，流量越少。

这个项目还有一个细节值得记下来：客户自己也隐约觉得哪里不对，但他给出的猜测是内容写得不够多。于是又追加了一批文章，用的还是同一档词，流量一点没动。在词选错的前提下加内容，等于把同一个错误复制了三十遍。

## 这个病症在报表上看不出来

这类问题最难办的地方在于它没有任何异常指标。

页面收录正常，加载正常，结构化数据正常。

母语审校打分很高，因为文字确实规范得体。

关键词工具给的数据也不刺眼，你查的那个医学词确实有搜索量，只是不多。

所有仪表盘都是绿的，唯一的异常是这个品类的流量比同规模的别的品类低一截，而这个差距总能找到别的理由解释掉。这类问题的平均存活时间以年计，不是因为难修，是因为没人怀疑过词表。

这类问题还有一个特征让它更难被发现：它的损失是缺席型的，不是下跌型的。没有任何一条曲线掉下来过，只是有一大片查询从头到尾没进过你的门。而监控系统天生盯的是变化，对一直不存在的东西完全无感。

这类缺席型损失还有一个特点：它跟预算多少无关。你把这个品类的投入翻一倍，缺的还是那一片，因为多出来的钱依然花在同一批词上。判断自己是不是撞上了这种情况，最快的办法是拿一份本地竞品的词表来对，看有没有整片你从来没见过的说法。

## 先说清楚这一篇管哪一类词

本文说的是一类特定的词：指代那些让人不太好意思直说的东西的词。

它覆盖的品类比多数人想的宽，失禁护理、女性护理、避孕、脱发、体重管理、口气与体味、痔疮、心理健康、部分成人用品，都在里面。

这些品类有个共同特点：东西本身完全正当，需求也完全真实，只是没人愿意把那个词大声说出来。

它们不是敏感话题，不是灰色地带，绝大多数还是刚需和高复购。

正因为是刚需，这里的钱才好赚；也正因为没人愿意说出口，这里的词才最容易做错。这两件事是同一枚硬币的两面。

这个范围还可以再补两句边界。真正被平台整类禁掉的商品不在本文讨论内，那是能不能卖的问题，不是怎么选词的问题。同样，那些只是文化上略微私人的品类，比如内衣和体重管理，程度轻一些，但本文的做法一样适用，只是坡短一点。

## 委婉语跟同义词差在哪儿，同义词表为什么救不了它？

## 同义词是并列的，委婉语是有高低的

很多团队第一反应是把这类词丢进同义词表，然后就当处理完了。

这个做法之所以不管用，是因为它假设了一件不成立的事：这几个词是平级的。

同义词表里的词彼此可以互换，谁替谁都行。

委婉语不是这样，它们排在一条从直白到含蓄的坡上，每个词有自己的位置。

坡上的位置决定了这个词能出现在哪种场合。医学词进说明书，含蓄词进广告，直白词往往哪儿都不进。把它们当同义词处理，等于把一条有方向的坡压成了一个平面，压完之后你就不知道该在标题里放哪一个了。

把它想象成一条坡还有一个好处：坡是有方向的，你可以说某个词比另一个词更靠上，而同义词表里没法表达这种关系。一旦能表达高低，词表里就可以多加一列写位置，写完之后每一层该用哪个词就变成了查表，不再靠个人语感。

## 它跟口语和书面语的差别也不在一条线上

另一个常见的误解是把它等同于口语和书面语的区别。

口语书面语这条轴讲的是正式程度，两端的词指的是同一个东西，态度是中性的。

委婉语这条轴讲的是要不要正面提到那个东西，两端的词态度完全不同。

一个词可以既书面又直白，也可以既口语又含蓄，两条轴是交叉的不是重合的。

德语里那个表示往好里说的动词，德语在线词典对这个动作本身的释义 (https://www.dwds.de/wb/besch%C3%B6nigen)说得很直接，它描述的是把事情说得比实际好听，而不是把话说得比实际正式。这两件事在词典里就是分开的。

两条轴交叉之后会出现四个象限，其中最有用的是又口语又直白那一格——那正是用户会打、页面上却几乎不会出现的一批词。把这一格单独列出来，通常就是这个品类流量缺口最集中的地方。口语与书面这条轴本身怎么处理，是另一件事。

## 真正的判据是这个词在场时的尴尬程度

那怎么判断一个词是不是这类词？

有个很土但很准的办法：想象把这个词印在包装上，放进购物车，再由快递员送到家门口。

整个过程里有任何一步会让人不太自在，它就是这类词。

这个判据比任何词典标注都管用，因为它测的正是这类词起作用的那个场景。

顺带说一句，这个判据也解释了为什么这类品类的包装设计普遍偏素净、纸箱普遍不印图案。整条链路上的每一方都在替用户遮一下，而遮的方式各不相同。

这个判据还有一个变体更适合团队里用：把候选词读出来，看念的人有没有下意识压低声音。这个动作骗不了人，也不需要任何语言学训练。开会的时候当场试一次，比讨论半小时更能达成共识。

这个判据还能反过来用一次，用来挑不该动的词。有些词听着直白，实际在本地已经完全中性化了，念出来谁也不会不自在。这类词不必替换，硬给它找个含蓄说法反而显得别扭。判据只挑出真正让人不适的那一小批，剩下的照常用。

## 德语的这一族词能拿来当标本

德语在这一类词上留下的痕迹特别清楚，适合当例子看。

表示月经期间用品的那个复合词，德语在线词典收了它的构词与用例 (https://www.dwds.de/wb/Monatshygiene)，你会发现它由月份和卫生两个部分拼成，整个词里没有一个成分正面提到那件事。

而具体到那个产品本身的词，词典给的正字法词条 (https://www.duden.de/rechtschreibung/Damenbinde)是另一个组合，前半截是女士，后半截是绷带。

两个词指的是同一类东西，绕开的部位却不一样：一个绕的是时间，一个绕的是用途。

这就是这类词最典型的形态——它们不是在换一个说法，而是在选一个可以被提到的侧面。你能提到时间、能提到人群、能提到功能，唯独不提那件事本身。

德语这类复合词还有一个技术上的后果：绕开的那个成分越多，词就越长，长到一定程度分词器切法就不稳。而这类词恰恰是这个品类的核心词，于是委婉手段和分词难度在德语上是绑在一起的。复合词本身怎么切、怎么进词表，德语复合词把关键词表拆掉一半 (https://zhangwenbao.com/german-seo-compound-words-umlaut-eszett-keyword-research.html)那篇给过完整做法。

## 写页面的人和搜东西的人，为什么绕开的方向正好相反？

## 作者往上躲，躲进医学词

先看写页面这一侧。

写商品页的人面对这类品类，本能是往上走。

往上走意味着换成医学名词、学术词根、外来的正式词。

这样写有三个好处：显得专业、不会冒犯人、法务那边也好过。

德语的失禁一词就是典型的往上走，词典里这个词条的用例 (https://www.dwds.de/wb/Inkontinenz)清一色来自医学和护理语境。写页面的人选它，几乎是本能。

往上走这个本能还有一个来源常被忽略：写页面的人多半不是这个品类的用户。他从产品资料里学到的第一个词就是那个医学词，因为产品资料就是那么写的。于是他不是在选词，他是在复述唯一一个他知道的词。

## 用户往下躲，躲进日常说法

再看搜索这一侧。

用户面对同一件事，本能是往下走。

往下走意味着用日常的、模糊的、绕一圈的说法，甚至干脆描述症状而不给它命名。

这不是因为他不知道那个医学词，很多时候他知道，只是那个词打出来太像在给自己下诊断。

于是搜索框里出现的是一堆听起来不像关键词的短语，比如描述场景的、描述人群的、描述某种不方便的。用户不是在找一个词，他是在绕开一个词。

还有一类下坡的说法特别值得留意，就是那种完全不提产品、只描述处境的短句。它们看起来根本不像关键词，长度长、口语化、每个人说法还不一样，但它们的转化率往往高得离谱，因为打出这句话的人已经在找解决办法了。

这类描述型的长句还有一个来源值得挖：站内搜索里那些零结果的查询。用户打进来一句谁也没想到的话，系统返回空白，这条记录就静静躺在日志里。这批零结果查询是这个品类里最诚实的一份语料，因为没有任何编辑加工过它们。

## 两条路方向相反，中间那个词谁都不用

把两侧放在一起，这件事的结构就清楚了。

作者从中间那个直白词往上走，用户从同一个词往下走。

结果是：页面上是上坡那一头的词，搜索框里是下坡那一头的词，两边都离开了中间，可离开的方向是反的。

这跟一般意义上的用词不当完全不是一回事。用词不当是走偏了，这里是两边都走对了，只是走的是两条相反的路。

知道了这个结构，做法就明确了：你要的不是把页面上的词换掉，而是让页面同时站在坡的两头。这句话听着简单，落地要花点心思，后面会展开。

这个结构还能推出一条挺反直觉的建议：这类品类不要请这个领域最专业的人来写页面。越专业的作者离中间那个词越远，写出来的东西越难被搜到。合适的作者是懂产品但仍然会用日常话说这件事的人，这种人比想象中难找。

## 这个结构解释了一个反常现象

它还能解释一个让很多人困惑的现象。

这类品类里，写得越正式的页面表现越差，而看起来相当粗糙的小站反而排在前面。

不是搜索引擎偏爱粗糙，是那些小站的作者本身就是用户，他们写的时候用的是自己搜的时候用的词。

专业团队反而因为专业，一步跨到了坡的另一头。

这大概是这一行里少数几个不专业反而占便宜的地方，虽然占的时间通常不长。

不过这个便宜通常占不久。粗糙小站的词选对了，但别的地方全是短板，一旦有懂行的团队愿意把坡画一遍，优势立刻易手。真正稳的做法是既有专业内容的完整度，又保留下坡那一档词的入口，两头都不放。

## 为什么翻译过来的委婉语，在目标语言里往往不是委婉语？

## 每门语言各自发明了自己的躲法

这是本文最要紧的一条。

委婉语不是从某个原型翻译扩散出去的，它是每门语言各自独立造出来的。

德语靠复合词，把两个中性成分拼起来，指向那件事却不说出它。

英语常常靠拉丁词根和短语，用一个学名或者一个由两三个词组成的说法。

日语则常常靠汉语词，一个汉语词在日语里天然带着一层距离感，说出来就没那么直接。三门语言用的手段分别是构词、借词和语体，手段都不一样，产物怎么可能对得上。

三种手段还能再补一条判断：一门语言靠什么手段造委婉语，通常跟它平时靠什么手段造新词是一致的。爱拼复合词的语言就拼复合词，爱借外来词的语言就借词，靠语体分层的语言就换语体。知道了这门语言的造词习惯，就能预判它的委婉语长什么样。

日语这条路子还值得单独说一句：汉语词在日语里天然带一层书面的、隔着距离的味道，用它来指代私密的事情，等于既说清楚了又不显得直白。这套三层文字并存带来的语感差别，日语三套文字混排的写法选择 (https://zhangwenbao.com/japanese-seo-hiragana-katakana-kanji-keyword-notation.html)那篇里有系统的展开，本文这一类词只是它的一个应用场景。

## 直译过去的结果通常是一句怪话

手段不同带来的后果很直接。

把一门语言的委婉语逐词翻到另一门语言，形式上能翻，效果上翻不了。

目标语言的读者读到的是一个语法正确、意思也对、但从来没人这么说的组合。

它既没有委婉的效果，也没有直白的清楚，两头不靠。

这跟逐词直译造出一批没人搜的词是同一个机制的一个特例，那件事在逐词直译留下的历史词表 (https://zhangwenbao.com/keyword-literal-translation-legacy-cost-non-english.html)那篇里讲过通用形态。本文这一类的特殊之处在于，就算你找了母语者来写，他也可能给你上坡那一头的词，因为他在替你的品牌考虑体面。

还有一种更隐蔽的失败：翻过去的那个词在目标语言里恰好是另一件事的委婉说法。这种情况下页面读起来毫无问题，只是读者会以为你在卖别的东西。这类错误母语审校也未必会指出来，因为句子本身完全通顺。

## 母语审校在这一类词上会主动往上调

这一层值得单独说，因为它跟直觉相反。

你请母语者来审校，他会本能地把稿子往规范、体面的方向调。

越是正式的项目、越是重视品牌的客户，这个倾向越强。

于是审校这道工序在这类品类上是一个稳定的往上推的力，每过一遍就往坡上推一点。

这不是审校员的错，他做的正是他被要求做的事。要想让稿子留住下坡那一头的词，必须在审校简报里把这件事写成一条明确的例外，否则它一定会被改掉。简报该怎么写，小语种译文验收清单 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)那篇给过结构，这里只是多加一条。

这条力还有一个放大器：越重要的页面被审的次数越多。首页、品类页、主推商品页往往过三四遍，每一遍都往上推一点，推到最后这几个最值钱的页面上，下坡那一档词一个都不剩。而边缘页面反倒保留着原样。

这条力还跟另一类词的遭遇一模一样：用户实际会打的削短形式，也会被审校一路改回全称。两件事的机制完全相同，都是质量关卡按正式度筛，而搜索按使用频度来。那一类的完整分析在用户搜的短词你的词典里查不到 (https://zhangwenbao.com/minor-language-clipped-short-forms-keyword-coverage.html)那篇里，可以对照着读，会发现这道关卡在小语种上反复咬人。

## 怎么验证一个候选词在目标语言里真的委婉

最后是验证办法。

光靠问一句这个词委不委婉，得到的答案很不可靠，因为对方会按你期待的方向回答。

更好的问法是给出场景：这个词你会不会当着家人的面说、会不会写进给同事的邮件里、会不会印在包装外面。

三个场景各问一遍，答案的分布就把这个词在坡上的位置定住了。

这套问法的好处是它不需要对方懂语言学，也不需要你懂这门语言，问的全是生活经验。三个人各答一遍，答案通常出奇地一致。

三个场景问完还可以补一个更狠的：这个词你会不会用来跟陌生人描述自己的情况。这一问测的是最私密的那一档，能把坡最下面那一小段区分出来。多数商品页用不到这一档，但它是搜索框里出现频率最高的那一档。

## 一个委婉说法能用多久，到期了谁会通知你？

## 委婉语会被它指代的东西慢慢污染

这类词有个特性，用久了会失效。

一个词被用来指代那件不好意思说的事，用得多了，它自己就沾上了那件事的味道。

沾上之后它不再委婉，人们于是再造一个新的，过些年新的又沾上。

这个循环在语言学里被讨论了很多年，它的实际后果是：这一类词有寿命，而寿命长短不定。

你词表里那个词今天好用，五年后可能已经变得跟当初那个直白词一样让人不自在。这是全站唯一一类会因为被使用而自己变质的词。

这个循环还有一个观察得到的后果：同一个品类里，越老的品牌用的词越靠上。它们的词是十几年前定的，那时候那个词还很委婉，如今已经滑到中间去了。看一眼各家品牌的成立年份和用词位置，这条曲线相当明显。

## 跟正字法那类有保质期的词，过期方式完全不同

这里要跟另一类词划清界限。

正字法层面也有会过期的写法，比如某个符号用法被官方规范推翻。

那一类的过期是有裁决的：有机构、有公告、有生效日期，你可以把这个日期写进词表的字段里。

委婉语这一类完全不同，没有任何机构能宣布一个委婉语过期了，它的过期是渐进的、没有公告的、事后才被发现的。

所以那种做法在这里用不上。你没法给它写一个到期日，只能靠周期性地重新测一次坡上的位置。这是两类完全不同的维护动作，一个是查公告，一个是做调研。

还有一层差别在维护成本上。查公告那种维护可以交给流程，设个提醒到点去看一眼就行；做调研那种维护交不出去，它需要有人真的去看竞品、听客服、读用户留言。前者能自动化，后者只能排人，这决定了它在预算表里长什么样。

两类维护还有一个共同的失败模式：都容易在换人的时候断掉。查公告那种断了还能补回来，因为公告一直在那儿；做调研那种断了就真断了，因为当年访谈里的判断没人记录。所以这类工作的产出必须写成文档，而不是留在负责人的判断里。

## 怎么发现自己那个词已经开始变质

那怎么察觉？有三个可观察的信号。

第一个是这个词在你自己的转化数据里开始跑输另一个词，而两者的流量并没有此消彼长。

第二个是客服那边开始出现用户主动换用另一个说法的记录。

第三个也是最灵的一个：竞品悄悄换了词，尤其是那种在这个市场深耕多年的本地竞品。

本地老玩家换词通常不是拍脑袋，他们比你更早听到风声。把三五家本地竞品的品类词做成一张表每半年比一次，这件事一小时就能做完，却是这类品类里性价比最高的一项例行工作。

三个信号里第三个最灵，但也最容易被忽视，因为看竞品用词这件事没人排进例行工作。建议把它跟每半年一次的竞品盘点合并，多花不了十分钟。顺带一提，如果发现三家本地竞品同时换了词，那基本可以确定不是巧合。

还有一个信号来自你自己的站内搜索：如果用户开始用一个你页面上完全没有的说法来搜，而且量在涨，那多半是坡在移动。这个信号比外部数据快，因为它记录的是用户此刻的用词，不是几个月前统计出来的。

## 平台那份受限品类词表，是按语言分别维护的吗？

## 这类品类天然踩在多条规则的边上

选词的麻烦还没完，另一头还站着一堆规则。

这类品类的商品，很多同时受药品广告、医疗器械、化妆品或者食品标示的管辖。

德国那部专管医疗健康类广告的法律，就把可以怎么说这件事规定得很细，比如它关于广告表现形式的那一条 (https://www.gesetze-im-internet.de/heilmwerbg/__11.html)列出了一长串不许用的表现手法。

英国那边的广告规范也有专门一节管药品、医疗器械与健康美容类产品 (https://www.asa.org.uk/type/non_broadcast/code_section/12.html)的说法。

日本这一侧则由不当赠品与不当表示相关的景品表示相关法规 (https://www.caa.go.jp/policies/policy/representation/fair_labeling/)那一套负责，重点在标示是否会误导。三个法域，三套写法约束。

这些规则还有一个共同点值得注意：它们管的是页面上写了什么，而不是用户搜了什么。也就是说合规约束只作用在坡的一侧。这一点很重要，它意味着你在词表里保留下坡那一档并不违规，违规的只可能是你把它写进页面的方式。

## 法条管的是怎么说，平台管的是能不能说

但真正每天卡住你的，往往不是法条而是平台规则。

法条约束的是表述方式，比如不能承诺疗效、不能用他人证言。

平台规则约束的是整类内容能不能出现，判定往往落在具体的词上。

两者的粒度完全不同：一个查你怎么说，一个查你说没说那个词。

而平台的判定通常是自动的、瞬时的、不给理由的，这就带来了下一个问题。

两者的申诉路径也完全不同。法条那一侧有明确的条款可引，可以讲道理、可以找法务出函；平台规则那一侧多数只能提交一个表单然后等，理由栏还只有几百个字符。所以真正卡进度的往往不是法律风险，是那个不给理由的自动判定。

## 小语种那份词表，多半是英语那份翻过来的

这是本节的关键。

平台的受限词表按语言维护，但各语言的版本质量差别极大。

英语那份是原生的，经过多年积累和申诉打磨。

小语种那份很多是从英语那份翻过去的，翻的时候用的是词典对应，而不是这门语言里真实的用词分布。

后果是两头都出错：一边把本地根本没人用的直译词列进了黑名单，一边漏掉了本地真正通行的那个说法。这类系统的误判怎么形成、例外条款为什么最难处理，跟本地词表的语言学质量直接相关。

这份词表的翻译质量还有一个可观测的迹象：如果你发现被拦下的词里有一批在本地语言里根本不通顺，那基本可以断定这份表是逐词翻过来的。这个迹象很有用，它意味着申诉的成功率会比你想的高，因为对方那份表确实有错。

这里还有一件实操上省时间的事：不要试图靠读平台的政策文档来预判哪些词会被拦。文档写的是原则，判定用的是词表，两者对不上。花二十分钟用小额预算实测五个候选词，得到的信息比读两小时文档多得多。

## 被平台拒掉的那个词，会不会正好是用户在搜的那个词？

## 会，而且比想象中常见

直说结论：会。

用户往下躲选中的那个日常说法，恰恰因为口语化，最容易落进平台词表里的粗俗或者敏感一档。

而你往上躲选中的医学词，平台通常放行，因为它看起来专业。

于是出现了这样一个局面：能投的词没人搜，有人搜的词投不了。

这个局面不是谁做错了，它是两套评分体系各自按自己的标准运行的自然结果。

这个局面还有一个更糟的变体：平台放行的那个医学词，因为搜的人少，投放竞价反而不低——愿意花钱买它的都是同行，大家都被逼到了同一个词上。于是你在一个没人搜的词上跟所有竞品抢，这笔账怎么算都不划算。

这笔账还有一个更隐蔽的损失：因为投放数据来自那个没人搜的词，你据此得出的品类结论也是歪的。转化率、客单价、人群画像，全都是从一小撮同行和少数专业用户身上采出来的样本。拿这份样本去指导自然搜索那一侧的选词，会一路错下去。

## 跟最高级那类冲突不是一回事

要把这件事跟另一类冲突分开。

最高级形容词那一类的冲突，双方都在引法条：搜索侧要那个词，合规侧引竞争法说不能说得太满。两边都拿着白纸黑字。

本文这一类不同。拒你的那一方拿的是平台自己的私人规则，而想要那个词的那一方是用户的实际用词，双方连争论的场地都不在一起。

前者是两套公开规则打架，可以摆条款谈；后者是私人规则对上真实行为，没得谈。

处理办法也因此不同：那一类要找第三种表述，这一类要做的是分场地。哪一层能用哪一档词，是可以设计的。

两类冲突还有一个处理顺序上的差别。最高级那一类必须先解决，因为它有法律风险，拖着可能吃罚单；本文这一类没有法律风险，拖着只是少赚钱。搞清楚哪一类是风险、哪一类是机会，排期时才不会把两件事混在一起谈。最高级那一类的完整处理办法在小语种最高级词的形态与合规冲突 (https://zhangwenbao.com/minor-language-comparative-superlative-keyword-forms.html)那篇里。

## 分场地的具体做法

分场地说白了就是承认几条渠道各有各的规矩。

付费投放那一侧，老老实实用平台能过的那一档词，不要试图绕。

自然搜索这一侧，可以放心用用户真正会打的那一档，因为它不经过平台的词表审核。

页面正文里两档词都要出现，只是位置不同，这一点下一节展开。

这套分法还有个附带好处：两侧的数据从此可比性更强了，因为你终于知道它们词表不同，不会再拿投放的转化率去质疑自然流量的词选得对不对。

分场地之后还要做一件事：把两侧的词表分开存，别放在同一个表里靠一个标记区分。放在一起迟早会有人拿错，尤其是在换人交接的时候。分成两个文件、两个负责人，这点冗余换来的是不会出现拿投放词表去写页面标题的事故。

还有一处容易忽略的场地：客服话术和售后邮件。这两处用的词该跟用户一致，也就是下坡那一档，因为用户会照着复述。如果客服回信里全是医学名词，用户下次搜索时反而更不知道该打什么，等于亲手把自己的入口词推远了一档。

## 回避这件事，为什么不只发生在词上？

## 用户在这类品类里的行为整条链都变形

这是本文最容易被漏掉的一层。

不好意思说出口这件事，不只影响用户打什么词，它影响用户做的每一个动作。

这类品类的用户更少留评价，更少分享链接，更少点开带有明显品类标识的广告。

他们更倾向于用无痕窗口，更倾向于直接下单而不加购物车，更倾向于跳过所有需要留下痕迹的环节。

换句话说，回避发生在整条行为链上，而不只发生在搜索框那一格里。

这条行为链的变形还有一个容易被误读的表现：这类品类的直接访问占比往往偏高。看起来像是品牌力强，实际上是用户不愿意每次都重新搜一遍那个词，于是记住了网址。把它当成品牌资产来汇报，会得出完全错误的结论。

直接访问偏高这件事还有一个正面用法：既然用户愿意记住网址回访，那这个品类的邮件和复购提醒的效果通常远好于社交渠道。渠道预算应该跟着这条行为特征走，而不是照搬别的品类的分配比例。本地用户对渠道的信任差别，小语种落地页的信任元素三分法 (https://zhangwenbao.com/minor-language-landing-page-trust-signals-payment-address-support.html)那篇里有按元素拆开的判断办法。

## 后果是所有行为类指标系统性偏低

这带来一个很实际的麻烦。

评价数偏低、分享数偏低、社交提及偏低、老客回访路径偏短。

这些数字在任何一张跨品类的对比表上都难看，而看表的人会把它读成这个品类做得不好。

真正的原因是这个品类的用户在刻意不留痕迹，跟内容质量毫无关系。

所以这类品类的指标只能跟自己比，跟同品类的本地竞品比，绝对不能拉进全站的横向对比表。这条判断在跨语言比较里已经成立过一次，跨品类这里同样成立。

还有一类指标受影响更深，就是那些依赖用户主动提及的信号。这个品类几乎没有人会在社交平台上主动提到自己买了什么，于是所有靠提及量估算的方法在这里全部失灵。这一点在跨市场比较的时候必须先说清楚，同一个词在不同市场的意图漂移 (https://zhangwenbao.com/minor-language-search-intent-divergence-across-markets.html)那篇里的对照组思路在这里同样适用：只跟同品类比。

## 连搜索入口的形态都不一样

还有一个更细的差别。

这类品类的用户常常先搜一个很泛的上位词，再在结果页里慢慢找。

因为把那个精确的词完整打出来这件事本身就让人不适，哪怕搜索框里没有别人在看。

结果是入口词偏泛、点击层级偏深、单次会话里的页面数偏多。

知道这一点之后，落地页的设计思路要跟着改：这类品类的分类页比商品页更重要，因为用户是从泛词进来的，商品页承接不住那个入口。这跟大多数电商品类的结论正好相反。

入口偏泛还带来一个内容上的机会：泛词进来的用户需要的是先被解释清楚，而不是立刻看到商品。所以这类品类的分类页上应该有一段真正在解释问题的文字，而不只是一排筛选器。这段文字往往是整个品类里最值钱的一段内容。

这段解释性文字还有一个额外好处：它天然就该同时出现两档词。解释问题的时候用下坡那一档，给出方案的时候用上坡那一档，读起来完全自然。很多团队苦苦寻找的两档词共存的位置，其实就在这一段里。

## 这两档词该怎么摆进页面，才不至于顾此失彼？

## 标题用坡上偏下那一档

先说标题。

页面标题标签里放的应该是用户真正会打的那一档，也就是偏下那一档。

理由很直接：标题是拿来匹配查询的，不是拿来体现品牌调性的。

如果偏下那一档词实在放不进去，退一步的做法是把它放进标题的后半截，前半截留给品类的通行说法。

这条跟很多品牌手册会打架，需要提前把账算给对方看：标题里那个更体面的词，每个月的代价是多少次没被匹配上的查询。

标题这一层还有一个折中技巧：把下坡那一档词放进标题，把上坡那一档放进元描述。搜索结果里两者会同时展示，匹配靠标题完成，体面靠描述找补。这个安排能让绝大多数品牌方接受，因为他们真正在意的是被人看到的那一行。

## 正文里两档词要同时在场

再说正文。

正文是唯一一个能把两档词同时容纳下来的地方。

做法不是把它们堆在一起，而是让它们各自出现在合适的句子里：说明产品结构时用上坡那一档，描述使用场景时用下坡那一档。

这样写出来的文字是自然的，因为现实生活里人们本来就在不同场合换着说。

顺带把两档词之间的关系写清楚一句，读者和机器都能建立起这两个说法指的是同一件事。这一步比反复堆同一个词有用得多。

正文里还有一个位置特别适合放下坡那一档词，就是小标题。小标题天然是用来复述用户问题的，用户怎么问就怎么写，读起来一点不突兀。相比之下在正文段落中间硬塞那个词，反而容易显得刻意。

小标题这一层还有个附带效果：它会被各类摘要机制优先读取。用户的原话被放在小标题里，等于把最匹配查询的那句话放进了最容易被摘走的位置，一举两得。这比在正文里重复堆词高效得多，也不伤可读性。

## 属性值和筛选器只能用一档

最后是最不容妥协的那一层。

筛选器背后是精确匹配，属性值必须严格相等，这一层不接受模糊。

所以这里只能选一档词，而且一旦选定就不能中途换。

建议选偏上那一档，因为它更稳定、更不容易在几年内变质，而变质的风险在属性值这一层代价最大。属性值这一层为什么完全不能靠模糊匹配救回来，属性枚举值在小语种里的范畴错位 (https://zhangwenbao.com/minor-language-color-category-attribute-value.html)那篇讲得很透，本文这一类词只是把那个问题又加了一个变量：它还会随时间漂。

属性值这一层还要防一件事：不要把两档词分别建成两个属性值。那样会把同一批商品拆到两个筛选项下面，用户点哪个都只看到一半库存。要接住另一档词，正确的位置是同义词配置或者搜索词映射，不是属性值本身。

## 一套两天能跑完的委婉词盘点流程

## 第一步：把坡画出来

第一天上午做一件事：给每个核心品类画一条坡。

坡的一头写最医学、最正式的那个词，另一头写最日常、最含糊的那个说法。

中间尽量把能想到的说法都摆上去，包括那个谁都不用的直白词。

一个品类通常摆得出五到八个位置，摆不出来说明这个市场你还不够熟。

这张坡图是后面所有决策的底图，也是跟品牌方吵架时唯一有用的道具。

画坡的时候有个实操建议：让至少一位这个品类的真实用户参与，哪怕只是团队里的家属。专业人士画出来的坡上半截很细、下半截很粗糙，而下半截恰恰是流量所在。这一步花不了半天，效果比多请一位顾问明显。

画完之后还有一步很多人会跳过：把每个位置上那个词在本地权威词典里的词条查一遍，记下它的用例来自什么语境。医学语境、日常语境还是文学语境，一查就知道它在坡上的真实位置，比凭感觉排要可靠。

## 第二步：给每个位置标三件事

第一天下午给坡上每个词标注三列。

第一列是用户会不会这么打，靠站内搜索日志和搜索建议判断。

第二列是平台放不放行，靠实际投一小笔预算试出来，这比看规则文档快。

第三列是审校会不会把它改掉，这一列靠问，问完写进简报的例外条款。

三列填完，哪个词该放在哪一层就基本自明了，剩下的只是执行。这套判断不需要搜索量数据支撑，在工具给不出数的语种里尤其重要，替代思路在工具没数据时的三条补救路径 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)里有完整方法。

第二列那个小额测试还有个附带收获：它能顺便测出平台对你整个品类的态度。如果连最中性的那个词都投不出去，说明问题不在词而在品类资质，那是另一条路要走，跟选词无关。这一点越早知道越好，免得在词上白折腾两周。

三列填完之后还建议加一列成本估算，写清楚这个词如果要用需要额外做什么，比如改属性值、改投放素材、跟法务确认。有了这一列，这张表就从一份语言分析变成了一份能进排期会的方案，这一步的转换往往决定它会不会被真的执行。

## 第三步：定复核周期，别定到期日

第二天做收尾。

把这张表接进内容规范，标题、正文、属性值三层各自引用表里的哪一行，写死。

然后定一个复核周期，建议半年一次，跟着本地竞品的用词一起看。

注意是定周期不是定到期日，因为这类词没有到期日可定。

最后留一条给自己：复核的时候先看竞品换没换词，再看自己的数据，顺序反过来就晚了半年。

收尾的时候还建议把这张表存成一份可以交接的文档，而不是留在某个人的脑子里。这类知识流失得特别快，因为它既不是技术文档也不是品牌规范，没有天然的归属地。写清楚每个词为什么放在那一层，接手的人才不会一上来就把它改回体面版。

文档里还建议留一节写清楚哪些词是被平台拦过的、什么时候拦的、申诉结果如何。这一节的价值在换渠道或者换代理商的时候会突然显现出来，它能省下重新踩一遍坑的几周时间。这类记录写起来只要几行，但重建起来要几个月。

## 常见问题解答

## 这类品类是不是干脆别做算了？

恰恰相反，这类品类往往是小语种市场里最值得做的一批。需求真实、复购稳定、竞争者少，而竞争者少的原因正是大多数团队被这层难为情挡在了外面。真正的门槛不是流量贵，是没人愿意花两天时间把那条坡画出来。把这件事做对的团队，通常能在这个品类上吃很久的红利，因为后来者要重复的不只是投入，还有面对这件事的意愿。

要说风险，主要在合规那一侧，而合规风险是可以逐条查清楚的，比模糊的品牌顾虑好处理得多。真做不了的品类是那些整类被平台禁掉的，本文说的这几个都不在其中。判断的第一步是查平台的品类政策而不是猜。换句话说，这个品类的护城河一部分是由别人的不好意思砌起来的。

## 能不能用两个词各建一个页面，各打各的？

不建议。两个词指的是同一件事，各建一页最可能的结果是两页互相蚕食，谁也排不上去。更麻烦的是这两页的内容必然高度重合，因为产品就那一个。正确的做法是一页承接，把两档词分别放进标题、正文和小标题里，让同一页同时接住两头的查询。

唯一的例外是两档词背后的搜索意图确实不同的情况，比如一个偏了解症状、一个偏直接购买。这时候拆的依据是意图不是词形。判断办法是各搜一次看结果页的构成，如果两次结果页里的页面类型明显不同，才值得拆。拆之前先确认库存和内容能不能撑起两个页面，撑不起来就别拆。

## 母语译者给的词，为什么不能直接信？

不是不能信，是要问对问题。你问他这个词对不对，他答对；你问他这个词自不自然，他答自然；这两个答案都是真的。问题在于你想知道的是第三件事：用户在搜索框里会不会打这个词，而这是译者的职业训练里最不涉及的一环。

更麻烦的是，这类品类会额外触发译者的体面倾向，他会替你的品牌把词往上调一档。所以正确的问法是给场景：这个词你会当着家人说吗，会写进工作邮件吗，会印在包装上吗。这三个问题他答得又快又准。这三个问题也可以直接写进审校简报，让对方在交稿时一并回答。

## 平台把我的词判成违规了，申诉有用吗？

有用，但要挑对申诉的理由。拿这个词在本地语言里是通行说法当理由，成功率远高于拿我们的产品是正规品类当理由，因为后者平台早就知道，前者才是它那份词表缺的信息。申诉时附上本地权威词典的词条截图，效果通常比长篇解释好。

另外一个实用做法是别指望一次申诉解决所有词，先申诉那个流量最大的。一个词申诉成功之后，同一批词的复议往往会顺畅很多。同时把这次申诉的结论记进词表，免得半年后换了人再来一遍。申诉记录本身要归档，它是下次换平台时最省事的一份现成材料。

## 怎么跟品牌方解释我们必须用那个不体面的词？

别用体面不体面这个框架谈，那是没法赢的辩论。改成谈两个数字：一个是那个偏下的词每月带来多少次查询，另一个是页面上现在那个词带来多少次。两个数字并排放，多数争论会在五分钟内结束。

如果对方仍然坚持，退一步的方案是把偏下那一档词放进正文和小标题，标题保留品牌偏好的说法，然后约定三个月后看数据再谈。这个方案的好处是它自带一个可验证的结论，而不是靠谁嗓门大。三个月后数据会替你说话。这类谈判最好带着数据去，而不是带着语言学解释去。

## 这套办法在其他语言上通用吗？

结构通用，具体的词一个都不通用。任何一门语言里都有这条从直白到含蓄的坡，坡的存在是人类的共性；但坡上有几个位置、每个位置用什么手段造出来，完全是这门语言自己的事。德语靠拼复合词，日语靠换用汉语词，别的语言还有靠借词、靠指小形式、靠委婉的动词短语的。

所以搬过去的是流程和判据，不是词表。每进一个新市场都要重画一次坡，画一次两天，这个成本在这类品类的收益面前完全不值一提。反过来，跳过这一步的代价通常要用半年的流量来还。每进一个新市场重画一次，这件事没有捷径也不该找捷径。

## 这件事该排在优先级的哪一档？

如果你的品类在本文说的那个范围里，它应该排在很前面，仅次于技术层面的硬阻塞。理由是它影响的是整个品类的入口词，改一次全站受益，而且几乎不需要开发资源，两天时间和几次访谈就能完成。

如果你的品类不在这个范围里，那这件事可以完全不做。它是一个品类特异的问题，不是所有小语种站都需要处理的通用项。判断自己在不在范围里，用那个包装与快递的想象测试就够了，五分钟得出结论。判断完如果发现自己不在范围里，把这两天留给别的事就是了。

## 权威参考资料



## 俄语的读者没有跟着地缘变化一起消失，只是不在你原来结算的那个国家了

- URL：https://zhangwenbao.com/russian-language-market-seo-decision-after-2022-geopolitical-shift.html
- 分类：小语种SEO
- 发布：2022-10-20  |  更新：2026-07-27
- 摘要：俄语的一语与二语使用者分布在十几个国家，语言层的资产跨境保值，支付与物流这些市场层的资产几周内作废。讲清两类资产怎么分、三档决策怎么选，以及冻结为什么远优于删除。
- 关键词：国际化SEO,出海SEO,多语言SEO,小语种SEO

> **TLDR**：摘要：2022年之后很多出海团队在问同一个问题：俄语这块流量还要不要做。这个问题问错了，因为它默认俄语等于一个国家。俄语的一语和二语使用者分布在十几个国家，语言这一层的资产跨境保值，而支付、广告、物流这些市场层的资产几周之内就会作废。真正该做的是把两类资产分开清点，再决定哪一部分留下、哪一部分改挂到别的国家去。

> 摘要：2022年之后很多出海团队在问同一个问题：俄语这块流量还要不要做。这个问题问错了，因为它默认俄语等于一个国家。俄语的一语和二语使用者分布在十几个国家，语言这一层的资产跨境保值，而支付、广告、物流这些市场层的资产几周之内就会作废。真正该做的是把两类资产分开清点，再决定哪一部分留下、哪一部分改挂到别的国家去。

## 俄语市场和俄罗斯市场，从来就不是同一个东西？

## 俄语读者分布在十几个国家

把俄语和俄罗斯画等号，是这轮决策里最贵的一个默认假设。

俄语是哈萨克斯坦、白俄罗斯、吉尔吉斯斯坦的通行语言之一，在乌兹别克斯坦、亚美尼亚、格鲁吉亚、摩尔多瓦有大量使用者。

以色列、德国、波罗的海三国都有规模不小的俄语社群，他们上网购物时会切换到俄语界面。

这些人加起来是一个可观的数字，而且他们的购买力分布很分散。

换句话说，俄语是一门跨国语言，跟西班牙语、阿拉伯语的分布形态更像，而不像日语韩语那种一国一语。

把一门跨国语言当成单一国家市场来运营，在任何时候都是错的，只是在平稳期这个错误不会显形。

使用者的分布数据不难查，语言资料库里有一语与二语使用者的分国统计。俄语的使用者分布与官方地位 (https://www.ethnologue.com/language/rus/)这类条目会列出哪些国家把它列为官方或工作语言、二语使用者规模多大。花半小时查一次，就能把这个默认假设从团队的讨论里彻底拆掉。

## 一语和二语使用者的比例决定内容怎么写

俄语的一个特点是二语使用者占比很高。

在中亚几国，相当一部分人日常使用本国语言，但检索和阅读长文时会用俄语。

这类读者对语言的期待跟一语使用者不同：他们更在意信息清楚，对细微的语体差别不敏感。

这意味着面向这批市场的内容可以更直白、句子更短、术语解释更充分。

反过来，针对一语市场那套讲究语体和修辞的写法，搬过去反而增加理解成本。

同一门语言，读者构成变了，写法就该跟着变。

这条差异在关键词层面同样存在：二语使用者更倾向用通用词而不是俚俗说法，查询也更短更直。俄语选词与词形变化那一套 (https://zhangwenbao.com/russian-seo-cyrillic-cases-declension-wordstat-keyword.html)讲的格变化处理在这几个市场照样适用，但词表里的高频词会明显不同——这也是把俄语当成一个市场时最容易漏掉的一层。

## 把语言当成市场，是这次决策最大的误区

语言是内容的属性，市场是生意的属性，两者本来就不该合并。

平稳时期合并没什么坏处，因为俄语流量的绝大部分确实来自一个国家。

但一旦那个国家的运营条件发生变化，合并的代价就一次性显现。

团队面对的问题变成一个二选一：要么整个砍掉，要么什么都不动。

而这两个选项都不是最优解，最优解在中间，前提是你能把两者拆开。

拆开这件事没法在决策当天临时做，它依赖平时的数据结构。

具体来说，如果你的分析后台里语言维度和国家维度是绑死的，比如把俄语流量直接命名成俄罗斯流量，那这次你就得先花两周把数据重新拆出来。数据结构里的每一次偷懒，都会在需要决策的那一天连本带利要回去。这是本文最想留下的一条工程建议：语言和国家在任何一张报表里都应该是两个独立的字段。

## 先数清楚你的流量到底来自哪几个国家

动手之前先做一件很基础的事：把俄语页面的流量按国家拆开。

多数团队做完这一步会有点意外，因为非俄罗斯来源的比例往往比印象中高。

再拆一层：把订单和收入也按国家拆开，看跟流量的分布是不是一致。

两个分布差别越大，说明你的市场层配置在某些国家越不匹配。

比如流量里哈萨克斯坦占了两成，订单只占半成，那多半是支付或者配送没配上。

这个缺口本身就是一个现成的机会，跟地缘变化没关系，只是以前没人看。

保哥给一个卖宠物食品和猫砂的站做过这个拆分，结果是俄语流量里非俄罗斯来源占到三成四，而这三成四贡献的订单只有不到一成。原因很简单：结账页只有一种货币，配送选项只覆盖一个国家。这批流量在过去两年里一直存在，从来没人专门看过，因为报表上它们被合并在俄语这一行里。

## 该问的不是要不要做，而是哪一部分留下来

## 语言资产和市场资产的分界线

语言资产包括关键词表、词形变体的处理规则、已经写好的正文、母语审校的合作关系、本地作者的署名体系。

市场资产包括支付通道、广告账户、物流合同、本地仓、法务实体、发票能力。

这两类资产的共同点是都要花钱花时间攒，区别是它们绑定的对象不同。

语言资产绑的是这门语言的使用者，他们在哪个国家都能读。

市场资产绑的是一个具体国家的基础设施，国家的条件变了它就跟着变。

所以地缘变化冲击的是后者，前者基本毫发无损。

这条分界线跟本栏目一直在用的那条分层是同一条：语言层的事跟语言走，架构层和市场层的事跟国家走。多语言站的语言与地区标签怎么配 (https://zhangwenbao.com/international-seo-hreflang-complete-guide.html)那篇讲的语言与地区两段结构，在这里第一次显出它的实际价值——标签写成两段的站，这次改起来只动后半段；写成一段的站，得整个重来。

## 四象限：哪一格保值，哪一格作废

把两类资产乘上保值与失效两种状态，就是一张四象限表。

语言资产加保值这一格最大，里面装着你过去几年积累的绝大部分内容工作。

市场资产加失效这一格最痛，因为它涉及真金白银的合同和账户。

语言资产也有会失效的部分：提到具体市场的价格、时效、促销、案例。

市场资产也有能保值的部分：跟支付服务商的谈判经验、跟物流商的合作模板，这些能搬到新市场去。

四格填满之后，动作就浮出来了。

资产类型 | 保值的部分 | 会失效的部分 | 对应动作 | 

语言资产 | 关键词表、词形规则、常青正文、审校关系 | 价格、时效、促销、绑定单一国家的案例 | 保留主体，重写受影响的段落 | 

市场资产 | 供应商谈判经验、流程模板、客服话术骨架 | 支付通道、广告账户、物流合同、本地仓 | 迁移可搬的，冻结不可搬的 | 

技术资产 | 站点结构、模板、多语言配置能力 | 绑定单一地区的跳转与货币设定 | 把地区设定从语言设定里解耦 | 

填表时最容易漏掉一行：站外资产。外链、名录条目、社群账号、合作媒体，这些绑的是你的域名，域名不动这一行就保值。顺手还可以核一个数，各语言的网站占比统计 (https://w3techs.com/technologies/overview/content_language)里俄语的份额近年相当稳定——盘子没有变小，变的只是它在哪个国家结算。

## 四个格子对应四个动作，不是一个决定

保留、迁移、冻结、退出，这四个动作可以同时进行。

保留的是内容主体和语言层的处理规则。

迁移的是那些能改挂到邻近市场的配置：货币、支付、配送、地区标签。

冻结的是暂时无法运营但也不该删除的部分。

退出的是明确不再投入的部分：广告预算、本地仓续约、当地实体的维护。

把一个模糊的要不要做，拆成四个明确的动作清单，讨论就从立场之争变成了排期问题。

这一步的价值主要在组织层面。一个模糊的问题会让每个人按自己的角色给出不同答案，内容团队舍不得，财务想止损，法务只想合规，谁也说服不了谁。拆成四个动作之后，每个团队只对自己那一格负责，讨论时间能省下八成。

四个动作还有个执行顺序：先冻结，再迁移，最后才做退出。顺序反了会出现一种尴尬——本地实体已经注销，才发现某项配置的迁移必须由那个实体来操作。退出动作通常不可逆，放在最后是常识，可惜压力大的时候常识最先被跳过。

## 哪些资产在这种变化之后仍然保值？

## 关键词表和词形变体处理是最值钱的那一块

俄语关键词工作里最费时的部分不是找词，是处理词形。

一个名词六个格、加上单复数就是十二种形态，动词的变化更多。

把这些形态归并、去重、映射到同一个意图上，是一件既需要工具也需要判断的活。

这套规则一旦建好，它跟哪个国家没有任何关系。

哈萨克斯坦的俄语用户搜的是同样的词形变化，规则原样可用。

删掉俄语目录的团队，损失最大的其实就是这套没人记得它存在的规则。

词干处理这类工作还有现成的开源实现可以对照。俄语的词干提取算法 (https://snowballstem.org/algorithms/russian/stemmer.html)把后缀剥离的规则写得很细，团队自己的归并规则可以拿它当基线来核对。这类资产的特点是建的时候很慢，用的时候无感，丢的时候没人察觉——直到两年后要重建。

这套规则的正确性可以对照公开的标注体系来验。俄语的通用依存标注 (https://universaldependencies.org/ru/index.html)里对格、数、体的标注方式定义得很细，拿它核对自建的归并规则，能查出那些把派生后缀误当成格尾的错误，这类错误在自建规则里相当常见。

## 正文和用词选择的积累不会因为市场变化而作废

写过的正文里，绝大部分内容跟国家无关。

宠物食品的成分怎么看、猫砂的除臭原理、幼猫的喂食频率，这些内容在任何俄语市场都成立。

受影响的只有那些提到具体价格、具体配送时效、具体促销活动的段落。

按经验，这部分在一篇常青内容里通常不超过两成。

也就是说，一个内容库的八成价值是跨市场的。

为了那两成而删掉整个库，是这轮决策里最容易犯的错。

更划算的做法是把那两成隔离出来。把价格、时效、促销这类易变信息做成独立的模块或者变量，正文只引用不写死。这样以后任何市场层的变动，都只需要改配置而不需要动正文。这件事最好在平时就做，事到临头再改，工作量会翻好几倍。

还有一类内容是彻底跨市场的：品类知识本身。怎么挑猫砂、幼猫多久换一次粮，这类内容不但跨国家，还跨语言——它甚至可以反向复用到其他语言版本里去，只要重新过一遍本地审校。这部分内容的比例，直接决定了这次变化对你的实际杀伤力。

## 母语审校和本地作者的关系也是资产

找到一个靠谱的俄语审校不容易，磨合更花时间。

这层关系跟对方住在哪个国家关系不大，尤其在远程协作已经普及之后。

很多俄语审校本身就分布在多个国家，付款方式也各不相同。

需要处理的只是结算路径，而这属于市场层的问题，有多种解法。

断掉合作关系是最不划算的选择，因为重建成本远高于维持成本。

哪怕暂时没有内容要审，保持低频的联系也比彻底断掉强。

本地作者那一侧也一样。小语种站的本地作者署名与资质信号 (https://zhangwenbao.com/minor-language-eat-local-author-byline-credential-signals.html)那篇讲过，站外足迹和署名体系是要按年积累的东西，撤下来容易，再挂上去就得从头解释这个人是谁、为什么消失过一段时间。这类资产的脆弱之处在于它一半在你手上，一半在别人手上。

## 哪些资产会在几周之内失效？

## 支付通道是第一个断的，也是最硬的那一环

2022年3月，两家国际卡组织先后公开宣布暂停在俄罗斯的业务。

对跨境电商来说，这一条的影响是即时的：用国际卡结算的那条路直接不通了。

本地发行的卡在境内仍可使用，但跨境收单是另一回事。

支付一断，后面所有环节都失去意义，页面做得再好也收不到钱。

所以清点资产时，支付通道要放在第一位判断。

它不是可以慢慢想的事，它决定了这个市场当下能不能运营。

两家机构的公告都能在各自的投资者页面上查到原文，Visa关于暂停俄罗斯业务的公告 (https://investor.visa.com/news/news-details/2022/Visa-Suspends-All-Russia-Operations/default.aspx)和Mastercard的相应声明 (https://investor.mastercard.com/investor-news/investor-news-details/2022/Mastercard-Statement-on-Suspension-of-Russian-Operations/default.aspx)是这类判断最可靠的一手依据。做市场决策时引用一手公告而不是二手报道，这个习惯在信息噪音大的时期尤其值钱。

判断支付可不可行，别只问服务商能不能开通，还要问结算路径是否合规、资金能不能顺利回到主体账户。这两个问题的答案有时是分开的：通道开着，钱却卡在中间某一环，而这一环通常不写在你的合同里。

## 广告账户与投放数据一起归零

广告投放在同一时期陆续停摆。

直接损失是投不出去，间接损失是过去积累的投放数据失去参照价值。

受众包、转化数据、出价模型，这些东西的价值建立在市场结构稳定的前提上。

市场结构一变，历史数据不但没用，还可能误导判断。

自然搜索这一侧受到的直接冲击要小得多，这是它在动荡期的一个结构性优势。

页面还在、索引还在、排名还在，只是变现路径需要重新接。

这一点值得单独强调：付费渠道的资产绑在平台上，自然渠道的资产绑在你自己的域名上。平台政策一变，前者归零，后者只是暂时用不上。团队在做渠道结构规划时，通常只用获客成本来比较两者，很少把这条抗变化能力算进去，而它在几年一次的动荡里体现得非常清楚。

## 物流和退货链路会先于支付出问题

跨境物流的中断往往比支付更早显现，而且形态更复杂。

有的线路完全停运，有的时效从两周变成两个月，有的能发出去但退不回来。

退不回来这一条最麻烦，因为它把退货政策变成了一句空话。

而退货政策是页面上最重要的信任元素之一，写着支持退货却实际做不到，伤害比不写更大。

所以物流一旦不稳定，页面上的相关承诺必须同步修改。

这一步经常被漏掉，因为改政策页要走法务和运营两条流程。

页面承诺跟实际能力脱节的代价，小语种落地页的信任元素 (https://zhangwenbao.com/minor-language-landing-page-trust-signals-payment-address-support.html)那篇算过一次：承诺落空造成的差评和退款，远高于一开始就把承诺写窄带来的转化损失。市场条件突变时，这条原则的适用频率会突然变高，因为几乎所有承诺都需要重新核一遍。

退货这条链路还有个容易被忽略的分支：已经在路上的订单。变化发生时总有一批货处在中途，它们的处理方式要单独定，而且要提前写给客服。没有预案的中途订单，会在两周内变成一批高强度的差评。

## 域名、服务器与实体归属带来的连带风险

用国家顶级域名做的站，这时候会遇到一个尴尬：域名本身带着地域绑定。

它在搜索层面的地域信号是明确的，也就是说它很难改挂到别的市场去。

服务器位置、支付实体所在地、发票开具方，这些也都带着国别属性。

这一层的问题不是内容能不能用，而是这套配置在新的市场里合不合适。

通用顶级域加语言子目录的结构，在这种时候的灵活性明显更高。

这也是本轮变化给出的一条长期教训：域名结构的选择不只是SEO问题，还是风险结构问题。

国家顶级域的委派信息是公开可查的，俄语国家域名的委派数据 (https://www.iana.org/domains/root/db/xn--p1ai.html)能看到管理机构和政策链接。选域名结构时把这一层的归属看清楚，跟看SEO收益同样重要。子域名与子目录的取舍 (https://zhangwenbao.com/subdomain-vs-subdirectory-seo-link-equity-domain-authority-transfer-decision.html)那篇比较的是权重传递，这里要补的是另一条：可迁移性。

想看清一个国家顶级域的归属，查委派数据是最快的路径。该国顶级域的委派记录 (https://www.iana.org/domains/root/db/ru.html)里能看到管理机构和相关政策的入口。这一层信息在选域名的时候几乎没人查，真出事时却是第一个要确认的。

## 三档决策该怎么选？

## 全退、冻结保资产、改挂邻近市场

三个选项各有适用条件，没有一个是普遍正确的。

全退适合俄语收入占比极低、且法务风险敏感的公司，比如有政府采购业务的。

冻结保资产适合收入占比中等、内容库有相当积累的站。

改挂邻近市场适合流量分布本来就分散、且品类适合中亚或高加索市场的站。

多数团队最后会落在第二和第三档的组合上：冻结一个国家，同时把语言资产改挂到另外几个国家。

这个组合的好处是它保留了回头的可能，而回头的成本比重建低一个数量级。

下面这张表把三档的判据、动作和复检周期并排列出。填这张表的时候有一条纪律：每一档都必须写上复检日期，没有复检日期的决策会自动变成永久决策。很多站的俄语目录就是这么在无人认领的状态下荒掉的。

档位 | 适用条件 | 核心动作 | 保留什么 | 复检周期 | 

全退 | 收入占比极低、法务敏感 | 关停页面并做好跳转，注销本地实体 | 关键词表与正文备份 | 不复检 | 

冻结保资产 | 收入占比中等、内容库有积累 | 停更停投，保留URL与索引，关掉结账 | 页面、索引、外链、审校关系 | 每季度一次 | 

改挂邻近市场 | 流量分布分散、品类适配 | 拆地区标签、换货币与支付、改物流信息 | 全部语言资产并新增市场配置 | 每月看数据 | 

选档之前建议先看一眼这个市场的公开数据，别只盯着自己后台。该市场的数字生态年度报告 (https://datareportal.com/reports/digital-2022-russian-federation)里的网民规模、设备结构与平台使用情况能提供一个外部参照，判断自己看到的下滑是行业普遍现象还是自身问题。

## 四条判据，按顺序过一遍就有答案

第一条是收入占比：这块业务占总收入多少，低于一个阈值就不值得复杂处理。

第二条是支付通道：还有没有合规可用的收款路径，没有就只能冻结或改挂。

第三条是法务风险：所在行业和客户结构对这件事的敏感程度。

第四条是内容复用率：你的内容库里有多少比例能直接搬到别的俄语市场。

四条按顺序过，通常在第二条或第三条就能定档。

第四条的作用是决定改挂这一档划不划算。

内容复用率这个数字建议实测而不是估算：随机抽二十篇，逐篇标出需要改写的段落比例，取平均。多数站测出来在七到九成之间，比团队的直觉高不少——因为直觉总是被那几篇促销文章带偏。小语种的优先级与成本模型 (https://zhangwenbao.com/minor-language-seo-priority-language-cost-model.html)那篇里的成本分档，可以直接拿这个复用率当输入。

## 决策要写成带复检日期的文档，不能停在会议纪要里

这类决策最常见的下场是执行了一半，然后无人认领。

广告停了，页面没人管；结账关了，政策页还写着原来的话。

半年后来了个新人，看到一堆状态不明的页面，不知道该修还是该删。

所以文档里必须写清楚三件事：当前档位、每一项的负责人、下次复检的日期。

复检那天要看的指标也要事先写好，通常是流量、支付可用性、法规变化三项。

写下来不花时间，找不到人负责才花时间。

这份文档还有个附带用途：它是对内解释的最好材料。市场层面的决策容易引发内部分歧，一份写清楚判据和复检机制的文档，比任何一次会议都更能让人接受当前的选择——因为它明确表示了这不是永久判决。

文档还要留一份对外口径，给客服和销售用。他们每天都会被问到这件事，没有统一口径就会出现十个人十种说法，其中总有几种会传成谣言。三句话的标准回答，比一份三十页的内部文档更能减少麻烦。

## 为什么说冻结不等于删除？

## 删掉整个语言目录，等于把语言资产一起删了

决定不做了之后，最省事的动作看起来是把俄语目录整个删掉。

这个动作的破坏力比多数人预估的大。

页面删了，索引跟着掉；索引掉了，外链指向的目标就成了空页。

外链是最难重建的一类资产，它依赖别人的站，而别人不会因为你回来了就重新链一次。

同时消失的还有那些页面积累的历史数据：哪些词曾经排上去过、哪些页面被抓得频繁。

这些数据在恢复时是最有价值的路标，删掉之后只能从零开始猜。

更隐蔽的一层是站内的主题结构。俄语目录整块拿掉，剩下的语言版本之间的内链和标签关系也会被打断，有些页面会因此变成孤岛。删除从来不是一个局部动作，它会顺着链接关系扩散出去，而扩散的范围往往在删完几周后才通过抓取报告显现。

如果确实必须下线某些页面，也有比直接删更稳的做法：把它们跳转到同语言的上级目录或者一个说明页，而不是让它们变成空页。跳转能把外链的价值接住一部分，也不会让点进来的用户直接撞上一堵墙。

## 冻结的具体动作清单

冻结不是什么都不做，它有一套明确的动作。

停止内容更新，停止付费投放，这两条最容易执行。

保留URL、保留索引、保留内链结构，这三条是冻结的核心，也是跟删除的分水岭。

把结账功能关掉，换成询盘表单或者到货通知登记，这样页面还能继续积累意向。

页面顶部加一条状态说明，写清楚当前不接受订单以及大致的原因，用词中性。

政策页里所有做不到的承诺同步改掉，这一步不能省。

状态说明这一条经常被写得含糊。合适的写法是只陈述事实：当前该地区暂不支持配送与结算，可留下邮箱在恢复时收到通知。不解释、不表态、不承诺时间。用户要的是知道现在能不能买，不是一段说明，而含糊的措辞只会带来更多客服工单。

还有一条常被忘记的动作：把定时任务和自动化流程一起停掉。自动改价、自动补货提醒、按计划发出的营销邮件，这些东西在冻结之后还在跑，会持续向用户发送跟当前状态矛盾的信息。它们不在页面上，所以检查清单里要单独列一行。

## 恢复时的成本对比，能把冻结的价值算清楚

假设两年后条件恢复，两条路径的成本差别很大。

走冻结路径：更新政策页、重开结账、恢复更新，几周就能回到线上。

走删除路径：重新建站、重写内容、重新被抓取、重新积累外链，按年计算。

更重要的是排名恢复的速度，冻结过的页面通常还有历史信号可依，全新页面没有。

冻结的维护成本几乎为零，无非是服务器和域名的续费。

用几年的域名费换掉一次按年计算的重建，这笔账在任何折现率下都算得过来。

唯一需要警惕的是冻结变成遗忘。所以前面那条纪律要重复一遍：写复检日期，指定负责人。一个冻结了三年、没人看过一眼的目录，最后往往会变成安全隐患或者被误删——它的价值只有在有人记得它存在的前提下才成立。

还有个数字值得记下来：冻结期间页面的抓取频率会下降，但通常不会归零。这意味着恢复更新之后，重新被频繁抓取的速度比全新站点快得多。这条差别在恢复期的头两个月体现得最明显，也是冻结优于删除最直接的证据。

## 改挂邻近市场，具体要动哪些字段？

## 语言标签从绑死一个地区，拆成多个地区

这是改挂动作里最基础的一步。

过去俄语版本通常只配一个地区标签，因为流量确实集中在一个国家。

现在要拆成多个：哈萨克斯坦、乌兹别克斯坦、白俄罗斯、亚美尼亚，按你的实际流量来。

拆之后要处理的是页面对应关系：是给每个地区做独立页面，还是共用一套页面配多个标签。

多数情况下共用一套更合适，因为内容差异不足以支撑独立页面。

只有价格、配送、税费这些确实不同的地方，才需要按地区分流。

这里有一条现成的判据可以用：语言与地区标签的完整配法 (https://zhangwenbao.com/international-seo-hreflang-complete-guide.html)那篇讲过同语言多地区的处理，核心是问内容差异有没有大到值得两套URL。俄语这几个市场的答案通常是不值得，共用一套页面加多组标签，再把差异部分做成动态模块，是成本最低的形态。

拆标签时有个常见错误：只顾着加新地区，却没留一个不指定地区的兜底版本。俄语使用者分布在十几个国家，你不可能给每一个都配一条，兜底那一条正是用来接住剩下所有国家的。

## 货币、价格和支付方式要整组换

货币不只是显示单位，它牵着价格策略、税费计算和支付通道。

中亚各国有各自的货币和主流支付方式，跟原市场的配置几乎没有重叠。

有些市场美元定价的接受度更高，有些则相反，这需要单独判断。

结账页上的支付方式排列也要跟着换，把本地主流方式放前面。

这一整组配置在结构化数据里也有对应字段，价格与货币要成对出现。

页面上写一套、标记里写另一套，是改挂过程中很常见的遗漏。

标记里的价格货币这个字段 (https://schema.org/priceCurrency)要求用标准的三字母货币代码，改市场时它和价格数值必须一起改。这类字段的问题在于它不显示在页面上，改漏了没人会发现，直到某一天发现结果里显示的价格是旧货币。

定价这一步还有个容易忽略的判断：新市场的价格锚点跟原市场不一样。同一款猫砂在两个国家的心理价位可能差出四成，直接按汇率换算过去会显得离谱。换市场时价格要重新做一次调研，而不是做一次换算。

## 地址、物流与法务信息要重做一遍

地址字段结构按国家不同，中亚几国跟原市场并不完全一致。

配送时效、可达区域、自提点，这些要按新的物流方案重写。

法务信息里的经营者主体、发票类型、消费者权利条款，都要按新市场的规则核一遍。

这一层的工作量常被低估，因为它看起来只是改几行字。

实际上每一行字背后都要有人去确认当地的规则是什么。

把这部分排进两周而不是两天，才是现实的估计。

下面这张表是保哥用过的改挂动作清单，左边是原来绑死在一个国家上的配置，右边是改挂后的形态。表的用法是逐行打勾，凡是打不上勾的行就是还没做完的活。

字段 | 原来的形态 | 改挂后的形态 | 归属层 | 

语言与地区标签 | 单一地区 | 一门语言配多个地区 | 架构层 | 

货币与价格 | 单一货币写死 | 按地区取值，与标记同步 | 市场层 | 

支付方式 | 原市场主流方式 | 按国家重排，本地方式在前 | 市场层 | 

地址表单 | 一套字段通用 | 按国家切换字段集合 | 市场层 | 

配送与退货 | 单一方案 | 按国家分方案，承诺写实 | 市场层 | 

关键词表 | 合并成一份 | 主体共用，高频词按国家微调 | 语言层 | 

正文 | 含写死的价格与时效 | 易变信息抽成模块 | 语言层 | 

确认规则时有个省事的入口：找一家目标国的本地头部电商，把它的政策页和结账流程完整走一遍。它已经替你把当地规则翻译成了具体做法，比啃法规条文快得多，也不容易漏掉那些写在条文之外的行业惯例。

## 引擎层要重新算一次账

俄语市场的引擎结构在不同国家差别很大。

本地引擎在原市场的份额很高，在中亚几国就没有那么高。

这意味着改挂之后，优化重心可能需要从一个引擎转向另一个。

好消息是语言层的工作对两个引擎都有效，词形处理、内容质量、结构清晰这些是通用的。

需要单独做的是提交、验证、站长工具这些引擎特有的配置。

本地引擎的自有服务生态也在这两年发生了调整，部分产品线易主，这一层要按当前状态重新确认。

引擎这半边的具体做法不在本文范围内。本地引擎的完整实战指南 (https://zhangwenbao.com/yandex-seo-russia-cis-complete-guide.html)那篇讲的是引擎特有的排名机制与工具配置，本文只负责说清楚一件事：引擎份额是按国家算的，不是按语言算的，改挂国家就必须重算一次这个比例。

重新算的时候要注意口径：引擎份额的统计通常按设备和地区分开，移动端和桌面端的差距在这几个市场里不小。拿一个笼统的全国份额去做预算分配，往往会高估桌面端那一侧。

## 独联体各市场的俄语用法完全一样吗？

## 同一门语言在不同国家的用词是有差别的

俄语在各国的书面标准高度一致，这是它跟西班牙语、葡萄牙语的不同之处。

但用词层面的差别确实存在，主要集中在日常生活领域。

本地机构名称、行政区划、货币单位、常见服务的叫法，这些在各国不一样。

还有一类是借词：各国从本国主体语言里借入的词，本地俄语使用者会直接用。

这些词不会影响理解，但会影响检索匹配，因为用户搜的就是本地那个说法。

处理办法跟其他多市场语言一样：主体词表共用，本地词单独收一小份。

差别的规模比想象中小，这是好消息。同样是一门跨国语言，西班牙语在两岸的分歧要大得多，西语在西班牙与拉美的词表分叉 (https://zhangwenbao.com/spanish-seo-es-es-latam-keyword-divergence.html)那篇里那种同一个商品叫两个名字的情况，在俄语各市场之间少见得多。所以改挂俄语内容的语言成本，比改挂西语低一个量级。

## 双语市场里，俄语和本国语言怎么分工

哈萨克斯坦、白俄罗斯这类市场是典型的双语环境。

用户在哪种语言下检索，跟内容类型、年龄层、地区有关。

通用做法是先用俄语覆盖，再按数据决定要不要补本国语言版本。

这个顺序的依据是俄语的覆盖面更广，起步成本更低。

但要注意本国语言的官方地位在提升，长期看这个比例会变。

所以决策文档里也该给这一项写一个复检日期。

双语市场的内容分工有成套的框架可用。双语市场里两套内容怎么切 (https://zhangwenbao.com/ukrainian-russian-seo-bilingual-market-content-split.html)那篇讲的正是这个问题：两种语言都看得懂的用户，你的站却只能有一套URL结构。那篇的判据在这几个中亚市场同样适用，只是两种语言的力量对比不同。

判断当前该主推哪种语言，有个免费的入口：看本地搜索建议的语言分布。同一个品类词分别用两种语言打进去，比较下拉里跟出的词条数量和具体程度，两种语言的活跃度差别一眼可见，不需要任何付费工具。

## 别把本国语言和俄语当成同一件事的两个版本

哈萨克语属于突厥语族，跟俄语在结构上没有亲缘关系。

它的构词方式是后缀层层叠加，跟俄语的格变化是两套完全不同的机制。

这意味着关键词处理规则不能复用，词形归并要重新做一套。

把这两种语言当成一件事的两个翻译版本，是排期估算失准的典型原因。

正确的估算方式是把它当成一门新语言来算成本。

它跟土耳其语的亲缘关系反而更近，那一套后缀处理经验可以借鉴。

这条经验可以直接复用：黏着语里后缀怎么层层叠加 (https://zhangwenbao.com/turkish-seo-agglutinative-suffix-stacking-keyword.html)那篇讲的处理方式，对同语族的语言基本适用。判断两门语言的关键词规则能不能复用，看的是构词机制而不是地理位置——这跟前面讲书写系统簇时用的是同一种思路。

顺便说一个排期经验：新增一门语族不同的语言，第一批内容的产出速度大约是同语族语言的一半。原因不是翻译更慢，是词形规则、审校标准、验收清单全部要重建一遍，而这些工作在同语族之间本来是可以复用的。

## 内容本身要不要跟着改？

## 提到具体市场的那些段落需要重写

内容库里真正需要动的是三类段落。

第一类是明确提到某个国家的市场描述，比如本地用户习惯、当地法规、本地节庆。

第二类是绑定具体渠道的操作指引，比如某个本地平台的使用步骤。

第三类是案例，尤其是带着具体品牌和具体数字的那种。

这三类加起来通常占内容库的一到两成，逐篇标记之后可以按优先级分批重写。

剩下的八九成一个字都不用改，这是前面说的内容复用率的具体来源。

标记的方法很土但有效：在内容管理系统里加一个字段，标出这篇是通用还是绑定某市场。这个字段在平时几乎没用，在需要批量判断的时候能省下几周。给内容打上归属标签，属于那种平时看不出价值、关键时刻决定反应速度的基础工作，跟前面讲的语言与国家字段分离是同一类。

## 价格、时效和案例这三类最容易过期

价格过期最快，因为汇率波动本身就会让它失真。

时效次之，物流方案一变，页面上的三到五个工作日就成了假信息。

案例过期得最隐蔽，因为它读起来仍然通顺，只是背景条件已经不成立了。

过期的案例比过期的价格更伤，因为它让整篇内容的可信度打折。

处理办法是给案例加上时间标注，让读者知道这是哪一年的情况。

标注比删除好，因为一个标明年份的旧案例仍然有参考价值。

汇率这一条还有个技术性的解法：价格用变量而不是写死，货币代码和数值分开存储。区域数据标记语言的通用规范 (https://www.unicode.org/reports/tr35/tr35-general.html)里对货币、数字格式、地区标识的定义可以直接当实现依据，多语言站按它设计一次，以后换市场就只是改配置。

案例标年份还有个额外好处：它让内容显得更诚实。读者看到标着年份的案例，不会觉得你在假装它是最新的；看到一个没有年份、背景又明显过时的案例，反而会开始怀疑整篇的时效性。标注年份是成本最低的一种可信度维护。

## 常青内容的比例决定了冻结的成本

常青内容比例高的站，冻结成本极低，因为内容放在那里不会腐坏。

以促销和时效性内容为主的站则相反，冻结几个月之后整站就显得陈旧。

所以在决定冻结之前，先算一下这个比例。

算法很简单：内容库里超过一年不需要更新仍然准确的那部分，就是常青部分。

比例低于一半的站，冻结期间至少要保留最低限度的维护。

最低限度通常是每季度更新一次核心页面的时效信息，工作量按天算。

这个比例还有个更长远的含义：它衡量的是内容资产的抗变化能力。常青比例高的站在任何一次市场动荡里都更从容，这跟内容质量本身无关，跟选题结构有关。选题里留出足够比例的原理型、方法型内容，本质上是在给内容库买一份保险。

算这个比例还有个副产品：它会暴露内容结构的失衡。如果一个站的常青内容不到三成，那就不只是冻结成本高的问题——平时的内容维护成本一定也很高，只是那部分成本被摊在每个月里，看不出来。

## 这套框架能复用到别的突发变化上吗？

## 判据只有一条：这次变化改的是语言层还是市场层

汇率剧烈波动，改的是市场层，语言资产完全不受影响。

某个国家出台新的数据本地化法规，改的是市场层和技术层。

某个平台调整内容政策，改的是渠道层，跟语言和市场都不完全重合。

只有一种情况会真正伤到语言资产：这门语言的使用者本身在大规模减少或转移。

这种情况极其罕见，而且以十年计发生，不会在一个季度里发生。

所以绝大多数突发变化冲击的都是市场层，而市场层是可以改挂的。

这条判据的实用价值在于它能立刻缩小讨论范围。听到某个市场出事，第一反应不该是要不要撤，而是先问这件事改的是哪一层。改市场层的，动配置；改语言层的，才动内容。这一问能挡掉大部分情绪化的决策提案。

还有一类边界情况：某个国家出台内容或数据方面的新规，看起来像内容层的事，其实改的仍是市场层，因为它约束的是你能不能在那里运营，而不是这门语言该怎么写。分辨方法是问一句：这条规矩换个国家还成立吗。

## 汇率、法规、平台政策三类变化各归哪一格

汇率类变化归市场层，动作是重定价和调整支付方式，内容基本不动。

法规类变化归市场层与法务层，动作是改政策页、改数据存储、必要时改主体结构。

平台政策类变化归渠道层，动作是重新分配渠道预算，同时提醒自己自然渠道的价值。

三类都有一个共同点：受影响的都不是你写的那些字。

这个共同点值得反复强调，因为内容团队在这类事件里最容易被误伤。

把内容砍掉是最快能看到的止损动作，也是最贵的那个。

土耳其市场在这几年经历的汇率波动是个好对照：定价和支付方式改了好几轮，土耳其语的关键词表和内容库一个字没动。土耳其语的后缀处理规则 (https://zhangwenbao.com/turkish-seo-agglutinative-suffix-stacking-keyword.html)那套东西建好之后，在汇率涨跌之间稳如磐石——因为它约束的是语法，而语法不看汇率。

判断一次汇率波动算不算需要重定价，可以看一个更慢的指标。该国的宏观经济数据 (https://data.worldbank.org/country/russian-federation)里的人均收入与通胀走势比汇率本身更能说明购买力的真实变化，短期跳动多半不必动价格，趋势性的变化才需要。

## 事前该准备的其实只有三件事

第一件是数据结构：语言和国家在所有报表里是两个独立字段。

第二件是内容结构：价格、时效、促销这类易变信息抽成模块，不写死在正文里。

第三件是站点结构：域名与目录的设计留出改挂的余地，别把地区绑死在域名上。

三件事在平稳期做，成本几乎为零。

在动荡期做，成本是几周的加班加上一次次的返工。

它们的共同特征是平时看不出收益，只在需要转向的那一刻兑现。

如果只能做一件，选第一件。语言和国家分成两个字段，是所有后续判断的前提——没有这一步，你连自己的俄语流量有多少来自别的国家都不知道，更谈不上决定哪一部分留下。这件事改起来通常只是配置层面的调整，却是本文所有建议里投入产出比最高的一条。

## 常见问题解答

## 俄语这块流量到底还值不值得做？

这个问题要拆成两问才能回答。第一问是俄语内容还值不值得留，答案基本是值得，因为俄语的使用者分布在十几个国家，语言层的资产跨境有效。第二问是某个具体国家的市场还要不要运营，这取决于支付通道、法务风险和收入占比，因人而异。把两问合并成一个要不要做，就只能在全砍和不动之间二选一，而最优解通常在中间。

## 直接把俄语目录删掉，是不是最省事？

省事但很贵。删掉会同时损失索引、外链指向、历史排名信号和站内主题结构，而这几样都是按年积累的。冻结的维护成本几乎只有域名和服务器续费，恢复时几周就能回到线上；删除之后重建要按年计算，而且外链几乎没法找回来。除非法务上要求必须下线，否则冻结优于删除，代价差着一个数量级。

## 冻结之后页面上该写什么？

只写事实，用词中性。写清楚当前该地区暂不支持配送与结算，提供一个留邮箱等通知的入口，不解释原因、不承诺恢复时间。同时把政策页里做不到的承诺全部改掉，尤其是退货相关的条款。含糊的措辞不会让用户少问，只会带来更多客服工单，而这些工单没有一个是能带来订单的。

## 改挂到中亚市场，内容要重写多少？

实测通常在一到两成。需要动的是三类段落：明确提到某个国家的市场描述、绑定具体本地渠道的操作指引、带着具体品牌和数字的案例。其余八九成的内容跟国家无关，一个字都不用改。建议随机抽二十篇逐篇标记算个平均值，这个数字比团队的直觉要高，因为直觉总是被那几篇促销文章带偏。

## 俄语和哈萨克语的关键词工作能共用吗？

不能。哈萨克语属于突厥语族，构词方式是后缀层层叠加，跟俄语的格变化是两套完全不同的机制，词形归并规则要重做一套。把它当成俄语内容的另一个翻译版本来估算工期，几乎必然失准。正确做法是按一门新语言算成本，同时可以借鉴同语族语言的后缀处理经验，那部分反而是通用的。

## 本地引擎那一侧要不要继续投入？

看你改挂到哪些国家。引擎份额是按国家算的，不是按语言算的，同样是俄语内容，在不同国家面对的引擎结构差别很大。语言层的工作对哪个引擎都有效，需要单独做的只是提交、验证、站长工具这些引擎特有的配置。改挂之后第一件事就是重新算一次目标国家的引擎份额，再决定这部分预算怎么分。

## 下一次别的市场出事，怎么才能反应更快？

提前做三件事：报表里语言和国家分成两个独立字段；价格、时效、促销这类易变信息抽成模块不写死在正文；域名与目录结构留出改挂余地。这三件事在平稳期做几乎不花成本，在动荡期做要付几周加班加上返工。如果只能做一件，做第一件，因为没有它你连自己的流量分布都看不清楚。

## 权威参考资料



## 小语种内容写的外国是谁？30门里21门第一名是美国，可份额只有一成五

- URL：https://zhangwenbao.com/minor-language-content-foreign-reference-country.html
- 分类：小语种SEO
- 发布：2022-10-13  |  更新：2022-10-13
- 摘要：30门语言外部指向实测：剔除名录型条目后21门第一名是美国但份额仅15%到23%，老挝语指向泰国38%、尼泊尔语指向印度29%才是真正的参照国。
- 关键词：竞品分析,多语言SEO,内容运营,小语种SEO

> **TLDR**：摘要：三十门语言各抽两百二十条公共内容，把判定为外国的那一堆按国别数一遍，看这门语言的读者心里的外部世界是谁。第一版结果是乌兹别克语指向美国、越南语指向法国、缅甸语指向日本，打开一看全是美国小镇、法国市镇、日本火车站——机器导进来的地名表。剔掉这类名录之后重算，三十门里有二十一门第一名是美国，但份额只有15% 到23%，那不是参照国，那是全球背景板。真正有参照国的是老挝语指向泰国38%、尼泊尔语指向印度29% 这几门。判读看份额不看名次。

> 摘要：三十门语言各抽两百二十条公共内容，把判定为外国的那一堆按国别数一遍，看这门语言的读者心里的外部世界是谁。第一版结果是乌兹别克语指向美国、越南语指向法国、缅甸语指向日本，打开一看全是美国小镇、法国市镇、日本火车站——机器导进来的地名表。剔掉这类名录之后重算，三十门里有二十一门第一名是美国，但份额只有15% 到23%，那不是参照国，那是全球背景板。真正有参照国的是老挝语指向泰国38%、尼泊尔语指向印度29% 这几门。判读看份额不看名次。

## 你写的案例都拿美国举例，这门语言的读者心里的外国是美国吗？

## 默认参照系是从哪儿来的

做出海内容的人有一个共同的默认设置：讲到“国外”的时候，脑子里浮出来的是美国。价格拿美元换算，竞品拿美国品牌，案例拿硅谷公司。

这个默认不是谁定的，是英语内容生态长期训练出来的。你读的资料是英语的，你参考的案例是英语的，写小语种内容的时候顺手就带过去了。

但读你内容的那个人不是在英语生态里长大的。他心里的“外国”是哪个国家，取决于他这一辈子读到的内容里外国是谁。

这个默认设置很难自查，因为它不表现为一个决定，而表现为一次都没被讨论过。写稿的人顺手举了个例子，审稿的人觉得没问题，译者照着翻了，谁都没停下来问一句这个例子对不对。

更隐蔽的是它会自我加强。你的英文站积累了一批以美国为参照的内容，翻译的时候整批平移过去，于是这门语言下你所有的页面共享同一套参照物，读者感受到的是一致的疏离感。

顺带说一句，这个问题不只出现在跨语言的场合。同一门语言里做不同地区的内容，也会带着总部那边的参照系过去，只是没有跨语言时那么刺眼。

本站上一篇量的是这门语言的内容里有多少写的是本地的事 (https://zhangwenbao.com/minor-language-content-local-topic-share.html)，这一篇接着量剩下那部分写的是哪儿。

## 这件事能量出来

一门语言的公共内容池子里，凡是讲外国的那部分，讲的是哪几个国家，是可以逐条数出来的。数完之后你就拿到了这门语言的参照系。

这个数不是民调，不是问“你最关注哪个国家”，而是直接看这门语言实际写下来的东西。写出来的比说出来的可靠。

方法跟上一篇是同一套，一次采集两列：那一篇取的是本地占多少，这一篇取的是外部那部分的国别分布。

量的对象是公共内容而不是商业内容，这一点要先讲明白。它反映的是这门语言的读者长期读到的知识背景，不是他们买东西时的比价对象。前者影响的是代入感，后者影响的是决策，两件事都重要但不是一回事。

好处是这个数可以回到任意一个历史时点，也可以横向比三十门语言。你自己的品类没法这么比，因为没有哪个工具会给你按语言拆开的题材构成。

我把三十门语言各抽了两百二十条，时点截到2022年6月底，判定每条讲的是哪个国家。这一篇用的是判为外国的那一堆。

跟内容里有多少是从别的语言搬来的 (https://zhangwenbao.com/minor-language-content-translated-share.html)那次一样，一次采集两列，方法完全共用。

## 为什么这个数值得单独看一次

因为它改的东西很具体：案例举谁、对比表放谁、价格拿哪儿当基准、外链引哪家机构。这四处只要错了参照国，读者的第一反应就是这篇不是给我写的。

而且这四处的修改成本几乎为零，就是换一批名字，不需要重写。收益却是整篇内容的代入感。

还有一个不那么直接但影响更大的地方：写作时的默认知识背景。你假设读者知道某个国家的什么事，这个假设错了，整段解释就得从头讲，或者干脆讲不通。

举个具体的：讲物流时效的时候拿本地读者熟悉的邻国当参照，一句话就说清了；拿一个他没概念的国家当参照，你得先解释那个国家有多大、快递一般几天，读者读到第三句就走了。

## 本文谈什么、不谈什么

谈的是内容池子里外国那部分的国别构成，以及它对内容写法的影响。不谈用户实际住在哪个国家，那是市场资产的问题；也不谈同一门语言在不同国家的用词差别，那是语言层的问题。

一句话划界：这里问的是这门语言在写谁，不是这门语言在被谁读。

另外不谈的还有一项：这门语言的读者对某个国家的态度是好是坏。数据只能告诉你写了多少，告诉不了写的是褒是贬。做内容的时候用的是熟悉度这一层，不是好感度那一层。

还有一句要说在前面：这份数只能告诉你方向，给不了精确值。看到16% 和18% 的差别不用当回事，看到8% 和38% 的差别才该动作。

读者散在哪几个国家是另一条线，西班牙语那一门跨二十个国家 (https://zhangwenbao.com/spanish-seo-es-es-latam-keyword-divergence.html)那篇算的是那笔账。

## “外部指向”这个数怎么算，分母是哪些条目？

## 先把三类条目分开

把抽到的条目按国别分成三堆：判定为这门语言主要使用国的，判定为别的国家的，还有判不出国别的。第三堆里有日期页、年份页、生物分类、数学概念这些本来就没有国别的东西。

这一篇只用第二堆。分母是判定为外国的全部条目，分子是其中指向某一个具体国家的条目数。分母不含本地那一堆，也不含判不出的那一堆。

为什么不把本地那堆算进分母：因为要回答的问题是“往外看的时候看的是谁”，本地那部分是“往内看”，混进来只会把所有语言的第一名都变成它自己。

分成三堆之后还有一个用法：三堆的比例本身能说明这门语言的内容结构。本地那堆厚说明社群在写自己的事，判不出那堆厚说明这门语言在结构化数据这一层被照顾得少。

这一篇只用中间那一堆，但看数的时候三个数一起摆着更容易发现异常。某门语言的外部堆特别大而本地堆特别小，多半是被灌了什么东西。

三堆的比例在三十门语言之间差得很大。判得出国别的从三成到八成，剩下那部分是日期页、年份页、生物分类单元、数学概念这类本来就没国别的东西。

判不出国别的那一堆里有一部分是数据缺失，这一点在上一篇 (https://zhangwenbao.com/minor-language-content-local-topic-share.html)里有完整的偏差自查。

判国别用的是数据项上的国家属性 (https://www.wikidata.org/wiki/Property:P17)与国籍属性 (https://www.wikidata.org/wiki/Property:P27)，前者管地点机构作品，后者管人物。

## 多国语言怎么算本地

有几门语言不止一个主要使用国。斯瓦希里语在坦桑尼亚、肯尼亚、乌干达、刚果东部都用；泰米尔语在印度、斯里兰卡、新加坡、马来西亚都用；豪萨语跨尼日利亚和尼日尔。

这些语言的本地国是一组而不是一个，命中任何一个都算本地。这么算会让它们的外部指向偏少一点，但反过来算会更糟——把肯尼亚算成斯瓦希里语的“外国”显然不对。

做对照的几门大语言同理：德语算德国、奥地利、瑞士，荷兰语算荷兰和比利时，英语算六个主要英语国家。

还有一类边界情况是历史上的同一个地方今天分成了几个国家，或者反过来。这类我按今天的行政归属处理，能对上一个国家的就并进去，跨多国的单列。

这套处理会引入一点主观性，所以我把并了哪些、单列了哪些都写出来了。你如果不同意某一条，把它挪到另一边重算，多数语言的结论不会变。

英语这一门我算了六个国家：英国、美国、澳大利亚、加拿大、爱尔兰、新西兰。范围比谁都宽，所以它的外部那一堆是全表最小的之一。

一门语言在哪几个地区被使用，可以查语言与地区的对照表 (https://unicode.org/cldr/charts/46/supplemental/territory_language_information.html)，里面连各地区的使用人口比例都有。

## 集中度用第一名的份额，不用信息熵

第一名占外部条目的比例，就是这门语言往外看时的集中度。这个数越高，说明这门语言眼里的“外面”越是某一个具体的国家。

本来想用信息熵，算完发现它对长尾里的小国太敏感，两门语言熵差不多但第一名完全不同的情况经常出现。改用第一名份额之后，读数跟实际翻条目看到的感受一致得多。

这不是说熵没用，是说这里要回答的问题是“有没有一个压倒性的参照国”，第一名份额直接就是这个问题的答案。

换尺子这件事在这个项目上已经发生过好几次了，规律是一样的：一把尺子在个别样本上给出明显反常的读数，多半不是那几个样本特殊，是这把尺子测的不是你想要的东西。

第一名份额还有个实际好处：它能直接翻译成动作。份额高就用它，份额低就别硬挑，中间那一档看品类。信息熵给不出这种直接的对应。

还有一个更简单的替代方案是前三名合计占比，我也算了，跟第一名份额的排序几乎一致，就没单独报。

## 样本量决定了能说到多细

每门语言抽220条，判得出国别的通常在八十到一百三十条之间，其中外部的又只占一部分。这个量足够看出第一名是谁，不足以给第七名排序。

所以文章里只报每门语言的前三名和第一名的份额，长尾不展开。看到某个数字很小的时候，先想一下它背后可能只有两三条。

缅甸语只剩二十一条这件事本身也是信息：它57% 的内容是名录型，剔完之后能用的部分很薄。一门语言的样本在剔名录之后掉得越狠，说明它的内容池子越虚。

抽样走的是页面属性接口 (https://www.mediawiki.org/wiki/API:Pageprops)，一次问五十个页面编号，只留正文命名空间且有数据项的。

## 第一版算出来的第一名，为什么全是假的？

## 三个说得通的结论

按上面的方法把三十门语言跑完，第一版结果是这样的：乌兹别克语指向美国，越南语指向法国，缅甸语指向日本，马其顿语指向德国。

每一条我都能当场编出一套解释。乌兹别克斯坦有大量劳务移民，越南和法国有殖民史，缅甸和日本历史往来密切，马其顿有大批劳工在德国。

听起来都很顺。这正是最危险的地方——一个结论如果每一条都能解释得通，你就该怀疑自己量的根本不是那个东西。

这种时候最容易犯的错是先写结论再找证据。四条解释都成立，随便挑一条写进文章，读者也挑不出毛病，因为它跟常识完全吻合。

拦住我的其实是第四条：马其顿语指向德国17%，这个数比它指向邻国希腊的还高，跟我在巴尔干那几个市场的实际观感对不上。一处对不上，就得把四处都翻一遍。

这件事之前在这个项目上发生过：一个算出来的方向刚好符合预期，回头一查是口径错了。所以现在的习惯是，越顺的结论越要打开原始记录看。

这跟品类词缺口那次的滞后天数 (https://zhangwenbao.com/minor-language-content-gap-category-words.html)是同一种翻车方式：算出来的方向刚好符合直觉，实际上口径就是错的。

## 打开条目看一眼

乌兹别克语那批判为美国的条目，标题是Donaldson（阿肯色州）、Ekwok（阿拉斯加州）、Remerton（佐治亚州）这类小镇，一水儿的美国乡村。

越南语那批判为法国的，是清一色的法国市镇：Fixem、Jonage、Caligny、Truttemer-le-Grand。缅甸语那批判为日本的，是日本的火车站和町村。

没有哪个乌兹别克读者关心阿肯色州的Donaldson有多少人口。这些条目是从一份现成的行政区划表里一行一条导进来的。

这一步只花了十分钟。把每门语言判为第一名的条目按标题列出来，扫一眼就看出来了——同一种命名格式重复几十遍，那不是人写的。

顺带一提，这个检查对任何一份看起来很整齐的统计都适用：把最集中的那一格里的原始记录打印二十条出来看，比多跑三个模型有用。

## 标题连翻译都没做

还有一个特征把这件事钉死了：这些条目的标题是拉丁字母原样写的，乌兹别克语版直接写着Saint-Étienne-sur-Usson，一个西里尔字母都没有。

连搬运的人都没打算让本地读者读它。它存在的意义是把页面总数推上去，不是给谁看的。

所以第一版量到的不是这门语言在看哪个国家，是哪个国家的表格被跑过一遍。尺子测的东西跟我想测的完全不是一回事。

这个特征还能反过来当筛子用。做竞品内容盘点的时候，如果对手站上一批页面的标题保留着源语言的写法，那批页面多半也是批量生成的，不用当成真正的竞争内容。

判断成本几乎为零：看标题里有没有本地文字。非拉丁文字的语言尤其明显，一眼就能分出来。

## 这类内容有多少

把能从名录成批生成的类型挑出来单独算，占比高得吓人。越南语的样本里76% 是这一类，其中光生物分类单元就有一百三十七条；瑞典语68%、荷兰语67%，也是物种。

约鲁巴语最极端：两百二十条样本里九十七条是编号小行星，占44%。这门语言的公共内容里将近一半是小行星。

另一头，豪萨语只有7%、高棉语9%、蒙古语11%、孟加拉语12%。这几门语言的内容基本是人一条条写出来的。

这个占比跟内容规模是正相关的，取对数之后相关系数 +0.476。也就是说规模越大的语言，名录型的比例越高，多出来的那部分里程序跑出来的占比更大。

所以一个反直觉的推论是：一门语言的内容总量越大，那个数字里的水分往往也越大。按内容量排出来的语言优先级，前几名最需要打折。

名录型这个概念是我为了这次分析定的，不是现成标准。清单包括行政区划与聚落、铁路车站、生物分类单元、天体、河流湖泊山岛、年份与日期、消歧义页和列表页。

这批页面还有一个可验证的特征：随机翻开一页几乎没有人读 (https://zhangwenbao.com/minor-language-page-reader-median.html)。

各语言版本的规模可以对照公开的规模清单 (https://meta.wikimedia.org/wiki/List_of_Wikipedias)，名录型占比跟规模是正相关的。

## 所以这一步不能省

剔掉名录型之后重算，三十门语言里有八门的第一名换了：越南语从法国换成美国，缅甸语从日本换成美国，阿塞拜疆语从伊朗换成苏联，马其顿语从德国换成意大利，还有立陶宛语、阿尔巴尼亚语、荷兰语和英语。

八分之三十，四分之一强。如果直接用第一版的数去改案例和对比表，这四分之一的语言会被改到反方向。

这一步的成本只是把条目按类型分个层，不需要重新采集，也不改变原始数据。

还有一层：不剔名录的话，同一门语言在不同年份的读数也没法比。今年跑一遍某个地名表，这门语言的参照国就换一个，而那跟读者没有任何关系。

剔完之后这个数才是稳定的，因为人写内容的构成不会因为某次批量导入而突变。

换掉第一名的那八门是：越南语、缅甸语、阿塞拜疆语、马其顿语、立陶宛语、阿尔巴尼亚语、荷兰语、英语。占三十门的四分之一强。

顺带一提，访问量里有一大半不是人 (https://zhangwenbao.com/minor-language-crawler-share-traffic-report.html)是同一个问题的流量侧版本，两边都得先把机器挑出去。

## 剔掉名录之后，第一名是谁？

## 二十一门指向同一个国家

结果跟我开工前的预期正好相反。我原本以为多数小语种的第一参照国会是邻国，实测下来三十门语言里有二十一门的第一名是美国。

泰语、德语、波斯语、蒙古语、印尼语、波兰语、孟加拉语、僧伽罗语、缅甸语、约鲁巴语、格鲁吉亚语、冰岛语、阿姆哈拉语、瑞典语、越南语、乌兹别克语、荷兰语、立陶宛语、斯瓦希里语、阿尔巴尼亚语、泰米尔语，全在这一列。

预期错得很彻底，但错的方式有意思：不是错在方向，是错在我以为这个数会因语言而异，实际上它对大多数语言是同一个答案。

这个结果对做内容的人其实是个好消息：多数情况下你的默认设置不算错，至少不算离谱。真正要改的是那九门，以及所有语言里份额那一列的读法。

但它同时也说明另一件事：这二十一门语言里美国的份额都不高，第一名的位置来得很勉强。这一点下一节展开。

这里要提醒一句口径：第一名是谁跟第一名占多少是两个问题，混着看会得出“所有语言都看美国”这种过头的结论。

## 不是美国的那九门

剩下九门各有各的第一名：老挝语指向泰国，尼泊尔语指向印度，豪萨语指向英国，高棉语指向泰国，阿塞拜疆语指向苏联，亚美尼亚语指向俄罗斯，马其顿语指向意大利，爱沙尼亚语指向拉脱维亚，英语指向西班牙。

这九门里，前四门的解释都摆在地图上：老挝挨着泰国，尼泊尔挨着印度，柬埔寨挨着泰国，尼日利亚曾是英国殖民地。

后面几门的解释在历史里，最后一门英语的解释是——它压根就没有第一名，后面会讲。

这九门有个共同点值得注意：除了英语那一门，其余八门的第一名要么是接壤的邻国，要么是有过殖民或者从属关系的国家。都是地理和历史留下的，不是媒体塑造的。

这也意味着这类参照关系变得很慢。它不会因为某年的国际新闻而改变，你今天量出来的结果三五年内都能用。

英语那一门放在这一列其实有点勉强，它的第一名西班牙只占7%，跟第二名日本5%、第三名波兰5% 几乎没差别，说它有第一名都是勉强的。

老挝语和高棉语都指向泰国这件事，跟东南亚三国那一篇 (https://zhangwenbao.com/southeast-asia-seo-vietnam-thailand-indonesia-language-layer.html)里语言层三家不能共用的结论并不矛盾。

语言 | 剔名录前的第一名 | 剔名录后的第一名 | 剔后份额 | 外部样本 | 

老挝语 | 泰国 | 泰国 | 38% | 69 | 

尼泊尔语 | 印度 | 印度 | 29% | 69 | 

泰米尔语 | 美国 | 美国 | 27% | 33 | 

阿尔巴尼亚语 | 法国 | 美国 | 23% | 73 | 

越南语 | 法国 | 美国 | 22% | 36 | 

乌兹别克语 | 美国 | 美国 | 22% | 45 | 

印尼语 | 美国 | 美国 | 22% | 87 | 

僧伽罗语 | 美国 | 美国 | 21% | 42 | 

孟加拉语 | 美国 | 美国 | 21% | 67 | 

波兰语 | 美国 | 美国 | 20% | 88 | 

缅甸语 | 日本 | 美国 | 19% | 21 | 

豪萨语 | 英国 | 英国 | 16% | 105 | 

泰语 | 美国 | 美国 | 16% | 88 | 

德语 | 美国 | 美国 | 16% | 88 | 

蒙古语 | 美国 | 美国 | 15% | 117 | 

波斯语 | 美国 | 美国 | 15% | 106 | 

高棉语 | 泰国 | 泰国 | 14% | 42 | 

荷兰语 | 德国 | 美国 | 12% | 49 | 

阿塞拜疆语 | 伊朗 | 苏联 | 12% | 99 | 

亚美尼亚语 | 俄罗斯 | 俄罗斯 | 11% | 97 | 

立陶宛语 | 波兰 | 美国 | 9% | 75 | 

马其顿语 | 德国 | 意大利 | 9% | 77 | 

斯瓦希里语 | 美国 | 美国 | 9% | 91 | 

爱沙尼亚语 | 拉脱维亚 | 拉脱维亚 | 8% | 71 | 

英语 | 波兰 | 西班牙 | 7% | 58 | 

## 前三名连起来看更清楚

只看第一名会漏掉一半信息。高棉语的前四名是泰国14%、美国10%、缅甸10%、老挝10%，四个里三个是邻国，加起来34%。

豪萨语的前四名是英国16%、加纳14%、美国10%、印度6%。加纳排第二这件事在任何一份英文资料里都看不到，它是尼日利亚在西非最紧密的对照国。

尼泊尔语是印度29% 加美国20%，两个加起来快到一半，剩下的全是零星。

加纳这一条我专门回头查了一下，那十五条不是同一批量导入的产物，是分散的人物、机构和作品条目，类型五花八门。所以它是真的。

这种“第二名比第一名更有信息量”的情况在小语种上不少见，因为第一名的位置经常被美国这个全球背景板占着，真正的本地参照排在它后面。

泰米尔语是另一种形态：美国27% 加英国21%，两个英语国家合起来快到一半。这跟泰米尔语社群在英语世界的分布是对得上的。

豪萨语和斯瓦希里语的市场背景可以对照在非洲选语种别先看人口 (https://zhangwenbao.com/africa-market-language-selection-swahili-hausa-francophone.html)那一篇。

## 样本量决定了能说到多细

剔掉名录之后，每门语言判得出国别的外部条目在二十到一百二十条之间。缅甸语只剩二十一条，是最少的，它的百分比只能当参考。

所以文章里只报前三到前四名和第一名的份额，第五名以后不展开。看到某个数字很小的时候，先想一下它背后可能只有两三条。

另外有几门语言的第一名和第二名咬得很紧，比如马其顿语意大利9% 对德国9%，那种情况下换一批样本第一名就会对调。

## 第一名是美国，为什么反而说明没有参照国？

## 看份额不看名次

把第一名的份额排出来，会看到一个很整齐的分层。美国当第一名的那二十一门语言里，份额基本落在15% 到23% 之间，中位数在18% 上下。

而不是美国的那几门，份额明显更高：老挝语的泰国38%，尼泊尔语的印度29%。

一成五到两成的第一名不叫参照国，那叫背景板。它的意思是这门语言的内容里，关于外部世界的部分散在几十个国家上，美国只是碰巧占了最大的那一小块。

这个分层不是我事先设计的，是把三十个数排成一列之后自己浮出来的。中间那一段特别密，两头很稀，看起来像两种不同的分布混在一起。

解释也很自然：美国在每门语言里都占一小块，这一块的大小取决于这门语言的内容规模和国际化程度；而真正的参照国是额外叠上去的，只有一部分语言有。

把这个分层写成一句能记住的话就是：第一名是谁不重要，第一名占多少才重要。前者三十门里有二十一门给同一个答案，后者从7% 到38% 铺开。

## 英语的数字把这件事说透了

英语的外部第一名是西班牙，份额7%，后面是日本、波兰、墨西哥各5%。这是全表最分散的一个。

换句话说，英语的内容池子在讲外国的时候，谁都不特别。它一半以上的内容写自己那几个国家，剩下的那不到一半均匀铺在全世界。

所以拿英语当参照系的默认设置有个隐含前提：写英语内容的人本来就没有参照国。你把这个设置搬到小语种上，等于把“谁都不特别”这个状态搬给了一批明确有偏好的读者。

把英语放进这张表还有一个用处：它给了一个“没有参照国”的基准线。任何一门语言的第一名份额如果跟英语差不多，那它跟英语一样，没有参照国。

英语7% 是全表最低。第二低的是爱沙尼亚语8%，两者的性质完全一样——都是视野分散，只不过一个是因为内容多到什么都写，一个是因为社群小到什么都写一点。

这也解释了一个常见的困惑：为什么英文资料里几乎找不到“该拿哪个国家举例”这类讨论。因为在英语语境里这个问题不存在，谁都可以举，读者都能接。

这跟按母语人口排优先级 (https://zhangwenbao.com/minor-language-seo-priority-language-cost-model.html)那套默认设置是同一个来源：英语世界不需要回答的问题，被整套搬给了需要回答的人。

## 三档判读线

第一名份额超过25% 的，这门语言有一个明确的参照国，写内容的时候必须用它。目前只有老挝语和尼泊尔语落在这一档，泰米尔语的27% 也算擦线。

份额在15% 到25% 之间的，第一名多半是美国，那是全球背景板，可以用但不必强求，读者对它没有特殊亲近感。

份额低于15% 的，这门语言的视野是分散的，硬挑一个参照国反而会显得刻意。爱沙尼亚语8%、立陶宛语9%、斯瓦希里语9%、马其顿语9% 都在这一档。

三档之间的边界不用抠得太死。落在24% 和26% 的两门语言，实际动作没什么区别。真正有意义的是两头：38% 那一档必须用，8% 那一档不用挑。

另外这三档是按公共内容算的，你自己的品类可能落在不同的档位。所以最好的用法是拿它当先验，再用自己那三十条结果页去校正。

三档对应的动作依次是：必须换、可以不换、不用挑。落在第一档的语言最少，但那几门语言上不换例子的代价也最大。

## 份额低不等于没得做

视野分散的语言反而给了你更大的自由度：举例可以按读者最可能熟悉的那个品类去挑，不用被某个国家绑住。

真正要小心的是第一档。在老挝语内容里拿美国品牌当参照，等于放着读者天天见的泰国货不用，去讲一个他只在网上见过的东西。

视野分散还有一个附带的好处：你可以在同一批内容里用多个国家的例子，而不会显得混乱。读者本来就习惯了看到各种各样的外部参照。

反过来在参照国明确的语言里，例子最好集中在那一两个国家上，来回换反而会削弱代入感。

## 参照国里为什么会冒出已经不存在的国家？

## 四门语言的前几名里有苏联

阿塞拜疆语的外部第一名是苏联，占12%，第三名是俄罗斯帝国7%。爱沙尼亚语的第二名是苏联8%，格鲁吉亚语第三名苏联6%、第四名俄罗斯帝国5%，波兰语第二名也是苏联6%。

这不是数据错误。这些条目讲的确实是苏联时期的人和事，数据项上的国家写的就是苏联，因为那时候今天这几个国家还不存在。

泰米尔语和孟加拉语上有同构的情况：英属印度。我把它并进了印度，因为那是同一块地方；苏联跨了十几个国家，并不进去，只能单列。

这几门语言还有一个共同点：它们的外部指向整体上都偏向东边和北边，很少出现西欧和东亚的国家。这跟内容是谁写的、写作者的知识来源直接相关。

亚美尼亚语的第三名是爱沙尼亚9%，这个组合乍看很怪，翻开条目是同一个时期的人物和机构，仍然是那条历史线索。

格鲁吉亚语的完整前四是美国18%、俄罗斯9%、苏联6%、俄罗斯帝国5%。三个跟俄罗斯有关的加起来20%，比第一名还高，只是被拆成了三格。

这类分布不均在公共内容里是个长期议题，有专门的系统性偏差协作项目 (https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Countering_systemic_bias)在跟，读它的讨论页比读结论更有收获。

## 这一档对做内容的人意味着什么

它说明这几门语言的公共知识里，有相当一块的时间坐标停在几十年前。读者在这门语言里读到的外部世界，有一部分是历史而不是现状。

落到写法上很具体：在这几个市场做内容，用历史类比要格外小心，因为读者对某个历史时期的了解可能比对当下的邻国还熟。

反过来这也是一个机会。关于当下外部世界的内容在这几门语言里明显偏薄，而这类内容不难写。

具体到写法上有一条能直接用：这几个市场的读者对“西方”这个笼统说法的感受，跟西欧读者不一样。写内容时把国家写具体，比用大区域称呼安全。

## 怎么处理这一档才不失真

我的做法是：能对上今天某一个国家的历史实体就并进去，跨多国的单列一档并在表里说明。

另一种做法是把所有历史实体统统剔掉，只看今天存在的国家。我试了一下，结论方向没变，但阿塞拜疆语和爱沙尼亚语的第一名会跟着换，而换出来的那个数背后只有六七条。

两种做法我都报，读者可以自己挑。凡是一个口径的选择会改变结论的地方，把两个口径都摆出来比替读者做决定安全。

这里其实还有第三种做法：把历史实体单独当成一档报出来，跟今天的国家并列。我试过，表会变得很难读，而且多数语言这一档是零，白占一列。

所以最后选了折中：能对上就并，跨多国就单列，并在正文里点名说明哪几门语言受影响。

## 这一条怎么改你的落地页和案例？

## 案例里举的公司要换

写一篇本地语言的选购指南，举例的时候拿哪家公司当参照，读者的感受完全不同。拿一个他每天路过的品牌举例，和拿一个他只在国际新闻里见过的品牌举例，说服力差一整档。

参照国这个数直接告诉你该往哪儿找例子。第一名是邻国的，就去邻国找；第一名是前宗主国的，那个国家的品牌在当地多半也真的有存在感。

这件事的成本几乎为零，只是把例子换一批，但它决定了读者读完之后觉得这篇是给他写的，还是给别人写的顺手翻了一份。

换例子的时候还有一个细节：本地读者认得的那个外国品牌，未必是它在原产国的主流品牌。有些牌子在本土不温不火，在某个市场却是家喻户晓，因为进入得早。

所以更稳的做法是拿参照国当线索，再去那个市场的实际销售榜上挑，而不是直接挑参照国的头部品牌。

一个能立刻做的自查：把你这门语言下已经发布的十篇内容打开，把里面出现的所有公司名和地名列出来，看看它们落在哪几个国家。多数团队第一次做这件事都会吃一惊。

举例里出现的地名还要过一道本地名与外来名 (https://zhangwenbao.com/minor-language-place-name-endonym-exonym-search.html)的检查，写法错了比举错例子还刺眼。

## 对比表里的竞品要换

产品对比页最容易犯的错，是把总部所在国的竞争格局照搬过去。你在国内的对手是那三家，在这个市场的对手可能是完全另外三家，而读者心里的默认对照物又是第三批。

正确做法是先看这门语言的参照国是谁，再去那个国家的市场上找同品类的知名品牌，把它放进对比表。哪怕你不卖那个品牌，读者也需要一个锚。

对比表还有一个常被忽略的位置：表头那一列的维度选择。你按什么维度做对比，本身就暴露了你的参照系。拿一个本地读者不关心的维度当第一列，后面写得再细也白搭。

对比表里出现的品牌名怎么拼，要按当地用户的输入法 (https://zhangwenbao.com/brand-name-transliteration-loanword-minor-language-search.html)来定，不是按你的品牌手册。

## 价格与规格的基准要换

换算基准这件事比想象中要紧。写“相当于多少钱”的时候，用哪个国家的物价当参照，直接影响读者对贵和便宜的判断。

规格同理。插头制式、电压、纸张尺寸、鞋码，这几项在参照国和你的总部所在国往往不一样，写错了不是不专业的问题，是直接把人挡在门外。

换算基准这件事有个简单的自检：把你写的那句“相当于……”念给一个当地人听，如果他要停下来算一下，那就是选错了参照。

## 外链和引用也要跟着换

引一个当地读者认得的机构，比引一个更权威但他没听说过的国际组织有用。参照国这个数同样适用于挑引用源。

顺带一提，这一条对生成式检索也成立：模型在这门语言下检索到的本地来源，本身就偏向这批国家，你的引用跟它对齐会更容易被一起摘走。

挑引用源的时候还可以顺手看一眼那个机构在本地语言里有没有条目。有条目说明本地读者可能听说过，没有的话你引它等于引了一个陌生名字。

这一层跟本地作者署名那批信任信号 (https://zhangwenbao.com/minor-language-eat-local-author-byline-credential-signals.html)是配套的，一起做效果最好。

## 竞品参照系该换成谁？

## 先分清三种参照物

做内容的时候会用到三种参照物，它们该取的国家不一样。第一种是价格锚：读者判断贵不贵时心里的那个数，取他日常接触的市场。

第二种是品质锚：读者判断好不好时心里的那个牌子，取这门语言内容池子里出现频率最高的那个国家的品牌。

第三种是规范锚：认证、标准、参数写法，取本国的，不取任何外国。这一项照搬外国是最常见也最致命的错。

三种锚可以来自三个不同的国家，这一点最容易被忽略。价格锚跟着日常物价走，品质锚跟着内容池子走，规范锚跟着本国法律走，硬要统一成一个反而处处不对。

写稿的时候可以在提纲里给这三个锚各留一行，写完对照检查一遍。这个动作花两分钟，能挡下相当一批低级错误。

规范锚那一项还牵扯到落地页上的支付、地址与客服信息怎么写 (https://zhangwenbao.com/minor-language-landing-page-trust-signals-payment-address-support.html)，那批字段一律跟着本国走。

## 参照国不等于出口目的地

有个容易混的地方：参照国是读者认知里的外部世界，跟你的货从哪儿来、往哪儿卖没关系。

你的产品可能是中国造的，卖给这个国家的人，而他心里的参照系是隔壁那个国家。三个国家是三件事，写内容的时候只有第三个那件事重要。

还有第四个容易混的：你的竞争对手来自哪个国家。竞品来源跟读者的参照系可以完全不重合，你在这个市场的对手是另一家中国公司，但读者心里的对照物是隔壁国家的老牌子。

## 什么时候该无视这个数

两种情况。一是你做的品类本来就有全球统一的头部品牌，读者不需要本地参照物，这时候直接用那个全球品牌更省事。

二是你的目标客户是本地的专业买家而不是普通消费者，专业买家的参照系跟着行业走，不跟着这门语言的公共内容走。

除了这两种，其余情况都值得先把这个数看一眼再动笔。

第三种情况是你的内容根本不需要外部参照，比如纯粹的操作说明和售后流程。这类内容里塞例子反而是干扰，写清楚步骤就够了。

## 半天能跑完的最小版本

## 三十条就够

不用做到这么大的样本。取你那个品类在目标语言下的三十个结果页，逐个打开，记下每个页面提到的外国是哪几个。

统计一下哪个国家出现得最多，那就是你这个品类在这门语言下的参照国。跟公共内容的读数对不上也没关系，品类级的数比语言级的数更该信。

记录的时候按页面记而不是按提及次数记，否则一篇长文里反复提到同一个国家会把结果带偏。一个页面就投一票，票投给它着墨最多的那个国家。

这三十条最好覆盖三种页型：品类页、对比页、指南页。三种页型的参照物用法不一样，只看一种会得到偏的结论。

抽这三十条的时候顺手把意图分叉 (https://zhangwenbao.com/minor-language-search-intent-divergence-across-markets.html)也标一列，两件事一趟能跑完。

## 加一列会更准

在记国家的同时，顺手记一下那个国家是以什么身份出现的：是产地、是标准来源、还是竞品来源。三种身份对应的写法不一样。

产地身份多的，读者关心的是原产地故事；标准来源多的，读者关心的是合规和参数；竞品来源多的，读者关心的是对比和替代。

三种身份的比例本身也能读出东西。产地身份占大头的品类，读者关心的是来源可信度；竞品身份占大头的，读者已经在比价了，内容要直接给结论。

## 什么时候要重跑

换品类要重跑，换语言要重跑，同一个品类同一门语言的话一年一次足够。

这个数的稳定性来自它反映的是长期的知识结构，不是短期的热点。热点会让某个国家在某几个月里冒头，但它压不住底层的分布。

还有一种情况必须重跑：你换了内容形态。做长文和做短视频脚本，读者对参照物的接受度不一样，短的那种容不下需要解释的参照。

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

## 用户在哪个国家，不归这一层

这份数量的是内容写的是哪个国家，不是读者住在哪个国家。一门语言的读者散在十几个国家这件事，本站另有一篇专门算过账，那是市场资产的问题，跟内容池子的构成是两回事。

两个数会互相影响但不能互相替代。内容池子偏向邻国，不代表你的买家在邻国；买家在邻国，也不代表这门语言的内容会跟着偏过去。

把这两件事分开还有一个操作上的好处：它们的数据源完全不同。用户在哪个国家看后台就知道，内容池子写的是哪个国家只能自己去量。前者随时能看，后者一年看一次。

如果两个数打架——用户主要在A国，内容池子的参照系指向B国——那就按B国写例子，按A国配货币和物流。它们本来就服务于不同的环节。

印度那种一国多语言的情况更复杂一点，十一门语言九套书写系统 (https://zhangwenbao.com/india-multilingual-seo-eleven-languages-nine-scripts-priority.html)那篇拆过。

## 语言变体与用词分叉，不归这一层

同一门语言在不同国家用词不一样，那是语言层的问题，本站西班牙语和葡萄牙语那两篇写得比这里细。本篇不碰用词，只碰题材。

一个具体的区分办法：用词分叉问的是同一件东西怎么说，题材构成问的是根本在说哪件东西。

两件事偶尔会撞在一起：某个品类在参照国的叫法被本地读者直接借用了。这种时候词表要跟着参照国走，但那是词表的事，不是题材的事。

## 翻译来源不归这一层

“这条内容是从哪门语言译过来的”跟“这条内容讲的是哪个国家”经常被混为一谈，其实差得很远。从英语译过来的条目完全可以讲的是本国的事，本地人自己写的条目也完全可以讲外国。

上一批算过来源那条轴，这一批算题材这条轴，两条轴交叉才是完整的坐标。

四个格子里最值得注意的是“自己写的、写的是外国”那一格。它意味着本地社群有产能，只是产能没用在本地题材上——这种局面最容易被撬动。

## 常见问题解答

## 第一名是邻国，会不会只是因为邻国的条目更容易被机器批量建出来？

这个怀疑是对的，必须单独查。查法是打开第一名那批条目看它们都是什么：如果全是同一种模板的行政区或者同一批物种，那多半是程序批量生成的；如果是人物、机构、作品这些需要一条条写的东西，就说明是人在写。实测下来两种情况都有，所以文章里对每门语言的第一名都做了这道分辨，把疑似批量生成的单独标出来。判断一门语言的参照系时，只看人写出来的那部分更可靠。

## 样本只有两百多条，第一名的结论稳吗？

第一名稳，第三名以后不稳。判得出国别的条目里外部那部分通常在五十到一百条之间，第一名如果占到三成以上，换一批样本基本不会变；占比在一成上下的那几门，第一名和第二名有可能对调。所以文章里凡是第一名份额低于百分之十五的语言，我都在表里注明了它的前两名咬得很紧，不建议单独拿去做决策。

## 知道了参照国，具体能改什么？

最直接的三处：案例里举的公司、对比表里放的竞品、以及价格和规格的换算基准。你写一篇泰米尔语的选购指南，拿美国品牌当参照，跟拿印度品牌当参照，读者的代入感完全不同。第二处是外链和引用，引本地读者认得的机构比引一个他们没听过的国际组织更有说服力。第三处是配图里出现的场景、货币符号和插头形状，这些细节骗不了人。

## 如果我的品类在这个市场根本没有本地竞品呢？

那参照系就换成读者熟悉的那个国家的同类产品，而不是换成你总部所在国的。判断依据是这份数据给出的第一名：读者的知识背景里，那个国家的东西是他见过的。拿他见过的东西做对比，比拿一个更权威但他没接触过的品牌做对比更有效。这条在做产品对比页和替代品页的时候尤其明显。

## 大语言的参照系是不是就没有这个问题？

有，只是方向反过来。规模大的语言往外看的时候更分散，第一名的份额明显低于小语种，说明它的读者没有一个压倒性的参照国。对做内容的人来说，这意味着在大语言市场上举例可以更自由，在小语种市场上举例必须挑对国家，挑错了那一段就是白写。

## 这个数会随时间变吗，多久重算一次？

结构性的东西变得很慢，一年重算一次足够。真正会让它变的是两类事件：一是这门语言的社群里出现了一批新的活跃编者，二是某个邻国发生了长期占据注意力的大事。前者会把本地那一堆抬上去，后者会把某个外国的份额顶上来。两者都不是几个月能看出来的。

## 这套方法能直接搬到自己的站上做竞品分析吗？

能，换个数据源就行。把随机抽样换成你那个品类的结果页，把属性链换成人工判读，逐条记下每个页面讲的是哪个国家的事。三十条就能看出趋势，一个下午能跑完。得到的数比这份公共数据更贴近你的实际竞争面，代价是没法跟别的语言横向比。

## 权威参考资料



## 波兰语给笔记本电脑用的是买猫那个词尾，词典说这是错的，用户就这么搜

- URL：https://zhangwenbao.com/minor-language-animacy-accusative-keyword-forms.html
- 分类：小语种SEO
- 发布：2022-09-08  |  更新：2026-07-29
- 摘要：斯拉夫语的宾格走哪一套形态，由这个名词指的东西算不算活的决定，而这条线是被词典记下来的不是被推出来的。讲清哪些品类词正在跨界、品牌名会不会被拉进去、站内搜索和筛选器怎么修。
- 关键词：关键词研究,多语言SEO,内容本地化,小语种SEO

> **TLDR**：摘要：斯拉夫语里名词的宾格形式不由这个词长什么样决定，而由它指的东西算不算活的决定。麻烦在于，语法回答这个问题的方式跟生物学不一样：波兰语口语把笔记本电脑、汽车品牌、香烟都归进活的那一边，词典说这是错的，用户就这么搜。宠物品类更极端，整张关键词表的核心词全是有生名词，等于全表都要换一套形态。本文讲清这条线画在哪、哪些品类词正在跨界、词典形态和口语形态各该放页面哪个位置、站内搜索和筛选器会错成什么样，以及关键词表该为这件事多加哪三列。

> 摘要：斯拉夫语里名词的宾格形式不由这个词长什么样决定，而由它指的东西算不算活的决定。麻烦在于，语法回答这个问题的方式跟生物学不一样：波兰语口语把笔记本电脑、汽车品牌、香烟都归进活的那一边，词典说这是错的，用户就这么搜。宠物品类更极端，整张关键词表的核心词全是有生名词，等于全表都要换一套形态。本文讲清这条线画在哪、哪些品类词正在跨界、词典形态和口语形态各该放页面哪个位置、站内搜索和筛选器会错成什么样，以及关键词表该为这件事多加哪三列。

## 为什么波兰语用户搜狗粮和搜吸尘器，用的不是同一套词尾？

## 一家波兰宠物站的零结果日志

有个客户做波兰市场的宠物用品，主营狗粮、猫砂、牵引绳这几类。

词表是照着标准流程建的：工具导出、按量排序、母语同事过了一遍，六百多条。

上线八个月，页面收录没问题，外链也在做，可品类页的自然流量一直卡在一个很低的水平上。

保哥让他们把站内搜索日志导出来看，发现零结果查询占比高得离谱，而且集中在几个最核心的词上。

更奇怪的是，这些零结果查询看上去跟词表里的词几乎一模一样，只是最后一两个字母不同。不是拼错，是同一个词的另一个形态，而且用户打得非常一致，成千上万次都是那一种。

把这批查询按品类分开之后，规律就出来了：出问题的全是宠物本身相关的词，而配件、器具、清洁用品这几类一点事都没有。同一个站、同一套模板、同一批人做的词表，偏偏只有一半的品类在漏水，这就说明问题不在流程上，在语言的某一条规则上。

还有一个细节当时被忽略了：这批零结果查询的时间分布跟别的查询不一样，它们更集中在晚上和周末。这说明打这些词的是真正在家里养宠物的人，不是白天顺手比价的那一批，商业价值只会更高不会更低。

## 同一个动词后面，两个名词的结尾不一样

把两组查询摆在一起看，差别一眼就能看出来。

用户搜买猫的时候，猫这个词是一种形态；搜买吸尘器的时候，吸尘器那个词保持原样没变。

两句话的句法结构完全相同，都是同一个动词加一个宾语，可宾语的形态一个变了一个没变。

这不是用户随手打的两种习惯，波兰语里这两种写法各自都是唯一正确的，写反了母语者立刻觉得别扭。

换句话说，你的关键词表如果只收了词典原形，那么在宠物这一半品类上，你收的形态跟用户实际打的形态从第一天起就不是同一个。跟着的是一整批查询悄悄落空，而报表上什么异常都看不到，因为这些词的搜索量本来就统计在另一个形态底下。

这里还有一条容易被跳过的确认：先排除掉输入法和键盘的因素。变音符号打不打、大小写对不对，这些都是另一类问题，而本文这一类差异出现在词尾且完全没有变音符号参与，两者的排查路径完全不同，混在一起会白绕一圈。

## 这不是变格类别的差异

第一反应通常是：会不会这两个词属于不同的变格类别，所以词尾表本来就不同。

不是。这两个词的性别相同、词尾相同、结尾的辅音也是同一类，按任何一本语法书的分类它们都归在同一组。

真正把它们分开的是另一个维度，这个维度不看词本身，看这个词指的是什么东西。

这一点很值得停一下。关键词表里其它所有的形态规则，你都可以拿词形算出来：看词尾是什么、看重音在哪、看它归哪一类。波兰语七个格那一篇 (https://zhangwenbao.com/polish-seo-seven-cases-diacritics-keyword-research.html)整理的就是这一类可计算的规则。

只有这一条不行。要用上这一条规则，你必须先回答一个跟语法无关的问题：它是活的吗。这是关键词表里唯一一个取值由词指的东西决定、而不是由词本身决定的语法维度，也是唯一一个你没法靠看字符串算出来的维度。

这里可以顺手记一条判别法：如果两个词在语法书里归在同一组，实际形态却不同，那差异一定来自某个不看词形的维度。这类维度在任何语言里都很少，但只要存在一个，靠算法就一定推不出来。

## 判据是先问它是不是活的

把这条规则说白了就一句话：宾格用哪个形态，取决于这个名词指的东西在语法上算不算活的。

算活的，宾格就跟属格长得一样；不算活的，宾格就跟主格长得一样。

猫、狗、仓鼠、鹦鹉全部算活的，所以宠物品类的核心词整批走第一条路。

吸尘器、碗、垫子、笼子全部算不活的，所以配件和器具那一半走第二条路，形态跟词典原形一致，词表正好收对了。

于是同一个站上会出现一个很有意思的分布：品类树上有一半的分支需要额外的形态，另一半完全不需要。而这条分界线不在你的商品分类体系里，也不在任何一份技术文档里，它在语言那一头，按东西活不活来切。

顺带说一句，这个分布对排期反而是好消息。你不需要重做整张词表，只要把品类树上活物那半边挑出来单独处理，工作量立刻从六百条缩到一百多条，一个下午就能收口。

## 语法上的活，跟生物学上的活是一回事吗？

## 语法把这条线画在了另一个位置

如果这条线跟生物学重合，那这件事就好办了，写个规则表就完了。

问题在于它不重合，而且不重合的地方恰好落在电商最常卖的那些东西上。

语法上的生命度是一个形态句法范畴，它记录的是这个词在历史上被怎么用，不是这个东西在自然界里是什么。

通用依存标注体系把它单列成一个特征，正是因为它必须靠标注而不能靠推理得到。

这里有一个反直觉的推论：正因为它是历史沉淀下来的，所以它会漂移。今天算不活的东西，二十年后可能就算活的了，而这个变化不会有任何人发公告通知你。

这个特征还带来一个组织上的后果：因为它是标注出来的，所以它可以被外包，也可以被验收。你不需要在团队里养一个懂斯拉夫语形态学的人，你需要的是一份标好的清单和一条什么时候重标的规则。

## 波兰语还多分了一层男性人称

波兰语在这件事上比俄语更细，它把阳性名词又切成了三档。

第一档是男性人称，指人的阳性名词单独算一类；第二档是有生但不指人，动物属于这一档；第三档是无生。

三档在单数和复数上的表现还不一样，复数那一层的分界线跟单数不在同一个位置。

对做SEO的人来说，三档里最要紧的是第二档，因为宠物、活体动物、以及一大批被口语拉过去的物品都落在这里。

值得提一句的是，第一档在电商上也不是完全用不上。招聘页、服务页、以及所有写给人看的角色词都会踩到它，比如兽医、训练师、寄养人这些词在句子里的形态跟商品词不是一套。这一层跟作者署名与资质信号那一篇 (https://zhangwenbao.com/minor-language-eat-local-author-byline-credential-signals.html)讲的人名处理是同一片区域。

三档这件事在实操上还有一层影响：工具导出的词表通常只给一个原形，你没法从原形看出它属于哪一档。所以分档这一步只能人工做一次，做完之后才谈得上自动化，顺序反过来的团队会在脚本上白花两周。

## 已经不动了的东西反而还算活的

最能说明这条线跟生物学无关的，是几个边界例子。

俄语里表示死者的那个词在语法上算有生，尽管它指的东西按任何标准都不再活着。

玩偶、棋子里的某些词也归在有生那一边，因为它们在语言里长期被当成人来说。

反过来，某些确实活着的东西在语法上却算无生，微生物这一类词在不同语言里的归属并不一致。

所以正确的说法不是这门语言把活的和死的分开了，而是这门语言在几百年里逐渐攒出了一份名单，名单上的词走一条路，名单外的词走另一条路。名单的成因有语义的成分，但绝不只有语义。

这几个边界例子的价值不在于你会卖玩偶或者棋子，而在于它们能一次性说服团队：这条线不能靠常识判断。只要有人拿这两个例子问一句那按常识该归哪边，讨论就会自动转向去查语料。

## 这条线是被记下来的，不是被推出来的

既然是名单，那处理办法就跟处理规则完全不同。

规则可以写进代码，名单只能查表，而且要定期更新。

这跟颜色范畴那一篇 (https://zhangwenbao.com/minor-language-color-category-attribute-value.html)的结论有一处相通：凡是取值由语言的历史约定决定的维度，交付物都是一张要维护的表，不是一段能跑的逻辑。

差别在于颜色那张表是多对多的映射，这张表是一列布尔值加一列例外说明，结构简单得多，但更新频率反而更高。

还有一个实操上的好消息：这份名单里跟你有关的部分非常有限。全站六百条词里真正需要标这一列的可能只有一百多条，其中会引起争议的不超过二十条，两小时就能过一遍。

更新频率高这一点有个具体原因：名单的增长方向是单向的，新词不断被拉进有生那一边，很少有词反过来跑出去。所以你每次复核要找的不是变动，是新增，这让复核这件事变得机械而且可交付。

## 哪些品类词会跨到有生那一边？

## 电子产品是最近几十年跨过去的一批

最典型的一族是电子产品，尤其是随身设备。

波兰语口语里买笔记本电脑这句话，笔记本电脑那个词用的是有生形态，跟买猫是同一套词尾。

手机、平板、路由器在口语里也大量出现同样的形态。

这批词的共同点是它们都是近几十年才进入这门语言的外来词，而新词在归属上本来就不稳定。

更有意思的是，这个现象在年轻使用者那里比在年长使用者那里更普遍，也就是说它还在往前走，不是残留而是趋势。这一层跟口语短词那一篇 (https://zhangwenbao.com/minor-language-clipped-short-forms-keyword-coverage.html)的方向一致：口语先跑，规范在后面追。

这里还有个可以直接用的信号：一个词跨界的程度跟它进入这门语言的时间长短成反比。越新的外来词越不稳定，越老的外来词已经定档。所以新品类上线时这一层的风险最高，而那恰好是没人有精力做语言核对的时刻。

## 汽车品牌和货币早就在那边了

另外几族跨界得更早，早到已经被词典正式收录。

汽车品牌名在句子里当名词用时按有生变格，我有一辆某某牌车这句话，品牌名带的是有生词尾。

货币单位、香烟品牌、部分舞蹈名称也在同一份名单上。

这几族的共同点是它们都经常出现在口语的拥有和购买句式里，也就是最高频的那几个句型。

对做电商的人来说，这里有个很直接的推论：越是高频出现在买和有这两个动词后面的词，越容易被拉进有生那一边。而那批词恰好就是你的核心商业词，一个都躲不开。

这一族对做本地化的人还有一个提醒：它们大量出现在用户评论和社区帖子里，也就是你最可能拿来做语料的那批文本。如果你从社区里挖词，挖出来的默认就是有生形态，而你的商品库里存的是另一个，两边对不上很正常。

## 食品饮料里有一半在摇摆

第三类最麻烦，因为它没定下来。

某些食品名称在语料里两种形态都有相当的出现次数，比例接近对半开。

词典对这一批的处理方式是两个形态都列出来，不判对错。

这种摇摆状态对关键词工作反而是最容易出事的，因为你无论选哪一个都会漏掉将近一半的查询。

处理办法只有一个：摇摆的这一批不做取舍，两个形态全部进匹配层。展示层可以只选一个，但匹配层做取舍等于主动扔掉一半的量，而这一半没有任何东西能替你补回来。

摇摆状态还有一个容易被误判的地方：它在不同体裁里的比例不一样。新闻语料里规范形态占优，论坛语料里口语形态占优，而搜索行为更接近论坛那一头。所以查语料时要留意语料的体裁构成，别拿新闻的比例去推搜索的比例。

## 判断办法只有一个，去查真实语料

既然规则推不出来，那就只剩下查。

波兰语国家语料库提供公开的检索界面，把两个形态分别丢进去看出现次数，几分钟就有结论。

俄语那边有对应的国家语料库，检索方式类似，也能按体裁和年代拆分。

这一步不需要你懂这门语言，你要做的只是输入两个字符串然后比较两个数字。

需要注意的是查询要限定在同一个句法位置上，否则数字会被别的格的形态污染。稳妥的做法是连动词一起查，把买和有这两个动词分别加在前面各查一遍，得到的分布才是可信的。

查语料还有一个额外收获：出现次数本身就是一个粗糙的需求信号。某个形态在语料里几乎不出现，那它在搜索框里大概率也是稀有的，这一层判断跟关键词工具没数据那一篇 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)里用语料补量的思路是同一套。

## 词典给的形态和用户打的形态不一致时，该收哪一个？

## 词典把两种都记下来了，还标了身份

这件事最特别的地方在于，规范和用法的冲突是被公开记录的。

波兰语的几部主流词典在这一批词的词条里会同时列出两个形态，并给其中一个加上口语标注。

也就是说，词典自己承认存在两种写法，并且告诉你哪一种更正式。

这跟绝大多数语言问题都不一样。拼写、变音符号、大小写这些事上，词典只给一个答案，你照着抄就行。

而这里，正确写法和高频写法被并排写在同一个词条里，你没法用跟着词典走这条通用策略把问题绕过去，因为词典自己就没有做取舍。

顺带说一句，这种并列记录的做法本身是词典编纂的美德，它忠实反映了语言的实际状态。只是这份忠实到了工程这一侧就变成了一个必须由你来做的决定，而做决定的人往往是词表里最没有语言背景的那一个。

## 搜索框里的分布跟词典的排序相反

把语料频次和搜索行为放在一起看，会看到一个很尴尬的对照。

词典把规范形态排在前面，口语形态排在后面加个标注。

搜索日志里的排序常常正好倒过来，口语形态的量明显更大。

原因不难理解：搜索框是最口语的一个输入场景，人在那里打的是他嘴里的话，不是他写作文时的话。

这里可以顺手推出一条更一般的经验：凡是某个写法被标注为口语的，它在搜索框里的占比就一定高于它在书面语料里的占比，而且高得不是一点。判断一个词该不该进匹配层，看的应该是搜索场景的分布，不是书面语的分布。

这个倒挂还有个副作用：如果你的母语审校只看页面文本不看搜索日志，他会诚实地把口语形态改回规范形态，而且改得完全正确。母语审校验收那一篇 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)讲的正是这类改对了却改坏了的情形。

## 跟着词典走这条通用策略在这里失效

大多数团队面对语言问题都有一条兜底策略：拿不准就按词典来。

这条策略在九成的场合都对，也正因为它太可靠，没人会想到它有失效的时候。

它失效的条件很清楚：当词典自己给出两个并列答案的时候，这条策略就没有输出了。

而它失效的时候通常不会报错，团队会默认取词典列在前面的那一个，然后以为自己做对了。

保哥见过好几次这种情况：所有人都遵守了流程，所有人都没做错任何一步，结果是一半的查询接不住。流程越规范，这类问题活得越久，因为没有任何一个环节会举手。

识别这条策略是不是正在失效，有个很简单的自查动作：翻开词典看这一条词条里有没有并列的第二个答案。有，就说明这个位置需要你自己做取舍，词典帮不了你；没有，那照抄就是。这个动作十秒钟，却能挡住一整类静默错误。

## 两个形态都要进表，但落地位置不同

结论其实很简单，难的是分清楚位置。

匹配层全收：站内搜索的同义词表、广告的关键词列表、结构化数据的别名字段，两个形态一律都放。

展示层选一个：标题、面包屑、筛选器的取值名称只用规范形态，因为那些位置是给人看的，观感成本比覆盖率更重要。

正文可以两个都出现，只要写得自然，一段里出现一次口语形态不会有任何观感问题。

这条按位置分工的原则不是这一篇独有的，首字母缩略语那一篇 (https://zhangwenbao.com/minor-language-acronym-initialism-local-forms-inflection.html)用的是同一套分工。区别在于那一篇分的是英文原形和本地变形，这一篇分的是规范形态和口语形态，位置表可以直接复用。

把位置分工写成一张表贴在词表旁边比写进文档管用得多。表里只要三行：展示层用哪一列、匹配层用哪几列、正文可以混用。新人接手时看这三行就够，不需要理解背后那套语法。

## 品牌名和型号会不会也被拉进有生变格？

## 外来品牌名进句子就跟着变

会，而且这一条经常让品牌方措手不及。

汽车品牌是最早被拉过去的一批，本地人说我有一辆某某车的时候，品牌名带的是有生词尾。

这个用法不是不规范，它已经进了词典，属于正式承认的写法。

对品牌方来说，麻烦在于品牌名恰恰是你最希望字符串保持稳定的那个词。

这跟品牌名音译那一篇 (https://zhangwenbao.com/brand-name-transliteration-loanword-minor-language-search.html)的处境正好相反。那一篇讲的是一个名字长出三种写法之后你要主动收敛成一种；这一篇里你收敛不了，因为决定加哪个词尾的不是你的品牌手册，是这句话的语法。

还有一个观察值得记下来：品牌名跨界的速度往往比同品类的通用词更快。原因不难猜，品牌名在口语里出现的频率高、句式固定，正好是最容易固化形态的环境。所以别拿品类词的结论去推品牌词。

## 型号和字母数字组合是另一回事

型号则要单独拿出来说。

带数字和字母的型号串在句子里通常不加词尾，本地人也觉得加了别扭。

这是好事，说明型号这一层是稳定的，可以放心当成不变的字符串处理。

唯一要注意的是纯字母的型号名，如果它读起来像一个本地词，就有可能被顺手加上词尾。

判断办法很土但很有效：把型号念出来给本地同事听，问他会不会在句子里给它加尾巴。念得出来的容易变，念不出来的通常不变，这条经验在斯拉夫语族里相当可靠。

还有一个更省事的做法：把型号在页面上跟品类词之间用符号隔开，别让它直接嵌进句子里。隔开之后本地人的语感就不会去给它加尾巴，这跟希伯来语那边靠断开连缀结构来绕开形态计算是同一个思路。

## 品牌名的这一格由用户填，不由你填

把品牌名这件事往上抽一层，会看到一个值得记下来的结构。

品牌名的拼写你说了算，商标注册和视觉规范都在你手里。

品牌名的语法归属你说了不算，它由这门语言的使用者在几年时间里投票投出来。

你能做的只有观察和跟随，观察的窗口是站内搜索日志和本地社区里的实际写法。

所以品牌名在这门语言里的处理要分成两件事：写法收敛是你的职责，形态覆盖是语言的现实。前者要在上线前定死，后者要在上线后持续采集，两件事的节奏完全不同。

这条结构还有一个延伸判断：凡是你能在上线前定死的东西都属于品牌资产，凡是要在上线后持续采集的东西都属于市场事实。把两类东西记在同一份文档里是很多混乱的起点，因为它们的复核节奏差了一个数量级。

## 站内搜索必须认这些形态

最容易被忽略的落地位置是站内搜索。

用户在自己的站上搜品牌名，打的是他嘴里那个形态，也就是带词尾的那个。

站内搜索如果只做精确匹配，这一批查询全部返回空白。

而在自己的站上被自己的搜索框拒绝，这个体验的杀伤力比排不上名大得多。

最省事的修法是在同义词表里为每个品牌名挂上两到三个形态，几十个品牌也就一两百行配置，一次做完长期有效。这条一样适用于品类词，两件事可以合并到同一次改动里。

再补一句排期上的建议：站内搜索这一处应该排在所有改动的最前面。它的改动范围最小、见效最快、而且完全不影响页面内容，属于那种可以在一次常规发布里顺手带上的动作。

## 俄语和捷克语的这条线，画在同一个位置吗？

## 俄语的线画得比波兰语保守

同属斯拉夫语族，这条线的位置并不一致。

俄语也有这套区分，但它把物品拉进有生那一边的程度明显低于波兰语。

波兰语口语里已经跨过去的那批电子产品，在俄语里基本还留在无生这一边。

这意味着你不能拿一门语言的名单去套另一门语言，哪怕两门语言的使用者互相能听懂大半。

这跟俄语变格那一篇 (https://zhangwenbao.com/russian-seo-cyrillic-cases-declension-wordstat-keyword.html)给的方法论并不冲突：那一篇解决的是一个词有几种形态，这一篇解决的是该走哪一套形态，两个问题要分开问。

两条线不一致这件事有个很实际的用处：它能帮你判断俄语市场和波兰语市场的词表能共用多少。答案通常是结构可以共用、取值必须各做一份，而这个结论跟跨市场搜索意图那一篇 (https://zhangwenbao.com/minor-language-search-intent-divergence-across-markets.html)给出的分工是一致的。

## 捷克语在单复数上的表现不一样

捷克语这边又是另一种情况。

它的区分主要体现在阳性名词上，而且单数和复数的规则不对称。

同一个词在单数上按有生走，在复数上可能就看不出区别了。

做关键词表时如果只验了单数形态，很容易得出一个过于乐观的结论。

稳妥的做法是单复数各验一遍，把四个格子都填上。这一点跟捷克语与斯洛伐克语那一篇 (https://zhangwenbao.com/czech-slovak-seo-content-reuse-decision.html)的判据可以放在一起用：两门语言能不能共用一套内容，形态这一层的差异要单独算一笔。

另外提醒一句，捷克语的检索资源跟波兰语不在同一个地方，语料库入口和查询语法都不一样。开工前先花十分钟确认这门语言有没有可公开检索的语料库，没有的话这套流程就得换成找本地同事抽样确认，工期要另算。

## 乌克兰语要跟俄语分开记

乌克兰语的情况需要单独说一句。

它有自己的一套区分，跟俄语相近但不完全重合。

由于两种语言在同一批用户那里同时流通，词表里如果不标语言，两套形态很容易混进同一列。

混进去之后最直接的后果是统计口径乱掉，你会看到一批查询量对不上任何一个形态。

处理办法是在词表里加一列语言标记，这一步跟乌俄双语市场那一篇 (https://zhangwenbao.com/ukrainian-russian-seo-bilingual-market-content-split.html)讲的内容拆分是同一件事的两个侧面：内容要拆，词表也要拆，而且词表这一层更容易被漏掉。

另外要留意的是这两种语言的用户可能在同一个站上共存，而站内搜索通常不区分语言。这意味着同义词表里两套形态会挤在同一个命名空间里，如果不加前缀，排查的时候你会分不清某一行是哪门语言的。

## 跨语言复用这张表的风险

做多语言站的人天然想复用。

这张表可以复用的部分是结构，也就是那三列字段。

不能复用的部分是取值，每门语言的名单必须各自验一遍。

省这一步的代价通常不是错得很离谱，而是错得很轻微，轻微到没人会发现。

保哥的经验是：跨语言复用取值这件事，出事的时候从来不会有一条曲线掉下来，只会有一片流量从头到尾没来过。这类缺席型的损失，监控系统天生看不见。

## 这一层会在站内搜索和筛选器上错成什么样？

## 零结果里藏着最贵的那批查询

站内搜索的零结果日志是这件事最好的探针。

打进来搜宠物名称的人，购买意图通常比搜配件的人更明确。

他们打的是有生形态，而你的商品标题里是词典原形，精确匹配直接落空。

更糟的是这类用户不会换个词再试一次，他默认这个站没有这个东西。

所以这批零结果查询的商业价值密度是全站最高的一档，而它们在报表上只表现为一个不起眼的零结果比例数字。把这个数字按品类拆开看，宠物那一半会明显高出来，这个对比本身就是最好的立项材料。

把这个对比做成图表其实很容易：横轴放品类，纵轴放零结果比例，活物那几个品类会明显高出一截。这张图不需要任何解释就能看懂，比任何一段语法说明都更适合放进立项材料的第一页。

## 筛选器的取值命名会跟着一起错

筛选器是第二个受害点。

适用宠物这类筛选项的取值是名词，而它出现在界面上的位置决定了它用哪个形态。

取值如果照抄词表，就会把形态问题一路带进结构化数据。

而枚举值这一层跟正文不一样，正文可以模糊，枚举值必须严格相等。

这条跟属性枚举值那一篇 (https://zhangwenbao.com/minor-language-color-category-attribute-value.html)是同一个机制的两个实例：那一篇的错源是范畴切分不同，这一篇的错源是形态选错，但落到筛选器上的症状完全一样，都是点了没结果。

筛选器这一层还有个额外的坑：取值一旦被写进结构化数据并被抓取，改起来就要等重新抓取和重新处理，周期以周计。所以这一处宁可上线前多花半小时核对，也别指望后面能悄悄改掉。

## 词干还原能不能把两个形态并回去

技术上的第一反应是让词干还原器替你摆平。

波兰语和俄语都有成熟的词干还原算法，把两个形态削到同一个词干在多数情况下是做得到的。

但这条路有个前提：削完之后不能把不该并的词也并进来。

而斯拉夫语的形态密度很高，削得越狠误并的概率越大，这一点在否定构词那一篇 (https://zhangwenbao.com/minor-language-negation-affix-exclusion-keyword-trap.html)里已经吃过一次亏。

比较稳的做法是不依赖还原器，直接在同义词表里把形态对显式写死。行数不多，行为可预测，出了问题一眼能查到是哪一行。这个取舍的原则是：形态数量有限且可枚举时，宁可查表也别算法。

另外要留意的是还原器的版本。同一个算法不同实现之间在后缀清单上会有出入，换一次搜索引擎版本可能就把你验过的行为改掉了。显式写死的同义词表没有这个问题，它的行为跟版本无关。

## 关键词表要为这件事多加哪几列？

## 一个布尔字段不够用

最容易想到的方案是加一列是否有生，填是或否。

跑两天就会发现不够，因为有相当一批词的答案是两者都有。

摇摆状态如果被硬压成一个布尔值，信息就在入库那一刻丢了。

后面的人看到这一列会以为它是确定的，不会再去查语料。

所以这一列的取值至少要有三档：稳定有生、稳定无生、两可。第三档不是数据缺失，它是一个有信息量的结论，代表这个词的两个形态都要进匹配层。

三档这个设计还有一个好处：它逼着填表的人承认自己不确定。布尔字段会诱导人猜一个，三档给了不确定一个合法的落点，而这个落点恰好对应一个明确的动作，也就是两个形态都进匹配层。

## 规范形态和口语形态各占一列

光有一个分类还不够，形态本身要落成字符串。

词表里要有一列规范形态、一列口语形态，两列都填实际的字符串而不是规则描述。

这样下游取用的时候不需要懂语法，取哪一列由位置决定。

展示层取规范列，匹配层两列都取，逻辑简单到可以写进配置。

这一步还有个附带好处：两列并排放着的时候，谁在什么时候把哪一列改动过是一目了然的，而如果只存一个规则描述，改动就会淹没在讨论里。

## 复核触发条件要写清楚

最后一列是时间。

这批词的归属会随时间漂移，而且没有任何机构会发公告。

所以复核不能等通知，只能主动排日历。

建议记的是下次复核日而不是上次确认日，前者是一个动作，后者只是一条记录。

触发条件除了日历还要加一条：新品类上线时必须为新词跑一次。新词是最不稳定的一批，而新品类的词又几乎全是新词，两者叠在一起正好是风险最高的时刻。

另外建议把这一列的粒度定在词而不是品类。同一个品类里的词跨界程度可以差很远，按品类打包复核会把稳定的词和摇摆的词混在一起，下次翻开表的人分不清哪些是查过的哪些是估的。

## 一套两天能跑完的排查流程

## 第一步，把品类词按有生性分三堆

先不查任何东西，凭常识把词表分堆。

明显指活物的一堆，明显指器物的一堆，剩下拿不准的进第三堆。

这一步不需要懂波兰语，看中文词表就能分，一个人半小时能过六百条。

分完之后你会发现第三堆通常只有几十条，工作量一下子就可控了。

这里有个筛选技巧：优先看那些经常出现在买和有后面的词，它们跨界的概率最高。而这批词跟你的核心商业词高度重合，所以先排它们的投入产出比也最好。

分堆的时候建议顺手记一列理由，哪怕只写两个字。半年后复核的人看到理由才知道当初是查过的还是估的，没有这一列的表格在第二次复核时只能整张重做。

## 第二步，拿语料验摇摆的那一堆

第三堆逐条丢进语料库检索。

两个形态各查一次，记下出现次数和比例。

比例悬殊的直接定档，接近对半的标成两可。

整个过程是机械的，可以交给任何一个会用浏览器的人做。

唯一需要注意的是把动词一起带上查，单独查名词形态会混进别的格。这一条是这套流程里最容易被省掉、也最容易导致结论反过来的一步，别省。

还有一个能省时间的做法：把查询串预先拼好放进表格，验的人只需要复制粘贴。这一步看着琐碎，但它把一件需要理解的工作变成了一件只需要执行的工作，能交出去的工作才有可能真的被做完。

## 第三步，把结论写成开发能执行的规则

验完之后要落成配置，不能停在一份表格上。

交给开发的东西应该是同义词表的增量行，不是一段语法说明。

规则描述会被理解错，字符串对不会。

顺带把筛选器取值和结构化数据的别名字段一起改掉，三处改动本来就是同一批数据。

验收的时候不要问开发是不是理解了生命度，问他把这一百行配置导进去之后，站内搜索这一百个查询是不是都有结果了。这个问法不需要任何语言学背景，而且答案是二值的。

还有一个交付细节：把这批配置单独放一个文件，别混进主同义词表。这样下次复核的时候你能一眼看出上次改了什么，也能在出问题时整体回滚，而不用在几千行配置里找那一百行。

## 第四步，验收只看三个数

上线之后盯三个数字就够。

第一个是宠物类查询的零结果比例，它应该在几天内明显下降。

第二个是站内搜索里两个形态各自的出现次数，用来确认用户确实在用口语形态。

第三个是这批词对应品类页的展现量，它的变化会比点击更早出现。

三个数里第一个最快见效也最容易解释，适合拿去汇报；后两个是给自己看的，用来判断这次改动的方向对不对，以及下一批该往哪儿扩。

三个数之外还可以补一个定性的检查：随机挑十条改动过的查询，自己在站内搜索里跑一遍，看返回的商品对不对得上。数字会告诉你有没有结果，只有亲眼看一遍才知道结果是不是相关的。

## 哪些事不归这一层管

## 格系统本身不在这篇里

这篇只处理一个问题：宾格该走哪一套形态。

一个名词总共有几个格、每个格长什么样、哪几个格会出现在搜索框里，这些是另一件事。

那部分在波兰语七个格那一篇 (https://zhangwenbao.com/polish-seo-seven-cases-diacritics-keyword-research.html)里已经按格拆过一遍，方法论可以直接拿来用。

两篇的关系是：那一篇告诉你要覆盖哪几个格，这一篇告诉你其中一个格里还藏着一个二选一。

把两件事混在一起谈是这个话题最常见的误区，混完的结果通常是词表膨胀好几倍，而真正漏掉的那批查询还是没接住。

## 锚文本的变形是另一篇的事

内链锚文本在这类语言里会跟着句子变形，这也是一个真问题。

但它的处理逻辑跟关键词表不同，因为锚文本的形态由行文决定，不由你选。

锚文本变形那一篇 (https://zhangwenbao.com/minor-language-internal-link-anchor-inflection-variants.html)讲的是怎么把审计口径从字符串换成词干。

这一篇不重复那一套，只补一句：做锚文本审计时，有生形态和无生形态要算成同一个词的两个形态，别当成两个不同的锚。

否则你会看到锚文本多样性这个指标虚高，而它虚高的原因纯粹是语法，跟你的内链策略一点关系都没有。

顺带提一句，锚文本这一层跟本文的关系其实是单向的：把形态处理好之后锚文本审计会跟着变准，反过来则不成立。所以两件事要做的话先做词表这一层，顺序反了会白算一遍指标。

## 引擎那一半交给平台层

最后还有一半功课不在语言这一层。

搜索引擎自己怎么处理形态变化、本地搜索引擎跟通用搜索引擎的处理有没有差别，这些属于引擎的行为。

本站把引擎那一半放在平台与多引擎那个方向里单独讲，这篇不展开。

把两边分开的好处是判断责任归属时不会互相甩锅：形态没覆盖是你的事，覆盖了还是不出现才轮到去查引擎。

顺序反过来的团队通常会在引擎行为上花掉几周时间，最后发现问题在自己的词表第三列里。这个顺序值得写进排查手册的第一行。

划清这条边界还有一个组织上的好处：语言这一层的活可以交给内容和本地化的人，引擎那一层要找技术或者投放的人。责任分不清的时候，两拨人会同时觉得这件事归对方管，于是它谁都不做。

## 常见问题解答

## 不懂波兰语，怎么自己判断一个词该走哪一套形态？

有一条几乎不需要语言能力的路径。先把这个词的两个候选形态写出来，规范形态就是词典原形，有生形态是在词尾加一个特定字母，这一步查任何一部在线波兰语词典的变格表都能拿到。然后把两个形态分别丢进波兰语国家语料库的检索界面，记下各自的出现次数。数字差十倍以上的直接定档，接近对半的标成两可。整个过程你需要的语言能力为零，需要的只是知道该查哪两个字符串。

要提醒的是查询时把买或者有这个动词一起带上，否则会混进其它格的形态，得到的比例是假的。做完之后可以再花十分钟把结论发给本地同事确认一遍，但确认的问题要问得具体，问他平时会怎么打这个查询，而不是问哪一种写法正确。另外提醒一点，语料库检索出来的次数不要直接当成搜索量看，它反映的是这个形态在书面语里的流通度，量级和口径都跟搜索工具不一样。

## 只做匹配层的覆盖，页面上完全不用口语形态，行不行？

大部分情况下可以，而且这是最稳妥的起步方案。匹配层包括站内搜索的同义词表、广告关键词、结构化数据的别名字段，这三处全部收两个形态，成本很低而且没有任何观感风险。页面可见文本继续用规范形态，标题和面包屑保持整齐。这样做能接住绝大部分的量，因为搜索引擎在处理形态变化上本来就有一定能力，你要做的是别让站内那一层先拒绝用户。

等这一版跑一段时间之后，再看要不要在正文里补几处口语形态。补的时候记住只补正文和问答区，别动标题，标题是搜索结果页上唯一露出的一行字，观感成本最高。还有一个附带的好处是这个方案完全可逆，如果后面发现效果不明显，把同义词配置删掉就回到了原样，不留任何痕迹。

## 词干还原器能不能一次性解决这个问题？

能解决一部分，但不建议只依赖它。斯拉夫语的成熟词干还原算法确实能把有生形态和无生形态削到同一个词干，站内搜索接上之后召回会立刻改善。问题在于这类算法是按后缀规则工作的，削得越狠误并的概率越大，而斯拉夫语里字符串相近语义相反的词对并不少见。更现实的方案是两条腿走路：还原器负责兜底，覆盖那些你没预料到的形态；同义词表负责核心词，把最重要的那一两百个词对显式写死。

这样出了问题能一眼看出是哪一行配置的事，而不用去猜算法这次为什么削多了一刀。如果只能选一条，选同义词表，因为它的行为是可预测的。另外提醒一句，站内搜索引擎自带的语言分析器不一定装了这门语言的模块，上线前先确认一下，别把它默认当成已经装好的。

## 这件事在广告投放那一侧会不会也有影响？

有，而且比自然搜索那一侧更直接。广告的关键词匹配是按词元工作的，形态不同在某些匹配类型下会被当成不同的词处理，于是你出价的那个形态可能恰好不是用户打的那个。更麻烦的是否定关键词，如果你只否定了一个形态，另一个形态的流量会照样进来，钱就白花了。稳妥做法是把两个形态成对加进关键词列表和否定列表，两边都要成对，缺一边比两边都不加还糟。

搜索词报告是最好的校验工具，跑两周之后把实际触发的搜索词拉出来，看看有没有你没加过的形态混在里面，那批词通常就是你名单上还缺的那几条。还有一点容易忘：广告的搜索词报告只显示达到一定展现量的词，量小的形态不会出现在里面，所以那份报告能证明有、不能证明没有。

## 宠物之外的品类，需要花同样的功夫吗？

不需要花同样的功夫，但需要花一次功夫做筛查。判断标准很简单：这个品类的核心词里有没有指活物的。有的话按本文的流程走一遍，没有的话只需要检查那批可能跨界的物品词，也就是电子产品、汽车相关、烟酒这几族。绝大多数品类跑完筛查会发现只有个位数的词需要处理，半小时就完事。真正需要整批处理的只有宠物、水族、园艺里的活体植物这几个类目，它们的共同点是商品本身就是活的。

顺带说一句，即便是纯器物类目，品牌名那一层仍然要单独看，因为品牌名跨界跟品类无关。另外一个省事的筛法是看商品图，图里出现的是活物还是器物，这个判断连语言都不需要，一眼就能分完大半张表。

## 怎么跟不懂这门语言的开发解释这个问题？

别解释语法，直接给数据。最有效的说法是：这一百个查询在我们站内搜索里返回零结果，用户打的字符串在这里，我们商品标题里的字符串在这里，两者差一个字母。然后把一百行同义词配置递过去。开发不需要知道为什么差这一个字母，他需要知道的是导进去之后哪一百个查询应该有结果。如果对方追问原因，一句话就够：这门语言里指活物的名词在这个位置有另一种写法。

再多的语法细节只会让讨论跑偏，而且对落地没有任何帮助。验收也按同样的方式做，跑那一百个查询看返回条数，二值判断，不需要任何语言学知识。如果对方还是不放心，可以让他先只导一个品类的配置上线看效果，跑通之后再导全量，这比反复解释语法有效得多。

## 这批形态会不会随着时间变化，做完就得一直维护？

会变，而且方向是单向的：越来越多的物品词被拉进有生那一边，很少有反过来的。变化速度不快，以年为单位，所以半年复核一次完全够用，熟练之后一次一小时。复核的动作就是重跑一遍语料检索，看那批标成两可的词比例有没有明显移动。真正需要额外注意的是新品类上线的时刻，新词是最不稳定的一批，值得单独跑一次而不是等到下一个复核日。

另外建议把复核记录留在词表里而不是留在文档里，因为文档会被人遗忘，而词表每次改动都要被打开。这一点跟别的语言维护工作是一样的道理：让检查项待在人每天都会经过的地方。还有一个信号可以顺手盯：如果某个词的口语形态在站内搜索里的占比连续两个季度上升，那它已经跨过去了，词表里那一格该改成稳定有生。



## 小语种内容里写本地的事占多少？30门语言拆下来乌兹别克语4%，英语53%

- URL：https://zhangwenbao.com/minor-language-content-local-topic-share.html
- 分类：小语种SEO
- 发布：2022-08-25  |  更新：2022-08-25
- 摘要：30门语言各抽220条实测公共内容的国别构成：剔除名录型条目后本地题材占比4.3%到68.6%，英语53.2%；本地条目跨语言覆盖中位2门，外国条目24门。
- 关键词：竞品分析,多语言SEO,内容运营,小语种SEO

> **TLDR**：摘要：三十门语言各随机抽两百二十条公共内容，逐条判定它讲的是哪个国家，时点截到2022年6月底。剔掉能从名录成批生成的条目之后，写本地的占比最低是乌兹别克语4.3%，最高是泰米尔语68.6%，英语53.2%，中位数落在27%。这个数跟内容总量的相关系数只有0.100，等于没有关系。最硬的一条是跨语言覆盖：本地题材的条目中位只有2门语言写过，外国题材是24门——你打算翻的那批，别人已经翻了二十几遍；翻不进来的那批，才是你能占住的位置。

> 摘要：三十门语言各随机抽两百二十条公共内容，逐条判定它讲的是哪个国家，时点截到2022年6月底。剔掉能从名录成批生成的条目之后，写本地的占比最低是乌兹别克语4.3%，最高是泰米尔语68.6%，英语53.2%，中位数落在27%。这个数跟内容总量的相关系数只有0.100，等于没有关系。最硬的一条是跨语言覆盖：本地题材的条目中位只有2门语言写过，外国题材是24门——你打算翻的那批，别人已经翻了二十几遍；翻不进来的那批，才是你能占住的位置。

## 内容量这个数，答不了“这些内容讲的是哪儿的事”

## 你手上那张表只有一列

做小语种排期的时候，几乎每个人手上都有一张表，一列语言，一列内容量。这门语言有多少页、多少条、多少篇，数字一排，看着就有了判断依据。

问题是这一列什么都没说。十万条内容可以是十万条关于本国城市和本国人物的记录，也可以是十万条从别处搬来的通用知识，两者在表里长得一模一样。

而这两种情况对你的意义正好相反。前一种说明当地已经有一批人在认真写自己的事，后一种说明关于这个地方的内容其实还没人写。

更麻烦的是这一列还很容易被当成决策依据。它是唯一一个能横向排序的数字，排完之后看起来像一份优先级清单，实际上它只回答了一个问题：这门语言的页面有多少张。

而这一列背后其实还站着另一个更基本的问题：这些页面到底是几个人写出来的 (https://zhangwenbao.com/minor-language-content-volume-editor-count.html)。

## 同样十万条，写的可以全是外国

这不是假设。抽样量下来，有几门语言的内容池子里，关于本国的条目占比是个位数，剩下的绝大部分讲的是别的国家的人、别的国家的地方、别的国家的作品。

你可以把它想成一间本地图书馆，书架是满的，但架上的书讲的都是别处的事。走进去的本地人想查一件本地的事，多半查不到。

对做内容的人来说，那间图书馆里空着的那一格，就是这门语言里最容易占住的位置。

这件事在预算会上很难讲清楚，因为它没法用一个现成的指标表达。你说这个市场的内容量不小，对方问那竞争激烈吗，你只能说不知道——问题就出在这儿，量和竞争之间隔着一层没人量过的东西。

本站早前量过一次洗衣机这类最普通的品类词在多少门语言里还是空的 (https://zhangwenbao.com/minor-language-content-gap-category-words.html)，那次查的是有没有，这次查的是写的是哪儿。

## 这跟内容是不是搬来的不是一回事

上一次量的是内容的来路，这次量的是内容的题材，两条轴独立。内容里有多少是从别的语言搬来的 (https://zhangwenbao.com/minor-language-content-translated-share.html)那一篇算完之后，留下的正是这个问题：搬进来的和自己写的，讲的是不是同一批东西。

一门语言完全可以自己动手写一大堆关于外国的东西，也可以从外语搬进来一批关于本国的东西。前者在数据里很常见，后者少得多。

所以别指望用来源那个数推出题材这个数，两个都得单独量。

举个具体的例子。一门语言里有一批关于本国节庆的条目，可能是本地人自己写的，也可能是某个国际项目组织人翻译进来的。来源不同，题材相同。反过来，本地人熬夜写出来的一篇欧洲足球俱乐部介绍，来源是本地的，题材是外国的。

## 这件事在英文市场几乎不用问

英语的内容池子里关于英语国家的部分本来就厚，做英文内容的人不会碰到“关于我这个市场的资料根本没人写”这种局面。

小语种不一样。这门语言的使用者集中在一两个国家，可这门语言的内容池子完全可能不围着那一两个国家转。这个错位是小语种独有的，把语种换成英语就不成立。

所以做英语内容的人给出的方法论，在这一层是不适用的。他们讲的选题技巧默认脚下有一大片现成资料可以站，而你要做的那门语言，那片资料可能压根不存在。

所以按母语人口给语言排优先级 (https://zhangwenbao.com/minor-language-seo-priority-language-cost-model.html)那套算法，在这一层上完全使不上劲。

## 本文量什么、不量什么

量的是公共知识池子的题材构成，一个背景读数。不量内容质量，不量收录排名，不量你那个品类的竞争强度。

用法是开工之前先看一眼刻度，知道自己面对的是一个已经被本地人写满的市场，还是一个连本地的事都还没人写的市场。这两种市场的打法完全不同。

还有一个用法是拿它做说服材料。跟不了解这门语言的人解释“为什么不能照搬英文站的选题清单”，一个具体的百分比比十句形容词管用。

关键词工具在这些语言上返回的那个零是数据缺口不是需求缺口 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)，这一条同样适用于内容量。

## 怎么在外面把“写的是哪儿的事”量出来？

## 先要一批能逐条判出国别的内容

这件事听着简单，做起来第一个坎是样本。你没法把一门语言的整个互联网抓下来，也没有哪家工具会告诉你某个站点的内容讲的是哪个国家。

能满足条件的公开语料其实只有一类：条目本身挂着结构化标注的百科型内容。每个条目背后有一个数据项，数据项上写着这东西属于哪个国家、这个人是哪国国籍、这个组织总部在哪。

这批数据的好处是它可以按时间截断，坏处是它只代表百科型内容，不代表整个语言的互联网。后面那条边界我会单独说清楚，先把量法讲完。

退一步说，即使能把整个互联网抓下来，你也没法逐页判断它讲的是哪个国家——那需要读懂内容。结构化标注的价值就在这儿：它把“读懂”这一步变成了查表。

## 抽样：在页面编号空间里随机取

常见做法是用随机条目接口，但那个接口给的是今天还存在的条目，没法回到某个时点。所以换了另一条路：直接在页面编号的整数空间里随机取。

每个页面在建立的那一刻拿到一个递增的编号，编号一旦分配就不再变。取一个编号区间的随机整数，再问接口这些编号今天对应什么页面，就得到一批不带任何主题偏好的样本。

接口一次能问50个编号，返回里带命名空间、是不是重定向、以及对应的数据项标识。只留正文命名空间、非重定向、并且能对上数据项的那些，其余丢掉。

这么抽会拿到不少空号和非正文页面，因为编号是所有类型的页面共用的，删掉的页面留下空洞。这些全部丢掉，代价是多问几次接口，好处是样本没有任何主题偏好。

接口的具体参数和返回结构可以查页面属性接口的说明 (https://www.mediawiki.org/wiki/API:Pageprops)，一次最多问五十个编号。

## 截断：先拿编号当水位，再逐页复核

要把时点定在2022年6月底，得知道那天的编号水位在哪儿。做法是查那天之前的页面创建日志，取一批事件的编号分布。

这里踩了一个坑，值得单独讲。第一版我取的是那批事件里最大的编号，结果老挝语的样本里有26% 落在截断点之后——页面编号并不严格单调，页面移动和批量导入都会打乱它。

改法有两步。水位改取75分位而不是最大值，把绝大多数越界样本挡在门外；然后每门语言抽45条逐页去查首版时间，把这把尺子的误差实测出来，而不是假设它准。这一步的结果后面会报。

复核的结果是：按75分位取水位之后，30门语言的越界样本全部为零，首版时间查询失败也是零。这把尺子在这个用法下是干净的，但前提是不能用最大值。

首版时间要用修订接口按时间正序取第一条 (https://www.mediawiki.org/wiki/API:Revisions)，这个参数组合一次只能问一个页面，没有批量写法。

## 判国别：一条属性链，直的和要拐弯的

拿到条目之后，判它讲的是哪个国家。数据项上能直接给出答案的属性有几个：国家这个属性 (https://www.wikidata.org/wiki/Property:P17)管地点、机构、作品，国籍这个属性 (https://www.wikidata.org/wiki/Property:P27)管人物，另外还有原产国、适用管辖区这几个。

直接给不出的，要再拐一道弯。比如一个条目只写了它位于某个行政区，那就再查那个行政区属于哪个国家；一个人只写了出生地，就查那个出生地在哪国。最多拐两跳，拐不到就算判不出。

这条链是自己定的，不是现成的，所以我在文章里把它完整写出来，你可以照着复现，也可以质疑其中某一环。

还有一处细节值得说：同一个地方有时候有两个数据项，比如荷兰王国和荷兰是分开的两条。不把它们并成一个，荷兰语的外部第一名会算成荷兰自己，那显然是错的。这类等价对我逐个合并了，历史上的几个德国也一样。

## 分子和分母来自同一批抽样

这条是上一批留下的教训。当时分子取一个接口、分母取另一个接口，两个口径差了1.27到2.38倍，越南语的数字因此虚高了一半还多。

所以这次分子分母是同一批条目：分母是抽到的全部条目，分子是其中判定为本地国的那些。中间不换数据源，不换时点，不换筛选条件。

另外报第二个口径：只在判得出国别的条目里算本地占多少。两个数一起看，才知道结论有没有被判不出的那部分带偏。

这条规矩听起来是常识，实际执行时最容易破。因为不同接口给的数据丰俭不一，人总会忍不住去更全的那个接口取分子，取完之后忘了分母还留在原来那个口径上。

## 判不出国别的那一半，是数据缺，还是真的没国别？

## 先看它们都是些什么东西

30门语言各抽220条，判得出国别的比例从三成到八成不等，中间那一大块判不出来。这一块不搞清楚，整套数就只是个半成品。

把它们的类型打出来看，第一批是本来就没有国别的：日期页、年份页、消歧义页、生物分类单元、数学概念、学科名。老挝语的样本里光是日期限定词就有20条。

第二批才是问题：本该有国别但数据项是空的。僧伽罗语抽到一条“西方省”，那是斯里兰卡的一个省，数据项上却没写它属于哪国。

这两批混在一起，会让人得出完全相反的判断。把它们统统当成“没有国别”，本地占比会被高估；统统当成“数据缺失”丢掉不算，本地占比会被低估。所以必须先估清楚两批各占多少。

## 用一个不依赖国别的办法验一遍

要判断第二批偏向哪边，得找一个跟国别无关的信号。我用的是跨语言覆盖数：这条内容一共有几门语言写过。

理由很直接。本地专属的东西别的语言不会写，通用知识则是几十门语言都有。所以覆盖数低的，多半是本地题材。

这个信号的好处是它跟属性链完全独立，属性链判错不会影响它。

这个信号还有一个附带的好处：它不需要我读懂那门语言。一条僧伽罗语条目讲的是什么我看不懂，但它在别的语言里有没有对应页面，接口直接会告诉我。

## 结果是判不出的那批明显偏本地

合并30门语言的样本，判定为本地的条目跨语言覆盖中位数是 2门，判定为外国的是 24门，判不出国别的是7门。

再看极端两头：本地条目里36.0% 只有这一门语言写过，外国条目里这个比例只有2.6%；反过来，有20门以上语言写过的，外国条目占55.6%，本地条目只占5.4%。

判不出的那批落在两者之间但明显更靠本地那头——只此一门的占27.5%。所以本地题材占比这个数是下限，真实值只会更高。

打开几条看也印证了这一点。僧伽罗语那批里有西方省的区秘书处、有本地寺庙相关的条目；豪萨语那批里有豪萨手工业史、豪萨嘻哈；高棉语那批里有本地寺庙和乡分区。全是外面没人会写的东西。

这跟从页面的壳上认翻译痕迹 (https://zhangwenbao.com/minor-language-translation-trace-shell-not-text.html)是同一个思路：正文里量不出来的东西，换一个跟正文无关的信号常常能量出来。

## 两个口径都报，别只报好看的那个

后面的表里我给两列：一列分母是全部抽样条目，一列分母只算判得出国别的。判定率高的语言两列差得少，判定率低的语言差得多。

看表的时候先扫一眼判定率那一列。低于四成的语言，它的数字要打个折再用。

顺带说一句，判定率低本身也是一个信号，说明这门语言的内容在结构化数据这一层被照顾得少。这跟内容多少无关，跟有没有人去补数据项有关。

## 一门语言的内容里，有多少是能从一张表成批生成的？

## 第一版算出来的结果不对劲

按上面的方法算完第一版，外部指向的第一名是这样的：乌兹别克语指向美国，越南语指向法国，缅甸语指向日本。

越南语指向法国还说得通，殖民史摆在那儿。乌兹别克语指向美国就有点怪，缅甸语指向日本更怪。

打开条目一看就明白了。乌兹别克语那批“美国”是Donaldson（阿肯色州）、Ekwok（阿拉斯加州）这类小镇；越南语那批“法国”是清一色的法国市镇；缅甸语那批“日本”是日本的火车站和町村。

当时最危险的地方在于，这三个结论都能编出一套听着很顺的解释。乌兹别克斯坦有大量劳务移民、缅甸和日本有历史往来、越南和法国有殖民史——每一条都说得通，每一条都不是真的。

## 这不是内容，是导进来的表格

这些条目有一个共同点：它们能从一份现成的名录里成批生成，一行一条，标题连翻译都省了，乌兹别克语版直接写着Saint-Étienne-sur-Usson。

它们在页面总数里跟别的条目一样是一票，可它们的国别只反映一件事——谁家的行政区划表被导进来过，跟这门语言的人关心什么毫无关系。

换句话说，第一版量到的不是“这门语言在写哪个国家”，是“哪个国家的表格被跑过一遍”。

一个很直接的验证办法：看标题有没有被翻译。乌兹别克语版的美国小镇标题原样写着拉丁字母，一个西里尔字母都没有。这说明连搬运的人都没打算让本地读者读它。

## 所以先按类型分一刀

解法是按条目类型分层：把能成批生成的挑出来单独算。我用的清单包括行政区划与聚落、铁路车站、生物分类单元、天体、河流湖泊山岛、年份与日期、消歧义页与列表页。

这份清单是我定的，不是现成标准，所以我把它原样写在这里，你可以质疑其中任何一项，也可以自己改一版重算。

剩下的那一堆——人物、机构、作品、事件、概念——是需要有人一条条写出来的，我叫它人写内容。

分层这一步不改变任何原始数据，只是把同一批样本按类型拆成两堆分别算。所以两个口径可以并排放，也可以随时换一份清单重算，不需要重新采集。

## 名录型占比本身就是一个读数

算出来的分布很吓人。越南语的样本里 75.9% 是名录型，其中光是生物分类单元就有137条；瑞典语67.7%、荷兰语67.3%，也是物种；缅甸语57.3%，是聚落。

最离谱的是约鲁巴语：220条样本里 97条是小行星，占44%。这门语言的公共内容里，将近一半是编号小行星。

另一头，豪萨语只有6.8%、高棉语9.1%、蒙古语11.4%、孟加拉语11.8%。这几门语言的内容基本是人一条条写出来的。

这个读数可以直接拿去改“内容量”那一列。一门语言号称有一百万条，名录型占七成，真正有人写的是三十万条——后面这个数才该进你的竞争分析。

这批页面还有一个特征：随机翻开一页几乎没有人读 (https://zhangwenbao.com/minor-language-page-reader-median.html)。

## 跟内容总量正相关，所以大维基的水分更大

名录型占比跟条目总数取对数之后的相关系数是 +0.476。内容规模越大的语言，名录型的比例越高。

这条跟直觉相反：一般人默认内容多的语言更成熟，实际上多出来的那部分里有相当比例是程序跑出来的。

这条也解释了为什么按内容量排出来的语言优先级经常反直觉。排在前面的那几门，多出来的部分有相当比例不是人写的，而排在后面的小语种，剩下的那点内容反而都是真的。

## 30门语言的本地题材占比排出来是什么样？

## 最低的那几门

按人写内容口径算，本地题材占比最低的是乌兹别克语 4.3%，然后是格鲁吉亚语7.2%、阿塞拜疆语7.5%、亚美尼亚语7.6%、越南语10.0%。

乌兹别克语这个数值得单独说一句。它的人写内容只剩96条，判得出国别的47条，其中判为乌兹别克斯坦的只有2条。样本小，置信区间宽到1% 到14%，但方向是明确的。

这几门语言的共同点是内容规模不算小，而关于自己国家的那一格几乎是空的。

格鲁吉亚语、阿塞拜疆语、亚美尼亚语这三门挨在一起也不是巧合。它们的内容池子里有一大块是苏联时期和周边国家的条目，本国那一格反而薄。这在前苏联地区的几门语言上是普遍现象。

## 最高的那几门

最高的是泰米尔语 68.6%，然后是英语53.2%、孟加拉语50.7%、爱沙尼亚语41.8%、豪萨语39.7%、德语38.9%。

泰米尔语这个数有个背景：泰米尔语的使用者主要在印度泰米尔纳德邦和斯里兰卡，我把印度、斯里兰卡、新加坡、马来西亚都算成本地，范围比单国语言宽，所以偏高是合理的。

英语53.2% 才是最值得注意的那一个。做英语内容的人，脚下有一半以上是关于自己这块地的资料；做乌兹别克语的人，脚下只有二十几分之一。

孟加拉语50.7% 同样值得注意。它的名录型占比只有11.8%，也就是说这个数几乎全部来自人写的内容——孟加拉语社群是真的在写自己的事。

泰米尔语和孟加拉语的背景可以对照印度那十一门语言的排期 (https://zhangwenbao.com/india-multilingual-seo-eleven-languages-nine-scripts-priority.html)那一篇。

## 中位数落在哪

30门语言的中位数在27% 上下。也就是说，一门语言的公共内容里，大约四分之一讲的是自己这块地方，其余四分之三讲的是外面。

这个比例听起来不高，但它是中位数——低于它的那一半语言，本地那一格更空。

换个说法可能更有体感：你打开这门语言的公共内容随便翻四页，大概只有一页讲的是本地。剩下三页讲的是别处，而那三页的内容在别的语言里都能找到。

各语言的条目总数取自各语言版本的规模清单 (https://meta.wikimedia.org/wiki/List_of_Wikipedias)，同样截到2022年年中。

## 两个口径差得最多的那几门

缅甸语是最戏剧性的一个。按全样本算，它的本地题材占比高达78.2%，排第一；剔掉名录型之后掉到 22.2%，排到中下游。

原因是它那220条样本里有104条人类聚居地，绝大多数是缅甸自己的村镇——一份缅甸地名表被导了进来。同样的情况在尼泊尔语（42.3% 掉到25.8%，村发展委员会26条）和高棉语（44.2% 掉到31.1%，乡分区13条）也发生了。

这三门语言看起来“本地内容很足”，实际上足的是地名表，不是内容。这一条是本批最该记住的判读陷阱。

识别这种情况其实不难，看名录型那一列就够了。名录型占比超过四成，本地占比那个数就不能直接用；再看那批名录是本国的还是外国的，方向立刻清楚。

语言 | 名录型占比 | 本地题材占比（全样本口径） | 本地题材占比（人写口径） | 

乌兹别克语 | 56% | 1.3% | 4.3% | 

格鲁吉亚语 | 38% | 10.8% | 7.2% | 

阿塞拜疆语 | 34% | 11.3% | 7.5% | 

亚美尼亚语 | 37% | 7.5% | 7.6% | 

越南语 | 76% | 7.8% | 10.0% | 

阿姆哈拉语 | 27% | 12.9% | 13.1% | 

蒙古语 | 11% | 13.9% | 14.0% | 

老挝语 | 18% | 18.9% | 18.8% | 

约鲁巴语 | 49% | 19.0% | 19.5% | 

缅甸语 | 57% | 78.2% | 22.2% | 

泰语 | 14% | 23.9% | 22.8% | 

尼泊尔语 | 25% | 42.3% | 25.8% | 

僧伽罗语 | 13% | 33.3% | 27.6% | 

高棉语 | 9% | 44.2% | 31.1% | 

斯瓦希里语 | 22% | 33.1% | 34.1% | 

德语 | 19% | 37.3% | 38.9% | 

豪萨语 | 7% | 39.2% | 39.7% | 

孟加拉语 | 12% | 52.1% | 50.7% | 

英语 | 24% | 50.0% | 53.2% | 

泰米尔语 | 18% | 73.8% | 68.6% | 

## 反方向也有

爱沙尼亚语和德语反过来：剔掉名录之后本地占比不降反升（37.5% 到41.8%，37.3% 到38.9%）。它们的名录型主要是物种和消歧义页，指向国外或者压根没国别，剔掉之后本地那部分的比重反而显出来。

所以这一步不是单方向的修正，是两个方向都会动。不做这一步，排行榜的前几名和后几名都是错的。

所以我不建议只报一个口径。两个都摆出来，读者能自己看出哪几门语言的数字需要额外小心，这比我替他们做一次修正更可靠。

## 内容多的语言，本地那一格是不是更满？

## 跟内容总量的相关是零

把30门语言的条目总数取对数，跟本地题材占比算相关，得到的是 +0.100。四舍五入就是没有关系。

这意味着你没法从“这门语言有多少内容”推出“这些内容里有多少是关于它自己的”。两个数必须分别去量。

拿两组对照最直观：越南语127万条对老挝语4300条，差295倍，本地题材占比是10.0% 对18.8%，内容少的那门反而高一倍。

这跟上一批得到的结论是同一族：现成的规模指标推不出内容的成分。上一批查的是内容从哪来，四个现成指标的相关系数全落在零附近；这一批查的是内容写什么，相关系数是0.100，还是零。

越南泰国印尼这三门的对比，跟把它们放进同一张东南亚预算表 (https://zhangwenbao.com/southeast-asia-seo-vietnam-thailand-indonesia-language-layer.html)那次得到的结论是一致的。

顺便一提，这类内容分布不均的现象有专门的研究方向，公开的知识缺口研究 (https://research.wikimedia.org/knowledge-gaps.html)把它拆成了内容、贡献者、读者三层，本文量的是第一层。

## 跟名录型占比的相关是负的

名录型占比跟本地题材占比的相关是 −0.312，弱负相关。名录灌得越多，本地那一格看起来越小。

但这个相关不能当因果用。缅甸语的名录灌的是本地地名，方向正好反过来。所以正确的做法还是分层算，不是拿这个相关去调整。

这也是为什么我不把名录型占比当成一个修正系数。它跟结果相关，但相关的方向随灌的是本国还是外国而变，用它做统一修正会把一部分语言修得更错。

## 跟判定率的相关要单独查

判不出国别的比例在各语言之间差得很大（从两成到七成），必须确认它没有把排行榜带偏。两个口径的相关系数是 +0.794：排序大体一致，但不完全一致。

不一致的那几个正是上面说的缅甸语、尼泊尔语、高棉语。所以这个0.794不是“可以放心用其中一个”的意思，是“有几门语言必须看另一个”的意思。

把0.794换成人话：三十门语言里大约有三门，你按其中一个口径读会得到明显错误的印象。麻烦在于你事先不知道是哪三门，所以只能两个都算。

## 成对样本比相关系数更能说明问题

格鲁吉亚语15.8万条、马其顿语12.8万条，规模差不到三成，本地题材占比7.2% 对27.4%，差3.8倍。

阿塞拜疆语19万条、立陶宛语20.5万条，规模几乎相同，7.5% 对31.8%，差4.2倍。

这两对说明的事情跟相关系数一样，但更硬：规模这个变量被控制住之后，本地题材占比照样可以差四倍。

成对样本还有一个好处，它不需要读者相信我的统计口径。规模差不到三成、结果差四倍，这句话本身就是证据，不依赖任何模型假设。

## 写的是哪儿，跟读的是哪儿，对得上吗？

## 读者那一侧怎么取

供给侧量完，还得看需求侧。取2022年上半年每门语言的月度最多阅读排行，把合计阅读量最高的那批条目按同一套属性链判国别。

两侧的判定逻辑完全一样，分母都取判得出国别的条目，所以差值可比。这一层每门语言取阅读量最高的一百条上下，样本比主表小，作用是验证方向而不是给精确值。

另外它天然绕开了名录型那个坑：热门榜上几乎见不到地名表和物种表。那批条目撑起了页面总数，却没有撑起任何阅读量。

选月度榜而不是单日榜是有原因的。单日榜会被当天的突发事件带走，量出来的是那天发生了什么；月度榜连取半年，反映的才是稳定的阅读结构。

阅读排行走的是公开的指标接口 (https://wikimedia.org/api/rest_v1/)，按月取，可以回到任意一个历史月份。

## 先剔掉读者侧的假数据

这一步差点被跳过。约鲁巴语算出来读本地只有1.5%，跟供给侧的19.5% 反着走，看着像个大发现。

打开榜单一看，前十二名分别是M、D、B、C、F、H、I、V、R、A、J、U——单个拉丁字母的页面，每个两千五百次左右。没有人会一个月里把字母M那一页读两千五百遍。

所以判读者侧的数据之前得先加一道自查：榜首十条里如果有一半是单字符、纯数字、日期这类没人会读的页面，整门语言的读数不能用。按这条约鲁巴语被剔除，其余二十九门通过。

这一条跟内容侧的名录型是同一个道理的两面：内容侧有一批页面是机器写的，流量侧有一批访问是机器发的。两边都得先把机器那部分挑出去，剩下的才是人和人之间的事。

这跟小语种访问量里有一大半不是人 (https://zhangwenbao.com/minor-language-crawler-share-traffic-report.html)那一篇量到的是同一件事，只是这次撞在了内容榜单上。

## 二十九门里二十六门，读的比写的更本地

僧伽罗语最夸张：写本地占27.6%，热门阅读榜上本地内容占91.3%，差63.7个百分点。

后面依次是印尼语25.6% 对72.1%、尼泊尔语25.8% 对70.8%、波斯语19.1% 对61.0%、缅甸语22.2% 对63.0%、越南语10.0% 对50.6%、泰语22.8% 对63.1%、荷兰语18.3% 对57.0%、斯瓦希里语34.1% 对69.7%。

二十九门的差值中位数是 +27.9个百分点。反过来的只有三门：豪萨语差6.3点、立陶宛语差10.0点、德语差2.2点——前两门本来就是本地题材占比偏高的那一档，供给这一侧已经跟上了。

还有一门波兰语几乎持平，写25.4% 读25.7%，差0.3点。这种持平状态才是内容供给和阅读需求对齐的样子，三十门里只出现了一次。

语言 | 写本地（人写口径） | 读本地（热门榜） | 读减写 | 

僧伽罗语 | 27.6% | 91.3% | +63.7点 | 

印尼语 | 25.6% | 72.1% | +46.5点 | 

尼泊尔语 | 25.8% | 70.8% | +45.0点 | 

波斯语 | 19.1% | 61.0% | +41.9点 | 

缅甸语 | 22.2% | 63.0% | +40.8点 | 

越南语 | 10.0% | 50.6% | +40.6点 | 

泰语 | 22.8% | 63.1% | +40.3点 | 

荷兰语 | 18.3% | 57.0% | +38.7点 | 

斯瓦希里语 | 34.1% | 69.7% | +35.6点 | 

阿塞拜疆语 | 7.5% | 41.9% | +34.4点 | 

蒙古语 | 14.0% | 43.1% | +29.2点 | 

阿姆哈拉语 | 13.1% | 41.0% | +27.9点 | 

老挝语 | 18.8% | 32.5% | +13.7点 | 

波兰语 | 25.4% | 25.7% | +0.3点 | 

德语 | 38.9% | 36.7% | −2.2点 | 

豪萨语 | 39.7% | 33.3% | −6.3点 | 

立陶宛语 | 31.8% | 21.8% | −10.0点 | 

## 这个差值怎么用

把它当成缺口读数。差值越大，说明这门语言里本地内容的供需错位越严重，而错位的方向对做内容的人是有利的：需求在，供给没跟上。

差值接近零甚至反过来的语言，说明本地那一格已经被填得差不多，要进去得拼质量而不是拼有没有。

还有一层可以直接抄的：把这套办法搬到自己的站上，就是拿站内搜索日志里带地名的查询占比，去比自己站上带地名的页面占比。两个数一减就是你自己的缺口。

要注意这个差值不能直接换算成流量预期。它说明的是结构性的缺口，不是某个具体关键词的搜索量。缺口大只代表这个方向值得试，具体投多少还得看词。

## 本地题材凭什么是唯一翻不进来的那一块？

## 先看一个数：这条内容有几门语言写过

前面为了验证漏判方向，顺手拿到了一列数据，它本身就回答了这个问题。判定为外国的条目，跨语言覆盖中位数是24门；判定为本地的，中位数是2门。

再看两头：外国题材里有20门以上语言写过的占55.6%，本地题材只占5.4%；反过来，本地题材里36.0% 只有这一门语言写过，外国题材只有2.6%。

把这两个数翻译成人话就是：你打算翻的那些内容，另外二十几门语言已经翻过了；而本地那批，根本没有源文可翻。

这个对比之所以硬，是因为它不依赖任何关于“本地”的定义。你可以不同意我把某个条目判成本地，但你没法否认它只有一门语言写过——那是一个客观事实。

## 能翻的都在被翻

通用知识有一个特点：它在哪门语言里都成立，所以谁都可以把它翻过去。一篇讲某个技术原理的文章，英语有、德语有、越南语也可以有，内容基本一致。

上面那个“中位24门”就是这件事的读数。这类内容的供给是无限的，因为翻译成本一直在往下掉。

你今天花力气把一篇通用指南翻成小语种，明年会有五家做同一件事，而且比你快。你在这一块上的领先只是时间差，不是壁垒。

机器翻译把这件事又推了一步。以前翻一篇通用指南要几天，现在几分钟，于是通用知识那一格的填充速度比任何人的产能都快。你在那一格里的位置随时会被覆盖。

## 翻不进来的是哪三类

第一类是本地的实体：本地的商家、本地的机构、本地的服务点、本地的展会。这些东西在别的语言里根本不存在，没有源文可翻。

第二类是本地的规矩：本地的税、本地的认证、本地的退货习惯、本地的付款方式。这些在别的语言里有对应概念，但取值完全不同，翻过来就是错的。

第三类是本地的价格与可得性：同一件东西在这个市场卖多少、从哪儿买、多久到。这一类连概念都对得上，就是数字换了，而这个数字只有在当地待过的人写得出来。

这三类有一个共同的成本特征：写它们的边际成本很低，但门槛很高。低在于你已经在这个市场做生意，这些信息本来就在你手上；高在于没在这个市场做过生意的人拿不到。

第一类的采集路径跟本地目录和本地社群那批外链渠道 (https://zhangwenbao.com/minor-language-link-building-local-directories-media-communities.html)高度重合，可以一趟跑完两件事。

## 竞争强度要按题材重算

把内容量当竞争强度，得到的是一个平均数。按题材拆开之后你会发现，同一门语言里通用知识那一格已经挤满了，本地题材那一格常常是空的。

所以正确的问法不是“这门语言的内容多不多”，而是“我要写的那一类内容多不多”。这两个问题的答案经常相反。

这也解释了一个常见的困惑：明明数据显示这个市场内容量很大，实际做进去却发现关于本地的具体问题一篇都搜不到。数字没错，只是它统计的不是你要的那一格。

重算的动作也不复杂。把你原来那张内容量的表加两列：名录型占比、本地题材占比。三个数一起看，语言的优先级排序常常会整个翻过来。

## 这个数怎么改你的选题清单？

## 三档判读线

本地题材占比在两成以上的，按正常竞争市场对待，当地有一批人在写自己的事，你得拿出真东西才进得去。

一成到两成之间的，通用知识那一格有人占，本地那一格半空，选题优先往本地实体和本地规矩上压。

一成以下的，这门语言的公共内容基本没在写本地的事，本地题材整片空着。这一档反而是最值得投的，前提是先确认有没有人搜。

这三档不是拿统计方法切出来的，是按三十门语言的实际分布和对应动作反推的。分界线附近的语言不用纠结落在哪一档，两档的动作差别本来就不大。

豪萨语和斯瓦希里语这两门可以对照在非洲选语种别先看人口 (https://zhangwenbao.com/africa-market-language-selection-swahili-hausa-francophone.html)那一篇的判据。

## 低本地率市场先做什么

先做本地实体页：城市、服务点、合作商家、常见问题里带地名的那些。这批内容没有源文可翻，也没有对手在做。

再做本地规矩页：税费怎么算、认证要哪些、退货能不能寄回去。这批内容的搜索量不高，但转化极硬，而且写完两年不用改。

最后才是通用知识的本地化版本。顺序反过来的话，你会在最挤的那一格上花掉全部预算。

顺序反过来的代价很具体：你会在通用知识那一格里跟一批已经把内容翻好的对手抢位置，而本地那一格空着没人碰，等你回头去做的时候已经晚了半年。

写这批内容的时候，本地作者署名那一层信号 (https://zhangwenbao.com/minor-language-eat-local-author-byline-credential-signals.html)值得一起配上，成本很低。

## 高本地率市场怎么切

本地题材已经被写满的市场，硬碰硬没意义。正确切法是往下一层找：本地的事写完了，但本地视角看外部的事往往还没写。

比如某个进口品类在当地怎么用、当地人买国外产品会踩哪些坑、跨境物流在这个国家的实际时效。这些题材既是本地的，又是当地社群没顾上写的。

另一种切法是往时间上找。本地社群写的多半是已经发生的事，正在发生和即将发生的那部分往往没人管。这一块的时效性强，但正因为时效性强，抄的人跟不上。

切的时候要留意同一门语言在两个市场的意图分叉 (https://zhangwenbao.com/minor-language-search-intent-divergence-across-markets.html)，别把两个市场的题材混成一份清单。

## 排期上怎么占位

本地题材的一个好处是它不怕被别人抄。抄的人拿不到你的一手信息，只能改写，而改写出来的东西一眼能看出没去过现场。

所以这批内容值得排在最前面，越早写完越早开始累积。通用知识那一批可以往后放，反正什么时候做成本都差不多。

排期上还有一个实际考虑：本地题材的采集要靠人跑，周期长。越早启动，交付的时间点越可控；压到最后再做，就只能拿通用内容顶上。

## 怎么在自己的市场上重做一遍？

## 没有百科数据的时候看哪三处

不是每个品类都有现成的结构化语料，多数时候你得自己看。三处最省力。

第一处是目标语言的结果页。搜你那个品类的核心词，把前二十个结果逐个打开，记下每个页面讲的是本地的事还是通用知识。二十条就能看出比例。

第二处是本地论坛和问答社区。那里的提问天然全是本地的，把高频提问归类之后，你会看到一批本地题材在正规内容里完全没有对应页面。

第三处是本地新闻站的分类导航。新闻站的栏目结构反映的是当地人关心什么，跟你的品类交叉一下，往往能挑出三五个没人写的题材。

三处都看一遍大概两个小时。别指望它们互相印证，多数时候三个结果会有出入，而出入本身就是信息——结果页偏通用、论坛偏本地，说明需求和供给之间有个口子。

## 一个下午能跑完的最小版本

取三十个词：十个品类词、十个交易词、十个带地名或本地机构名的词。逐个搜，每个词记两件事——前十个结果里有几个是本地站，有几个页面讲的是本地的事。

算两个比例，一个是本地站占比，一个是本地题材占比。前者告诉你竞争对手是谁，后者告诉你内容缺口在哪。两个数经常不一致，而不一致的那部分就是机会。

这套动作不需要任何工具，也不需要懂那门语言——判断一个页面讲的是不是本地的事，看地名、看货币符号、看电话区号就够了。

记录的时候建议留一列原始截图或者链接，因为过两个月你会忘了当时为什么把某一条判成本地。这一列的成本是零，回头复盘的时候很值钱。

## 多久重算一次

一年一次。这个数变得很慢，因为它反映的是一个社群长期的写作习惯，不是某次算法更新。

会让它明显变化的只有两件事：当地出现了一批新的活跃作者，或者你自己那个品类被某个大平台整体铺了一遍。两件事都不是几个月能发生的。

如果你所在的品类刚好赶上某个大平台进入这个市场，那要单独提前重算一次。平台铺内容的速度不是社群的速度，几个月就能把某一格填满。

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

## 内容质量不归这一层

这套数只回答一件事：这些内容讲的是哪儿的事。它不看这些内容写得好不好、长不长、有没有人维护。

一个只有两句话的本地地名条目，跟一篇写满的本地历史条目，在这份统计里是一样的一票。想知道内容有多厚多旧，那是另一把尺子。

所以别拿这份数据去论证“这门语言的内容质量差”。它只数了条目，一个字都没读。质量要另外抽样人工看，那是完全独立的一件事。

## 内容是谁写的、从哪儿来的，那半边已经写过

“这些内容是搬来的还是本地写的”跟“这些内容讲的是哪儿的事”是两条独立的轴，交叉起来是四个格子，不是一条线。

一门语言完全可以自己动手写了一大堆关于外国的内容，也可以从外语搬进来一堆关于本国的内容。前者在数据里很常见，后者比想象中少。

两条轴交叉出来的四个格子里，最值得注意的是“自己写的、写的是外国”那一格。这一格意味着本地社群有产能，但产能没用在本地题材上——这是最容易被撬动的一种局面。

## 架构与地区定向那半边归国际化那一层

语言标签怎么配、地区版本怎么分、跳转怎么做，这些是架构层的事，跟这门语言本身没关系。把语种换成英语，那些问题一样存在，所以不属于这里讨论的范围。

判据还是那一条：把语种换成英语之后问题还成不成立。语言标签配错这件事英语站一样会犯，所以它不属于这里；而“关于我这个市场的资料没人写”这件事，英语站基本碰不到。

## 百科数据代替不了商业调研

最后这条最重要。百科型内容的产出动机是志愿投入，商业内容的产出动机是搜索量，两批人关心的东西不一样。

所以这份数据能回答的是“这门语言的公共知识池子偏向哪儿”，它是一个背景读数，不是你那个品类的竞争分析。真要下预算，还得去看目标市场的实际结果页。

更实际的用法是拿它做排序而不是做决策。三十门语言摆在一起，你至少知道该先去实地看哪几门，这比按人口排或者按内容量排都靠谱。

## 常见问题解答

## 百科上的内容构成，能代表这门语言的整个互联网吗？

不能，这一点必须说在前面。百科型内容的产出动机是志愿投入，写什么由写的人自己的兴趣决定；商业内容的产出动机是搜索量和转化。两批人关心的东西不一样，产出的地理构成也就不一样。这份数据的正确用法是当背景读数：它告诉你这门语言的公共知识池子整体偏向哪儿，帮你在开工之前调整预期。真要决定某个品类投不投，还得去目标市场的结果页上实地看一遍。

## 为什么不直接数带地理坐标的条目，那样不是更简单？

因为带坐标的只有地点，人物、机构、作品、事件全都没有坐标，而这几类恰恰是内容池子里的大头。只数坐标会把结论变成“这门语言写了多少地名”，那是另一个问题。所以这里走的是属性链，人物按国籍算、机构按总部算、作品按原产国算，地点才走坐标背后的行政区。代价是判定率下降，收益是覆盖到的内容类型完整得多。

## 判不出国别的那一半会不会把结论整个推翻？

方向上不会，幅度上会有影响，而且影响的方向是确定的。判不出的那批里，除了本来就没有国别的日期页、年份页、生物分类、数学概念，还有一类是“本该有国别但数据项是空的”，这一类明显偏向本地题材——本地条目更没人去补数据项。所以本地占比这个数是下限，真实值只会更高不会更低。文章里两个口径都报，就是为了让你自己判断这个偏差有多大。

## 本地题材占比低，是不是说明这门语言不值得做？

正好相反。这个数低意味着这门语言的公共内容里，关于本地的那一块是空的，而那一块恰恰是从英语翻不过来的。翻译能补的是通用知识，补不了本地的商家、本地的规矩、本地的价格。所以低本地率对应的动作是往本地题材上压资源，不是撤退。真正该谨慎的是另一种情况：本地率高、内容也厚，那说明当地已经有一批人在认真写自己的事。

## 这套方法能不能用在自己的品类上，而不是整个语言上？

能，而且更该这么用。把随机抽样换成你那个品类的关键词，逐条打开结果页，看排在前面的那几个站是本地的还是外来的、内容讲的是本地的事还是通用知识。样本量小很多，但结论直接对着你的预算。整个语言的读数只是给你一个背景刻度，让你知道自己那个品类的数字是偏高还是偏低。

## 为什么要把时点截到两年前，用最新数据不是更好？

因为这套数的用处是看结构而不是看新闻，而结构的变化以年为单位。截到一个固定时点还有一个好处：同一批语言在同一个截面上比较，不会出现某门语言的数据是上个月的、另一门是去年的这种情况。想看趋势的话，正确做法是隔一年用同样的方法再跑一遍，两个截面相减，而不是把不同时点的数混在一张表里。

## 这件事跟内容是不是从别的语言搬来的，是同一个问题吗？

不是，它们是两条独立的轴。内容来源问的是这份内容怎么来的，地理构成问的是这份内容讲的是什么。一门语言完全可以自己动手写一大堆关于外国的内容，也可以从外语搬进来一批关于本国的内容。两条轴交叉起来是四个格子，每个格子对应的动作都不一样。想把这两个数一起用，先分别量出来，别指望其中一个能推出另一个。

## 权威参考资料



## 在非洲选语种别先看人口，先看有没有人拿这门语言写价格和退货政策

- URL：https://zhangwenbao.com/africa-market-language-selection-swahili-hausa-francophone.html
- 分类：小语种SEO
- 发布：2022-08-11  |  更新：2026-07-27
- 摘要：非洲的语种选择不该按使用人口排，该按这门语言有没有人用它写商业文案排。讲清承载度三档怎么判、豪萨语的正字法为什么在键盘上打不出来，以及语言边界与货币边界为什么不重合。
- 关键词：国际化SEO,出海SEO,多语言SEO,小语种SEO

> **TLDR**：摘要：非洲的语种选择通常是从一张使用人口排名表开始的，从上往下勾几门看着够大的语言。这张表回答不了真正的问题。真正该问的是：有没有人拿这门语言写价格、写退货政策、写客服话术。有，它就能承载一整个站点；没有，它只能承载关键词和内容，剩下的交给殖民语。

> 摘要：非洲的语种选择通常是从一张使用人口排名表开始的，从上往下勾几门看着够大的语言。这张表回答不了真正的问题。真正该问的是：有没有人拿这门语言写价格、写退货政策、写客服话术。有，它就能承载一整个站点；没有，它只能承载关键词和内容，剩下的交给殖民语。

## 非洲的语种表为什么不能按使用人口从上往下勾？

## 人口排名表的诱惑

做非洲市场的第一份材料，通常是一张语言使用人口排名表。

表上的数字都很大，几千万起步，最上面几门过亿。

照着这张表勾三门语言，方案看起来立刻就有了依据。

问题在于，这张表统计的是会说这门语言的人，跟买东西的人是两回事。

会说和会写是两回事，会写和会拿它上网购物又是两回事。

中间每一道折损都不小，叠起来能差出一个数量级。

非洲是全球语言密度最高的地区之一，光是尼日利亚一国境内的语言数量就是几百这个量级，在这样的地方按人口排名做决策，等于把一个多层筛选问题压扁成了一次排序，而被压掉的那几层恰好是决定成败的部分。

这张表还有一个隐蔽的问题，它把一门语言在不同国家的地位抹平了。同一门语言，在甲国是国语、在乙国只是家庭用语，表上却只有一个合计数。做区域方案的时候，这个合计数会诱导你把两个国家放进同一个桶，而它们的落地做法可能完全相反。看排名表时，最该先做的动作是把每一行按国家再拆开一次。

## 三种人口不是同一批人

把这件事拆细一点，需要区分三个数。

第一个是使用人口，也就是会说这门语言的人。

第二个是检索人口，会用这门语言在搜索框里打字的人。

第三个是购买人口，会用这门语言完成一次线上支付的人。

这三个数从左到右逐层缩小，缩小的比例每门语言都不一样。

斯瓦希里语三个数之间的落差相对温和，豪萨语的落差就很陡。

落差为什么会陡，答案不在语言本身，而在这门语言有没有被用于书面商业场景，这也是下一节要展开的判据。按母语人口排优先级那篇 (https://zhangwenbao.com/minor-language-seo-priority-language-cost-model.html)讲的是同一件事的通用版本，非洲把这个问题放大到了极端。

三个数之间的落差还可以拿来做一个粗略的判断：落差越陡，这门语言越适合停在词表层。落差平缓说明书面使用与口语使用接近同步，页面写出来有人读；落差陡说明大量使用者在需要写字的场合会切换到另一门语言，页面写出来也接不住人。这个判断不需要精确数字，量级对得上就够用。

## 三张表错位的实际后果

错位不是理论问题，它会具体地表现出来。

典型症状是页面上线之后收录正常，流量接近于零。

不是排名不好，是根本没有人用这门语言搜这批词。

另一种症状是流量有，咨询全部换成另一门语言进来。

用户看得懂你的页面，但他要问问题的时候会自动切回英语或法语。

这两种症状都说明语言层选错了，跟内容质量没有关系。

我们给一家做太阳能灯与家用小电器的客户排过一次非洲的语种优先级，第一版按人口排，豪萨语排在斯瓦希里语前面；三个月后豪萨语页面的自然流量是个位数，而同一批商品的英语页面在同一个国家跑得好好的，问题不在页面，在于那批用户搜索时用的根本不是这门语言。

还有第三种症状更隐蔽：流量和咨询都正常，但复购极低。这通常意味着首次购买是靠广告推来的，用户并没有把这个站当成可以再来的地方。语言只是其中一个原因，但它是最容易验证的那个，把客服对话按语言分组统计一遍复购率，两个小时就能得出结论。

## 判断一门语言能不能承载页面，该看什么？

## 把问题换成一句朴素的话

判据可以压缩成一个特别不学术的问题。

问：这门语言里，有没有人拿它写过价格、退货政策和客服话术？

注意问的不是有没有人说，也不是有没有文学作品。

问的是有没有成规模的书面商业语域。

商业语域的存在，意味着有一套现成的措辞、格式和惯例可以借用。

不存在，意味着你得从头发明一套，而用户没有义务看懂你发明的东西。

这个判据的好处是它可查、可证伪，而且不需要任何语言学知识，一个不懂这门语言的项目经理花两小时就能得出结论，比拿着人口表开三次会靠谱得多。

这个判据还能挡住一类常见的情绪化论证。做本地化的人常会说，用母语才是尊重用户。这句话本身没错，但它默认了母语等于书面商业语言，而在非洲的多数地区这两者并不重合。用一门当地人自己都不用来谈钱的语言写价格页，不叫尊重，叫误判使用场景。

## 四个可以查的信号

怎么查，看四个信号就够。

第一，本地主流媒体有没有这门语言的商业与财经版面。

第二，政府和监管机构的公开文书用不用它。

第三，当地电商平台和支付应用的界面提不提供这门语言。

第四，本地品牌的广告投放里有没有这门语言的文案。

四个信号里满足三个，基本可以判定商业语域成立。

第三个信号权重最高，因为平台愿意做一门语言的界面，说明它算过账，而这笔账跟你要算的那笔几乎是同一笔，免费借用别人已经做完的市场调研，是这个判据最实惠的地方。

四个信号还有一个使用顺序上的讲究：先查第三个，再查其余三个。因为平台界面的语言选择是可以在几分钟内自己验证的，打开当地最大的电商应用或支付应用看一眼语言列表就有答案。前两个信号需要翻文档，第四个需要看广告投放，都比它慢。全网站点的内容语言分布统计 (https://w3techs.com/technologies/overview/content_language)可以当第五个辅助信号，看这门语言在真实网页里的占比量级。

## 斯瓦希里语的答案很干脆

拿这四个信号去量斯瓦希里语。

它是坦桑尼亚和肯尼亚的官方语言之一，政府文书大量使用。

区域组织把它列为工作语言，联合国教科文组织在2021年设立了专门的国际日。

本地媒体有完整的商业报道，广播电视的覆盖面很大。

更关键的是，它有一个国家级的语言规范机构长期维护书写标准。

这意味着拼写稳定、术语有据可查、审校资源找得到。

四个信号全中，所以它是整个东非唯一一门可以承载完整站点的本土语言，这门语言的国际地位与设立缘由 (https://www.unesco.org/en/days/kiswahili-language)写得很清楚，拿它做内部立项材料比任何二手统计都硬。

还有一个容易被忽略的加分项：它在东非几个国家之间是通用的。也就是说，这一份内容可以同时服务多个市场，而多数本土语言只能服务一个国家。可跨国复用的语言资产，摊薄成本的能力是不可跨国复用语言的好几倍，这一条在算投入产出比的时候权重应该给得很高。

## 豪萨语与阿姆哈拉语要分开看

另外两门经常被一起提起的语言，答案不一样。

豪萨语的媒体覆盖很强，国际广播机构做了几十年的豪萨语频道。

但商业书面语域薄，本地电商和支付界面几乎不提供这门语言。

阿姆哈拉语的情况又不同，它有独立的书写系统和长期的书面传统。

可它的使用范围高度集中在一个国家，而那个市场的跨境电商基础设施尚在早期。

两门语言的结论都是不承载整站，但原因完全不同，一个是语域问题，一个是市场基础设施问题。

把结论相同、原因不同的两门语言混在一起讲，是很多非洲方案里最含糊的一段，而原因不同意味着未来的解锁条件也不同：豪萨语要等电商界面本地化，阿姆哈拉语要等支付与物流跑通，豪萨语的谱系与分布条目 (https://glottolog.org/resource/languoid/id/haus1257)能帮你把这两条线分开记。

顺带说一句它们的共同点：这两门语言的媒体内容都很丰富，所以拿媒体覆盖当判据会得出错误结论。广播和新闻属于单向传播，它对语言的要求是能听懂；商业交易属于双向确认，它对语言的要求是能白纸黑字写清楚责任。两种场景的门槛差得很远，用前者的繁荣推断后者的可行性，是这类方案里最常见的一次跳跃。

## 承载度三档具体怎么分工？

## 第一档：整站承载

第一档的意思是这门语言可以撑起一个完整站点。

从商品标题、详情、政策页到客服模板，全部用它写。

语言标签、站内搜索、邮件模板也一起换过去。

进入这一档的门槛很高，非洲本土语言里目前只有斯瓦希里语稳稳站住。

南非的几门本土语言接近门槛，但当地英语的强势地位削弱了必要性。

判断标准仍然是前面那四个信号，不是使用人口。

这一档的投入大约等于新增一个完整市场，工期按季度算，所以决定进这一档之前，最好先用第二档跑三个月试水，用真实数据确认需求存在，而不是拿一份人口表说服自己。

进入第一档还有一项容易漏算的义务：这门语言的内容需要跟主站保持同步更新。促销、政策、商品变更每次都要多一份。如果团队没有稳定的排期能力，第一档的内容会在半年后变成一堆过期信息，而过期的本地语页面比没有本地语页面更伤信任，因为用户会按上面写的时效和价格来要求你。

## 第二档：只做词表与内容层

第二档是绝大多数语言的正确落点。

做法是关键词表收录这门语言的高频购买词，内容层出几篇针对性的问答。

商品页、结算流程、政策页仍然用殖民语。

用户搜本土语的词进来，落到一个用英语或法语写的页面上。

这在当地是完全自然的体验，因为他们本来就习惯两门语言并存。

成本极低，通常是一个人两周的工作量。

这一档最容易被跳过，因为它既不像做完整本地化那样有汇报价值，又不像完全不做那样省事，但它的投入产出比在所有档位里最高，关键词工具没数据时的补数办法 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)正好是这一档需要的全部方法论。

第二档的具体交付物可以定得很死：一份带频次的本土语关键词表、三到五组用这门语言写的问答、以及站内搜索的同义词映射配置。三样东西加起来不超过十页纸，却能让整个市场的检索覆盖上一个台阶。把交付物定死的好处是它可验收，不会滑向做一半的本地化。

## 第三档：整块交给殖民语

第三档是不做这门语言的任何内容。这跟菲律宾那种嵌套双语市场 (https://zhangwenbao.com/philippine-english-taglish-mixed-language-keyword-research.html)的处理逻辑相通，用户本来就在两门语言之间自由切换，页面分叉并不能给他更多东西。

适用于书面商业语域几乎不存在、且使用者高度双语的情形。

西非法语区的多数本土语言属于这一档。

不做不等于不管，要做的是把殖民语那一侧写得更贴近当地。

也就是把预算从语种数量转向单一语种的本地化深度。

这个转向在汇报材料里不好看，做的语言数量从五门缩到一门。

但它带来的实际收益通常更高，因为一门写得地道的法语页面，胜过五门谁也不会用来搜索的本土语页面，语种数量是最容易被拿来当业绩的指标，也是最容易脱离真实需求的指标。

第三档里还有一个反直觉的动作值得做：在殖民语页面里适当保留几个本土语的高频词。比如商品名旁边加一个当地叫法，或者在问答里引用用户的原话。这几个词不影响页面的主体语言，却能接住那批用本土语搜索的查询，成本几乎为零，属于第三档里唯一值得做的语言层动作。

## 斯瓦希里语凭什么排在最前面？

## 它同时是国语和区域工作语言

斯瓦希里语的特殊地位来自两个层面。

一个是国家层面，坦桑尼亚把它当国语，教育和行政全面使用。

另一个是区域层面，东非区域组织把它列为工作语言。

2022年初，非洲大陆层面的组织也把它纳入工作语言。

这意味着它的使用场景不断从口语向正式书面场景扩张。

对做内容的人来说，正式场景越多，可参照的措辞就越多。

这一点可以直接验证：非洲联盟官网的斯瓦希里语版本 (https://au.int/sw)是完整维护的，一个大陆级组织愿意长期维护一门语言的全站内容，说明这门语言的书面表达能力足以承载政策、财务和法务这些最挑剔的文体。

工作语言这个身份还有一个连带效果：大量政策与法律文本会被正式译成这门语言并公开发布。这些文本对做内容的人来说是极好的语料，因为它们提供了正式文体的措辞样本，写退货政策和服务条款时可以直接参照。多数小语种最缺的恰恰就是这类正式文体的参照物。

## 书写标准稳定，审校资源找得到

第二个优势是工程上的。

它用拉丁字母书写，没有额外的附加符号，键盘直接打得出。

没有变音符号意味着不存在拼写变体爆炸的问题。

国家级的语言委员会长期发布术语标准，新词有官方译法可查。

这在小语种里是难得的待遇，多数语言的新技术词全靠民间约定。

审校人才也相对好找，两国有成熟的翻译与媒体行业。

拼写稳定这件事的价值，做过带附加符号语言的人最清楚：不用维护三套变体、不用担心搜索匹配漏掉一半、不用给字体额外加子集，国家斯瓦希里语委员会的术语工作 (https://www.bakita.go.tz/)相当于免费提供了一份持续更新的术语库。

还有一个工程上的便利经常被忽略：没有附加符号意味着URL可以直接用本土语词，不需要转写也不会产生百分号编码长串。本站讨论过本地字母与拉丁转写的取舍，那套权衡在这门语言上根本不存在，这是它相对其他非拉丁或带符号语言的一项隐性优势，省掉的是一整类问题而不是一个参数。

## 它的边界在哪里

优势说完，边界也要说清楚。

在肯尼亚，城市中产的线上购物语言大量是英语。

斯瓦希里语在那里更多用于日常口语与本地服务。

所以同一门语言在两个国家的商业权重是不同的。

坦桑尼亚一侧的本土语权重明显更高，肯尼亚一侧要跟英语分账。

做区域方案时，这两个国家不能填同一个数字。

更细一层的差别是品类相关的，快消与本地服务偏斯瓦希里语，电子与跨境商品偏英语，该国2022年的数字生态数据 (https://datareportal.com/reports/digital-2022-kenya)里的平台使用与设备结构可以帮你判断自己的品类落在哪一侧。

两国的差别还体现在正式程度上。坦桑尼亚一侧的书面标准更严格，用词更规范；肯尼亚一侧的日常表达里混入英语词的比例明显更高。这意味着同一份内容在两国的自然度不一样，理想做法是主体共用、把混用度高的那几处做成地区变体，而不是硬凑一个两边都不太像的中间版本。

## 豪萨语的正字法为什么在键盘上打不出来？

## 四个带钩字母是标准的一部分

豪萨语的书写有一处很特别的地方。

它的标准正字法里有四个带钩的字母，用来表示内爆音和喉化音。

这四个字母不是装饰，它们区分词义，去掉之后会产生歧义。

也就是说，按标准写和按简化写，是两种不同的字符串。

关键词匹配是按字符串做的，两种写法在系统看来毫不相干。

这跟带变音符号的欧洲语言是同一类问题，但严重程度高一档。

严重在哪里：欧洲语言的变音符号至少在多数键盘布局上有输入方案，而这四个字母在通用输入法里几乎没有位置，豪萨语的字母表与拼写体系 (https://www.omniglot.com/writing/hausa.htm)里能看到它们的标准形态，看完你就会明白为什么普通用户不会去打它们。

这四个字母还有一个连带影响，它们会让自动化的语言识别出错。带钩写法和退化写法在模型看来相似度很低，同一批内容可能被识别成两门语言，从而在报表里被拆成两行。做数据统计之前，先把这几个字母做一次归一化映射，否则你看到的所有分语言数字都是偏的。

## 连字体都不一定有这几个字形

还有一层更底层的问题。

这几个字母散落在拉丁扩展区和国际音标扩展区，不在基本拉丁区。

很多覆盖面很广的字体并不包含这几个字形。

我们在给这一批文章做配图素材时实测过一次，一套覆盖了中日韩全部汉字与欧洲拉丁扩展的大字体，这四个字母一个都没有，渲染出来全是方框。

字形缺失的后果是，即使用户想打，页面上也可能显示不出来。

而方框比拼写错误更劝退，用户会直接判定这个站有问题。

这条约束把语言选择跟前端资源直接绑在了一起，网页字体字形集那篇 (https://zhangwenbao.com/minor-language-web-font-glyph-set-first-screen-cost.html)里算的那笔首屏成本账在这里要再加一项：你可能得为四个字母单独引一套字体，而这四个字母出现的频率并不低。

字形缺失还有一个很实际的排查难点：它在开发者的机器上往往不复现。开发机装了大量字体，系统会自动回退到某一款包含该字形的字体，页面看起来一切正常。而用户的手机上没有那一款字体，方框就出来了。所以这类问题必须在干净环境里验，不能靠本地目测。

## 用户实际打的是退化拼法

那用户到底打什么。

答案是用基本拉丁字母的对应字母替代，钩全部去掉。

这种写法在当地网络文本里占绝对多数，没有人觉得它不对。

所以关键词表的主键必须是这种退化拼法，标准写法只能当别名。

页面正文可以按标准写，标题和关键词覆盖必须按退化写法来。

这个分工跟正文与词表分离的做法一致，只是这次两边的差别落在字符层。

如果只能记住一句话，就记这句：凡是设备打不出来的正字法，它在关键词表里就不是主键，无论它在语言学上多么正确。判断一个字母能不能打出来，看它的码位落在哪个区块最快，基本拉丁区之外的都要额外验证一遍。

退化拼法当主键还有一个副作用要提前接受：它会跟别的词产生同形冲突。去掉区别性符号之后，原本不同的两个词可能变成同一串字符。处理办法不是恢复符号，而是在关键词表里给这类词加上语境修饰词，用组合来消歧。这跟希伯来语那种辅音写法的处理思路是一样的。

## 跟希腊语那个案例正好反过来

这里有一处值得玩味的对照。

希腊语市场的问题是用户用拉丁字母打希腊语词，标准写法仍然是主流。

豪萨语市场的问题是标准写法根本进不了输入环节。

前者是两套字母并存，主次分明；后者是一套字母的完整版与残缺版并存，残缺版占多数。

所以前者的解法是让标准写法当主键、转写形态做覆盖。

后者的解法必须倒过来，退化写法当主键、标准写法做补充。

同一套方法论在两个市场给出相反的排序，判断依据只有一条：希腊语那篇讲的覆盖顺序 (https://zhangwenbao.com/greek-seo-greeklish-latin-transliteration-coverage.html)成立的前提是标准写法打得出来，这个前提一旦不成立，整个排序就要翻过来重排。

把这两个案例并排放着，还能提炼出一条更通用的判据：决定主键的不是语言标准，是输入链路。用户从键盘到搜索框这条链路上能稳定产出的形态，就是主键；链路上产不出来的形态，无论多标准都只能当别名。正字法归语言委员会管，主键归输入法管，这两件事从来不是同一件。

## 法语区的法语，跟你写的那种法语是同一种吗？

## 词汇差异比想象中系统

西非和中非有一大片法语区市场。

很多团队直接把欧洲法语站复制过去，认为语言相同就够了。

实际上非洲法语有一批稳定的本地用法，尤其在日常商品和服务领域。

这些词不是俚语，它们出现在正规的媒体和广告里。

用欧洲法语的说法，不算错，但接不住用本地说法搜索的那批人。

这跟魁北克那一侧的情况结构相同，只是词表内容完全不同。

法语的地区变体问题在本站讲过一次，法语重音符号与魁北克变体那篇 (https://zhangwenbao.com/french-seo-accents-quebec-keyword-variants.html)给的判据在这里同样适用：先查本地媒体怎么写，再决定词表收哪一个形态，别拿词典当依据。

核对本地用法的时候有一个偷懒的办法：看当地大型零售商的官网和促销页。他们的文案是花钱投放过、被市场验证过的，用词比任何词典都贴近真实。把三五家的商品分类名抄下来做成对照表，一个下午就能得到一份可用的本地词汇基线，比找译者从头造词可靠得多。

## 价格与支付的表述差别最大

差异最集中的地方不是商品名，是交易相关的表述。

货币单位、分期方式、移动支付的说法，各地都有自己的习惯。

移动钱包在这一带是主流支付方式，它的说法直接进搜索词。

配送与自提点的名称也高度本地化，跟欧洲的物流词汇几乎不重合。

这批词的购买意图极强，漏掉它们等于漏掉最下游的那批查询。

做法很直接，把交易环节的每一个名词都拿到本地媒体里核对一遍。

这件事的工作量小得惊人，通常半天就能列完，但它的收益比重写十篇商品文案都高，因为它命中的是已经决定要买、只差最后一步的那批人。

交易表述里还有一处最容易翻车：分期与赊购的说法。这一带的分期形态跟欧洲的信用卡分期不是一回事，很多是基于移动钱包或者本地小额信贷的产品，名字也完全不同。照搬欧洲说法的页面，用户读完不知道你到底支不支持他惯用的那种付款方式，于是直接离开。

还有一个跟支付说法紧密相连的字段是手续费归属。这一带的移动支付里，手续费由谁承担各家规则不同，用户对这一项非常敏感。页面上不写清楚，客服就要一条条解释，而这批问题在工单里的占比常年排前三。

## 什么时候需要单独的非洲法语版本

要不要为非洲法语做独立版本，看两个条件。

第一，交易环节的词汇差异是否已经导致明显的漏词。

第二，价格、税费、配送政策是否跟欧洲那一侧根本不同。

第二个条件通常成立，因为货币和法规都不一样。

所以多数情况下需要的是独立的地区版本，而不是独立的语言版本。

也就是说，语言标签换地区码，内容做局部替换，而不是重写。

局部替换的范围可以控制在两成以内，主要是交易表述、政策条款和几十个本地词，其余内容整段复用，这一点跟本站讲同语言多地区那套方法一致，只是这里的地区差异比欧洲内部大得多。

还有一个判断条件常被忽略：客服的排班时区。如果这批市场跟欧洲总部有明显时差，且客服无法覆盖，那么内容做得再地道也会卡在响应速度上。这条跟语言无关，但它经常是决定要不要开一个地区版本的真实约束，写方案时最好把它跟语言条件并列写出来，免得后面被当成意外。

## 语言边界、货币边界和物流边界为什么不重合？

## 同一个名字的货币其实是两种

先说一个很多人不知道的细节。

西非和中非各有一种名字相同的法郎，代号却是两个。

两者的面值挂钩相同，但它们不是同一种货币，跨区不能直接流通。

也就是说，两个都说法语的国家，可能属于两个不同的货币区。

结算、定价、退款流程按货币区走，不按语言走。

把它们放进同一个价格模板，账会在某一天对不上。

两个货币区各有自己的中央银行与监管框架，西非货币联盟央行的职责说明 (https://www.bceao.int/fr/content/presentation-de-la-bceao)里能查到成员国名单，做定价方案之前把这份名单跟你的语言分组叠一遍，会发现两张图长得完全不一样。

货币这条线还牵着定价策略。两个货币区的汇率安排与通胀水平并不完全同步，同一个商品在两边用同一个数字标价，实际购买力差别可能很大。所以价格不能只做一次换算，要在每个货币区单独定一次锚点价，这件事属于商业决策，但它的执行落在页面模板上，得提前留好字段。

## 域名与站点结构该按哪条线切

三条线不重合，站点结构就得选一条来切。

按语言切，同一个语言目录下会混进多个货币和多套政策。

按国家切，站点数量会膨胀到难以维护。

可行的折中是语言做目录、国家做地区变体、货币和政策做数据字段。

也就是让最不稳定的那几项别写死在页面里。

这样新增一个国家只是加一行配置，而不是复制一整套内容。

国家域名的管理政策差别也不小，注册资格和本地实体要求各国不同，该国国家域名的委派信息 (https://www.iana.org/domains/root/db/ng.html)里有管理机构与政策链接，选域名结构之前应该先看它，而不是先看哪个后缀更好记。

还有一个结构选择要一并定下来：语言目录与国家参数谁在前。放在路径前段的那个维度，天然获得更强的聚合信号；放在后面或者放进参数的那个维度，会被稀释。hreflang与多语言站结构那篇 (https://zhangwenbao.com/international-seo-hreflang-complete-guide.html)里讲的标注方法在这里仍然适用，只是需要标注的组合数量因为货币线的存在而多出一倍。

## 物流按承运商的覆盖切

第三条线又是另一个画法。

物流覆盖跟着承运商的网络走，跨国网络往往覆盖多个语言区。

同一家承运商可能同时服务英语国家和法语国家。

所以配送时效和自提点信息的维护单元，既不是语言也不是货币。

这就是第三条互不重合的边界。

页面上要写的时效数字，得按这条线取值。

三条线各画各的，最后落到页面上的每一个字段都要指明它跟着哪条线走，这张对照表一旦画出来，团队里关于要建几个站的争论通常十分钟内就能结束。

物流线还有一个内容层的影响：自提点的名称和位置说明必须用当地人认得的地名，而不是行政区划的官方名。同一个地点，官方名和民间叫法可能完全不同，用户按民间叫法搜索，也按民间叫法判断远近。这批地名同时是一批可观的本地长尾词，写对了顺带就把词覆盖了。

## 三线错位表怎么画

画法很简单，一张三列表就够。

行是你要进的市场，列是语言、货币、物流网络。

把每个市场在三列里的取值填进去。

然后看哪几行的三个取值组合是唯一的，那就是必须独立维护的单元。

取值完全相同的几行可以合并成一个单元。

通常十个市场能合并成四到五个维护单元。

这张表还有一个副作用，它能挡掉一类很常见的提议：既然都说法语，就合成一个站吧。表一摆出来，提议的人自己就会发现货币那一列填不下去，把隐性冲突变成表格里填不满的格子，比在会上争论有效得多。

表画完之后建议再加一列：内容语言。因为维护单元是按三条线的组合切出来的，而每个单元用哪门语言写，是另一个独立决定。有的单元语言相同货币不同，有的单元货币相同语言不同。把内容语言单列一列，能避免把维护单元数量和语言版本数量这两个概念混起来算。

## 移动端和流量成本会怎么改写语言决策？

## 页面重量在这里是硬约束

非洲多数市场的上网方式以移动端为主。

数据资费在收入中的占比明显高于其他地区。

用户对页面加载失败的容忍度很低，因为那等于白花了流量。

所以页面重量在这里不是体验指标，是转化指标。

多做一门语言，往往意味着多一套字体、多一批图片、多几个脚本。

这些代价在预算表里从来不出现，因为它们记在前端而不是内容。

网络与设备的基础数据可以在国际电信联盟的统计栏目 (https://www.itu.int/en/ITU-D/Statistics/Pages/stat/default.aspx)里查到，看一眼移动宽带渗透率与资费占收入比例这两个数，你对页面重量的容忍度会立刻降下来。

页面重量的账还要算上重试成本。弱网环境下一次加载失败，用户往往会再刷新一两次，这几次重试消耗的流量都记在他的账单上。所以一个偏重的页面在这些市场的真实代价，不是它的字节数，而是字节数乘以平均重试次数，这个乘数在网络条件差的区域可以到两倍以上。

还有一个容易被忽视的重量来源是第三方脚本。统计、客服插件、评价组件这些东西在总部看来是标配，在弱网市场却可能占到首屏体积的一半。做区域方案时应该给这些脚本单独列一张表，按市场决定装哪几个，而不是全站一套配置走天下。

## 字体子集要单独算一笔

字体这一笔特别值得单列。

拉丁字母的基本区很小，任何字体都覆盖。

豪萨语那四个字母、约鲁巴语的附加符号字母都在扩展区。

要正确显示它们，就得引入包含这些字形的字体或者做子集合并。

阿姆哈拉语更极端，它是一整套独立的书写系统，字形数量以百计。

这几笔加起来，可能比内容翻译本身还贵。

算这笔账的方法本站写过，把字形集当成一项独立的首屏成本来估，而不是等前端上线之后才发现首屏多了两百KB，语种选择在多数团队里是内容部门做的决定，可它的账单有一半开给了前端。

字体这一项还有一个折中方案值得考虑：本土语内容用系统字体，不引自定义字体。牺牲一点排版一致性，换来零字体开销和零方框风险。多数本土语页面的角色是承接检索而不是塑造品牌形象，这个交换在第二档语言上几乎总是划算的，只有第一档语言才值得为字形付出首屏预算。

## 语言版本数量本身就是成本

还有一项隐性成本经常被忽略。

每多一个语言版本，回归测试、内容同步、审校排期都要多一份。

这份成本不随内容量变化，只随版本数量变化。

三门语言和六门语言的差别，不是内容量翻倍，是协调复杂度翻几倍。

所以砍掉一门低效语言的收益，远大于它对应的那点翻译费。

这也是承载度三档的意义所在，它让多数语言停在第二档，只做词表。

第二档的语言不产生版本，只产生词条，而词条的维护成本几乎为零，这个区别是整套方法里最省钱的一处设计，也是最容易在汇报时被误解为不够重视某个市场的一处。

版本数量的成本还有一个滞后特征：它不在上线时显现，而在第一次大改版时集中爆发。改一次导航、换一次模板、加一个法务提示，都要乘以版本数量。所以评估要不要新增一个版本，正确的问法不是这次做它要多少钱，而是未来两年每一次改版都要多付多少钱。

版本数量还会影响一件很少被提起的事：内部知识的稀释。版本越多，每个版本得到的注意力越少，最后所有版本都停留在能用但不出彩的水平。集中做少数几个版本，反而更容易做出一个真正地道、能被当地用户认出来的站点。

## 内容做出来之后，谁来审、外链去哪里找？

## 审校资源的分布跟语言地位一致

审校这一环在非洲市场差别极大。

斯瓦希里语有成熟的翻译与媒体行业，找人不难。

豪萨语的审校者多集中在广播与新闻背景，商业文案经验偏少。

法语区反而最容易，因为法语的专业服务市场很成熟。

选语种时把审校可得性当成一个显性条件，能省掉后面很多麻烦。

找不到稳定审校的语言，本身就不适合进第一档。

验收口径也要提前定死，要的是可执行的问题清单而不是改好的稿子，母语审校验收清单那篇 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)里那套判据在这里一字不用改，唯一要加的是让审校者标注哪些词是他自己也拿不准的新词。

审校资源还可以换一个找法：不找翻译公司，找当地做客服或者做电商运营的人。他们每天都在用这门语言跟买家沟通，对措辞的判断比科班译者更贴近真实场景。代价是他们不擅长处理长文本的一致性，所以适合审校商品页和问答，不适合审校法务条款，两类内容要分开找人。

## 本地目录与媒体是可用的

外链渠道的形态跟欧美完全不同。

行业目录数量少，但本地商会与协会的名录质量不错。

本地新闻网站对本地商家的报道意愿比欧美高得多。

大学与技术社区的站点也是可用的渠道。

把英文手册里那份渠道清单搬过来，大概率一条都对不上。

找渠道的正确顺序是先看本地人在哪里聚集，再看那里能不能放链接。

这套方法本站讲过，小语种外链渠道那篇 (https://zhangwenbao.com/minor-language-link-building-local-directories-media-communities.html)的结论在非洲更极端：能用的渠道几乎全部在当地人的社群里，而不在任何一份可以购买的目录数据库里。

本地媒体这条渠道还有一个特点：报道的门槛低但要求真实。当地媒体乐于报道给本地创造就业或者解决具体问题的商家，套模板的品牌稿反而没人接。豪萨语的国际广播频道 (https://www.voahausa.com/)这类媒体的内容形态可以拿来参考，看看当地读者关心的角度是什么，再决定拿什么故事去接触本地媒体。

## 社群渠道要按平台分开看

社群这一层要再拆一次。

不同国家的主流社交平台差别很大，不能按一个模板做。

即时通讯群组在这一带的商业作用远超多数市场。

很多交易实际上是在群里完成的，网站只承担展示和收录。

这意味着内容的传播路径可能绕过搜索，直接进群转发。

所以页面要考虑被转发时的呈现，标题和首屏摘要要能独立成立。

本地互联网基础设施与网络运营者的分布也值得看一眼，非洲地区的互联网号码资源注册管理机构 (https://afrinic.net/)的会员与统计数据能帮你判断某个市场的本地托管与访问条件，这一层直接影响你要不要把站点资源放到更近的节点上。

群组传播还带来一个技术要求：分享卡片的抓取必须稳定。链接被转发进群时，如果标题和摘要抓不出来，只剩一串地址，点击率会掉一大截。这件事跟语言无关，但在以群组转发为主要传播路径的市场里，它的权重比很多所谓的排名因素都高，值得单独排一次检查。

## 怎么排期，怎么定试水期？

## 三个月试水期只做词表

排期的核心是先做便宜的那一档。

第一个月做语言判定，四个信号逐门语言核对。

第二个月做词表，本土语高频购买词并进现有关键词表。

第三个月做内容层，每门候选语言出三到五组问答。

三个月结束看数据，再决定要不要有语言升到第一档。

整个试水期的投入通常不超过一个人力月。

试水期的关键纪律是不要中途加码，一旦有人提议顺便把商品页也翻了，试水就变成了小型本地化项目，三个月后你将无法判断到底是词表起了作用还是页面起了作用。

试水期还要提前定好数据口径，尤其是怎么把本土语查询从日志里识别出来。最简单可靠的办法是准备一份本土语高频功能词清单，按词过滤，比任何语言识别模型都稳。口径要在试水开始前定好并写进文档，否则三个月后不同的人用不同的口径统计，会得出互相矛盾的结论。

试水期结束时还要做一件事：把三个月里积累的原始查询样本存档。这份样本是后面所有决策的基线，半年后想验证某个判断有没有变化，只有跟原始样本比才有意义。很多团队做完试水就把中间数据丢了，下一次决策又得从头采样。

## 三条不依赖语言能力的检查

验收同样需要机械判据。

第一条：查关键词表里本土语词条的占比，低于一成说明采样不足。

第二条：查这批词带来的落地页是否至少有一个本地支付方式名的文字出现。

第三条：抽查五个页面在窄屏低带宽下的首屏加载，看有没有出现方框字。

第三条尤其重要，它是字形缺失的唯一可见症状。

三条都不需要懂这门语言，任何人都能执行。

方框字这个检查还有一个变体做法：把页面在关闭自定义字体的环境里打开一次，如果本土语词条大面积变方框，说明你的字体方案对这门语言不成立，而这件事在正常环境里永远看不出来。

三条检查之外还可以加一条成本检查：统计本土语页面的首屏字节数，跟主语言页面比。如果因为额外字体而高出三成以上，说明这门语言的前端方案需要重做。这条检查同样不需要语言能力，但它能在项目早期就把一个隐性预算问题摆到桌面上，而不是等上线后再发现。

## 升档与退档的条件

最后是两个方向的判据。

升档条件：本土语查询占该市场自然流量两成以上，且转化率不低于殖民语页面。

两个条件必须同时满足，只有流量没有转化通常说明用户只是看看。

退档条件：连续两个季度本土语查询占比低于百分之五。

退档不是失败，是把预算还给更有效的那一侧。

把退档写进方案，能让升档的决定做得更果断。

保哥做这类区域方案时有个习惯，先把退出条件写在立项文档的第一页，因为没有退出条件的语言项目最后都会变成没人敢关掉的存量负担，而非洲市场的语言数量足够多，这种负担积攒起来的速度也比别处快。

升档与退档之外还有第三种状态值得写进方案：暂停。指的是内容保留、索引保留，但不再投入新增和更新。适用于数据介于两条线之间、暂时判断不了的语言。暂停的维护成本几乎为零，而且随时可以重新激活，比直接退档更适合那些基础设施正在快速变化的市场。

## 常见问题解答

## 非洲市场应该先做哪一门语言？

如果只能选一门本土语言，答案通常是斯瓦希里语，因为它是唯一在四个信号上全部成立的本土语言：政府文书使用、区域组织列为工作语言、本地媒体有完整商业版面、书写标准由国家级机构长期维护。但先做本土语这个前提本身要成立才行。多数出海团队的正确第一步其实是把英语或法语那一侧写得更贴近当地，包括支付方式、配送时效和本地地名，这一步的收益比新增任何一门语言都快。

## 豪萨语的关键词表到底该用哪种拼法？

主键用去掉钩的退化拼法，标准正字法作为别名收录。理由是设备与输入法的现实约束：那四个带钩字母在通用键盘上几乎打不出来，很多字体也不包含对应字形。页面正文可以按标准写，标题标签与关键词覆盖必须按退化写法来。这个顺序跟带变音符号的欧洲语言正好相反，那些语言的标准写法至少是打得出来的，而这里的前提不成立。

## 法语区能不能直接复用欧洲的法语站？

内容主体可以复用，交易相关的部分不能。要替换的是三类：货币与价格表述、支付与配送方式的本地名称、政策与税费条款。这三类加起来通常不超过内容量的两成，但它们承载了绝大多数的购买意图查询。做法是复用内容、新增地区版本，而不是新建一门语言，语言标签换地区码即可，这比重写整站便宜一个数量级。

## 非洲市场的语种数量做多少合适？

按维护单元数量算，不按语言数量算。把目标市场按语言、货币、物流网络三个维度填一张表，取值组合相同的市场合并成一个维护单元，通常十个市场能合并成四到五个单元。每个单元一套内容，这个数字就是你实际要维护的份数。本土语言绝大多数停在只做词表这一档，不产生新的维护单元，所以它们的数量可以放宽，真正要控制的是完整版本的数量。

## 阿姆哈拉语值不值得投入？

目前多数跨境电商团队的答案是不值得做完整站点，但值得做词表覆盖。它有独立的书写系统和悠久的书面传统，语言本身完全能承载商业内容，制约因素在市场侧：跨境支付与物流的成熟度还在早期，字形集的前端代价也明显高于拉丁字母语言。如果你的业务恰好在当地有本地仓与本地收款能力，那这个结论会反过来，判据始终是市场基础设施而不是语言本身。

## 怎么判断本地用户到底用哪门语言搜索？

最可靠的三个来源依次是：自己站点的搜索日志、客服对话记录、当地电商平台的搜索建议。三者都不需要花钱，两周就能攒出一份可用的样本。关键词工具在这一带的数据密度很低，返回零是常态，而更危险的是它对殖民语返回一个看着健康的数字，那个数字统计的是全球该语言的搜索量，跟当地需求分布关系不大。永远拿一手样本校准工具数据，不要反过来。

## 页面上的方框字是怎么回事，怎么避免？

那是字体里缺少对应字形的表现。非洲多门语言用到基本拉丁区之外的字母，常见字体不一定包含它们。避免方法有三步：先确认这门语言用到的所有字母的码位落在哪些区块，再挑一款覆盖这些区块的字体或做子集合并，最后在关闭自定义字体的环境里实测一遍。第三步最容易被跳过，而它恰好模拟的是弱网下字体没加载完的真实场景，那正是这批市场最常见的浏览状态。

## 权威参考资料



## 小语种内容都在追新词，洗衣机这种词写了19年，21门语言里只有10门写过

- URL：https://zhangwenbao.com/minor-language-content-gap-category-words.html
- 分类：小语种SEO
- 发布：2022-07-19  |  更新：2022-07-19
- 摘要：22门语言实测内容缺口：全球品牌覆盖21门，洗衣机只有10门、雨伞13门、充电站3门。给出完整覆盖表、逐语言缺口分布、陈旧率与字节比三层口径，以及品类词优先的选题清单。
- 关键词：关键词研究,多语言SEO,内容运营,小语种SEO

> **TLDR**：摘要：拿29个跟做生意有关的概念在22门语言上逐个查条目，量的是三件事——有没有、有多旧、有多薄。结果跟做内容的直觉是反的：全球品牌那一格早填满了，微软21门、谷歌20门、新冠20门；而洗衣机这种词英文写了19年，21门语言里只有10门有人写过，雨伞缺8门，冰箱缺7门，缺的名单里没有一门成熟语言。已有的那些还很旧，约鲁巴语60%、阿姆哈拉语57%的条目超过两年没人动，阿姆哈拉语的条目字节只有英语的1.4%。本文给出完整覆盖表、一把在中途失效的尺子，以及一份把选题从追新词改成占品类词的清单。

> 
摘要：拿29个跟做生意有关的概念在22门语言上逐个查条目，量的是三件事——有没有、有多旧、有多薄。结果跟做内容的直觉是反的：全球品牌那一格早填满了，微软21门、谷歌20门、新冠20门；而洗衣机这种词英文写了19年，21门语言里只有10门有人写过，雨伞缺8门，冰箱缺7门，缺的名单里没有一门成熟语言。已有的那些还很旧，约鲁巴语60%、阿姆哈拉语57%的条目超过两年没人动，阿姆哈拉语的条目字节只有英语的1.4%。本文给出完整覆盖表、一把在中途失效的尺子，以及一份把选题从追新词改成占品类词的清单。

去年做一份东南亚市场的内容排期，第一批词的清单是从竞品的热门页面里扒出来的。清单交上去，本地同事看了一遍，问了一句：为什么全是新东西。

清单上确实全是新东西。直播带货、跨境支付、某个平台的运营方法。理由也说得通——新东西竞争少，做得早能占位置。

那位同事说，这些词在我们这儿也确实少人写，但更少人写的是另一批。他举了个例子，你们要不要查一下，我们语言里有没有一篇正经讲洗衣机怎么挑的东西。

查完之后我把那份清单重做了。这篇写的就是重做的依据。

## 做小语种内容排期，第一批词是怎么挑出来的？

## 清单通常从哪儿来

做一门新语言的第一批内容，选词的路子来来回回就三条：翻译英语站的现有清单、扒本地竞品的热门页、从关键词工具里按搜索量排序取前几十。

三条路各有各的毛病——拿词典逐词换出来的词表 (https://zhangwenbao.com/keyword-literal-translation-legacy-cost-non-english.html)是其中一种——但它们有一个共同的毛病：都在照着已经存在的东西选。翻译照的是英语市场已经存在的，扒竞品照的是本地已经存在的，看搜索量照的是工具已经记录的。

已经存在的东西会有偏向。它偏向热闹的、新的、有人在讨论的，因为只有这些东西才会留下足够多的痕迹让你扒到。

缺口按定义就是没有痕迹的地方。用照着已有的东西选词的办法，找不到缺口。

## 缺口这个词在这里指什么

先把定义收窄。这里说的缺口不是这个词没有搜索量，也不是这个词竞争度低。它指的是这门语言的公共知识里，关于这个东西还没有一份说得过去的中文之外的表述。

为什么盯这个而不是盯搜索量？因为搜索量在小语种上本来就测不准，工具返回的零有一半是数据缺口 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)。而公共知识里有没有这份东西，可以直接数出来。

更实际的理由是：当有人要在这门语言里回答一个问题——不管是搜索引擎、答案系统，还是一个记者、一个学生——它会去公共知识里找。找不到的时候，你那份就是唯一的一份。

所以缺口的价值不在于竞争少，在于你写的那份会成为默认答案。这两件事在英语市场是一回事，在小语种市场不是。

## 这次量了什么

29个概念，22门语言，逐个查有没有对应条目、条目什么时候建的、最后一次修改是什么时候、现在有多大。

概念分三组。老的一组是1990年代以前就存在的东西：咖啡、鞋、洗衣机、自行车、冰箱、手表、雨伞、信息技术，加上微软和IBM两个老牌子。

中间一组是2000年之后长出来的：智能手机、电子商务、搜索引擎优化、比特币、Instagram、云计算、二维码、网上购物、加密货币、机器学习、播客，加上谷歌。

新的一组是最近这些年的：TikTok、新冠、5G、通用数据保护条例、充电站、无人机、电动汽车。

## 为什么用维基百科的数据

这套数据的来源是维基百科各语言版本的条目和它们的完整修订史。选它有一个很实际的理由：它是唯一一个在所有语言上用同一套规则、且把每次修改的时间都公开的地方。

它当然不等于这门语言的商业内容。但它是这门语言公共知识里组织得最好的那一块，用它做出来的结论是个上界。它都空着，商业内容只会更空。

另外它有一个别的来源给不了的性质：可以回溯。所有数字都能截到某一个时点重算，不受今天的状态影响。用同一套数据算写内容的人有几个 (https://zhangwenbao.com/minor-language-content-volume-editor-count.html)用的是这批数据的另一列。

本文的所有统计截止到2022年6月30日。

## 本文不谈的两件事

第一件是这些词有没有搜索量。缺口和需求是两条独立的轴，一个词可以缺而且没人搜，那种词不该做。怎么判断需求那一侧，工具返回零的时候怎么补数据 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)写过。

第二件是写出来之后怎么让引擎收录。那是另一层的事，跟这门语言里有没有人写过没有关系。

本文只回答一个问题：这门语言的公共知识里，哪一格是空的。

## 二十年过去，洗衣机这种词在几门语言里还是空的？

## 先看两头的对照

把29个概念按覆盖门数排一遍，最上面和最下面的差距大到不像同一批数据。

最上面：微软21门语言全有，谷歌20门，新冠20门，咖啡18门，自行车17门，鞋16门，Instagram16门，TikTok16门。

最下面：充电站3门，手表7门，网上购物7门，机器学习9门，洗衣机10门，播客10门。

把这两列并排看，一个很别扭的事实浮出来：一门语言里可能有关于TikTok的条目，却没有关于洗衣机的条目。

## 洗衣机缺在哪11门语言里

洗衣机的英文条目建于2003年1月，到观测点已经19.4年。这19年里，21门非英语语言中有10门写了对应条目，11门没有。

没有的那11门是：缅甸语、高棉语、僧伽罗语、老挝语、蒙古语、尼泊尔语、阿姆哈拉语、斯瓦希里语、豪萨语、约鲁巴语、乌兹别克语。

这11门语言的使用者加起来超过五亿人，其中好几门在印度十一门语言那份预算表 (https://zhangwenbao.com/india-multilingual-seo-eleven-languages-nine-scripts-priority.html)里被单独讨论过。这五亿人里想在自己的语言里读一篇关于洗衣机的介绍，公共知识里一份都没有。

雨伞的情况类似，缺8门；冰箱缺7门。这三个都是家家户户都有的东西，也是电商大类里最常见的品类。

## 与之对照的新东西

新冠的英文条目建于2020年1月，到观测点2.4年。这2.4年里，21门语言中有20门写了对应条目，只有宿务语没有。

TikTok的英文条目建于2018年3月，4.3年时间覆盖了16门。5G十三年覆盖11门。

把新冠那个数摊开算：平均每年有8.35门语言补上这个条目。洗衣机19年才补上10门，平均每年0.51门。差16倍。

当然新冠是极端案例，全球性事件。但即使拿掉新冠和TikTok，剩下的新东西也没有出现洗衣机这种量级的空缺。

## 把两组数摆在一张表上

概念 | 英文条目年龄 | 覆盖门数 | 平均每年补几门 | 

新冠 | 2.4年 | 20/21 | 8.35 | 

TikTok | 4.3年 | 16/21 | 3.70 | 

Instagram | 11.2年 | 16/21 | 1.43 | 

谷歌 | 17.7年 | 20/21 | 1.13 | 

微软 | 20.7年 | 21/21 | 1.02 | 

咖啡 | 18.2年 | 18/21 | 0.99 | 

自行车 | 20.9年 | 17/21 | 0.81 | 

冰箱 | 17.7年 | 14/21 | 0.79 | 

雨伞 | 18.6年 | 13/21 | 0.70 | 

洗衣机 | 19.4年 | 10/21 | 0.51 | 

播客 | 17.7年 | 10/21 | 0.56 | 

充电站 | 15.2年 | 3/21 | 0.20 | 

最上面五行有一个共同点：它们要么是全球品牌，要么是全球事件。最下面几行也有一个共同点：它们是没有主人的普通东西。

## 缺口的分布不是均匀的

如果一门语言只是内容少，缺口应该均匀地散在各个话题上。实测下来不是这样。

约鲁巴语在这29个概念上缺了24个，剩下的5个是：微软、谷歌、Instagram、二维码、新冠。三个全球品牌、一个技术标准、一个全球性事件，日常品类一个都没有。

豪萨语剩7个：微软、谷歌、Instagram、TikTok、新冠，加上自行车和冰箱。高棉语剩8个，里面有微软、谷歌、TikTok、新冠，加上咖啡、信息技术、电子商务、二维码。

规律很清楚：一门语言的公共知识薄到只剩几条的时候，留下来的几乎全是全球专名和全球事件。它们能留下来不是因为重要，是因为全世界都在说同一个名字，翻译成本最低。

## 阿姆哈拉语的例外说明了什么

阿姆哈拉语剩下的7条里有一条不符合上面那个规律：咖啡。除了微软、谷歌、新冠这三条全球款，它还有咖啡、鞋、自行车、冰箱。

咖啡出现在这个名单上一点都不奇怪——埃塞俄比亚是咖啡的原产地，这是这个社群的核心话题之一。有人愿意花时间把它写好。

这条例外把规律补完整了。决定一个词在这门语言里有没有人写，不是它新不新，也不是它常不常用，是它跟这个社群有没有特殊关系。

要么是全世界都在说的名字，要么是本地特别在意的东西。两头不沾的普通品类词，就一直空着。洗衣机在任何一个社群里都不是话题，所以在11门语言里没人写。

## 这批数据里有一把尺子中途失效了，是哪一把？

## 手表这一行不对劲

覆盖表排出来之后，最低的那几行里有一个数看着别扭：手表只有7门语言有条目。而缺它的名单里出现了瑞典语、希腊语、匈牙利语。

这三门语言在其他所有指标上都属于健康档，它们的维基百科各有几十万到上百万个条目，编辑人数上千。这样的语言不会没有关于手表的内容。

点开看了一下就明白了。这三门语言把手表和钟写在了同一个条目里，一个条目讲计时器具，手表是其中一节。而我用来对齐概念的那个数据库把这个条目链到了钟那一边。

所以手表那一行的7不是真实缺失，是概念切分粒度在语言之间不一致。同样的问题也出现在网上购物那一行——瑞典语和匈牙利语把它并进了电子商务。

## 这条判据可以直接用

发现这个问题之后，我给整张表加了一道自查：看每个概念的缺失名单里有没有出现成熟语言。

如果缺失名单里出现了瑞典语、希腊语、匈牙利语、波斯语、印尼语这一档，那多半是概念切分问题，不是真实缺失。只有缺失名单全部落在小语种上，才是真信号。

拿这条筛一遍，手表和网上购物两行被标为不可用。而洗衣机、雨伞、冰箱三行全部通过——缺它们的11门、8门、7门语言里，没有一门属于成熟档。

这道自查花了大概二十分钟，救下来的是整篇文章的主结论。如果不做，我会拿手表那个7当成最强的证据，而它是假的。

## 还有一把尺子在同一批数据上失效了

最开始的分析口径不是覆盖率，是滞后天数——一个概念在英语里有了条目之后，各语言平均隔多久补上。

按这个口径算出来：老概念中位滞后2015天，中间那组1755天，新概念只有1218天。看起来新东西进得更快，正好是我想要的结论。

但这个数是错的，错在观测窗口。新概念的英文条目本身就只有几年历史，它的滞后天数在数学上不可能超过这个年限。老概念有二十年可以慢慢拖，新概念最多只能拖六年。

这叫右删失，是个很基本的统计陷阱，而它在这里伪装得特别好——因为算出来的方向刚好符合直觉，让人不想再查。

## 换成不受删失影响的口径

补救办法是把所有概念截到同一个观测年限。取英文条目建立后的头六年，数这六年里有几门语言补上了。

结果反过来了：老概念头六年平均覆盖8.2门，中间组8.0门，新概念4.2门。在同样长的窗口里，新东西铺开得反而更慢。

这个口径也不是完美的。老概念的头六年正好是2001到2010年，那是各语言维基百科的扩张期；新概念的头六年是2016到2022，各语言版本早已进入平台期。时代背景在动。

所以两个口径都有偏。真正干净、两边都不受影响的证据只有一条：绝对覆盖数。手表二十年七门、洗衣机十九年十门、充电站十五年三门，这些数不需要任何换算就能说明问题。

## 尺子失效之后剩下什么

两把尺子倒下之后，主张需要重写。原来想说的是新东西进得快、老东西进得慢；实测支持不了这个说法。

能站住的是另一句：覆盖率跟这个词是不是全球专名强相关，跟它新不新、常不常用都不相关。这句话每一个口径都支持。

顺带说一句，这已经是本站第五次记录到尺子在小语种数据上失效。前几次分别是地区参数不生效、整条判定看不见混合语言、工具对某语言返回的零是数据缺口。

每一次的处理都一样：不是修尺子，是换一把。换出来的那把通常比原计划更硬，因为它绕开了原来那个假设。

## 为什么最普通的词反而最晚有人写？

## 写条目的动机不是需求

要解释这个分布，得先想清楚谁在写这些东西，为什么写。写维基条目的人不拿钱，他们写的理由通常是三种之一：这件事我懂、这件事最近很热、这件事跟我们有关。

三种理由都跟这个东西常不常用没有关系。洗衣机每家都有，但它不属于任何一个人的专业，最近也没有新闻，跟任何一个社群都没有特殊关系。

所以它在选题的时候永远排在后面。这不是懒惰，是资源分配——一个只有三十个活跃编辑的社群，先写什么后写什么是有优先级的。

而全球专名不一样。微软、谷歌这类词有现成的英文条目可以对照翻译，事实清楚、结构固定、争议少，是最容易上手的选题。

## 商业内容的动机也是偏的

那商业内容会不会把这个缺口补上？理论上应该会，因为品类词才是有转化的那批词。实际情况没那么乐观。

做本地内容的团队面临的是同一批约束的另一个版本：预算有限，先做什么后做什么要看回报。而回报最好算的是品牌词和热点词，因为它们的搜索量能测出来。

品类词在小语种上的搜索量恰恰是最测不准的那一批，工具返回的经常是零。于是它在排期上又排到了后面，两个市场的意图差异 (https://zhangwenbao.com/minor-language-search-intent-divergence-across-markets.html)那一层的判断也就跟着落空。

两批人各有各的理由，避开了同一批词。结果就是这批词在这门语言的互联网上长期是空的。

## 翻译为什么没有自动补上

还有一个显而易见的候选解释：既然英文条目都在，翻译一遍不就完了。这件事确实一直在发生，但它有自己的偏向。

翻译的优先级通常跟着源语言的重要性走。英文维基里被认为重要的条目、被列进基础条目清单 (https://en.wikipedia.org/wiki/Wikipedia:Vital_articles)的条目，被翻译的概率更高。

而那些清单本身是按知识体系的重要性排的，不是按商业价值排的。跨语言那份每个语言版本都该有的条目清单 (https://meta.wikimedia.org/wiki/List_of_articles_every_Wikipedia_should_have)也是同一个逻辑，一千条里绝大多数是国家、人物、学科、事件。洗衣机在知识体系里的位置不高，在电商品类里的位置很高，两个排序不是一回事。

这一层的错位是结构性的，不会自己消失。你不做，它就一直空着。

## 这个解释能不能证伪

上面那套解释听着顺，但顺不等于对。能拿来检验它的一条预测是：如果动机是全球专名和本地话题两头，那么本地特有的东西应该覆盖得很好。

阿姆哈拉语的咖啡就是一个正例。反过来找反例的话，可以查这些语言里本地的传统服饰、本地菜、本地节日有没有条目——按这套解释应该有。

这次没有跑这一组，因为本地特有概念在Wikidata里的对齐质量很差，跨语言比较做不干净。这是一个坦白的缺口，不是结论。

所以上面那套因果讲的是一个说得通的机制，不是被验证过的结论。真正被验证的只有分布本身：全球专名覆盖高，普通品类覆盖低。

## 这个机制在别的地方也见过

这套结构其实不新鲜。任何靠志愿投入的内容体系都会往同一个方向偏：有争议的、有话题的、有人格化对象的东西被反复写，无聊而必要的东西没人碰。

英文维基百科自己也有这个问题，他们专门有个常设项目 (https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Countering_systemic_bias)在处理这件事。区别在于英语的分母足够大，偏向之后剩下的绝对量还是很可观。

小语种的分母只有几十个人，同样比例的偏向会让整个品类彻底消失。偏向的比例可能一样，后果差了一个数量级。

这也是为什么这套观察不能直接从英语市场的经验里推出来。在英语市场，你从来不会遇到一个品类完全没有人写过的情况。

## 逐语言看，缺口集中在哪一档语言上？

## 22门语言的缺口分布

前面按概念看，现在换个方向按语言看：每门语言在老、中、新三组概念上各缺几个。三组的总数分别是10、12、7。

语言 | 老概念缺几个 | 中期概念缺几个 | 新概念缺几个 | 

印尼语 | 0/10 | 0/12 | 0/7 | 

波斯语 | 0/10 | 0/12 | 0/7 | 

瑞典语 | 1/10 | 1/12 | 0/7 | 

泰语 | 0/10 | 0/12 | 1/7 | 

越南语 | 0/10 | 0/12 | 1/7 | 

希腊语 | 1/10 | 0/12 | 1/7 | 

匈牙利语 | 1/10 | 1/12 | 1/7 | 

泰米尔语 | 0/10 | 1/12 | 2/7 | 

孟加拉语 | 0/10 | 1/12 | 2/7 | 

乌兹别克语 | 3/10 | 6/12 | 3/7 | 

蒙古语 | 3/10 | 4/12 | 4/7 | 

僧伽罗语 | 3/10 | 5/12 | 5/7 | 

斯瓦希里语 | 2/10 | 5/12 | 5/7 | 

尼泊尔语 | 3/10 | 6/12 | 5/7 | 

缅甸语 | 5/10 | 7/12 | 3/7 | 

老挝语 | 6/10 | 9/12 | 4/7 | 

高棉语 | 7/10 | 9/12 | 5/7 | 

豪萨语 | 7/10 | 10/12 | 5/7 | 

阿姆哈拉语 | 5/10 | 11/12 | 6/7 | 

约鲁巴语 | 9/10 | 9/12 | 6/7 | 

## 这张表分成三段，不是连续的

上面九门语言几乎全绿，缺口加起来不超过三个。这一档做内容跟做英语市场没有本质区别，缺口地图对它们没什么用。

中间六门在三到六之间，是缺口地图最值得跑的一档。有一半的格子空着，另一半有内容可以参照，投入产出比最好。

最下面五门缺了大半，属于公共知识整体薄的状态。这一档要先回答另一个问题——这门语言的商业活动是不是整体用另一门语言在办，答完再决定要不要做。

三段之间的分界不在语言的使用人口上。豪萨语和斯瓦希里语的使用者都以千万计，孟加拉语两亿多，泰米尔语八千万，它们分散在三段里。

## 缅甸语和老挝语的一个反常

看最下面那一档会发现一件怪事：缅甸语在老概念上缺5个、中期概念缺7个，可新概念只缺3个。老挝语也是，老概念缺6个、中期缺9个，新概念只缺4个。

按比例算，这两门语言在新概念上的覆盖率反而比老概念高。这跟英语的直觉正好相反。

能想到的解释是：新概念大多带着一个全球通行的名字进来，翻译成本低、参照现成；而老概念要用本地词从头写，工作量大得多。前面阿姆哈拉语那条例外说的是同一件事。

不管解释对不对，落到动作上很清楚：在最薄的那几门语言里，你以为最安全的基础品类词，恰恰是最空的那一批。

## 缺口正在被填，速度能测出来

还有一组数值得记下来：在观测点之后才建起来的条目。这批条目今天存在，但在2022年6月30日那一刻还没有。

乌兹别克语7条，豪萨语4条，蒙古语3条，缅甸语、高棉语、僧伽罗语、斯瓦希里语各2条，越南语、泰米尔语、孟加拉语、老挝语、阿姆哈拉语各1条。

把这个数除以时间跨度，就是这门语言填补缺口的速度。乌兹别克语明显快于其他几门，它同期的编辑人数也在涨，两个信号是一致的。

这个数的用法是估窗口期。如果一门语言每年填两三个格子，而你的品类清单里有十个空格，那你大概有三到五年时间；如果它每年填七八个，就得抓紧。

## 就算有条目，它有多旧、有多薄？

## 有没有只是第一层

覆盖率回答的是有没有。但一个存在的条目可能只有两句话，也可能六年没人碰过。对做内容的人来说，这三层是叠加的。

所以同一批条目又量了两件事：最后一次修改距离观测点多久，以及现在有多少字节。第一个是新鲜度，第二个是分量。维基媒体自己有个叫条目深度 (https://meta.wikimedia.org/wiki/Wikipedia_article_depth)的口径，做的也是把数量和分量分开这件事。

这两个数跟覆盖率不完全相关。有些语言覆盖率不低，但条目普遍很旧很薄；也有覆盖率低但剩下那几条维护得很勤的。

三个数一起看，才能判断这门语言的这个格子到底是空的、旧的，还是活的。

## 静默月数：多久没人动过

把每门语言的条目按最后修改时间排，取中位数，得到的是这门语言的内容平均沉睡了多久。

最久的是阿姆哈拉语，60.2个月，五年。然后是约鲁巴语29.6个月、尼泊尔语18.3个月、僧伽罗语17.8个月、蒙古语15.3个月、高棉语10.3个月。

另一头，波斯语0.9个月、越南语1.8个月、印尼语2.1个月、希腊语2.5个月。这些语言的条目几乎每个月都有人碰。

老挝语是7.3个月，缅甸语8.7个月，都在中间。这跟它们的编辑人数对得上——人少但那几个人在动。

## 陈旧率：超过两年没人动的占多少

中位数会被少数活跃条目拉偏，所以另外算了一个比例：有多少比例的条目超过24个月没人改过。

约鲁巴语60%，阿姆哈拉语57%，老挝语40%，僧伽罗语38%，斯瓦希里语35%，蒙古语33%，高棉语29%，泰米尔语19%。

另一头是一批零：瑞典语、宿务语、泰语、越南语、希腊语、匈牙利语、孟加拉语、豪萨语、乌兹别克语的24个月陈旧率都是0，英语也是0。

这里有个反常值得记下来：豪萨语的24个月陈旧率是0，但它超过6个月没动的比例是71%。它的条目全都在半年到两年之间被碰过一次，一次都没有更久的。这说明它有一个活跃度不高但没断的维护节奏。

## 字节数：条目有多厚

第三个数是条目大小的中位数，跟英语的中位数比。

阿姆哈拉语1.4%，豪萨语2.1%，老挝语2.5%，斯瓦希里语2.7%，乌兹别克语3.1%，宿务语3.6%，约鲁巴语3.7%，尼泊尔语3.9%。

这一档的意思是：英语条目写了一万字的东西，这门语言里对应的那份是一百多字。不是简版，是一句话加一张信息框。

另一头是波斯语25.6%、希腊语17.8%、印尼语17.6%、越南语16.0%、孟加拉语15.4%。这一档是真的在写内容，只是没英语那么全。

## 三个数怎么合起来读

把覆盖率、陈旧率、字节比三个数放一起，能分出三种完全不同的格子。

第一种是空的：这门语言根本没有这个条目。你写的那份是第一份，没有参照也没有竞争。

第二种是旧的：有条目，但五年没人动、只有一百多字。这种格子表面上被占了，实际上一推就倒。阿姆哈拉语和约鲁巴语的绝大多数格子属于这一种。

第三种是活的：有条目、经常更新、内容成规模。这一档要按正常竞争对待，波斯语和印尼语的多数格子属于这一种。这三档跟学界给世界语言排的资源等级 (https://aclanthology.org/2020.acl-main.560/)的资源分层大体对得上，只是那份分层看的是语料总量，这里看的是具体某一格。

## 缺口的形状变了，选题清单该怎么改？

## 先把品类词单独拉一张清单

动作上最小的改动是：在原来那份从竞品和工具里扒出来的清单之外，另起一张只放品类词的清单。

品类词的定义很朴素：你的商品分类树上的那些节点名。洗衣机、羽绒服、行李箱、跑鞋、蓝牙耳机，就是这些。不要带修饰语，不要带品牌。

这张清单不需要关键词工具，看自己的后台分类就能列出来。三十到五十个，一小时能列完。

列完之后逐个查这门语言的公共知识里有没有对应内容。查法下一节说。

## 逐个查的方法

最省事的做法是打开这门语言的维基百科，用它的搜索框逐个搜。有条目、条目多长、最后编辑时间，三个信息在一个页面上都能看到。

三十个词手工查大概四十分钟。要是嫌慢，可以用查询接口 (https://www.mediawiki.org/wiki/API:Query)批量跑，一次请求能查五十个标题。

查的时候注意用这门语言的说法，不是英语的说法。同一个概念在不同语言里对应的条目标题不一定是直译——品牌名的本地写法 (https://zhangwenbao.com/brand-name-transliteration-loanword-minor-language-search.html)是最典型的一类——用跨语言链接找过去最稳。

还要注意前面那条判据：如果一个词查不到，先确认它是不是被并进了上位概念的条目里。并进去了不算缺。

## 查完之后怎么排优先级

三个信号排出三档。完全没有条目的排最前，这是真空地带。

有条目但两年以上没动、且字节数很小的排第二。这一档的机会同样大，而且写的时候有个现成的参照能看出本地人怎么称呼这个东西。

有条目且维护活跃的排最后。这不意味着不做，意味着做的时候要有比现有内容更强的东西，不能只是复述。

另外提醒一句：这个排序是内容缺口的排序，不是收益排序。真正的排期还要乘上这个品类在你这儿的毛利和库存，这一层每家不一样。

## 内容该怎么写才占得住

占住一个空格子的门槛比想象中低，但有两个条件。第一是内容本身要能独立成立，不能是一段从英语翻过来的介绍加一个购买链接。

第二是要用本地的说法。这个东西在这门语言里叫什么、当地人买它的时候会关心哪几件事、有没有本地特有的规格或标准，这些是翻译带不过来的。结构化数据里的语言与地区字段 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)那一层也要一起处理。

做到这两条，你那份内容在这个格子里就是最好的一份，而且很可能长期是唯一的一份。母语审校那道工序 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)在这种内容上比在营销文案上重要得多。

反过来，如果做不到这两条，最好别做。一份翻译腔的品类介绍占住格子之后，你后面想改的时候要跟自己竞争。

## 这套做法的时间成本

列清单一小时，查一遍四十分钟，加起来不到两小时就能拿到一门语言的缺口地图。这个成本低到可以在决定要不要做这门语言之前先跑一遍。

跑完能回答两个问题：这门语言的公共知识空到什么程度，以及我手上这批品类里有几个是真空的。第二个数直接决定第一批内容做几篇。

多门语言并行的时候，这套查法可以复用同一份品类清单，换语言参数重跑。二十门语言一天能跑完。

拿到的结果不会过期得很快。公共知识的填补速度是以年计的，一份缺口地图用一年没问题。

## 品类词的位置，凭什么认为你能占住？

## 占住的意思不是排第一

先把话说清楚。这里说的占住，不是指某个关键词排到搜索结果第一位。它指的是当有人在这门语言里问这个东西，你那份内容是被找到的那一份。

这两件事在内容稀薄的语言里几乎重合，因为候选本来就没几个。在英语市场它们差得很远，因为候选有几千个，排序才是全部。

所以小语种的品类词有一个英语市场没有的性质：写得好本身就能兑换可见度，不需要额外的推动。这个性质在候选池填满之后会消失。

能占多久，取决于这门语言的内容生产速度。前面那些数据里，编辑人数和新建量的增长率就是这个速度的代理。

## 三类竞争者各自会怎么动

可能来抢这个格子的有三类。第一类是本地的内容站和媒体，他们最有可能写，但他们的选题同样跟着热点走，品类介绍不是他们的重点。

第二类是全球品牌的本地站。他们有预算也有动机，但他们写的是自己的产品，不是品类，而且从英文模板批量生成落地页这条路他们走得最熟 (https://zhangwenbao.com/minor-language-emphasis-markup-anchor-drift.html)。品类介绍对他们没有直接回报。

第三类是批量生成的内容。这一类的威胁在过去几年里明显上升，因为生成成本降到了几乎为零。机器翻译直接发布那条质量线 (https://zhangwenbao.com/machine-translation-direct-publish-search-risk-quality-line.html)讲的就是这类内容的边界。

三类里第三类最值得防，也最好防——它的特征太明显，本地读者一眼能认出来，而且它不会去查本地特有的规格和标准。

## 一个反向的风险

有一种情况会让整套判断失效：这个品类在这门语言的市场里根本不存在。

洗衣机在某些市场的家庭普及率很低，那么这门语言里没有关于洗衣机的内容不是缺口，是没有需求。这时候你写得再好也没有人来。

区分的办法是拿这个品类的本地说法去查搜索建议，看有没有返回，顺手把用户实际打出来的短形式 (https://zhangwenbao.com/minor-language-clipped-short-forms-keyword-coverage.html)可以一起做掉。有返回说明这个词在查询池里活着；一条都没有说明这一类查询在这门语言里整个不存在。

这一步不能省。缺口和需求是两条独立的轴，只看缺口会把没有需求的格子当成机会。

## 什么时候该放弃这门语言

把缺口和需求交叉，会得到四种组合，其中两种是明确的信号。

有缺口且有需求，是最好的机会，该抢。没缺口且没需求，说明这个品类在这门语言里既没人写也没人问，直接放弃。

另外两种要具体判断。有缺口但没需求，多半是品类没长起来，可以等；没缺口但有需求，说明这是个正常市场，按常规打法做。

值得注意的是，第一种和第二种在只看内容量的报表上长得完全一样，都是低数字。把它们分开的唯一办法是把需求那一侧单独测一遍。

## 做完之后怎么判断有没有效

三个月内不要看流量。品类词在这类市场的量本来就小，三个月的数据看不出趋势，容易做出错误的停手决定。

该看的是三个别的信号：有没有被本地站点引用、有没有出现在这门语言的问答里、有没有人拿它当参考。这三个信号出现得比流量早，本地目录与社群 (https://zhangwenbao.com/minor-language-link-building-local-directories-media-communities.html)里给过一份可以照抄的渠道清单。

更直接的一个检验是过半年再查一次那个格子。如果这半年里没有第二份内容出现，说明这个位置确实空着，继续做；如果突然冒出来三四份，说明有人跟你想到一块儿了，得加快。

这个复查跟第一次的查法完全一样，五分钟。它比看流量报表更接近这件事的本质。

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

## 需求侧那半边

本文从头到尾量的是供给：有没有人写过。它一次都没有回答有没有人在搜。

这两件事必须分开测。前面说过怎么测需求那一侧，但那只是一个粗筛，真正做决策的时候还需要更细的信号。

把两侧混在一起是这类分析最常见的错误，因为它们的数字长得像——都是低数字。低供给和低需求，动作完全相反。

## 语言本身的机制那半边

这门语言的词形怎么变、怎么分词、用什么书写系统，跟公共知识里有没有这个条目完全无关。

它们决定的是你做这门语言的技术成本，比如转小写会把土耳其语的词改成另一个词 (https://zhangwenbao.com/minor-language-case-folding-lowercase-turkish-dotless-i.html)，又比如屈折语站的锚文本报告里精确匹配那一栏是假的 (https://zhangwenbao.com/minor-language-internal-link-anchor-inflection-variants.html)，这一层跟缺口地图没有交集。

两张表分开做：缺口地图进选题会，技术成本进预算表。合成一个分数会得到很奇怪的结论。

## 引擎收录那半边

写出来的东西能不能被抓到、被收录、被排上去，是另一套逻辑。这门语言公共知识空不空，对引擎的收录行为没有直接影响。

实操上建议先确认引擎那一层没问题，再来看缺口。引擎那层如果有毛病，缺口地图做得再准也用不上。

顺序上这是个前置条件，不是并列关系。

## 维基百科代替不了商业内容的调研

这一条是本文最大的软肋，值得重复。维基百科的内容分布和商业内容的分布不是同一件事，前者受志愿者兴趣驱动，后者受商业回报驱动。

两者的偏向方向其实挺像——都偏热点、偏品牌、避开无聊而必要的东西。这是这套代理指标能成立的基础，但相似不等于相同。

能做的补充验证有一个：把缺口清单里排最前的三五个词，拿去用这门语言直接搜一遍，看返回的前两页里有没有像样的内容。半小时能跑完，能把明显的误判排掉。

## 这套方法的边界在哪

它在两种情况下不该用。第一是这门语言的公共知识已经很厚，覆盖率普遍在九成以上，这时候缺口地图全是绿的，给不出信息。表里的波斯语、印尼语、越南语、泰语基本属于这一档。

第二是你要做的品类特别细，细到公共知识里本来就不会有对应的条目。这时候要往上找一层，查它的上位品类，属性值本身在这门语言里怎么分格 (https://zhangwenbao.com/minor-language-color-category-attribute-value.html)这类问题也要一并考虑。

剩下的情况它是好用的，尤其是你手上有二十个品类、五门语言，要决定先做哪几格的时候。两小时能把明显的空格找出来。

开头那位本地同事的问题，后来查出来的答案是没有。我们那份清单里加了七个品类词，第一批就上了三个。

## 常见问题解答

## 维基百科上没有的东西，就等于这门语言的互联网上没有吗？

不等于，它只是一个方向性的信号。维基百科的内容偏向和商业内容的偏向很像但不完全一样，两者都避开无聊的品类介绍，但商业内容会因为转化价值补上一部分。

所以正确的读法是把它当第一道筛子：维基上有的，商业内容大概率也有；维基上没有的，商业内容里可能有一点，但十有八九不成规模。

拿到缺口清单之后花半小时用这门语言实搜前三个词，看前两页的结果，就能把误判排掉。这一步的成本很低，但能让整份清单从推测变成有依据。

## 为什么手表那一行不算数，洗衣机那一行就算数？

判据是缺失名单的构成。手表的缺失名单里有瑞典语、希腊语、匈牙利语，这三门语言的维基百科各有几十万到上百万条目、上千名编辑，不可能真的没有关于手表的内容。

点开确认之后发现它们把手表和钟写在同一个条目里，是概念切分粒度的差异，不是缺失。洗衣机的缺失名单里一门成熟语言都没有，全部是小语种，所以它是真信号。

这条判据可以直接搬去用在你自己跑的数据上：任何一个概念，如果它的缺失名单里出现了内容量明显充足的语言，先假设是对齐问题，点开验证之后再决定要不要采信。

## 覆盖率低的语言，是不是干脆不该做？

正好相反，覆盖率低本身是机会信号，但它必须跟需求侧的数据一起看才有意义。

缺口大而有需求，是最值得投的一档；缺口大而没需求，说明这个品类在这个市场还没长出来，可以先记下来等两年。这两种在报表上都表现为低数字，分开它们的唯一办法是单独测一次需求。

另外还要看这门语言的内容有多旧多薄。有条目但五年没人动、只有一百多字的格子，实际难度跟完全空着差不多，机会同样大。

## 这些空格子会不会很快被别人填上？

速度比想象中慢。公共知识的填补是以年为单位的：洗衣机这个条目在英语里存在了19年，21门语言里才补上10门，平均每年0.51门。

会加速这个过程的因素有两个：一是批量生成内容的成本降到接近零，二是这门语言的编辑人群在增长。第二个因素可以直接查，把新建量和编辑人数的年度趋势拉出来看方向。

保险的做法是做完之后每半年复查一次那几个格子，看有没有第二份内容出现。这个复查跟第一次的查法一样，五分钟，比看流量报表更接近这件事的本质。

## 用什么词去查，用英语还是本地语言？

用本地语言，而且要用跨语言链接找过去，不要自己翻译。同一个概念在不同语言里的条目标题经常不是直译，自己翻的词很可能查不到已经存在的条目。

做法是先在英文维基上找到这个概念的条目，然后从侧边的语言列表里点到目标语言。这一步同时能拿到这个概念在这门语言里的标准说法，写内容的时候用得上。

要批量跑的话，用概念的实体编号一次拿到它在所有语言的标题，一个请求几十个概念。这比逐个搜快得多，也不会因为翻译不准漏掉。

## 条目字节数这个指标可靠吗，会不会被模板撑大？

会，这是它最大的问题。信息框、分类标签、参考文献列表都算在字节里，一个只有两句正文的条目可能因为挂了一堆模板而显得不小。

所以字节数只适合做量级判断，不适合做精确比较。1.4%和25.6%的差别是真的，14%和16%的差别不必当真。

要更准的话得把渲染后的正文抽出来单独数，那要多一步抓取。做初筛的时候不值得，做最终决策的时候可以对排在最前面的那几个词单独做一遍。

## 这套缺口分析，中文市场用得上吗？

整体上用不上，中文的公共知识在覆盖率这一层已经很厚，缺口地图基本全绿。

但换一个粒度就有用了。如果你做的是一个很细的垂直领域，同样可以问：这个领域里的基础概念有没有一份说得过去的公开表述。答案往往是有，但都很旧，或者都是互相抄的。

做法上要换个数据源，中文没有一个像维基那样公开修订史的地方，只能靠实搜和抽样。结论会粗糙一些，但那个提问方式——不问竞争多不多，问最基础的那一份写好了没有——是可以直接搬的。

## 权威参考资料



## 菲律宾被算进英语市场，可你的页面用的不是他们搜的那个英文

- URL：https://zhangwenbao.com/philippine-english-taglish-mixed-language-keyword-research.html
- 分类：小语种SEO
- 发布：2022-05-19  |  更新：2026-07-27
- 摘要：当地用户的查询是英语实词加他加禄语功能词的混写串，而那批英语实词本身也不是美式英语。讲清并列双语与嵌套双语为什么处理方式相反，以及关键词工具给的数字为什么比返回零更危险。
- 关键词：国际化SEO,出海SEO,多语言SEO,小语种SEO

> **TLDR**：摘要：菲律宾在多数出海预算表里被划进英语市场，于是整块跳过了本地化。可当地用户在搜索框里打出来的，是英语实词加他加禄语功能词的混写串，而且那批英语实词本身也不是美式英语。这不是要不要翻译的问题，是关键词表内部要不要分层的问题。

> 摘要：菲律宾在多数出海预算表里被划进英语市场，于是整块跳过了本地化。可当地用户在搜索框里打出来的，是英语实词加他加禄语功能词的混写串，而且那批英语实词本身也不是美式英语。这不是要不要翻译的问题，是关键词表内部要不要分层的问题。

## 菲律宾市场为什么会被整块跳过本地化？

## 官方语言是英语带来的第一个误判

做东南亚预算的时候，菲律宾往往是最快被处理完的那一格。

理由听起来无懈可击：英语是官方语言之一，学校用英语授课，商务文书用英语写。

于是这一格填的是复用英文站，预算写零，工期写零。

接下来发生的事也很规律，流量确实来了，转化率却始终比同一批投放的其他市场低一截。

团队第一反应是加投、改价、换素材，很少有人回头去查最上游的那份关键词表。

问题正好出在那份表上，它是从英文站原样搬过来的，一个字没动。

把一个市场判成不用做本地化，成本不会立刻显形，它会伪装成转化率偏低、加购率偏低、客服问题偏多这些看起来跟语言无关的指标，然后在半年后的复盘会上被归结为品类不适合当地。判成英语市场和判成不用做语言工作，中间隔着一大截，这一步跳过去几乎不会有人提醒你。

## 流量数据看着正常，掉的是哪一层

先说一个容易被忽略的观察角度。

菲律宾的英文页面通常能拿到不错的展示量，因为英文内容天然覆盖了一批查询。

掉的是点击率与加购率这两层，也就是用户看到之后决定要不要点、点进去之后决定要不要买。

点击率低，多半是标题里的词跟用户打的词对不上。

加购率低，多半是页面上没有他关心的那几个本地条件。

这两层都不体现在收录和排名报表里，所以看报表的人会觉得一切正常。

我们给一个自行车配件品牌做过一次三个月的对照，把菲律宾的英文页面和印尼语页面放在同一张表里比，前者的展示量高出四成，加购率却只有后者的一半出头。展示量高说明搜索引擎认得出这一页在讲什么，加购率低说明用户认不出这一页是给他写的，两个数字指向的根本不是同一个问题。

## 被跳过的三个动作

把复用英文站这个决定拆开，实际被跳过的动作有三个。

第一个是关键词调研，没有人查过当地用户实际怎么打这批词。

第二个是落地页的本地条件，付款方式、配送时效、地址字段全是国际版。

第三个是客服与售后语料，模板全是标准英语，读起来像跨国公司的法务函。

三个动作里，第一个是上游，另外两个的错误多半是它带出来的。

顺序也别搞反，先把词查清楚，再改页面，最后改客服语料，反过来做会返工两次。

这套顺序跟做任何一个非英语市场没有区别，唯一的区别在于，别的市场没人敢跳过它，菲律宾因为顶着英语市场这个标签，跳过去显得理直气壮。越南泰国印尼那一篇里的十道工序表 (https://zhangwenbao.com/southeast-asia-seo-vietnam-thailand-indonesia-language-layer.html)可以整套搬过来用，只要把第一道工序的输入从翻译改成混写采样。

还有一个顺序上的细节值得提前说清楚：这三个动作的产出物是互相喂给对方的。关键词调研产出的是词表，落地页改造消费这份词表，客服语料又反过来给词表提供新的原始输入。团队常见的做法是三件事分给三个人并行推进，结果每个人都在等另外两个人的东西，两个月后交付出来的是三份互相对不上的文档。

## 菲律宾人搜的那个英文，跟你写的英文差在哪里？

## 品类词整体位移，不是个别词不一样

先看最直接的一类差异，品类词本身换了。

运动鞋在当地的日常说法是rubber shoes，人字拖是slippers，背心是sando。

你的页面写sneakers，用户搜的是rubber shoes，两串字符没有一个字母重叠。

flip-flops在当地几乎只出现在外贸文案里，本地人说slippers的时候指的就是它。

这不是同义词的问题，是同一个物品在两套英语里挂着不同的名字。

词典查不出来，因为词典收的是标准英语的义项，而这几个是在菲律宾英语里稳定使用的义项。

最省事的验证办法是拿两个词分别去当地的电商平台搜一遍，看结果页的商品数量和广告位密度，当地最大的两个购物平台之一 (https://www.lazada.com.ph/)的搜索建议列表比任何一个关键词工具都更接近真实输入，因为它记录的是掏钱的人打的字。

更麻烦的是这类差异没有一个现成的清单可查。判断一个品类词有没有位移，最实用的办法是把两个候选词分别丢进当地平台的搜索框，比较结果页的商品数量、广告位密度和评论数量。数量差在三倍以上，基本可以确定当地人只用其中一个。这个动作单个品类只要五分钟，一个类目跑下来半天就够。

## 缩写化是另一条稳定规律

菲律宾英语有一个很明显的倾向，长词会被砍短。

空调是aircon，冰箱是ref，洗手间是CR，这几个是全民通用的写法。

这类缩写的特点是它们在当地的正式文书里也照样出现，不属于俚语。

做家电和家居品类的时候，这一条直接决定标题里写哪个词。

写air conditioner不算错，但它接不住搜aircon的那一批人。

两个词同时覆盖是可行的，标题用本地写法，正文里出现一次完整写法。

这套处理跟希腊语市场那个拉丁转写的问题结构一模一样，都是标准写法和真实输入并存，区别在于希腊那边是两套字母，这边是同一套字母的两种词汇选择。希腊语那篇讲的覆盖办法 (https://zhangwenbao.com/greek-seo-greeklish-latin-transliteration-coverage.html)可以直接照搬，把两种形态都放进词表，页面上分位置承载。

缩写化还有一个副产品，它会影响页面标题的长度预算。当地写法普遍比标准写法短，同样一条标题能多塞一个修饰词进去。做小语种的人常年跟标题字数不够较劲，德语那边是一个复合词吃掉半条标题，这边是反过来，本地写法省下的字符刚好够放一个购买意图词，是少见的白捡的空间。

## 品牌名当品类名用

第三类差异更麻烦一点。

当地有一批品牌名已经泛化成了品类名，用户用它指代整个品类。

牙膏说Colgate、复印说Xerox是全球都有的现象，菲律宾的名单还要长一些。

这类词的搜索量往往比正规品类词高好几倍。

不能直接拿来做标题，因为那是别人的商标。

能做的是在正文和问答里自然出现一次，让页面接得住这类查询。

处理这批词的原则跟品牌名音译那篇一致：命名权不在你手里的时候，能做的只有承认既成事实，而不是纠正它。区别在于音译那边要挑一个主写法，这边一个都不能挑，只能在不侵权的前提下让页面出现在结果里。

处理这批泛化品牌词还有一条纪律：绝不能把它写进标题标签或者商品名。搜索量再诱人也不行，因为这是商标使用问题，风险不在算法那一侧。可以出现的位置是正文的说明句、问答区的用户提问原话、以及站内搜索的同义词映射，这三处都属于对用户真实说法的引用，不构成商业标识使用。

## 数量与包装词是本地独有的一层

还有一类词，是从当地的零售形态里长出来的。

小包装单卖在当地极其普遍，对应的说法是sachet和tingi。

这两个词在英美电商语料里几乎不出现，在当地却是高频购买词。

它背后是真实的消费习惯，一次买一小份，而不是买一整瓶。

做个护、日化、宠物食品这类品类，这一层词能带来相当可观的长尾。

做家电和大件的团队可以跳过这一层，但要知道它存在。

这类词是判断一份关键词表有没有真正落地的最快标尺，表里如果一个本地零售形态词都没有，基本可以确定这份表是从英文站直接复制过来的，只是把货币符号改了一下。

零售形态词还牵着另一件事，就是商品的规格拆分。既然当地习惯小份购买，商品页上就该有小规格的选项，哪怕它的毛利更低。词表和货盘在这里是连着的，只做词不改货盘，用户搜进来看见的还是大瓶装，跳出率反而会更难看。当地贸工部关于消费者交易的规定 (https://www.dti.gov.ph/)里对包装标识有明确要求，拆规格之前顺手核对一遍不吃亏。

## Taglish到底是怎么混的，有没有规律？

## 实词留英语，功能词留他加禄语

现在说这批查询最核心的那条规律。

混写不是随机的，切换点相当稳定。

名词、品牌、品类这些实词大多留在英语里。

疑问词、助词、连词、否定这些功能词大多留在他加禄语里。

所以典型的查询长成这样：murang laptop、paano mag-order ng shoes。

前半截是他加禄语的壳，后半截是英语的芯。

这条规律在语言学里叫语码转换，有专门的研究传统，计算语言学界甚至为它办了连续多届的专题工作坊，语码转换计算方法工作坊的历届论文集 (https://aclanthology.org/venues/calcs/)里能看到英语跟西班牙语、印地语、阿拉伯语混写的处理方法，思路对做关键词的人同样有用。

这条规律对做技术的人还有一个直接推论：不能用语言识别的结果来给查询分流。语言识别模型看到一条混写串，会按整串的多数字符判成英语，于是那批带着他加禄语壳的高意图查询被丢进英语通道，用英语的分词和同义词规则处理，壳里的信息全丢了。要分流就按词性分流，不要按语种分流。

## 疑问壳是可枚举的

好消息是，那层壳的数量有限。

问价格用magkano，问方法用paano，问地点用saan，问时间用kailan。

问有没有用may加上句尾的ba，这个ba是疑问标记。

把这几个词跟你的品类词做笛卡尔积，就得到了第一版混写词表。

这批组合的搜索量单个都不高，加起来相当可观。

更关键的是它们的购买意图非常明确，问价格和问怎么下单的人离掏钱只差一步。

这套做法本质上就是把疑问壳当成修饰词层，跟长尾词工程里的那套组合矩阵是同一个方法，只是修饰词换成了另一门语言的功能词。他加禄语的疑问壳不超过十个，一个下午就能穷举完，这是整篇文章里性价比最高的一件事。

穷举完之后还有一个动作别省：给每个疑问壳标上意图类型。问价格的属于比价意图，问方法的属于操作意图，问地点的属于渠道意图。三类意图对应的落地页完全不同，比价意图要落到列表页，操作意图要落到问答或者指南页，渠道意图要落到门店或配送说明页。壳和落地页的映射表一旦建好，后面所有新词都能自动归位。

## 连接词的粘连要单独处理

混写串里有几个小词特别容易被忽略。

ng是属格标记，na是连接词，mga是复数标记。

它们出现在英语实词的前后，把两门语言粘在一起。

做分词和做匹配的时候，这几个词会被当成停用词扔掉。

扔掉之后，混写查询就退化成了纯英语查询，本地特征全没了。

所以停用词表不能直接用英语那一套，也不能直接用他加禄语那一套。

正确做法是先拿真实查询样本跑一遍，统计这几个小词的出现频次和位置，再决定哪些保留哪些丢弃。关键词工具没数据时怎么补 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)那篇里的站内搜索采样法在这里刚好合用，因为混写查询的样本只能从自己的日志里长出来。

这几个小词还有一个很实际的用途，它们是判断一条查询是不是本地真实输入的标记。日志里几十万条查询要人工看是不可能的，但只要按这几个功能词过滤一遍，剩下的就是高度确定的本地混写样本。保哥习惯把这一步叫做用停用词做正向筛选，跟通常拿停用词做剔除的用法正好反过来。

## 拼写变体比想象的多

最后一层是拼写。

他加禄语的口语写法很自由，ngayon会被打成ngaun，kayo会被打成kau。

没有一个权威机构会去纠正这些写法，网上也不会有人觉得它们错。

关键词表里如果只收标准写法，就会漏掉相当一部分真实查询。

处理办法是给每个高频功能词准备两到三个变体，一起进表。

页面上不用把变体全写进去，那样会让文案读起来很奇怪。

变体的正确位置是在问答区和站内搜索的同义词配置里，让它们在匹配层生效而不在展示层露面。他加禄语的字母与拼写体系 (https://www.omniglot.com/writing/tagalog.htm)可以当作判断变体合理性的底本，看一个写法是不是拼音层面站得住，而不是凭感觉决定收不收。

拼写变体还有一个容易被忽视的来源，就是输入法的自动纠错。当地用户大量使用移动端输入，纠错会把某些他加禄语词改成形近的英语词，用户往往懒得改回去，于是这些被纠错过的形态也稳定地出现在日志里。它们看着像乱码，实际上代表着真实的一批人，收进词表的判断标准只有一个，就是出现频次是不是稳定。

## 并列双语和嵌套双语，为什么处理方式正好相反？

## 并列型：两批人各说一门语言

做过多语言市场的人手里都有一套双语市场的处理框架。

加拿大的法语和英语、比利时的荷兰语和法语、乌克兰的乌语和俄语，都属于同一类。

这一类的共同特征是，用户各自使用一门语言，很少在一句话里混着来。

所以解法也很统一，内容分叉、地址分叉、语言标签分叉，各走各的。

用户进站之后选一次语言，之后就一直待在那一侧。

报表也按语言拆两份看，两侧的关键词表几乎没有交集。

这套框架在本站已经写过好几遍，从荷兰语和佛兰芒语，到乌克兰语和俄语，判据一直是数市场个数加看国界位置，而它们全都默认了一件事：一个用户在一次会话里只使用一门语言。

并列型市场还有一个共同的工程特征：两侧的内容可以由两个互不通气的团队分别维护，只要保证商品数据是同一份就行。这也是这类市场看起来比较省心的原因，分工边界跟语言边界重合。hreflang那套标注方法 (https://zhangwenbao.com/international-seo-hreflang-complete-guide.html)之所以在这类市场特别好用，前提正是两侧内容确实是两份互相独立的东西。

## 嵌套型：一批人在一句话里混着用

菲律宾把这个默认假设直接推翻了。

这里不存在说英语的那批人和说他加禄语的那批人。

同一个人，同一次搜索，两门语言同时在场。

他不会因为你出了他加禄语版本就切过去，因为他本来也没觉得自己在用两门语言。

同类市场还有印度的英语加印地语、新加坡和马来西亚的本地英语变体。

这几个市场共享同一个特征，双语关系是嵌套的，不是并列的。

把嵌套型当并列型处理，会做出一个谁也不用的他加禄语版本，同时把英语版本继续放在那儿接不住混写查询，等于花了两份钱买了两个都不对的结果。这类错误在复盘时特别难认，因为团队确实按流程做了本地化。

嵌套型市场的工程特征恰好相反：内容只有一份，分工边界落在词表和版面上，而不是落在语言上。这意味着不需要第二个内容团队，但需要一个人专门维护混写词表和位置分工规则。人力上其实更省，只是组织结构里往往没有这个岗位，于是这件事最后谁都不做，页面就一直停在原样复用英文站的状态。

## 一句话判据与误判的代价

判据可以压缩成一个问题。

问：这个市场的两门语言，是分给两批人，还是分给同一批人的不同词性？

分给两批人，就是并列型，按老框架分叉处理。

分给不同词性，就是嵌套型，页面不分叉，分叉的是词表内部。

这个问题不需要语言学背景，看一眼当地社交平台的评论区就能回答。

评论里一句话里两门语言换着来，就是嵌套型，一目了然。

判断错的代价是不对称的：把并列型误判成嵌套型，页面会写得夹生但还能用；把嵌套型误判成并列型，会同时产出一个多余的语言版本和一批接不住的页面，而且这两笔损失会分别记在不同的项目里，很难被合起来看见。

这条判据还有一个变体用法，可以拿来判断历史遗留的多语言目录该不该保留。如果某个语言版本的流量长期只有主版本的百分之几，而且用户在两个版本之间频繁跳转，那多半就是当初把嵌套型误判成了并列型。这种目录不必立刻删除，先把它的内容合并回主版本，观察一个季度再决定去留，代价最小。

## 关键词工具在这类市场返回的数字，为什么比返回零更危险？

## 返回零和返回一个好看的错数

小语种做久了的人对返回零这件事很熟悉。

工具查不到数据，你知道要自己想办法补。

菲律宾市场不给你这个提醒。

你查sneakers，工具会给你一个体面的数字，还带着趋势曲线。

那个数字是真的，只是它统计的是全球英语的搜索量，跟菲律宾用户在打什么关系不大。

你照着这个数字排优先级，排出来的表看着专业，落地全是偏的。

没有数据的时候你会警惕，有数据的时候你会照做，所以一个看起来健康的错数比一个明显的空值危险得多。这一条不只适用于菲律宾，凡是官方语言跟大语种重合的市场都会遇到，包括印度、尼日利亚、肯尼亚这几个。

这个陷阱在预算评审会上尤其致命，因为一份带着体面数字和趋势曲线的关键词表，是最容易通过评审的材料形态。没有数据的市场反而会被要求补充调研，有数据的市场则直接进入执行。评审机制天然偏袒看起来完整的错误，而不是看起来残缺的正确，做小语种的人对这一条要有心理准备。

## 混写查询会被聚合逻辑打散

再说这个数字为什么会偏。

混写查询的形态是他加禄语壳加英语芯，长度普遍偏长。

工具按词根做聚合的时候，壳会被识别成噪声词剔掉。

剩下的英语芯被并进了那个大词的桶里。

于是一批有明确本地特征的查询，在报表上消失成了大词的一部分。

你看到的大词很大，看不到的是它由几十种混写形态拼起来的。

这也解释了另一个常见现象：菲律宾的自然流量分布特别平，看不出明显的头部词，因为真正的头部被拆散在长尾里了。多语言关键词调研那篇 (https://zhangwenbao.com/multilingual-keyword-research-cross-cultural-localization-query-language.html)里讲的查询语言切换法，在这里要再加一道混写采样才够用。

要验证自己有没有中招，有一个不到十分钟的自查动作：把站内搜索里出现频次最高的两百条查询导出来，统计其中含有本地功能词的比例。这个比例如果超过三成，而你的关键词表里一条混写形态都没有，那就说明工具给的那份排序跟真实需求已经严重脱节，先别继续往下做内容规划。

## 三个能自己补数的地方

补数据的办法有三个，按可靠性排序。

第一是站内搜索日志，这是唯一能看到用户原话的地方，没有任何聚合。

第二是客服工单与聊天记录，用户在那里问的是同样的问题，只是打得更长。

第三是当地电商平台的搜索建议，输入前两个字母看它补全什么。

三个来源加起来，两周就能攒出一份比工具更准的词表。

攒的过程要保留原始串，别急着做词形归并，那一步一做本地特征就没了。

这三个来源在本站讲过不止一次，这里唯一的新要求是采样时把混写串整条留下来，包括那些看起来像拼写错误的写法，因为在这个市场里，看起来像错的往往才是对的。

这三个来源还可以互相校验。站内搜索告诉你用户想找什么，客服工单告诉你他们没找到什么，平台搜索建议告诉你整个市场在找什么。三份数据重合的部分是确定要做的，只在平台建议里出现的部分是增量机会，只在工单里出现的部分往往是页面信息缺失而不是词的问题，处理方式完全不同。

## 页面到底该用哪一种语言写？

## 正文用英语，但要用当地的那种英语

这是整篇里团队最关心的一个决定。

结论是正文用英语，而且是菲律宾本地写法的英语。

理由不复杂，当地的商业书面语就是英语，用户读英语不费劲。

换成他加禄语的正式书面语，反而会让人觉得像政府公告或者课本。

本地写法的英语意味着品类词用rubber shoes这种当地说法，价格和单位按当地习惯写。

不意味着满篇夹他加禄语，那样会显得刻意。

这个结论跟很多人的直觉相反，很多人以为做本地化就是往当地语言靠，实际上本地化的目标是贴近真实语言使用，而当地真实的商业书面语恰好是英语，只是这门英语跟你写的那门不完全一样。

用当地英语写还有一个额外好处，它会自动带出正确的语气。菲律宾的商业文案普遍比英美的更客气一些，问候语更长，感谢句更多。这跟日语敬语那种改写字面的机制不同，实词并不变，变的只是句子的边缘，所以它不影响检索，只影响读起来像不像本地商家写的，属于品牌语气范畴。

## 标题和问答用疑问壳

那批他加禄语功能词往哪儿放。

答案是放在标题、小标题和问答区。

因为用户的混写查询绝大多数是问句形态，落点也在这几个位置。

一个以magkano开头的小标题，能接住一整批问价格的查询。

正文段落里不用这么写，保持顺畅的英语即可。

这个分工可以概括成一句话：壳放在骨架上，芯放在正文里。

把不同语言分配到页面的不同位置，是屈折语锚文本那篇提出来的思路的另一种用法，那边是把精确匹配需求挪到非句内位置，这边是把另一门语言挪到标题层，同样是把语言问题变成版面问题。

位置分工还要考虑一个现实约束：标题标签的显示长度是有限的。疑问壳虽然短，但它挤掉的是品类词的修饰空间。所以真正的做法是分层，标题标签保留最核心的品类词加一个壳，页面内的小标题和问答区承载其余的壳形态。锚文本变形那篇 (https://zhangwenbao.com/minor-language-internal-link-anchor-inflection-variants.html)里那套按位置分配语言形态的思路，在这里是第二次派上用场。

## 纯他加禄语版本为什么反而不自然

必须专门讲一下这个坑。

把整站翻译成他加禄语，看起来是最彻底的本地化。

实际效果通常很差，因为正式他加禄语在当地的使用场景很有限。

它出现在学校、政府文件、部分新闻里，不出现在网购语境。

用户看到一整页正式他加禄语商品描述，第一反应往往是这个站有点怪。

更实际的问题是，机器翻译出来的他加禄语质量普遍偏低，可用的审校资源也不好找。

语域不匹配这件事，比翻译质量本身更难补救，因为它不体现在任何一句话的对错上，而体现在整页读起来像不像给购物者写的。机器翻译直接发布那篇 (https://zhangwenbao.com/machine-translation-direct-publish-search-risk-quality-line.html)里划的质量红线，在这个市场上要再往上抬一档。

语域这件事有一个简单的判断方法：去看当地销量最大的几家本土电商，看它们的商品描述用什么语言写。答案基本是英语，配上少量本地词。本土商家没有任何理由不用母语，他们选择英语，说明这就是这个语境下最自然的选择。跟着本地商家走，比跟着任何一本本地化手册走都可靠。

## 语言标签写en-PH而不是tl-PH

工程侧有一个很具体的结论。

这批页面的语言标签应该是en-PH，不是tl-PH，也不是fil-PH。

因为页面的主体语言确实是英语，只是地区变体是菲律宾。

标成他加禄语会给自己制造麻烦，包括匹配、字体、分词一连串下游行为。

如果确实做了独立的他加禄语版本，那一份才用fil-PH。

fil和tl两个子标签是有区别的，前者指菲律宾语这个国家语言，后者指他加禄语这门语言。

这类子标签的正确用法可以在语言子标签注册表 (https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry)里逐条核对，标签的组合规则则写在RFC 5646关于语言标签的定义 (https://www.rfc-editor.org/rfc/rfc5646)里，这两份材料能省掉一场没有结论的内部争论。

标签写错的代价不只在搜索侧。浏览器和操作系统会依据语言标签决定断行规则、日期格式、数字格式和默认字体，标成一门实际没在用的语言，这些下游行为会一起偏掉。通用区域数据库里的区域设置数据 (https://cldr.unicode.org/)正是被这些系统消费的那一份，标签跟内容对不上，等于给所有下游模块喂了一个错误的前提。

## 商品页上哪些字段必须换成本地说法？

## 尺码、单位与价格的写法

先从最容易改也最容易漏的一组说起。

鞋码在当地习惯用美制，服装尺码习惯用亚洲版型对照。

只写一套尺码，会把一批本来要下单的人挡在退货顾虑上。

价格写法用比索的三位货币代码加数字最稳妥，符号形态在部分设备上显示不全。

数字的千分位用逗号，小数点用点，这跟英语习惯一致，不用改。

分期付款在当地非常普及，商品页上写不写分期，直接影响加购。

这一组字段有个共同点，它们都不属于翻译工作的范围，所以外包翻译时不会有人动它们，最后往往要等到客服工单堆起来才被发现，凡是不在翻译清单里的字段，都要在本地化清单里单列一遍。

价格写法还有一个细节值得单说：促销价和原价的排列顺序。当地用户对分期金额的敏感度高于总价，很多本土商家会把每月付款额放在最显眼的位置，总价反而排在第二行。这不是排版偏好，是购买决策路径的差异，照搬英美站那种总价加折扣率的写法，会让页面在同一批商品里显得更贵。

## 地址与配送字段的层级不一样

地址字段是另一处硬伤。

当地的地址层级里有一个barangay，是比市镇更小的行政单元。

国际版表单里没有这一栏，用户只能把它塞进街道地址那一行。

塞进去的后果是快递员找不到，最后变成配送失败和退款。

省和大区的划分也跟表单默认的那套对不上，大马尼拉地区是一个独立的概念。

岛屿之间的配送时效差别很大，只写一个全国统一时效基本等于没写。

地址表单是转化漏斗上最沉默的一环，用户不会为了填不下一个字段来找客服，他会直接关掉页面，所以这类问题在报表上永远表现为跳出，不会表现为投诉。

地址字段还有一个跟搜索直接相关的用途：那批行政单元名本身就是长尾词。用户会搜品类词加上自己所在的区名，看看有没有当地卖家或者当地自提点。表单里连这一级都没有的站，自然也不可能在内容里出现这些地名，于是整批本地意图词一条都接不住，而这批词的转化率通常高得离谱。

## 付款方式那一栏是购买意图最强的词

最后一组是付款方式。

当地的电子钱包普及率很高，货到付款同时也还占着相当大的份额。

便利店代收和汇款点付款是两条独立的通道，各自有自己的用户群。

这些方式的名字本身就是高意图关键词，用户会拿它们跟品类词一起搜。

商品页上支持了却一个字没写，是这个市场上最常见的一处浪费。

写法也有讲究，把方式名写全称并且跟品类词同段出现，比堆一排图标有效。当地央行公布的电子支付统计与监管口径 (https://www.bsp.gov.ph/)能帮你判断哪几种方式值得写进页面。

本站关于信任元素那篇讲过同一件事，落地页上那些看着像装饰的信任元素 (https://zhangwenbao.com/minor-language-landing-page-trust-signals-payment-address-support.html)其实是搜索量最高的一批购买词，菲律宾市场把这个现象放大了一倍，因为这里的付款方式种类比多数市场都多，当地用户量最大的电子钱包 (https://www.gcash.com/)光是名字本身就是一个稳定的品类修饰词。

## 客服与售后的语言该怎么定？

## 首轮用英语，追问跟着用户走

客服语言的问题比页面语言简单一些。

首轮回复用英语，因为它对所有人都成立。

用户如果用混写追问，回复就跟着切到混写。

这不是随意，而是一条可以写进规范的规则。

跟着用户的语言走，是所有多语言客服里最省心的一条准则。

需要提前准备的，是那批混写模板，不能等到对话中间现编。

准备模板的成本比想象中低，因为需要混写的只有开头的招呼句、确认句和结束句这三类，中间的实质内容依然是英语，真正要本地化的是对话的骨架而不是内容。

跟着用户语言走这条规则要写进客服的质检标准里，否则它会被理解成可以随意。质检时抽查的口径很简单：用户混写而客服全程标准英语的对话，标记为不达标；客服在用户尚未混写时主动混写的，同样标记为不达标。两条一起用，才能把这条规则从一句倡议变成可以考核的动作。

## 模板语料要从工单里长出来

模板从哪儿来，答案是从自己的工单里来。

把过去半年的对话导出来，按问题类型分组。

每组挑出十条用户原话，看他们怎么起头、怎么问价、怎么催单。

照着那批原话写模板，比找一个翻译写一版靠谱得多。

这样写出来的模板天然带着当地的语气和用词。

顺带还能得到一份高质量的关键词补充材料，一举两得。

我一直建议团队把客服语料和关键词表放在同一个流程里维护，因为它们的原始材料是同一批用户说的同一批话，只是被两个部门分别用了，母语审校验收清单那篇 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)里的验收口径同样适用于客服模板，读着自然不等于验收通过。

从工单里长模板还有一个隐藏收益，就是能顺手发现商品页的信息缺口。同一个问题在工单里出现超过五十次，说明页面上根本没写清楚这件事。把这类问题整理成一张缺口清单交给内容团队，比任何一次页面体检都准，因为它统计的是用户实际卡住的地方，而不是我们以为他们会卡住的地方。

## 三个渠道的语域是不同的

还有一个细节值得说。

电话、在线聊天、社交平台私信，这三个渠道的语域差别很大。

电话里几乎全是混写，社交平台私信更随意，工单和邮件偏正式。

用同一套模板覆盖三个渠道，会在某一头显得生硬。

比较省事的做法是准备两档，正式一档给邮件和工单，随意一档给聊天和私信。

两档之间的差别主要在招呼语和结束语，中间部分共用。

这个两档制在别的市场也成立，只是在菲律宾差别更明显，因为这里的正式和随意之间恰好还叠加了一层语言选择，随意的那一档自动就变成了混写。

渠道语域的差别还会影响关键词采样的权重。私信和聊天里的原话最接近搜索框输入，邮件和工单里的表述则被用户自己整理过一遍，离真实查询更远。所以做词表采样时，聊天记录的权重要高于邮件，采样量少也没关系，它的信噪比高得多，这个优先级在多数团队里是反着的。

## 这套做法搬到宿务语区会不会失效？

## 马尼拉之外还有一大片市场

菲律宾不是一个单语市场，这一点要专门说清楚。

他加禄语是国家语言的基础，但它不是全国母语。

中南部有大量宿务语使用者，规模是当地第二大的语言群体。

此外还有伊洛卡诺语、希利盖农语等多个规模不小的语言。

这些地区的用户同样在做混写，只是壳换成了他们的母语。

所以前面那套判据仍然成立，需要更换的只是壳的具体词表。

各语言的谱系关系与使用范围可以在宿务语的语言库条目 (https://glottolog.org/resource/languoid/id/cebu1242)里查到，做区域优先级的时候拿它跟自己的订单分布叠一遍，比按人口排要准。

区域差异还体现在设备与网络上。首都圈之外的移动网络条件普遍更差，页面重量对转化的影响被放大。做区域扩张时如果只准备了内容却没压首屏体积，效果会打折扣。该国的宏观与基础设施数据 (https://data.worldbank.org/country/philippines)里能查到分区域的联网水平，排优先级时把它跟订单密度叠一层看。

## 三档投入怎么分

投入分三档，按订单密度决定做到哪一档。

第一档只做词表覆盖，把宿务语的疑问壳并进现有词表。

第二档加做问答区，用宿务语壳写几组常见问题。

第三档才是独立的落地页，通常只有区域订单占比过两成才值得。

绝大多数团队停在第一档就够了，成本几乎为零。

第二档的成本主要是找一个当地人写十几组问答，一周内能完成。

把投入分档而不是二选一，是本站在小语种话题里反复用的做法，原因也一直是同一个：大多数语言的正确答案既不是完全不做也不是全套做，而是只做最上游的那一层。

三档投入之间还要留一个回退机制。第二档做完之后观察一个季度，如果宿务语壳带来的查询占比没有明显上升，就说明这个区域的用户其实也在用他加禄语壳搜索，那就该停在第一档而不是继续往上加。语言分布跟人口分布不重合是常态，实际搜索行为才是唯一算数的证据。

## 什么时候值得做第二套内容

什么条件下才升到第三档，可以给一个可判断的标准。

看三个数：区域订单占比、区域客服工单占比、区域自然流量占比。

三个数里有两个超过两成，就值得做独立内容。

只有流量高而订单低，多半是内容不对路，先修词表再说。

只有工单高，往往是配送时效问题，跟语言无关。

三个数一起看，能挡掉大部分拍脑袋的扩张决定。

这条判据跟本站讲搜索意图差异那篇的思路一致，同一份关键词表在两个市场要拆成两种落地页 (https://zhangwenbao.com/minor-language-search-intent-divergence-across-markets.html)说的是内容分叉的条件，这里说的是语言分叉的条件，两者可以合成一张表来用。

做第二套内容之前还有一件事要先确认：客服能不能跟上。内容上线之后带来的咨询会用同一门语言进来，如果客服团队没有对应的语言能力，转化会卡在最后一步，前面的投入全打水漂。宿务语的字母与拼写体系 (https://www.omniglot.com/writing/cebuano.htm)不难，难的是找到能稳定值班的人，这一步要在内容排期之前落实。

## 怎么排期，怎么验收？

## 六周排期表

把前面的动作串成一个可执行的顺序。

第一周导出站内搜索日志与客服对话，只做采样不做加工。

第二周整理混写词表，疑问壳穷举，品类词换成本地写法。

第三周改标题与小标题，问答区按疑问壳重写一遍。

第四周改商品页字段，尺码、地址、付款方式三组一起动。

第五周改客服模板，两档语域各出一版。

第六周留给复核与观测，重点看点击率与加购率这两个指标有没有动，排名和收录在这套改动里基本不会变，所以拿排名当验收指标会得到一个什么都没发生的结论。

这份排期表里有一条隐含的假设值得点破：前两周是纯采样，不产出任何可交付物。很多团队扛不住这两周的空窗，于是跳过采样直接开始改页面，改完再回头补数据，然后发现改的方向不对。采样阶段没有可交付物，不等于没有产出，它产出的是后面四周不返工。

## 三条不用懂他加禄语的机械检查

验收环节最怕的是没人懂当地语言。

所以要有几条不依赖语言能力的检查。

第一条：数标题里的本地品类词，一个页面至少出现一次rubber shoes这类当地说法。

第二条：数问答区的问句开头，至少三分之一以他加禄语疑问壳起头。

第三条：查付款方式名有没有以文字形式出现在正文里，只有图标算不通过。

三条都能靠搜索命令和肉眼完成，不需要语言背景。

机械检查的价值不在于精确，而在于它能被没有语言能力的人执行，从而让这件事不依赖某一个人的判断，这也是本站在小语种话题里一直坚持给出机械判据的原因。

这三条检查还可以再加一条自动化的：定期抓取自己页面的标题标签，跟当前混写词表做一次匹配，统计覆盖率。覆盖率低于某个阈值就报警。这件事一个定时脚本就能做，好处是它不依赖任何人记得去查，而多数本地化工作的退化，恰恰不是因为做错了，而是因为上线之后再也没人看过。

## 谁来审，审什么

最后是审校。

找母语者审校时，要明确告诉对方审的是自然度不是正确性。

因为混写文案在语法上本来就不标准，按标准语法审会被全部改掉。

正确的指令是：读一遍，标出哪些地方本地人不会这么说。

另外要找的是做零售或客服的人，不是语文老师。

语文老师会把混写改成规范他加禄语，那正好是我们要避免的结果。

保哥这些年在多语言项目里踩过最多的一次，就是审校口径没定清楚，交付回来一份语法完美、没有一个用户会这么说的文案，返工成本比重写还高。

审校的交付物形态也要提前约定。要的是一份带位置标记的问题清单，不是一份改好的稿子。因为审校者一旦直接改稿，就会顺手把混写改成规范写法，而我们没有办法逐句还原他改了什么。约定成清单形态，判断权就留在自己这一侧，这条规矩在任何一个语域敏感的项目里都值得先立起来。

## 常见问题解答

## 菲律宾市场到底要不要单独做内容？

要，但做的不是翻译。需要单独做的是三件事：关键词表按本地英语与混写形态重做一遍、标题与问答区换成疑问壳形态、商品页的付款与地址字段按本地形态重排。正文主体依然是英语，不需要重写。这三件事加起来大约是一个市场本地化工作量的三成，成本远低于新增一门语言，收益主要体现在点击率和加购率上。

## 做一个纯他加禄语版本有没有意义？

多数情况下没有。正式他加禄语在网购语境里几乎不被使用，用户读到整页正式他加禄语商品描述会觉得别扭，加上机器翻译质量偏低、审校资源难找，实际效果通常不如一个写得地道的英语版本。真正值得投入的方向是让英语版本用当地的说法，并在标题和问答里接住混写查询。只有在做政府、教育、公共服务这类内容时，纯他加禄语版本才有明确价值。

## 语言标签应该写成什么？

主体是英语的页面写en-PH，这是最贴近实际的标注。不要因为页面里出现了几个他加禄语词就改成tl-PH，那会让下游的匹配与排版逻辑做出错误假设。如果确实做了独立的他加禄语版本，那一份用fil-PH。fil指的是作为国家语言的菲律宾语，tl指的是他加禄语这门语言，两者在注册表里是不同的子标签，混用会给自己埋坑。

## 关键词工具的数据完全不能用吗？

能用，但只能当作量级参考，不能当作排序依据。工具给的英语数字是全球聚合的结果，混写形态在聚合中被打散，所以它反映的是这个品类在英语世界的整体热度，而不是当地的真实需求分布。正确用法是拿工具的数字定品类大盘，拿站内搜索日志和平台搜索建议定具体词的优先级，两份数据分别回答不同的问题，不要指望其中一份把两件事都办了。

## 混写词表要维护多久更新一次？

建议每季度更新一次，重点看新增的功能词变体和新出现的品牌泛化词。这类词的变化速度比正规品类词快，因为它跟着社交平台的流行说法走。更新的成本很低，导一次站内搜索日志按频次排序，看排名前两百的串里有没有陌生形态即可。真正需要重做的情况只有一种，就是品类结构发生了变化，比如从卖配件扩展到卖整车，那时候壳不变、芯要重来。

## 这套方法能直接搬到印度或新加坡吗？

框架能搬，词表不能。三个市场同属嵌套型双语，都是实词英语加本地语功能词的结构，所以判据、页面分工、验收方式全都通用。但每个市场的功能词、缩写习惯与本地英语词汇是各自独立的，印度的英语变体跟菲律宾的英语变体是两套词。搬框架能省掉大约一半的方案时间，搬词表则会把错误一起搬过去，这也是嵌套型市场彼此之间最容易被误判的地方。

## 预算有限的话，先做哪一件？

先换品类词。把标题和主要小标题里的品类词换成当地说法，这是唯一一件当周就能上线、当月就能看到点击率变化的事，成本只有一个人两天。第二件做问答区的疑问壳，第三件做付款方式的文字化。这三件做完，大部分低垂的果实就摘完了。地址表单和客服模板虽然重要，但它们的收益体现在转化后段，见效周期长，适合排在后面。

## 权威参考资料



## 你的色卡上蓝和绿是两格，120门语言的样本里只有30门这么分

- URL：https://zhangwenbao.com/minor-language-color-category-attribute-value.html
- 分类：小语种SEO
- 发布：2022-04-12  |  更新：2026-07-28
- 摘要：筛选器背后是一次精确相等的查询，用户点的选项和库里的字符串差一个字母就是零结果，而颜色恰好是各语言边界最对不齐的一类词。讲清拆与并两个方向为什么要分开处理、一对一翻译表错在结构而不在译者，以及营销色名和基本色名的命名权为什么不在一处。
- 关键词：出海SEO,多语言SEO,小语种SEO,商品数据

> **TLDR**：摘要：正文里同一个意思可以有一百种说法，模糊匹配都能救回来；属性值这一层不行，用户点的那个选项和库里存的那个字符串必须严格相等。而颜色恰好是各语言之间边界最对不齐的一类词，有的语言把你的一格拆成两格，有的语言把你的两格并成一格。本文把这层范畴错位拆开，给出一张多对多映射表的建法。

> 摘要：正文里同一个意思可以有一百种说法，模糊匹配都能救回来；属性值这一层不行，用户点的那个选项和库里存的那个字符串必须严格相等。而颜色恰好是各语言之间边界最对不齐的一类词，有的语言把你的一格拆成两格，有的语言把你的两格并成一格。本文把这层范畴错位拆开，给出一张多对多映射表的建法。

## 为什么俄语用户搜的那个蓝色词，你的库里根本没有？

## 一次筛选器上的空结果

那是一家做俄语市场的厨房小家电站，主力是电水壶和料理机。

商品有六七种配色，颜色筛选器是从英文站直接搬过来的。

翻译做得很规矩，每个英文颜色词都配了一个俄语词。

上线之后，颜色筛选器的使用率一直低得反常。

站内搜索里那个高频词，在筛选器的选项里一个都对不上。

问题出在一个英语里根本不存在的地方：俄语把浅蓝和深蓝当成两个基本颜色，各有各的词，就像英语里的红和粉是两个词一样。而那张翻译表把英语的蓝色映射成了其中一个，另一个词在整个站上一次都没出现过。

搜另一个词的人不是少数，他们只是被整个筛掉了。

后来把站内搜索日志翻出来对了一遍，那个没进筛选器的词在颜色类查询里排第二，量只比首选词少三分之一。也就是说这不是一个边缘写法被漏掉，而是接近一半的颜色需求从入口那一步就被挡住了，而后台的筛选器使用率报表只会显示这个筛选器不受欢迎。

## 这不是翻译质量问题

负责翻译的是母语译者，给出的词完全正确。

问题在于任务本身就出错了：一个格子只能填一个词。

译者拿到的是一张两列表格，左边英文，右边俄文。

这张表的结构强制他必须在两个词里选一个。

选哪个都是错的，因为原来那一格本来就装不下。

这条值得单独强调：当交付物的结构本身错了，再高的执行质量也救不回来。译者能做的只有在备注栏里写一句“这里其实有两个词”，而备注栏的内容通常不会进任何一个系统。

后来那家站的负责人问了一句很实在的话：这种事还有多少？

类似的结构性错误还有几种常见形态：给译者一个字符数上限、给译者一个必须复用的句式模板、要求译文的段落数跟源文一致。它们的共同点都是把源语言的某个属性当成了普适约束。判断办法是问一句，这条约束如果换个源语言还成立吗，不成立的就是假约束。

## 这篇文章不讨论颜色词该怎么变形

先划一条线，免得跟另一类问题混起来。

颜色词在很多语言里是形容词，要跟名词配合变形。

俄语、德语、意大利语都是如此，形态一大把。

那是形态问题，跟这篇要讲的不是一回事。

这篇讲的是范畴问题：这个词指的到底是不是同一块颜色。

意大利语性数配合那篇 (https://zhangwenbao.com/italian-seo-gender-agreement-elision-keyword-research.html)和韩语属性值那篇 (https://zhangwenbao.com/korean-seo-spacing-particles-keyword-research.html)处理的都是“同一个值在目标语言里长什么样”，本篇处理的是前一个问题：这个值在目标语言里到底还是不是同一个值。形态错了用户还能看懂，范畴错了整条数据就指向了别的东西。

两类问题的排查顺序也不同。形态问题可以靠词形展开工具批量处理，属于可以外包给算法的那一类；范畴问题必须有人对着实物或者色值做一次判断，没有任何算法能替你决定当地人把哪一段光谱叫做一个颜色。先解决范畴再处理形态，顺序反了会白做很多词形。

## 属性值这一层为什么不能靠模糊匹配救回来？

## 正文有一百种说法都不要紧

先说正文那一层为什么宽容。

页面上描述一件商品的颜色，可以有很多种写法。

写成天蓝、浅蓝、湖蓝、雾霾蓝，都能被理解。

检索侧同样宽容，词形近似、同义、部分匹配都算数。

所以正文层写得不精确，代价通常是排名差一点。

这种宽容让人产生一种错觉，以为整个站都是这么宽容的。实际上宽容只存在于自由文本那一层，一旦进入结构化字段，规则完全变了。

这种宽容还有一层来源经常被忽略：正文里同一个概念多写几种说法，本身就是被鼓励的做法，因为它顺手覆盖了长尾。于是做内容的人长期在一个奖励冗余的环境里工作，等他们去填结构化字段的时候，那套直觉正好是反的，而没有人提醒过他们规则换了。

还有一种情形会加深这个错觉：正文写得越丰富，页面在颜色类查询上的表现越好，团队会据此认为颜色这块做得不错。而筛选器和结构化数据那两处的损失从来不会出现在同一张报表上，两边的信号完全没有交汇的机会。

## 枚举值这一层要求字符串严格相等

筛选器背后是一次精确查询。

用户点了那个选项，系统拿选项的值去库里找。

找的方式是完全相等，一个字母不同就是零结果。

检索引擎里的精确词查询 (https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-term-query.html)说明得很清楚，这类查询不做任何分析和归一化，传进去什么就拿什么去比对。

这是设计如此，不是缺陷，筛选本来就该是确定的。

于是就有了这么一条：属性值是全站唯一一处用户想要的东西和库里存的字符串必须严格相等的地方。正文可以模糊，标题可以模糊，标签可以模糊，唯独枚举值不能。而颜色偏偏是所有属性里语义边界最模糊的一类。

最不容妥协的那一层，装的是最不好界定的那类词。

这一层还有个容易踩的细节：即使字符串完全一样，大小写、首尾空格、全角半角的差别照样会导致零结果。很多站的颜色值是运营手工录进去的，同一个词在库里存着好几种写法。开工之前先跑一次去重统计，把库里实际存在的取值全部列出来，经常一列就吓一跳。

## 站内搜索也吃这一层的亏

不只是筛选器，站内搜索也一样。

用户在搜索框里输入的颜色词如果不在你的词表里，命中率会掉得很厉害。

好一点的实现会做同义词扩展，检索系统的语言分析文档 (https://solr.apache.org/guide/solr/latest/indexing-guide/language-analysis.html)里对同义词过滤器的位置有专门说明，但同义词表本身还是得有人填。

而填同义词表的人，用的还是那张一对一的翻译表。

错误就这么从一个地方复制到了另一个地方。

小语种关键词工具没数据那篇 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)里讲过一件事：站内搜索日志是小语种市场上最可靠的一份本地语料。这一层正好可以印证——日志里出现频次很高却一次都没命中过的词，几乎全是范畴错位造成的。

还有一个更省事的诊断入口：把站内搜索的零结果词按频次排序，只看前五十个。范畴错位造成的词会成群出现，通常是同一个颜色家族的几个说法一起排在前面。这个特征很好认，跟拼写错误造成的零结果长得完全不一样，后者是散落的、各不相同的。

## 结构化数据里的那一格也是枚举

还有第三个位置，很多人没意识到它同样敏感。

商品的结构化数据里有一个颜色字段。

这个字段在词汇表里的定义 (https://schema.org/color)是一个自由文本，看着很宽松。

但消费这个字段的下游系统通常按精确值处理。

比价平台、商品聚合、广告投放，都会拿它去归并。

填一个当地人不用的词进去，等于在这些渠道上把自己归到了一个空分类里。这一层的反馈比筛选器还要慢，因为你在自己的后台完全看不到别人的归并结果。

这一层还有个连带影响：广告投放的商品信息流用的也是这些字段。投放系统按属性值做定向和分组，颜色词填错会让一部分商品进错受众包。跟筛选器不同的是，这里的损失体现在成本上而不是转化上，报表里看到的只是某个组的表现差，很难追溯到一个词。

## 颜色范畴在语言之间是怎么对不齐的？

## 先看一组硬数据

颜色词这件事有现成的跨语言调查可以参考。

世界语言结构图集里关于绿与蓝的那一章 (https://wals.info/chapter/134)统计了120门语言，结果相当反直觉。

把绿和蓝当成两个独立基本颜色词的，只有30门。

用一个词同时覆盖绿和蓝的，有68门。

还有15门把黑、绿、蓝三者合在一个词里。

换句话说，把蓝和绿分成两格，在这份样本里是少数派。要说明的是，这份样本按全球语言分布取样，跟电商目标市场的分布完全不是一回事，你实际要做的那几门语言多半都在分开的那一档里。但它给出了一条更硬的结论：分成两格不是天经地义的，它只是你熟悉的那几门语言恰好如此。

同一份资料里还有另一张表，统计基本颜色范畴的总数。

这份调查还有一个用法：它按语系和地区标注了每一门语言，可以快速看出某个区域的语言在这件事上是不是整体偏向某一种分法。要做一个陌生市场之前翻一眼，比凭印象猜靠谱。当然它是语言学取样不是市场取样，只能当背景知识，具体到某门语言还是要自己量一遍。

## 范畴总数本身就不一样

关于基本颜色范畴数量的那一章 (https://wals.info/chapter/133)统计了119门语言，分档从三档到六档不等。

只有三个基本颜色范畴的语言有10门。

五个范畴的最多，有56门。

六个范畴的有29门。

你的色卡通常按英语那套十来个基本色词设计。

把一套十几格的划分投射到一套五格的划分上，必然有格子要合并；反过来投射，必然有格子要拆开。这是一个纯粹的结构问题，跟任何一方的语言丰富程度都无关。

这里有个反直觉的地方值得说明：基本颜色范畴少，不代表那门语言表达不了细微的色差。它一样有大量的限定说法和比喻说法，只是这些说法不构成独立的基本词。做筛选器要用的恰恰是基本词那一层，因为只有基本词才是用户会不假思索打出来的。

这条同样适用于反方向：基本颜色范畴多，也不意味着做起来更麻烦。多出来的那一格如果在你的品类上根本没有商品，它就跟你无关。真正决定工作量的是有商品的那几块颜色跟你的色卡对不对得上，不是这门语言总共有几个色词。

## 拆开与合并是两个方向

错位有两个方向，处理办法完全不同。

一个方向是拆：源语言一个词，目标语言两个词。

俄语的深浅蓝就是这一类，日语的青也是，这项特征的取值分布表 (https://wals.info/feature/134A)里能查到每一门语言各自属于哪一档。

另一个方向是并：源语言两个词，目标语言一个词。

越南语里蓝和绿共用一个词，要靠后缀限定才分得开。

拆的方向要在词表里加行，成本低但容易漏；并的方向麻烦得多，因为你得决定这一个词到底挂在哪个筛选项下，或者干脆让它同时挂两个。拆是覆盖问题，并是归属问题，后者需要一次真正的决策。

实际操作里还有第三种情况，就是错位而不是拆并：两门语言的分界线都只有一条，但画的位置不一样。这种最难发现，因为两边的词数相同，一对一映射看着毫无问题，只有拿实际色值去比对才会露馅。这也是为什么中间层必须绑色值，不能绑词。

## 方向还可能不对称

更麻烦的是，同一对语言在不同颜色上的方向未必一致。

英语到俄语，蓝色要拆，别的颜色多数一一对应。

英语到日语，青色的边界跟蓝绿两个词都不重合。

英语到德语，紫色一带的划分和英语差得比想象中大。

所以不能得出“某某语言比英语分得细”这种整体结论。

这一点在排期上很重要：范畴错位是按颜色逐个成立的，不是按语言整体成立的，所以工作量的估算单位是语言乘以颜色，而不是语言。一门语言上可能只有两三个颜色出问题，其余全都干干净净。

排期的时候可以直接把这个当成一个矩阵来看：行是语言，列是颜色，格子里填对不对齐。填完之后一眼就能看出工作量集中在哪几行哪几列。多数站填出来的矩阵是很稀疏的，真正需要处理的格子不到一成，这个结论本身就能省掉一次大规模返工。

## 一对一的翻译表为什么从一开始就是错的结构？

## 两列表格暗含了一个假设

回到最开头那张表。

它有两列，一行填一对词。

这个结构本身就假设了两边的格子数量相同。

只要这个假设不成立，表就装不下真实情况。

而装不下的部分不会报错，只会被悄悄丢掉。

这类问题在数据建模上有个通用的识别办法：看一眼表的主键，如果主键是源语言那一列，就说明你已经默认目标语言不会比源语言多出任何东西。改法是把主键换成一个跟语言无关的编号，两边都挂在它下面。

这个假设还会以别的形式冒出来，比如要求每门语言的属性值数量一致，或者用一个共享的自增编号同时当英文词的主键。判断标准仍然是那一条：结构里有没有哪一门语言享有特权。有特权的那门语言，通常就是最早上线的那门，跟它是不是英语其实无关。

还有一个信号可以帮你快速识别这类结构：看看这张表在没有目标语言的时候能不能存在。如果去掉所有译文之后，剩下的那一列仍然是一份完整可用的数据，说明结构是对的；如果剩下的只是一堆孤零零的英文词，那它本来就不是一份主数据。

## 正确的结构是一个中间层

可行的做法是加一层不属于任何语言的标识。

给每一块实际的颜色一个编号，编号只对应色值。

然后每门语言各自挂自己的词，数量可以不等。

英语挂一个词，俄语挂两个词，越南语两个编号共挂一个词。

这样拆和并两个方向都能表达。

这一层的编号最好直接绑到实际色值上，而不是绑到某个英文词上。用色值当锚有个额外好处：新增一款商品时，是拿实物色卡去比对，而不是让运营在下拉框里挑一个英文词，这一步的判断质量会明显提高。

这个中间层还有个附带好处：它让颜色数据可以脱离站点独立存在。换一套电商系统、接一个新的渠道、给经销商导一份表，靠的都是这层编号。凡是能独立于任何一个系统存在的主数据，迁移成本都会低一个数量级，这一点在换平台的时候才会真正体现出来。

## 映射不只是多对多，还得带权重

光有多对多还不够用。

两个词挂在同一个编号上，通常不是平等的。

其中一个是当地人更常用的说法，另一个偏书面或者偏专业。

展示的时候只能选一个，检索的时候两个都要能命中。

所以每一行还要标一个字段，说明它是不是首选。

首选词决定筛选器上显示什么、结构化数据里填什么；非首选词只进同义词表和站内搜索的扩展词典。这个区分做出来之后，前面提到的三个位置就都有了明确的取值规则，不用每次现商量。

权重字段的取值不必复杂，一个布尔标记加一个可选的排序号就够用。要抵制的是把它做成打分制，因为打分需要依据，而这一层根本没有可靠的依据可打。首选与非首选这个二分，母语者两秒钟就能判断，做成五档评分反而没人愿意填，最后全是默认值。

## 这套表要能承受商品新增

最后一个结构要求是可扩展。

新商品带来新颜色是常态，尤其是服饰和家居。

如果新增颜色要先在英文里定一个词才能往下走，节奏就卡住了。

正确的顺序是先给色值一个编号，各语言再各自补词。

英语没想好名字，不该阻塞俄语上架。

葡语双市场那篇 (https://zhangwenbao.com/portuguese-seo-brazil-portugal-two-markets-keyword.html)里讲过商品属性词比正文更值得抠的道理，这里可以再补一条：属性词表的结构决定了它的更新速度，而更新速度决定了新品能不能按时在各个市场同时上架。结构问题最后都会变成排期问题。

还有一个容易被忽略的扩展方向是渠道。同一个色块在自己的站上、在平台上、在广告信息流里可能要求不同的取值格式，有的平台还有自己的封闭色词表。中间层在这里同样能兜住，各渠道各挂一列映射即可，别去改主数据迁就某一个渠道。

## 哪些属性词跟颜色一样有范畴问题？

## 先说判据

不是所有属性都有这个毛病，多数属性其实很老实。

判据只有一条：这个属性的取值是不是连续的。

颜色是连续的，光谱上没有天然的分界线。

分界线是各语言自己画的，画在哪儿全凭习惯。

而容量、重量、尺寸这些是数值，不存在这个问题。

这条判据可以在半小时内把全部属性过一遍：凡是取值本身是一个连续谱、而词只是在谱上切段的属性，都有范畴错位风险；凡是取值本身就是离散事实的属性，最多有翻译问题没有范畴问题。

这条判据还能顺手解释一个现象：为什么尺码这类属性问题很多，但麻烦的性质完全不同。尺码是离散的，只是各地的编号体系不一样，那是一个换算问题，有确定答案。颜色没有换算表可查，因为它压根不存在一个各语言公认的刻度，这是两类完全不同的活。

## 材质和面料是第二大重灾区

按这条判据筛下来，材质排在颜色后面。

材质看着像离散的，实际上边界很软。

皮革、再生皮、合成革在不同语言里的分法不一样。

有些语言里某个词同时覆盖两三种工艺。

而这个属性还带着法规约束，用错词不只是搜索问题。

做这一类属性时有个稳妥的做法：先查目标市场对这类词有没有强制定义，有强制定义的以法规词为准，没有的再按用户习惯选。跨市场搜索意图分歧那篇 (https://zhangwenbao.com/minor-language-search-intent-divergence-across-markets.html)提到的思路在这里同样适用，先分清哪些差异是习惯造成的，哪些是制度造成的。

材质这一层还有一个额外的坑：同一个词在两个市场的法规定义可能不同，而这两个市场用的是同一门语言。也就是说这里的分歧不是按语言划的，是按司法辖区划的。处理办法是把材质词的映射表主键加一维地区，别跟颜色那张表用同一个结构。

## 款式与风格词最难办

第三类是款式和风格。

休闲、商务、复古、简约这类词在各语言里的切分差得很远。

它们还带着强烈的本地文化含义，直译过去经常不知所云。

这类词的范畴甚至会随时间变，比某某风格流行三年就换一批。

所以风格词更适合当标签，不适合当筛选器的枚举值。

一个可操作的分界是：范畴稳定的属性放筛选器，范畴会漂的属性放标签。筛选器要求的是确定性，标签允许一个商品挂多个、也允许过一阵子调整，两者的容错完全不同。

还有一个实用的信号可以帮你判断某个风格词稳不稳：去看它在当地媒体和平台上的使用是不是有明确的定义，还是纯靠语感。有明确定义的可以进筛选器，纯靠语感的一律走标签。这个信号比问母语者可靠，因为母语者对熟悉的词往往说不出边界在哪儿。

## 营销色名和基本色名该分开处理吗？

## 两类色名的命名权不在一个地方

商品上其实有两套颜色说法在同时跑。

一套是基本色名，蓝、绿、灰，人人都会说。

另一套是营销色名，午夜蓝、雾松绿、石墨灰。

基本色名的命名权在语言手里，谁也改不了。

营销色名的命名权在品牌手里，想叫什么叫什么。

这条区分能直接推出处理办法：命名权在语言手里的必须重新划分范畴，命名权在品牌手里的只需要决定翻不翻。本地作者署名那篇 (https://zhangwenbao.com/minor-language-eat-local-author-byline-credential-signals.html)里讨论过命名权归谁决定收敛还是汇总，这里是同一把尺子量在另一类对象上，得到的结论方向不同但逻辑一致。

这条区分还能推出一个排查顺序：先把两类色名在数据里分开，再谈处理。多数站的问题是这两类词混在同一个字段里，营销色名和基本色名共用一个下拉框，于是筛选器上既有蓝色又有午夜蓝，用户完全不知道该点哪一个。分开这一步做完，一半的问题就没了。

## 营销色名不要翻译

营销色名的处理其实最简单。

它是品牌资产，保持一致比让人看懂更重要。

直译过去往往很怪，因为那些比喻本来就是英语的。

更要紧的是，几乎没有用户会拿营销色名去搜索。

它出现在商品页上，不出现在搜索框里。

所以营销色名的正确位置是展示层，跟在基本色名后面当补充说明。真正进筛选器、进结构化数据、进关键词表的，一律用基本色名。这个分工做清楚，能省掉大量关于“这个词该怎么译”的讨论。

有一类情况例外值得留意：如果营销色名里含有当地语言中不合适的谐音或者联想，那就必须换，这时候换的理由是风险不是检索。判断这件事只能靠母语的人，而且要问的是有没有别的意思，不是问好不好听。这个问题问法一变，得到的答案质量差很多。

## 两套名字要在同一页共现

还有一个小动作值得做。

把营销色名和基本色名写在同一个位置，中间用括号或者破折号连起来。

这样搜基本色名的人能找到这个商品。

看到营销色名的人也知道它到底是什么颜色。

共现这件事对检索侧的作用比想象中大。

这跟品牌名的处理是一个思路。品牌名音译那篇 (https://zhangwenbao.com/brand-name-transliteration-loanword-minor-language-search.html)讲的是让几种写法在同一页出现，让机器把它们关联起来；颜色这一层，共现的作用是把品牌自造的词挂到一个真实存在的词上去。

共现的具体位置也有讲究：放在商品标题里通常太挤，放在规格参数表里又太靠下，比较稳妥的是放在选色区块的标签上。那个位置本来就要显示色名，多加一个括号不占额外空间，而且用户在挑颜色的时候正好会看到，属于顺手就能收下的一处改动。

## 建一张多对多映射表的四个步骤

## 第一步：先数目标语言有几个基本色词

动手之前先做一件小事，结论会决定后面所有的工作量。

找一份目标语言的常用词表或者词典，把基本颜色词列一遍。

基本颜色词的判断标准不难：单词素、常用、不限定于某类物体。

列完数一下有几个，跟你的色卡格数对一下，词典里基本色词的词条 (https://www.dwds.de/wb/blau)通常比复合色词长得多，用例也密集得多，这个差别可以当粗筛信号。

数量差得多，说明这门语言要认真做。

这一步半天能做完，产出是一个数字加一张十来个词的清单。词典里这类颜色词条 (https://www.dwds.de/wb/hellblau)通常会标注它是不是复合形式，复合形式的往往不是基本色词，这个信息可以直接拿来筛。

数完之后还有一个小检查值得做：看看这些基本色词里有没有哪一个在你的商品品类上根本用不到。有些语言的基本色词里包含了偏农业或者偏自然物的颜色，在消费电子这类品类上一次都不会出现。把用不到的划掉，剩下的才是这门语言实际要处理的规模。

## 第二步：拿实物色值当锚点

第二步是给每一块颜色定编号。

编号绑色值，色值来自实际商品或者设计规范。

不要绑英文词，也不要绑现有的筛选项。

色值可以用任何一种通用表示法，能唯一确定就行。

这一层建好之后，各语言就互相独立了。

网页里那套具名颜色 (https://developer.mozilla.org/en-US/docs/Web/CSS/named-color)是个反面参考：一百多个名字全是英语的，而且有好几对名字指向完全相同的色值。这套东西适合写代码，不适合当业务上的颜色主键。

色值本身也要定一个精度。同一款商品在不同批次、不同屏幕上的色值会有差异，如果精度定得太细，会造出一堆本质上是同一个颜色的编号。实践中按色相分段再人工归并一次就够了，目标是让每个编号对应一块人眼能明确区分的颜色，不是追求精确复现。

还有一个实操建议：编号本身别带任何语义，纯序号就行。一旦编号里塞进了颜色的英文缩写或者色系代码，过一阵子就会有人拿编号当词用，中间层的隔离作用等于白建。让编号难读一点，反而能保证它一直只当锚点使。

## 第三步：每门语言各挂各的词并标首选

第三步交给母语的人来做。

给他们的不是两列表格，是一组色块加编号。

请他们对着色块写词，一个色块可以写多个词。

写完再请他们标出哪个是最常用的说法。

这一步的交付物结构，跟第一节那张错表完全不同。

值得强调的是任务形式的改变：看着色块写词，跟看着英文词写译文，做出来的东西不一样。前一种任务里，母语者是在用自己的语言划分世界；后一种任务里，他是在替英语找替身。任务形式决定了你拿到的是本地范畴还是英语范畴的影子。

交付形式上还有个细节：色块要给足够大，别用小方块。小色块会让人凭印象报词，大色块才会让人真的去分辨色相。另外最好一次给一组相邻的色块而不是单个，因为颜色词的边界只有在相邻对比中才会显现，单看一块颜色，多数人给出的都是最泛的那个词。

## 第四步：用搜索量给首选词排序

最后一步是验证。

把每个色块下的候选词拿去查搜索量。

量最高的那个通常就该是首选。

如果母语者标的首选和数据不一致，值得回头问一句。

多半是书面语和口语的差别，两边都对但用途不同。

小语种查搜索量本来就困难，退而求其次可以用站内搜索日志和客服记录来排序。这两份材料的好处是它们记录的是真实输入，不经过任何编辑加工，在这一层比任何外部工具都可靠。量的时候顺手记一下差异出现在哪几个色相段上，这份记录换一门语言还能接着用。

排序完成之后建议留一份记录，写清楚每个首选词是根据什么定下来的。过一两年有人来问为什么用这个词不用那个，有记录就不用重做一遍。这类小决策最容易在人员更替时丢失，而丢失之后新来的人往往会按自己的语感改一遍，把好不容易对齐的东西又打散。

## 筛选器、结构化数据和正文各要填哪个词？

## 筛选器只放首选词

三个位置的取值规则不一样，得逐个定。

筛选器是选项列表，能放的数量有限。

放多了用户挑不过来，放少了覆盖不够。另外筛选器上的顺序也有讲究，按色相排比按字母排好用，用户是靠眼睛找颜色的。

规则很简单：每个色块只放首选词，一个不多。

非首选词一律不进筛选器，改进搜索的扩展词典。

有一个例外要留意：如果某个色块下的两个词在当地人眼里指的是明显不同的颜色，那它们本来就不该挂在同一个色块上，应该拆成两个编号。筛选器上要不要合并，判据是当地人会不会觉得它们是一回事，不是它们在你的色卡上是不是同一格。如果确实要保留一份英文值，把它放进另一个自定义字段，别占用标准字段那一格。

还有一个展示层的细节：筛选器上的色名旁边最好带一个色块。带了色块之后，即使某个词的选择不完全贴合当地习惯，用户也能靠视觉判断，容错一下子高了很多。这不是替代范畴对齐，而是给对齐留一个兜底，两件事一起做效果最好。

## 结构化数据填首选词加色值

结构化数据这一格要考虑下游怎么消费。例外是那种已经进了当地媒体报道的标志性配色，这类词值得单独查一次再决定。

下游要做的是把你的商品跟别人的商品归到一起。

所以填的词要跟当地同行用的词一致。

顺手把色值也带上，有的规范支持额外属性。

词负责被人搜到，色值负责被机器对齐。另外要留意这类限定说法在不同地区可能不同，同一门语言的两个市场要分别确认。

结构化数据的语言与地区字段那篇 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)里讲过一条：这类字段错了没有人会投诉，因为只有机器读它。颜色字段属于同一类，唯一的差别是它错了之后的表现更隐蔽——你不会看到零结果，只会看到本该出现的地方没有出现。确认环节最好用色块加候选词的形式提问，别让人对着一张纯文字表格做判断。

这一格还有个跟语言无关的老问题：同一款商品在不同语言版本上填的颜色词必须指向同一块颜色。听着像废话，但只要各语言版本是各自维护的，时间一长就会分家。中间层编号在这里的作用就是让各语言版本的取值全部由编号派生，而不是各写各的。

## 正文两个词都写进去

正文那一层反而最宽松。

首选词和非首选词都可以写，营销色名也可以写。

写全了对检索有好处，还能顺手覆盖长尾。

唯一要注意的是别堆砌，一句话里塞三个同义词很难看。

自然的做法是首屏用首选词，详情段落里用另一个。

强调标记跨语言漂移那篇 (https://zhangwenbao.com/minor-language-emphasis-markup-anchor-drift.html)里那条判据在这儿也用得上：这段文字的措辞，是有人在这门语言里重新决定过的，还是从英语继承来的？颜色词如果是继承来的，那它多半只是英语色卡的一次直译。

正文里还有一处特别值得写全：商品的描述段落里提一句这个颜色在实际光线下偏什么调。这类描述天然会带出好几个相关色词，覆盖长尾的效率比硬塞同义词高得多，而且读起来是有信息量的。检索侧的收益是顺带的，内容本身先得站得住。

## 怎么用搜索量数据反推目标语言的颜色分法？

## 先跑品类词加颜色词的组合

如果手上没有母语同事，还有一条数据驱动的路。

把品类词和目标语言里所有可能的颜色词做组合。

颜色词从词典里抄，宁可多列几个。

把这些组合全部拿去查搜索量。

有量的留下，没量的划掉。

这份清单本身就已经能说明问题：如果某个颜色在你的色卡上是一格，但在数据里对应着两个都有可观搜索量的词，那基本可以断定这一格在当地是两格。这个判断不需要懂那门语言。

组合的时候别只用一个品类词。同一个颜色在不同品类上的说法可能不一样，尤其是服饰和家电这类差异大的品类。稳妥的做法是挑三个代表性品类各跑一遍，三组数据都指向同一个结论才算数。只跑一个品类得到的结论，很可能只是那个品类的行话。

还有一个细节：组合里的品类词要用当地人真正在搜的那个词，别用你自己站上的分类名。分类名往往是从英文品类树翻过来的，如果它本身就不地道，跑出来的搜索量会整体偏低，你会误以为这个颜色没人搜，其实是品类词那一半就错了。

## 看两个词的量是不是同一个量级

接下来看量的分布。

两个词的搜索量在同一个量级，说明它们是并列的两个范畴。

一个词的量是另一个的几十倍，说明后者只是一个不常用的说法。

这个比值可以直接拿来定首选。

比值接近的时候，两个词都得进筛选器。

需要提醒的是，跨语言比较搜索量的绝对值没有意义，语言的使用人数差得太远。要比的是同一门语言内部两个词之间的比值，这个数字才是可比的。两件事的归属通常也不在一个团队，先把名字这条线定下来再拉技术，沟通成本更低。

量级判断还有一个补充维度，就是看这两个词的搜索趋势是不是同步。同步波动说明它们大概率是同一个需求的两种说法，走势独立则说明它们背后是两批不同的人。这个信息在决定要不要把它们拆成两个色块时很有用，比单看绝对量更有指向性。

## 拿本地同行的筛选器当对照

第三个办法最省事，也最容易被忽略。

打开三家本地头部同行的商品列表页。

看他们的颜色筛选器里列了哪些选项。

他们已经替你做过这道题了，而且是拿真金白银试出来的。

三家的选项取交集，基本就是当地的通用分法。

这个办法有个前提，同行必须是本地的，不能拿国际品牌的当地站当对照。国际品牌的当地站很可能跟你犯着同一个错误，它们的颜色筛选器多半也是从总部那套色卡直接翻译过来的。

看同行的时候还有一个额外收获：留意他们的筛选器里有没有你的色卡上完全没有的选项。有的话说明当地存在一个你根本没意识到的颜色需求，这类发现的价值往往比修正已有的错误还大。看三家用不了一小时，是这整套流程里性价比最高的一步。

## 这套东西该由谁维护，多久复核一次？

## 归属放在商品数据团队而不是内容团队

先定归属，否则这张表很快就会没人管。

它长得像翻译资产，实际上是商品数据资产。

它的消费方是筛选器、搜索和结构化数据，全是系统。

内容团队没有权限改这些系统，也没有动力维护它。

放在商品数据这条线上，更新才会跟着上新走。

这里有个通用经验：一份资产该归谁，看它的消费方是谁，不看它长得像什么。翻译资产里有相当一部分其实是数据资产，错放归属之后，它们会在两个团队的交界处慢慢烂掉。

归属定下来之后还要配一个明确的接口人。这张表会被内容、翻译、投放三方同时消费，如果没有指定人，改动会从三个方向同时发生。做法是把改动收口到一个人，其余方提需求，这比给三方都开权限稳得多，代价只是慢一点点。

接口人还有一个隐性职责，就是替这张表挡住临时需求。运营经常会为了一次活动想临时加一个色名，加完就忘了删。设一个人守着，这类临时值才不会沉淀成永久脏数据。这张表的价值来自它的干净程度，守住入口比事后清理便宜得多。

## 复核跟着新品走而不是跟着日历走

复核的触发方式也要选对。

颜色范畴本身几十年不变，不需要定期复核。

需要复核的是新增的色块有没有配齐各语言的词。

所以触发点是新品上架，不是每季度一次。

把这一项加进上新的检查清单里就行。

各语言的常用色词和格式约定在通用区域数据仓库 (https://cldr.unicode.org/)这类公共数据集里也能找到一部分参照。唯一需要定期看一眼的是搜索日志里的零结果词，那份清单会自己告诉你哪儿漏了。定期任务只保留这一个，其余全部改成事件触发，维护成本能压到很低。

事件触发还有一类要覆盖：进入新市场。新增一门语言时，这张表要整体走一遍前面那四步，不能只是把已有的映射直译过去。这是最容易偷懒的一处，因为表已经存在了，看起来只要加一列就行，而加一列恰恰就是那张两列表格的错误重演。另外别忘了同一门语言的不同地区可能分法一致但常用词不同，这一层要分开确认。

零结果词那份清单还有个用法：把它按周对比，看有没有新词冒出来。新词成群出现通常意味着市场上出了新的流行色名，或者某个平台改了自己的色词表。这类外部变化你收不到通知，只能靠这份清单自己发现，成本是每周看五分钟。

## 先做哪几门语言

最后是排期。

按前面那条判据，工作量的单位是语言乘以颜色。

先算每门语言有几个颜色跟你的色卡对不齐。

对不齐的数量乘以这门语言的流量占比，排个序。还有一个折中做法是把细分色名做成二级筛选，点开主色之后再出现，不占首屏空间。

从高的开始做，多数站做完前两三门就解决了大半问题。另外要注意各语言版本的这一格必须由同一个编号派生，否则时间一长就会各自漂走。

还有一个更省事的起点：先只看蓝绿这一片。北欧三国内容共用那篇 (https://zhangwenbao.com/nordic-seo-swedish-norwegian-danish-content-sharing-boundary.html)里那个先算可复用面再决定投入的思路在这里也成立，先量一下错位面有多大，再决定要不要为这门语言单独建一套。

还有一个排期上的现实考虑：这件事最好安排在一次商品数据迁移或者平台切换的窗口里做。那种时候本来就要动属性表，顺手把结构改对，边际成本极低。单独立项去改一张运行中的属性表，阻力和风险都要大得多，这也是很多站一直没动它的真实原因。还有一点，营销色名如果进了表，后面每次上新都要维护它，这笔长期成本容易被低估。

还有一种排期选择是按渠道倒推：如果某个市场的主要流量来自比价平台或者聚合站，那这门语言的结构化数据字段就该优先处理，因为那条链路完全依赖精确取值。反过来，主要靠自然搜索和直接访问的市场，筛选器和正文的优先级更高。另外这类语言的商品标题里最好也写完整形式，别让标题和筛选器上的说法对不上。

## 常见问题解答

## 只做欧洲几门大语言，也会碰到颜色范畴问题吗？

会，但没有想象中普遍。西欧几门主要语言的基本颜色划分跟英语相当接近，真正会出问题的主要是俄语这类把蓝色分成两个基本词的语言，以及紫色和棕色一带的一些边界差异。稳妥的做法是不假设、也不全查，先按前面那个数基本色词的办法花半天量一遍，量出来差得少就只处理那几个颜色。这件事的性价比在于诊断很便宜，真正贵的是全量重建，而多数站根本不需要全量重建。还有一条，工具给出的搜索量在小语种上普遍偏保守，量小不等于没人搜，别急着划掉。

## 颜色筛选器上的选项，是不是越多越好？

不是，选项过多会明显降低筛选器的使用率，用户面对二十个色块时通常直接放弃。合理的做法是筛选器只放当地公认的基本色，把细分色名放到商品页和搜索的扩展词典里去。判断一个词该不该进筛选器，看它在当地是不是一个独立的基本颜色范畴，而不是看你的商品有多少种配色。配色多可以靠商品页解决，筛选器解决的是快速缩小范围的问题。如果实在拿不准，看一眼当地头部同行的筛选器里放了几个色块，多数情况下十个上下就够用了。

## 结构化数据里的颜色字段填英文可以吗？

技术上可以，字段本身接受任意文本，但这样填等于放弃了这个字段的价值。下游做归并和比价的系统会按当地语言的词去聚合，填英文的商品会被归到一个几乎没人访问的分类里。正确的做法是跟页面上展示的首选词保持一致，如果规范允许，再额外带一个色值方便机器对齐。这一层的错误反馈极慢，通常只能靠对比同行的曝光情况才发现，所以宁可一开始就填对。还有一点，多语言站上这一格最好由系统按编号自动生成，交给人手工填迟早会出现各写各的。

## 营销色名到底要不要进关键词表？

不要，除非这个色名已经变成了品牌的一个标志性资产，用户会主动拿它来搜。绝大多数营销色名的搜索量是零，把它们放进关键词表只会让表变长而不变强。正确位置是商品页的展示层，跟在基本色名后面当补充。如果确实想验证一下，把营销色名拿去查一次搜索量就有答案，有量的留下，没量的一律不进表，这个判断不需要争论。换个角度说，营销色名解决的是记忆点，基本色名解决的是被找到，两件事不该挤在同一个字段里。

## 越南语这种蓝绿共用一个词的语言该怎么做筛选器？

用带限定成分的完整说法当选项，也就是那个共用词加上表示具体色调的后缀，这在当地是通行写法，用户自己也这么打。筛选器上不要只放那个光秃秃的共用词，否则点进去会同时出现蓝色和绿色两类商品，用户体验很差。同时要在搜索的扩展词典里把光秃秃的共用词也收进去，因为搜索框里输入的往往是短形式。展示用长形式、检索收短形式，这是这类语言的通用处理方式。还有一个办法是在扩展词典里把长短两种形式互相关联，这样两种输入都能落到同一批商品上。

## 没有母语同事，光靠工具能把这件事做对吗？

能做到七八成。数据驱动的路径是可行的：把品类词和候选颜色词做组合去查搜索量，再看本地同行的筛选器取交集，这两步不需要懂那门语言就能完成。剩下那两三成主要是判断两个词到底是并列范畴还是主次关系，以及某些词有没有别的含义或者不合适的联想，这些还是得有人看一眼。可行的折中是把前两步做完，再花很短的时间请一个母语的人只确认最终清单。另外把候选清单交出去之前先自己去掉明显重复的，别让人在三十个词里挑，效率会差很多。

## 这件事跟商品变体的URL和索引策略有关系吗？

有关系但不是同一件事。变体策略解决的是同一款商品的不同颜色要不要各自成页、要不要被索引；范畴对齐解决的是这些颜色叫什么名字。两者的先后顺序很明确，先把名字定对，再决定页面结构，因为页面结构里的URL、标题和面包屑都会用到那个名字。名字定错了再去调页面结构，等于在错误的基础上加固，返工成本会高很多。另外颜色名一旦定下来就不要轻易改，它会同时出现在URL、面包屑和外部渠道里。简单说，名字属于商品数据这条线，页面结构属于技术这条线，先后颠倒会让两边都返工。

## 权威参考资料



## 小语种的竞争强度按内容量算会算反，那批词条历史上只有27个人碰过

- URL：https://zhangwenbao.com/minor-language-content-volume-editor-count.html
- 分类：小语种SEO
- 发布：2021-11-16  |  更新：2022-07-14
- 摘要：把内容量换成写内容的人数来评估小语种竞争强度：23门语言页/人比值完整对照、机器人批量灌注的识别方法、单个词条背后的编辑人数与集中度、十年趋势的两极分化。
- 关键词：关键词研究,多语言SEO,内容运营,小语种SEO

> **TLDR**：摘要：把23门语言的维基百科建站以来的逐月新建页面数和逐月活跃编辑数并排放，宿务语累计新建706万个页面，同期月均只有29个中坚编辑，人均24万页；2013年8月那一个月新建39.7万页，当月中坚编辑18人。同一个月，菲律宾另一门语言瓦瑞语也是39万。而老挝语的这个比值是803，只比英语的539高一半。本文给出23门语言的完整对照表、机器人灌注的三个识别信号、单个词条背后到底站着几个人，以及一个把内容量换成写内容的人数的评估口径。

> 
摘要：把23门语言的维基百科建站以来的逐月新建页面数和逐月活跃编辑数并排放，宿务语累计新建706万个页面，同期月均只有29个中坚编辑，人均24万页；2013年8月那一个月新建39.7万页，当月中坚编辑18人。同一个月，菲律宾另一门语言瓦瑞语也是39万。而老挝语的这个比值是803，只比英语的539高一半。本文给出23门语言的完整对照表、机器人灌注的三个识别信号、单个词条背后到底站着几个人，以及一个把内容量换成写内容的人数的评估口径。

那天下午对着一张竞品调研表发呆。表上第三列写着各语言市场的内容量，一门东南亚语言那格数字是七位数，旁边红色批注写着竞争激烈，建议缓做。

做这张表的同事没做错什么。内容量是最容易拿到的数，也是最容易讲给老板听的数。麻烦在于它回答的问题跟我们想问的那个问题不是同一个。

我们想问的是这门语言里有多少人在跟我抢位置。内容量回答的是这门语言里堆了多少东西。这两件事在英语市场几乎是一回事，在小语种市场经常不是。

那天顺手把那门语言的维基百科拉出来看了一眼编辑名单。七位数的内容量背后，一个月里编辑超过五次的人有三十几个。三十几个人，一间教室坐得下。

## 竞品表上那个内容量，为什么不能直接当竞争强度用？

## 那张表通常是怎么做出来的

做市场评估表的时候，语言这一列的数据来源翻来覆去就那么几个：搜索工具给的结果数、维基百科各语言版本的条目数 (https://meta.wikimedia.org/wiki/List_of_Wikipedias)、抓一批本地站点数页面。三个数都好拿，都能填满格子。

问题是这三个数量的是同一件事——存量。存量告诉你这门语言的互联网上现在堆着多少东西，它不告诉你这些东西是谁堆的、什么时候堆的、还有没有人在往上堆。

维基媒体自己其实早就意识到这个问题，专门做了一个叫条目深度 (https://meta.wikimedia.org/wiki/Wikipedia_article_depth)的口径来跟条目数区分开。存量在英语市场是个不错的代理指标，因为英语的存量和写作人群大致成正比。一门语言里有一千万篇内容，通常意味着有几十万人在写。这个比例关系是我们默认成立的，默认到没人验过。

而它在小语种上不成立。不成立的原因不是数据不准，是这批内容里有相当一部分不是人写的。

## 存量回答的是有没有东西，不是有没有人

这个区分听着像抠字眼，落到排期上是两个完全相反的决定。存量高说明这块地已经被占了，该缓做；写作人群小说明这块地没人守，该抢做。同一个市场，两把尺子给出两个反方向的动作。

更麻烦的是这两把尺子在同一份报告里长得一模一样，都是一个数字加一个单位。看报告的人没有任何线索能分辨出你量的是哪一个。

保哥这几年做小语种评估，最后固定下来的做法是两个数一起给，中间画一道杠。内容量除以写内容的人数，这个比值本身就是一条判据。

本文要讲的就是这个比值怎么算、算出来长什么样，以及为什么它在有些语言上会大到不像话。

## 先说清楚这次量了什么

这次的数据全部来自维基百科的公开接口，一共两套。一套是各语言版本的逐月新建页面数和逐月活跃编辑数，从2005年拉到2021年10月，逐月对齐。

另一套是用修订史接口 (https://www.mediawiki.org/wiki/API:Revisions)拉到的逐条目完整修订历史，包含每一次修改的时间和作者。选了29个跟做生意有关的概念，从咖啡、鞋、洗衣机这类日常物件，到电子商务、二维码、云计算这类近二十年的东西。

语言选了23门，覆盖已经写过的那批小语种，另外加进宿务语和瓦瑞语这两门菲律宾语言做对照，再拿英语和瑞典语当基准。越南泰国印尼这三家 (https://zhangwenbao.com/southeast-asia-seo-vietnam-thailand-indonesia-language-layer.html)是这次的重点观察对象之一。

所有统计都截止到2021年10月31日。之后发生的事不在这次的口径里，因为混进新数据会让逐月曲线的解读出问题。

## 为什么拿维基百科当代理指标

维基百科当然不是商业内容，它的编辑人群跟你在这门语言里的竞争对手不是同一批人。这一点必须先摆在桌面上。

用它有三个理由。第一是它的修订历史全部公开且带时间戳，商业站点没有任何一个能提供这种粒度的数据。第二是它在所有语言上用同一套软件、同一套规则，跨语言比较不需要做口径换算。

第三个理由更实际：维基百科通常是一门语言在互联网上内容质量最好的那一块，拿免费入口给十一门语言排语料量级 (https://zhangwenbao.com/india-multilingual-seo-eleven-languages-nine-scripts-priority.html)那一层用的也是同一个道理。它都薄成这样，商业内容只会更薄。这个指标是个上界，不是平均值。

所以下面所有的数字都请这么读：不是这门语言的商业内容就是这个数，而是这门语言的内容生产能力最多到这个数。

## 本文不谈的两件事

第一件是搜索引擎怎么对待这些内容。引擎的收录逻辑、排名逻辑是另一层的事，跟这门语言里有几个人在写没有直接关系。那半边交给关键词工具在小语种上返回零的那些情况 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)。

第二件是这些内容写得好不好。质量评估要看具体内容，要有懂这门语言的人参与，不是数数能解决的。母语审校那道工序该怎么验收 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)已经单独写过。

本文只回答一个问题：这门语言的内容，是多少个人写出来的。

## 一个月新建39.7万个页面，当月在写的人有几个？

## 2013年8月那个数字

先看一条最极端的记录。宿务语维基百科在2013年8月新建了397097个页面。同一个月，在这门语言上编辑超过五次的人是18个。

把这两个数摆在一起算一下：人均22061页，一个月。一个人一天要建735个页面，不吃不喝不睡，每两分钟一个。

这显然不是人干的。做这件事的是一个叫Lsjbot (https://en.wikipedia.org/wiki/Lsjbot)的机器人程序，它从公开的生物物种数据库和地名数据库里读记录，按模板生成条目，一条一条往上传。

这件事本身完全合规。维基百科对机器人有一份明确的政策 (https://meta.wikimedia.org/wiki/Bot_policy)，事先申请、社群批准、按规矩跑，Lsjbot走完了所有流程。它不是偷偷摸摸干的，它是被允许这么干的。

## 同一个月，另一门语言也是39万

接下来是这次实测里最干净的一条对照。瓦瑞语是菲律宾的另一门地方语言，使用者约三百万。它的维基百科在2013年8月新建了390370个页面。

两门语言，同一个月，一个39.7万，一个39.0万，相差不到2%。这不是巧合，是同一个程序在同一段时间里跑了两遍，换了个语言参数。

这条对照的价值在于它把变量控制住了。两门语言的使用人口、经济水平、上网率都不一样，但它们的内容量在同一个月被同一个原因抬到了同一个位置。

如果你在2014年做一张菲律宾语言市场的评估表，这两门语言在内容量那一列会并列排在前面，前面是英语和他加禄语。这个排名是真的，但它的含义不是你以为的那个。

## 英语的峰值月拿来做对照

英语维基百科在这段时间里的单月新建峰值出现在2015年3月，643082个页面，比宿务语的峰值还高六成。

差别在分母。那个月英语的中坚编辑是69240人。人均9页，一个月。一个人三天写一页，这个数字看着就像人干的。

9和22061，中间差了2451倍。同样是一个月建几十万个页面，一边是几万人各写几页，一边是一个程序批量吐。

这两种生产方式产出的东西，在任何一张只有内容量的表上都长得一模一样。

## 把时间轴拉长，曲线的形状

宿务语的逐年新建量是这样的：2012年1241页，2013年142.6万页，2014年45万页，2015年50万页，2016年196.6万页，2017年191.6万页，2018年掉回723页。

五年时间里堆了六百多万个页面，然后一夜之间回到每年几百页的水平。这条曲线的形状不像内容生产，像一次工程施工。

同期的中坚编辑数几乎是一条直线：2012年34.8人，2013年22.3人，2016年24.2人，2018年36.8人。这条直线跟语料量决定一门语言的能力上限 (https://zhangwenbao.com/multilingual-bert-seventy-languages-minor-language-seo-watershed.html)那条判据说的是一件事。整整六年，这门语言里认真写东西的人一直在二十到四十之间。

灌注结束之后，这六百万个页面留在那儿，没有人维护，也没有人删。它们会一直出现在每一张统计表的分子上。

## 瑞典语是同一件事的温和版本

同一个机器人也在瑞典语上跑过。瑞典语维基2013年新建165.3万页，而它的中坚编辑是1482人。人均1115页，同样不是人干的。

区别在于瑞典语有一千多个真人在写，机器人灌进去的那部分被稀释了。宿务语只有二十几个人，机器人灌进去的部分就是全部。

所以这不是一个非黑即白的分类。同一个动作落在不同规模的社群上，后果差得很远。判断的关键从来不是有没有机器人，是机器人产出占了多大比例。

把这条推广开：一门语言的内容量里有多少是批量生成的，取决于这门语言原本有多少人在写。人少的地方，任何一次批量灌注都会成为主体。

## 机器人灌过的语言，怎么一眼认出来？

## 第一个信号：单月新建量跳变

正常的内容生产是平缓的。人写东西有节奏，一个月比上个月多两成、少一成，都属于正常波动。英语维基十年里的月度新建量一直在16万到20万之间，从来没有翻过倍。

机器人灌注的特征是跳变。宿务语从2012年12月的几百页跳到2013年1月的六万七千页，一个月涨了一百多倍。这种形状在人工生产里不存在。

识别方法很朴素：把逐月序列拉出来，看有没有某一个月比前一个月高一个数量级。有就是有，没有就是没有，不需要统计检验。

顺带说一句，跳变不一定只发生在小语种上。乌兹别克语2013年5月新建37078页，当月中坚编辑35人，人均1059页，同样是一次灌注。这门语言的使用者有三千多万。

## 第二个信号：编辑人数完全没跟着动

这是第一个信号的配套检查，也是更可靠的那个。真实的内容爆发通常伴随人群扩张——某个话题火了，一批新人涌进来写，新建量和编辑数一起涨。

机器人灌注只抬新建量，编辑数纹丝不动。宿务语2013年新建量涨了一千多倍，中坚编辑从34.8人跌到22.3人，方向甚至是反的。

为什么会跌？这个现象在几门被灌过的语言上都出现了，一个说得通的解释是原本的编辑看到内容量突然变成天文数字，参与感被稀释了。这只是解释，不是结论。

无论原因是什么，判据是清楚的：新建量涨而编辑数不涨，产出就不是人做的。这一条比看内容本身快得多。

## 第三个信号：条目内容长得一模一样

前两个信号靠公开的统计接口就能拿到，几分钟能跑完。第三个信号要点开看，但它是最直观的。

机器人从数据库生成的条目有固定句式。物种条目通常是一句拉丁学名加一句分类归属加一句分布地区，换个物种名字其余全一样。地名条目是一句坐标加一句行政归属加一句海拔。

随机点开十个条目，如果七八个的第一句话结构完全相同，只有专有名词在换，那就是模板生成的。这个判断不需要懂这门语言，看句子长度和标点位置就够。

这一步的意义在于确认前两个信号的解释。统计上的跳变有可能来自一次数据迁移或者一次批量导入，点开看能把这些情况排掉。

## 自己查一遍要几分钟

三个信号跑完大概十分钟。第一步打开维基媒体的统计站，选语言，选新建页面，把时间轴拉到建站至今，看曲线有没有立柱。

第二步在同一个站切到编辑数那一栏，选活跃度五次以上，看同一时段的曲线形状。两条曲线叠起来看，跳变而不同步就是信号。

第三步回到该语言维基的首页，用随机条目功能连点十次，看开头那句话。这三步不需要写代码，也不需要账号。

如果你要做的是一份正式评估，把这三步的截图放进附录，比在报告里写一句内容量七位数有用得多。

## 认错了会付出什么代价

把灌注过的语言误判成竞争激烈，代价是把一块没人守的地让出去。这块地通常还很便宜，因为别人也在看同一张表，得出同一个结论。

反过来的错误也存在但少见：把正常发展的语言当成被灌过的，然后低估投入。这种错的成本是内容做出来发现打不过，损失是钱和时间。

两个方向的错误比起来，第一种更值得防。它的损失不出现在报表上——你从来没做过那个市场，就永远不知道错过了什么。

这也是为什么保哥建议把这三步放进评估流程里当固定动作，而不是等到觉得数字奇怪的时候才去查。觉得奇怪的时候，多半已经过了决策那一刻。

## 换成写内容的人数这把尺子，排序会变成什么样？

## 23门语言的完整对照

下面这张表是建站至2021年10月的累计新建页面数，除以同期的月均中坚编辑数。中坚编辑指一个月里编辑五次以上的人，这个门槛能把偶尔改一个错别字的路人排掉。

语言 | 累计新建页面 | 月均中坚编辑 | 页/人 | 

宿务语 | 7069850 | 29.4 | 240546 | 

瓦瑞语 | 2032962 | 26.6 | 76433 | 

乌兹别克语 | 316907 | 34.5 | 9182 | 

缅甸语 | 191744 | 30.6 | 6268 | 

越南语 | 3951017 | 652.8 | 6053 | 

孟加拉语 | 684335 | 175.9 | 3890 | 

印尼语 | 2386827 | 692.4 | 3447 | 

泰米尔语 | 395199 | 125.7 | 3143 | 

斯瓦希里语 | 108762 | 34.9 | 3115 | 

波斯语 | 3151290 | 1103.2 | 2857 | 

瑞典语 | 4019726 | 1480.6 | 2715 | 

蒙古语 | 81484 | 40.2 | 2025 | 

僧伽罗语 | 67169 | 35.3 | 1903 | 

匈牙利语 | 1153072 | 821.5 | 1404 | 

高棉语 | 24427 | 23.4 | 1045 | 

泰语 | 666952 | 647.6 | 1030 | 

尼泊尔语 | 80471 | 80.6 | 998 | 

希腊语 | 466972 | 522.8 | 893 | 

老挝语 | 7850 | 9.8 | 803 | 

英语 | 40772236 | 75588.3 | 539 | 

豪萨语、约鲁巴语、阿姆哈拉语的数在2200到2700之间，为了表格不至于太长没有全列进来。

## 老挝语的位置最出人意料

开工前我给自己写了一份预期，其中一条是老挝语作为内容最薄的语言之一，各项指标应该都在最差那一档。

实测下来老挝语的页/人是803，倒数第二低，只比英语的539高了一半。换句话说，老挝语维基的内容虽然只有七千多页，但这七千多页的人工纯度是全表最高的那一档。

这条把我原来的直觉打翻了。内容少和内容假是两件不同的事，它们甚至可能反向相关——没人来灌的地方，剩下的都是人写的。

落到实操上，这意味着老挝语这样的市场，你的对手虽然只有几个人，但那几个人是真的在写。按人口给小语种排优先级 (https://zhangwenbao.com/minor-language-seo-priority-language-cost-model.html)那一层的账里，这个变量原来是缺的。

## 内容少不等于人少，内容多不等于人多

把表按两列各排一次，前五名没有一个是重合的。按内容量排，前五是英语、瑞典语、越南语、波斯语、印尼语。按中坚编辑数排，前五是英语、瑞典语、波斯语、匈牙利语、印尼语。

看起来还挺接近，是因为大语言两边都强。分歧全部集中在中间那一段：宿务语按内容量排第三，按编辑人数排倒数第五。

这就是这把尺子的全部价值——它在大语言上给不出新信息，在小语种上会把排序整个翻过来，跟品牌名该叫什么由当地输入法决定 (https://zhangwenbao.com/brand-name-transliteration-loanword-minor-language-search.html)是同一类修正。而做小语种决策的时候，你要看的正好就是中间那一段。

这是本站第三次记录内容总量这把尺子在小语种上失效。前两次一次是拿条目数当活跃度，一次是拿条目数排语言优先级，都得到了跟真实情况相反的排序。

## 这几个数从哪儿拿

逐月新建页面和逐月编辑数在维基媒体的统计接口上，一个语言一个请求，返回JSON。不需要密钥，不需要注册。

接口路径里有两个参数要注意。活跃度那个参数决定你数的是哪一档编辑，默认值是全部，会把只改过一次的路人算进来，那一列的数会大三到五倍。

另一个坑是时间戳格式。返回的时间戳带横杠，如果你按位置切前六个字符想拿到年月，切出来的是年加一位月份，所有月份会塌成两组。这个错误我犯过一次，第一版表格里所有的十年趋势都是错的。

整套跑完二十几门语言不到五分钟。数据是每月更新的，任何时候重跑都能拿到最新的一版。

## 比值多大算异常

英语的539可以当基线，因为它的人工比例最高，几乎没有批量灌注的成分。

500到3000这一档属于正常，说明这门语言的内容量和写作人群大致成比例。表里的大多数语言落在这一档。

3000到10000要看一眼，多半有过一次或几次灌注，但社群规模还撑得住。乌兹别克语和缅甸语在这一档，两门语言都能在逐月曲线上找到明显的立柱。

超过10000基本可以断定内容量的主体不是人写的。这一档目前只有宿务语和瓦瑞语，它们的比值是240546和76433，跟第三名差了一个数量级。

## 一个词条背后到底站着几个人？

## 把镜头从语言拉到单个词条

前面那把尺子量的是整门语言。做内容决策的时候真正要问的其实更具体：我要写的这个品类词，这门语言里已经有谁写过。

所以第二组数据换了粒度。29个跟生意有关的概念，逐语言拉出完整修订史，数每条背后有几个不同的人类账号，以及贡献最多的那个人占了多大比例。

机器人账号靠两条规则识别：一是该语言维基授予过机器人权限的账号名单，二是账号名以bot结尾。两条取并集，能覆盖绝大多数。

英语因为修订次数远超采集上限被单独处理，它的数只用最早两千次修订算，所以英语那一行的编辑人数是低估的。这一点在读表的时候要记住。

## 人类编辑数的中位数

结果按人类编辑数从少到多排：宿务语1人，老挝语3人，豪萨语4人，乌兹别克语4人，高棉语5人，斯瓦希里语5人，蒙古语6人，阿姆哈拉语6人，约鲁巴语6人。

然后是缅甸语7人，僧伽罗语7人，尼泊尔语7人，泰米尔语10人，孟加拉语17人，泰语28人，希腊语45人，越南语52人，匈牙利语57人，印尼语59人。

顶上是瑞典语97人、波斯语108人。英语在保守口径下是947人，真实值只会更高。

把两端放一起：英语的咖啡条目背后至少九百多个人，老挝语的对应条目背后三个人。这不是三百倍的差距，这是两种不同性质的东西。

## 头号贡献者占了多少

比人数更能说明问题的是集中度。老挝语的中位数是63%，意思是一半以上的词条里，一个人写掉了六成以上的内容。

老挝语63%，僧伽罗语50%，尼泊尔语50%，豪萨语50%，高棉语49%，缅甸语48%，约鲁巴语45%。这一档全部在四成以上。

另一头，印尼语9%，瑞典语9%，波斯语9%，匈牙利语13%，希腊语15%。英语5%。

还有四条是百分之百：僧伽罗语的云计算、宿务语的TikTok、泰语的通用数据保护条例、乌兹别克语的无人机。这四个词条从建立到2021年10月，人类那一侧只有一个账号动过。

## 四条百分之百意味着什么

先说它不意味着什么。它不意味着这些内容是错的，也不意味着写的人不专业。一个人认真写完一个条目，质量完全可能比十个人吵出来的好。

它意味着的是脆弱。这门语言里关于云计算的公开中文之外的表述，全部来自一个人的理解和一次写作。这个人如果理解偏了，没有第二个人会发现。

对做内容的人来说，这是一个非常具体的机会信号：这个词在这门语言的公共知识里只有一个版本，而那个版本是六年前一个志愿者写的。

顺便说，泰语作为表里的中等资源语言，它的通用数据保护条例条目也是一个人写的六次修订。这说明集中度不是均匀分布在整门语言上的，它按话题分布。

## 这批词一共只有多少人碰过

最后一个数是去重之后的总人数：这29个概念里该语言有的那几条，历史上一共被多少个不同的人类账号编辑过。

约鲁巴语23人，老挝语27人，豪萨语32人，宿务语35人，高棉语40人，阿姆哈拉语60人，斯瓦希里语61人，尼泊尔语81人，缅甸语93人。

乌兹别克语102人，僧伽罗语113人，蒙古语127人，泰米尔语205人，孟加拉语352人，泰语877人，希腊语1107人，匈牙利语1318人，印尼语1535人。

英语21588人，还是保守口径。老挝语的27人和英语的两万多人放一起，这条差距比内容量那一列的差距更能说明市场的真实形状。

## 十年过去，哪些语言的写作人群在长、哪些在缩？

## 我原本以为是普遍萎缩

开工前写下的预期里有一条：各小语种的活跃编辑数十年间在下降，社群在萎缩。这条听起来很顺，网上关于维基百科编辑流失的讨论也支持它。

实测下来这条错得最彻底，而且错得有价值。把2012年全年的月均中坚编辑数跟2021年前十个月的对比，23门语言分成了方向相反的两批。

缩的那批确实存在：阿姆哈拉语跌75%，蒙古语跌61%，约鲁巴语跌58%，高棉语跌53%，老挝语跌53%，瓦瑞语跌45%。

但涨的那批更醒目：孟加拉语涨305%，豪萨语涨254%，越南语涨200%，波斯语涨187%，印尼语涨78%。同期英语跌了10%，瑞典语跌了40%。

## 分界线不是语料量

第一反应是按资源分档，学界给世界语言排资源等级 (https://aclanthology.org/2020.acl-main.560/)那套六档分层就是这么切的：大语言在长，小语种在缩。但数字不支持这个解释。豪萨语的编辑人数是两位数，它涨了254%；瑞典语上千人，它跌了40%。

第二个猜测是按地区：非洲和南亚在长，东南亚在缩。这个稍微贴一点，但也有反例——斯瓦希里语只涨了5%，而它跟豪萨语在同一片大陆。

把这批语言逐个看下去，涨得最快的几门有一个共同点：所在市场的智能手机普及和移动网络铺开发生在这十年之内。孟加拉国、尼日利亚、越南、伊朗、印尼都在这个名单上。

缩的那几门，要么是上网人口在这十年之前就基本饱和，要么是国内环境出现过明显变化。这只是观察，因果关系需要更多证据。

## 趋势方向该怎么用

存量告诉你现在有多少，趋势告诉你三年后会有多少。做内容排期的时候，第二个数往往比第一个数重要，因为你的内容也要三年才能长起来。

具体到动作：编辑人群在涨的语言，竞争会一年比一年重，早进场的红利是真的。编辑人群在缩的语言，你的内容会在更长时间里保持稀缺，但也说明这个市场的整体活跃度在往下走。

后一种情况要多问一句：是内容供给在缩，还是需求也在缩。这两件事分开看，答案完全不同。这个区分在两个市场之间做需求分析 (https://zhangwenbao.com/minor-language-search-intent-divergence-across-markets.html)那一层展开过。

趋势数据跟存量数据来自同一个接口，多要一个时间范围而已。做评估表的时候把这一列加上，成本几乎为零。

## 一条不该忽略的反常

缅甸语的曲线值得单独看。它的中坚编辑数十年间涨了10%，看着平平无奇，但它的单月新建峰值出现在2020年12月，50054页，当月中坚编辑92人。

人均544页，一个月。这个数落在灌注那一档，而且发生的时间比宿务语晚了整整七年。

意思是批量灌注不是2013年前后那一波的专属现象，它随时可能在任何一门语言上再发生一次。你去年做的评估，今年可能就不作数了。

所以这套检查的复用价值高于一次性调研。放进季度例行动作，五分钟跑一遍二十几门语言。

## 人少，对你到底是好消息还是坏消息？

## 好消息那一面

写的人少意味着位置空着。一门语言里某个品类词只有三个人写过，你写第四个版本，它进入这门语言公共知识的概率非常高。

这个概率在英语市场是不可想象的。英语里任何一个商业词后面站着几百个内容团队，你写第四百零一个版本，能不能被看见取决于外链和品牌，不取决于你写得好不好。

小语种的情况反过来。写得好这件事在这里还能直接兑换成可见度，因为分母足够小。这个窗口是真实存在的，而且不需要预算。

这一点在用户真正打出来的那个短词 (https://zhangwenbao.com/minor-language-clipped-short-forms-keyword-coverage.html)上体现得尤其明显。另一个好处是被引用的路径更短。当模型或者答案系统要在这门语言里找一个说法，候选池里就那么几份东西，你的那份进池子的机会按比例算是很高的。这跟本地目录与社群里的外链位置 (https://zhangwenbao.com/minor-language-link-building-local-directories-media-communities.html)那一层的稀缺红利是同一个机制。

## 坏消息那一面

写的人少也意味着读的人可能同样少。内容供给稀薄不总是因为没人愿意写，也可能是因为这件事在这门语言里本来就没人问。

更麻烦的一种情况是这个市场的商业活动整体用另一门语言在办，落地页上 (https://zhangwenbao.com/minor-language-landing-page-trust-signals-payment-address-support.html)那批信任元素会先失效。本地人上网用本地语言，但买东西、比价、看规格的时候切到英语。这时候你在本地语言里做的内容，写得再好也接不到人。

还有一种坏消息是配套缺失。写的人少通常伴随着词典、分词工具、同义词表这些基础设施同样薄，你的内容做出来之后，站内搜索和筛选器接不住它。词干还原把两个相反的词并到一起 (https://zhangwenbao.com/minor-language-negation-affix-exclusion-keyword-trap.html)就是这一层的典型事故。

所以人少这个信号本身不带方向。它只是说明这块地没人占，不说明这块地值不值钱。

## 决定是哪一面的那个变量

把好坏两面分开的那个变量是需求侧有没有人在搜。这个数拿不到精确值，但方向能判断出来。

最省事的做法是拿这门语言的常用品类词逐个查搜索建议，看有没有返回，工具返回零的时候 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)里给过一套补数据的路子。有返回说明这个词在这门语言的查询池里活着，没返回说明这一类查询整个不存在。

把这个结果跟供给侧的编辑人数交叉，会得到四种组合。有人搜有人写是正常市场；有人搜没人写是最好的机会；没人搜有人写说明你看到的内容量是灌出来的；没人搜没人写说明这门语言这个品类还没长出来。

四种组合里，第二种最值得投，第四种最该缓。这两种在只看内容量的表上长得完全一样，都是低数字。

## 三档判读怎么落到排期

把页/人比值和中坚编辑绝对人数两个数一起看，可以粗分成三档。

第一档是比值正常且人数在两百以上，比如泰语 (https://zhangwenbao.com/thai-seo-no-spaces-word-segmentation-keyword.html)、希腊语、匈牙利语。这一档按普通市场做，该有的调研、竞品分析、内容规划一个不省。

第二档是比值正常但人数在几十，比如老挝语、高棉语、僧伽罗语。这一档的策略是少而精：挑最核心的十几个品类词，每个做到能当这门语言里最好的那一份，不铺量。

第三档是比值超过一万，比如宿务语、瓦瑞语。这一档要先把内容量那个数从决策依据里划掉，重新按人数评估，然后多半会发现它其实属于第二档。

## 一个反例：人多也可能是假的

前面一直在说人少的语言要小心，反过来的情况也有。编辑人数多不等于这些人在写你关心的东西。

波斯语的中坚编辑上千人，看起来是个成熟市场。但如果你要做的是某个细分品类，这上千人里可能一个都没碰过那个话题。整门语言的活跃度和某个具体词的活跃度是两个尺度。

所以完整的做法是两层都查：先用语言级的数判断这门语言值不值得进，再用词条级的数判断具体哪些词有位置。前面那组数五分钟能跑完，后面那组要按词查。

只做第一层就下结论，容易在成熟语言上错过细分机会；只做第二层，容易在被灌注过的语言上被内容量骗过去。

## 这套数怎么变成排期上的一格？

## 先算三个数

第一个数是页/人比值，判断这门语言的内容量有多少是真的。超过一万就把内容量这一列作废。

第二个数是中坚编辑的绝对人数，判断这门语言的内容生产能力有多大。几十人和几百人对应完全不同的投入强度。

第三个数是十年趋势的方向，判断三年后会怎样。涨的语言要抢时间，缩的语言可以慢慢做。

三个数都来自同一个接口，一次请求能拿全。做二十几门语言的评估，从写脚本到出表格半天足够。

## 三档对应的动作

做过一遍分档之后，动作是清楚的。正常档按现有流程走，稀薄档收缩品类清单、提高单篇标准，灌注档先重新评估再决定。

这里有个容易做错的地方：稀薄档的收缩指的是收品类，不是收质量。十个词做到最好，比一百个词做成模板，在这类市场里的回报差得很远。

原因还是分母。一百份模板内容在一门只有三十个人在写的语言里，会立刻成为这门语言里最大的一批低质内容，而且很显眼。

灌注档的重新评估要注意别走另一个极端。内容量是假的不等于这个市场是假的，它只说明你手上那个数没用，得换个数来量。

## 报表上加哪一列

最小的改动是在原来的内容量那一列右边加一列写内容的人数，再加一列比值。三列并排，看报表的人自己就能看出问题。

比在报告里写结论有效。数字并排放着，不需要你说服任何人，看的人会自己得出结论，而且他会记得更牢。

如果空间只够加一列，加人数那一列，别加比值。人数是原始数据，比值是加工过的，加工过的数容易被质疑口径。

另外建议在表脚注一句数据截止时间。这类数每月变，半年前的表拿出来讨论会引起不必要的争论。

## 跟母语团队怎么讲这件事

这套数据有个很实际的用途：说服本地团队相信他们的语言值得投入。做小语种的本地同事经常自己也觉得这门语言没什么内容、做了也没用。

把编辑人数那一列给他们看，很多人会意外。他们知道自己的语言内容少，不知道少到只有几十个人在写——也就不知道自己进场之后能占多大比例。

讲的时候别用竞争这个词，用位置。竞争听着像要打仗，位置听着像还有空位，后者更接近事实。

顺带一提，这个数对招人也有用。一门语言里认真写东西的人只有几十个，这几十个人里有一部分是可以找来做兼职审校的，本地作者署名与资历信号 (https://zhangwenbao.com/minor-language-eat-local-author-byline-credential-signals.html)那一层也用得上他们。

## 多久重跑一次

半年一次够了。编辑人数是慢变量，季度级的波动没有意义，看的是年度方向。

触发提前重跑的信号有两个：一是某门语言的内容量在你的定期监测里突然跳了一档，二是要新进一个市场做决策。

第一个信号对应的多半是一次新的灌注，缅甸语2020年那次就是。第二个不解释。

重跑的时候语言清单要保持稳定，别每次换一批。同一批语言连着跑几年，趋势那一列的价值才出得来。

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

## 引擎那半边

这门语言里有多少人在写，跟搜索引擎怎么处理这门语言是两件事。引擎的分词、收录、排名各有各的逻辑，人多人少不直接影响它们。

实际操作里这两层经常被搅在一起：内容做出来没排名，到底是因为竞争激烈还是因为引擎根本没把这门语言处理好。分开查，第一层看本文这套数，第二层看收录和索引。

顺序建议是先查第二层。引擎那一层如果有问题，第一层的所有结论都用不上。

## 内容质量那半边

人数这把尺子完全不看内容好坏。一门语言里三十个人写的东西，可能每一篇都很扎实，也可能全是从英文机翻过来的。

判断质量要另外一套方法，要有懂这门语言的人参与，而且是逐篇看。机器翻译直接发布那条线该划在哪里 (https://zhangwenbao.com/machine-translation-direct-publish-search-risk-quality-line.html)讲的是这一层。

两层的关系是：人数决定你有多大位置，质量决定你能不能占住。位置再大，东西不行也占不住。

## 语言本身的机制那半边

这门语言的词形变化、书写系统、分词难度，比如转小写这一步在土耳其语上会把词改成另一个词 (https://zhangwenbao.com/minor-language-case-folding-lowercase-turkish-dotless-i.html)，全都跟写的人有多少无关。它们决定的是你做这门语言的技术成本，不是竞争强度。

两者容易被合并成一个语言难度分。合并之后会出现很奇怪的结果：一门技术上很难但没人写的语言，跟一门技术上很简单但竞争激烈的语言，得分可能一样。

这两个市场该做的动作完全相反，不该出现在同一个分档里。技术成本进预算表，竞争强度进排期表，两张表分开。

## 商业站的供给跟维基不是一回事

这一条前面说过一次，值得再说一次，因为它是这套方法最大的软肋。维基百科的编辑人群和商业内容的生产者不是同一批人，有些语言里两者的差距可能很大。

能做的补充验证有一个：随机抓这门语言的二三十个商业站点，看它们的正文是不是本地语言、有没有明显的模板痕迹，顺手把结构化数据里的语言字段 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)也查一遍。这个补充要花半天，但能大幅提高结论的可信度。

不做这个补充也不是不能用，只要在报告里把代理指标这四个字写清楚就行。用代理指标不丢人，把代理指标当成真值才丢人。

## 这套指标的边界在哪

它不适用于两种情况。第一是语言级别的内容量本来就很大且人工比例正常，这时候这把尺子给不出新信息，还是得回到常规的竞品分析。

第二是你要做的品类特别小众，整门语言的活跃度跟这个品类的活跃度关系不大。这种情况要直接跳到词条级的数据。

剩下的绝大多数情况它是好用的，尤其是在你手上只有一张内容量表、要在二十门语言里挑三门的时候。它能把明显的陷阱先排掉。

## 八个月后的一次复查

这套数写完之后隔了八个月又跑了一遍，主要想验证一件事：前面说的季度复查到底有没有必要。

宿务语的答案很清楚。2021年10月那个月它还在新建93513个页面，到2022年4月只剩76个，2022年6月153个。灌注在这半年里停掉了，而且是断崖式的停。

同期它的中坚编辑数是40到81人之间波动，跟灌注期完全没有区别。内容量在半年里掉了三个数量级，写内容的人一个没少也一个没多。这条正好把前面那个判据反过来验了一遍。

顺带纠正一个可能的误读。如果只取2021年11月到2022年6月这八个月单独算，宿务语的页/人是2317，不再是那个吓人的24万。累计口径量的是历史遗留，近期口径量的是当下产能，两个数都对，回答的不是同一个问题。

做决策的时候两个都要看：累计口径告诉你搜索结果里现在堆着什么，近期口径告诉你未来一年还会多出什么。前者决定你要绕开哪些位置，后者决定你有多少时间。

那张让保哥发呆的竞品调研表后来改了。第三列还是内容量，右边多了两列，红色批注从建议缓做改成了先抓十个品类词。

## 常见问题解答

## 维基百科的编辑人数，跟我要面对的商业竞争对手真的是同一件事吗？

不是同一批人，但两者高度相关。一门语言里愿意在网上认真写长篇内容的人，是一个整体上的池子，维基编辑和内容团队都从这个池子里出。池子有多大，两边都受它限制。

更稳妥的用法是把它当上界看：维基百科通常是一门语言里内容组织得最好的地方，它的编辑人数如果只有几十，商业内容的生产者不会多到哪儿去。反过来不成立——维基编辑多不代表商业内容一定繁荣，那还要看这个市场的电商成熟度。

如果决策金额比较大，值得花半天做一次商业站点的抽样验证：随机抓这门语言的二三十个电商或者媒体站，看正文语言、看模板痕迹、看更新频率。两组数据方向一致就可以放心用，不一致就以抽样为准。

## 宿务语那六百万个条目，对搜索引擎来说算不算低质内容？

这个问题超出了本文的口径，但可以说几点确定的。那些条目是从结构化数据库生成的，事实层面基本准确，不是编造的内容，所以它跟通常说的垃圾内容不是一回事。

对你的实际影响主要在两个地方。一是它们会占据一部分搜索结果的位置，尤其是长尾的物种名和地名查询。二是它们会抬高各种统计口径里这门语言的内容量，让所有基于内容量的判断失真。

第二点才是本文关心的。第一点对做商业内容的人影响有限，因为你要抢的品类词跟物种名地名基本不重叠——这恰恰是关键：六百万个页面里，跟做生意有关的那29个概念只覆盖了4个。

## 页/人这个比值，能不能直接拿去跟老板汇报？

不建议单独给。这个比值是加工过的数，别人第一反应会问你怎么算的，然后讨论会歪到口径上去。

更有效的做法是把两个原始数并排放：内容量七位数，写内容的人三十几个。这两个数放一起，结论是听的人自己得出来的，不需要你解释比值的定义。

如果一定要给比值，把英语的539一起给出来当参照。有基线的数字才有意义，没基线的比值只是一个陌生的数。

## 编辑人数在涨的语言，是不是就该早点进场？

方向上对，但要看涨的是什么。编辑人数涨可能来自三种原因：这个市场的上网人口在涨、某个话题引起了一波参与、或者有组织的编辑活动。

第一种是真的市场扩张，值得抢时间。第二种是短期波动，看两三年的曲线能分辨出来。第三种通常集中在特定话题上，跟商业内容关系不大。

判断方法是把曲线拉长看形状：持续多年的缓坡是第一种，一两个月的尖峰是第二种，阶梯状的跳变是第三种或者机器人。三种形状用肉眼就能分开。

## 要是这门语言的维基百科条目太少，样本不够怎么办？

本文的29个概念在最薄的几门语言上确实只覆盖到四五条，这时候词条级的结论要谨慎，但语言级的结论仍然成立。

语言级的数据来自逐月统计，跟你选了哪些概念无关，样本量是这门语言的全部页面和全部编辑。这一层不受影响。

词条级的数据可以换一批概念重跑，比如换成你自己要做的那些品类词，逐个查这门语言有没有对应条目。查不到本身就是最强的信号——这个概念在这门语言的公共知识里还是空的。

## 这套方法在中文市场有没有用？

中文不是本文的对象，它的内容量和写作人群都在最高那一档，这把尺子给不出新信息。

但方法本身可以搬。如果你在中文市场里做的是一个很细的垂直领域，同样可以问：这个领域里认真写东西的人有几个。答案往往比想象的少，而这个数比领域内的内容总量更能说明你的机会。

拿到这个数的路径不一样。中文没有一个像维基那样公开修订史的地方，只能靠抽样：找二三十篇这个领域的深度内容，数作者署名，去重。做出来的数粗糙，但方向是对的。

## 这些数据每月都在变，做完的评估表多久就过期了？

存量和人数是慢变量，一年内的变化通常不会改变分档。真正会让评估作废的是灌注事件，那是跳变，一个月就能把内容量抬一个数量级。

所以监测的重点不是重跑全表，是盯跳变。把二十几门语言的月度新建量做成一个简单的对比，每季度扫一眼有没有立柱，五分钟的事。

发现立柱之后再单独重算那一门语言。没有立柱就沿用上一版，一年做一次全表更新足够。

## 权威参考资料



## 落地页上最像装饰的那几个信任元素，在小语种市场是搜索量最高的购买词

- URL：https://zhangwenbao.com/minor-language-landing-page-trust-signals-payment-address-support.html
- 分类：小语种SEO
- 发布：2021-10-21  |  更新：2026-07-27
- 摘要：小语种市场的信任元素分三类：政策文本能翻译，支付方式与地址字段必须整体替换，客服语言承诺写了就得兑现。讲清替换清单怎么列，以及支付方式名为什么同时是一批高意图关键词。
- 关键词：国际化SEO,出海SEO,多语言SEO,小语种SEO

> **TLDR**：摘要：落地页上那几个看着像装饰的信任元素，在小语种市场根本不是装饰。支付方式的名字、地址表单的字段、客服语言的承诺，这三样翻译过去要么无效要么更假：iDEAL翻成网银转账等于没写，英国地址表单翻成德语仍然收不到货，写着支持本地语言客服却回一封英文邮件比不写还伤。更值得注意的是，这批元素的名字本身就是一批搜索词，而且是购买意图最强的那一批。

> 摘要：落地页上那几个看着像装饰的信任元素，在小语种市场根本不是装饰。支付方式的名字、地址表单的字段、客服语言的承诺，这三样翻译过去要么无效要么更假：iDEAL翻成网银转账等于没写，英国地址表单翻成德语仍然收不到货，写着支持本地语言客服却回一封英文邮件比不写还伤。更值得注意的是，这批元素的名字本身就是一批搜索词，而且是购买意图最强的那一批。

## 信任元素在小语种市场为什么是语言层的问题？

## 英文站的做法是加徽章，小语种站要换的是实物

英文市场做信任建设，路径相当成熟。

加评价模块、挂安全认证徽章、把退货政策写清楚、放上真实照片，这套动作有大量现成的清单可抄。

把这套清单原样搬到德语站、日语站、俄语站上，会发现大部分动作确实能做，效果却打了对折。

原因不在于当地用户不吃这一套，而在于清单里有一半的项目在跨语言时换了内容。

徽章还是那个徽章，但当地用户没见过它；政策还是那份政策，但里面写的天数不是当地法律规定的天数。

更彻底的一类是支付方式：它不是翻译问题，是这个市场里根本没有这个东西。

所以小语种站的信任建设有一个英文站不需要处理的前置动作：先判断每一个信任元素在目标市场是不是同一个东西。同一个词底下装的可能是完全不同的实物，配送、付款、退货这三件事在不同市场的具体形态差别之大，远超过多数团队上线前的预估。同一份关键词表在两个市场的意图分叉 (https://zhangwenbao.com/minor-language-search-intent-divergence-across-markets.html)那篇讲的是落地页结构要拆成两种，本文讲的是结构定下来之后，格子里该填什么。

## 三类信任信号：能翻译的、必须替换的、必须兑现的

把落地页上的信任元素倒出来分类，会自然分成三堆。

第一堆是纯文本类：退货政策、配送说明、隐私声明、关于我们。这类翻译就够。

第二堆是实物类：支付方式、地址格式、电话格式、注册号、发票类型。这类翻译无效，必须整个换掉。

第三堆是承诺类：客服语言、响应时间、本地退货地址、本地库存。这类写了就要兑现，写了不兑现的伤害大于不写。

三堆的处理动作完全不同，投入产出也不同，混在一个工单里做是很多团队踩坑的起点。

这个三分法最大的用处是给排期定优先级：第二堆决定用户能不能完成购买，第三堆决定用户会不会回来，第一堆只决定用户读起来舒不舒服。预算有限的时候顺序应该是二、三、一，而绝大多数团队的实际顺序正好倒过来——因为第一堆最容易外包，报价也最便宜。

类别 | 典型元素 | 处理动作 | 做错的后果 | 验收方式 | 

能翻译 | 退货政策、配送说明、隐私声明 | 翻译，但把数字换成当地法定值 | 读着别扭，法务上可能不合规 | 母语审校加法务复核 | 

必须替换 | 支付方式、地址字段、电话格式、注册号 | 整体换成当地实物，不做翻译 | 用户付不了款、收不到货 | 本地测试下单一次 | 

必须兑现 | 客服语言、响应时间、本地退货地址 | 只写做得到的，做不到的删掉 | 信任反噬，评价区被点名 | 拿真实工单抽查 | 

## 翻译得越漂亮反而越可疑的那一类

第三堆里有一个反直觉的现象。

一段翻译质量很高的本地语言客服承诺，会显著提高用户发起咨询的意愿。

然后用户发来一封本地语言的邮件，四十八小时后收到一封英文回复。

这一刻的落差比页面上什么都不写要糟糕得多。

用户的结论不是这家店客服能力有限，而是这家店在页面上撒了谎。

一旦形成这个结论，页面上其余所有信任元素会被一并折价。

保哥给一个做升降桌和人体工学椅的站做过复盘，德语站的咨询转化率一度比英语站高出一截，退款率却也高出一截。查下来原因很简单：页面承诺德语客服，实际团队里只有一个人能读德语，处理不过来时就用翻译工具回英文。用户不是不能接受英文，是不能接受承诺和实际不一致。把那行承诺改成明确写出工单二十四小时内以德语回复之后，咨询量降了两成，退款率降了一半。

## 语言层和架构层的分界线在哪儿

信任元素这件事横跨好几层，容易混。

域名结构、区域跳转、多语言标签，这些属于架构层，跟具体是哪门语言无关。

支付方式叫什么、地址怎么写、客服说哪种语言，这些属于语言与市场层，换一门语言就得重做一遍。

本文只讲后者，前者交给国际化架构那条线。

分清楚的好处是排期不会互相等待：架构那边在改域名的时候，语言这边可以并行地把支付方式清单和地址字段做完。

两件事唯一的耦合点是结构化数据里的地址与语言字段，那一处需要两边对一下口径。

还有一层容易被忽略的耦合：字体。本地字符集缺失会让地址、注册号、支付方式名显示成方框，而这几处恰恰是用户最会盯着看的地方。小语种字体的字形集与首屏成本 (https://zhangwenbao.com/minor-language-web-font-glyph-set-first-screen-cost.html)那篇算过这笔账，信任元素区是全页面上最不能容忍缺字的位置——正文缺一个字读者会自己脑补，注册号缺一个字它就作废了。

## 哪些信任元素翻译一下就够了？

## 政策文本可以翻译，但里面的数字要换

退货政策、配送说明、隐私声明，这三份文本的结构在各国大同小异。

翻译是合理的处理方式，也是成本最低的。

但文本里的数字不能跟着一起翻。

退货期限、冷静期、退款到账时间，这些在各国有各自的法定下限。

照抄源市场的数字，轻则不合规，重则被当地消费者组织盯上。

更常见的情况是数字定得比法定值更严，用户一查就知道你不熟悉本地规则。

这里有个省事的做法：先查清目标市场的法定下限，把页面上的承诺定在下限之上一点点，然后把这个数字单独抽成一个变量，各语言版本引用同一个变量。这样以后法规变了只改一处。政策文本本身反而是最不容易出错的部分，出错的永远是那几个被写死在正文里的数字。

## 退货期限这个数字为什么最容易翻车

欧盟给远程销售定了统一的冷静期下限，各成员国在此基础上可以更宽。

德国市场的实际竞争水平远高于法定下限，头部零售商普遍给得更长。

日本没有统一的法定冷静期，通信销售的退货条件由商家自行标示，但必须标示清楚。

这三种情形对应三种页面写法，照抄任何一种到另一个市场都不合适。

日本这一条尤其反直觉：没有法定期限，不等于可以不写。

恰恰相反，因为法律要求你必须明确标示，不写的后果比写得短更严重。

日本的通信销售还有一批必须表示的事项，退货条件只是其中之一，经营者名称、地址、联系方式、价格之外的费用都在清单里。特定商取引法 (https://www.caa.go.jp/policies/policy/consumer_transaction/specified_commercial_transactions/)对这批事项的要求是具体到条的，而这些内容在页面上正好构成了日本用户最先扫的那一块。合规和信任在这个市场上是同一件事的两面。

## 政策页的语言档位可以跟正文不一样

政策页天然偏正式，这一点各语言都成立。

但正式的程度在不同语言里差别很大。

德语的政策文本可以相当法条化，用户不会觉得冷淡。

日语的政策文本要用敬体，而且客服话术还可以再高一档。

把商品页的语气规范原样套到政策页上，通常会显得轻浮。

所以语气规范要按页面类型分格写，不是全站一条。

这件事在敬语体系明显的语言上更突出。日语敬语档位怎么按页面位置分配 (https://zhangwenbao.com/japanese-seo-keigo-politeness-levels-conversion-ranking.html)那篇里那张位置表，本质上就是把语气规范拆成了格子，政策页和客服邮件在表里各占一格，档位可以高于商品页。信任元素区跟政策页往往挨在一起，两者的档位需要一起定。

政策文本还有一个机器可读的出口。退货政策这个类型 (https://schema.org/MerchantReturnPolicy)可以把退货期限、运费由谁承担、适用范围写成结构化字段，跟页面上的文字一一对应。多语言站尤其该填，因为它是少数几个不受翻译质量影响的信任表达方式。

## 支付方式的名字为什么一个字都不能翻译？

## iDEAL不是网银转账，它就叫iDEAL

荷兰市场的主流线上支付方式叫iDEAL。

它的机制确实接近网银转账，但荷兰用户不会用网银转账这个说法去找它。

结账页上写着银行转账四个字，荷兰用户会以为你不支持iDEAL，然后离开。

这不是翻译得不好，是把一个专有名词降级成了品类词。

专有名词降级成品类词，在别的场景里可能只是不精确，在支付这里是致命的。

因为用户在结账页上找的是一个他认识的图标和一个他认识的名字。

更麻烦的是这类错误往往在测试时发现不了。测试的人知道iDEAL是什么，看到银行转账会自动对应上；本地用户没有这个上下文，他只是没看到自己那一项。各国常用支付方式一览 (https://www.adyen.com/payment-methods)这类清单最好在项目启动时就打印出来贴在墙上，它决定了结账页要留几个位置。

## 先货后款在德国是一个有名字的具体方式

德国市场有一个别处少见的习惯：先收货，再付款。

这个方式在德语里有固定的说法，用户会直接拿它当筛选条件。

它在德国的接受度长期居高不下，尤其是服装和家居这类需要试用的品类。

对卖升降桌和人体工学椅的站来说，这一项几乎是能不能进德国市场的门槛。

而在别的市场，同样的机制要么不存在，要么由第三方以另一个品牌名提供。

所以它不是一个可以从英文站复制过来的选项，它是德国市场的独有配置。

德国还有一条跟结账按钮直接相关的规定：按钮上的文字必须明确表示这一点会产生付款义务。这条要求写在民法典里，业内直接管它叫按钮解决方案。德国民法典关于电子商务合同的条款 (https://www.gesetze-im-internet.de/bgb/__312j.html)规定得非常细，细到按钮上不能写含糊的词。这是一个典型的例子：一个看似属于交互设计的元素，实际由当地法律定义。

## 便利店付款、货到付款、分期，在各国指的不是同一件事

日本的便利店付款是一个成熟的独立通道，用户下单后拿号码去便利店缴费。

俄语市场的货到付款曾长期是主流，背后是对线上付款的普遍谨慎。

巴西的即时支付系统由央行统一推出，几年之内改变了整个市场的付款结构。

这三件事都可以粗略地翻译成一句本地化支付，但落到实现上是三套完全不同的对接。

页面上要写的名字、要放的图标、要解释的流程也各不相同。

把它们统称为本地支付方式，是排期估算失准的常见原因。

巴西那套即时支付是最能说明问题的例子：它由巴西央行的即时支付系统 (https://www.bcb.gov.br/en/financialstability/pix_en)直接运营，上线之后迅速成为主流选项之一。这种由公共机构推动的支付基础设施，在英文市场几乎没有对应物，团队的经验库里也就没有它的位置。遇到这类结构性差异，靠翻译和靠经验都不管用，只能查当地的一手资料。

## 支付图标的排列顺序本身也是信号

结账页上那一排支付图标，顺序不是随便排的。

把本地主流方式排在第一位，是一个很轻但很有效的信号。

反过来，把国际信用卡排在最前面、本地方式塞在最后，用户会读出这家店主要不是做本地生意的。

这个判断只需要一秒钟，而且相当准确。

顺序调整不需要开发资源，通常改个配置就行。

它属于那种成本接近零、但很少有人专门去做的事。

顺带说一句，图标的顺序还影响用户的心理预期：排第一的那个方式会被默认成这家店最推荐的方式。如果你的本地支付通道手续费更低，把它排前面还能顺便省一笔。信任和成本在这个位置上罕见地站在了同一边，这种机会不多，遇到就用上。

图标本身也有正规来源。支付服务商通常提供官方图标资源和使用规则，各支付方式的接入文档 (https://stripe.com/docs/payments/payment-methods/overview)里会写明哪些方式在哪些国家可用、图标该怎么显示。用官方素材比自己截图强，后者经常因为版本过旧被本地用户一眼认出来。

## 支付方式的名字为什么同时是一批关键词？

## 用户真的会拿支付方式当搜索词

这是本文最想让人记住的一条。

荷兰用户会搜某个品类加上iDEAL，德国用户会搜某个品类加上先货后款的说法。

这类查询的结构是品类词加支付方式名，它是一个完整的、有明确购买意图的长尾。

搜这种词的人已经决定要买了，他在筛的是谁支持他习惯的付款方式。

页面上如果没有出现那个支付方式的名字，你根本不在候选池里。

而多数出海站的结账页支持这个方式，商品页上却一个字都没提。

支持和写出来是两件事。支付方式配置在结账系统里，商品页和品类页上却看不到任何痕迹，用户要点进结账才知道——可他不会走到那一步。把支持的本地支付方式在商品页上明写一行，是那种改动量极小、命中却极准的动作，它同时解决了信任和覆盖两件事。

这类查询还有一个特征：它们经常带着地域词一起出现。用户会把品类、支付方式和城市或国家名拼在一起，因为他同时要确认这家店是不是在本地做生意。三个成分凑到一起，竞争度更低，转化也更集中。

## 这批词在英文关键词工具里基本看不见

拿英文思路去挖词，挖不到这一批。

原因有两层。

第一层是这些词是本地专有名词，英文工具的词库里未必有；第二层更关键，做词的人根本想不到要去查它。

关键词研究的常规流程是从品类词、属性词、场景词展开，没有人会把付款方式当成一个展开维度。

结果是这批词在词表里系统性缺席，不是量少，是压根没被找过。

补的办法很直接：把目标市场的支付方式清单列出来，逐个跟品类词做交叉，然后去查量。

这套办法在数据稀薄的语种上要换个查法。关键词工具没数据时的替代办法 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)那篇里的几个免费入口都能用来验证这批词是否真有人搜，其中搜索建议的下拉词是最快的——打进品类词，看后面会不会跟出支付方式名，跟得出来就说明这个组合确实有量。

还有个更省事的挖词入口：本地竞品的帮助中心目录。那些问答标题往往就是用户的原话，其中一批必然是关于付款和配送的。把二三十条标题抄下来，跟自己的词表比一比，缺的那几行通常就是被整体忽略掉的那个维度。

## 为什么说这是购买意图最强的一批长尾

按购买阶段给查询排序，支付方式类查询排得非常靠后，也就是非常接近成交。

比它更靠后的只有品牌加官网、品牌加优惠码这类。

更重要的是这批词的竞争度普遍很低。

本地的大零售商不需要专门做，因为用户默认他们支持；国际站又想不到要做。

于是它成了少数还留着的低竞争高意图区间。

做法上也很轻，一个帮助中心页面加几处商品页的行内提示就能覆盖。

把这条思路推广一层：任何一个用户拿来筛选商家的本地条件，都可能是一批被忽略的关键词。付款方式、配送方式、能不能开当地格式的发票、支不支持本地退货点，这四类在各个市场都存在，而且都很少被当成词来做。意图在不同市场的分叉 (https://zhangwenbao.com/minor-language-search-intent-divergence-across-markets.html)那篇讲的差异，在这四类词上表现得最极端。

## 地址表单为什么不能照抄英文版？

## 差的不只是顺序，是字段本身就不一样

把英文地址表单翻译成目标语言，是最常见的做法，也是最容易出错的。

因为不同国家的地址结构差的不是字段顺序，是字段集合。

日本的地址从大到小写，都道府县、市区町村、丁目番地，邮编写在最前面并且带一个专用符号。

俄语地址里街道、楼、单元、公寓是四个独立层级，缺一个就送不到。

荷兰的邮编自带一段字母，配合门牌号就能唯一定位，反而不太需要街道名。

硬套一套字段结构，结果是有的国家填不完整，有的国家被迫把信息挤进备注栏。

万国邮联对各国地址结构有整理过的规范，做多国站的时候这是最省事的一手参考。万国邮联的地址规范工作 (https://www.upu.int/en/Postal-Solutions/Programmes-Services/Addressing-Solutions)覆盖了成员国的地址组成方式，比一个个国家去猜快得多。地址这件事跟语言的关系是间接的——同一个语言在不同国家可能用不同的地址结构，所以真正的划分单位是国家而不是语种。

## 邮编的位置、格式和校验规则各不相同

邮编是地址里最容易做自动校验的字段，也是最容易做错的。

格式上，荷兰是四位数字加两位字母，日本是三位加四位并带一个专用符号，巴西是五位加三位。

位置上，日本写在最前面，德国写在城市前面，英国写在最后。

校验上，硬套一个只认数字的正则，会把荷兰和英国的用户全部挡在门外。

这类错误的隐蔽之处在于它只影响一部分市场，报表上看是那个市场转化偏低，看不出是表单挡的。

排查方法是看表单的字段级放弃率，哪个字段填了又清空，问题就在那里。

邮编还有个跟检索有关的副作用：不少市场的用户会拿邮编搜配送范围。能不能配送到某个邮编，是一类真实存在的查询，尤其在配送费按区域分档的市场。这类页面在服务型行业里很常见，实物电商很少做，但对配送政策复杂的品类是有价值的。

校验规则最好走配置而不是写死在前端。国家一多，正则会堆成一坨没人敢动的代码。把每个国家的邮编格式做成一张配置表，新增市场时加一行，这件事在第三个市场上线时做，比在第八个市场上线时做便宜得多。

## 地址第二行这个字段的坑

地址第二行是英文表单的传统配置，用来放公寓号、楼层、公司名。

它的问题是含义模糊，用户不知道该往里填什么。

移植到别的语言市场之后，模糊程度会加倍，因为翻译过去的标签更不知所云。

结果是有人把整段地址填进去，有人把它当备注栏用。

正确做法是按国家拆成具体字段，比如公寓号、楼层各占一格，标签写得具体。

字段多一个不可怕，可怕的是一个字段承担四种含义。

这个具体的坑有过专门的研究。地址第二行的表单可用性研究 (https://baymard.com/blog/address-line-2)给出的结论是这个字段的实际填写行为极其混乱，而它带来的收益远小于它造成的困惑。多语言站的处理更简单粗暴：按市场决定要不要这一格，不要的市场直接不显示，别翻译一个更含糊的标签放上去。

## 收不到货的代价远大于少一个转化

地址字段做错的后果，通常不是当场少一单。

而是订单成立了、钱付了、货发出去了，然后退回来。

这条链路上的成本包括双向运费、客服时间、退款手续费，以及一个几乎必然发生的差评。

在小语种市场，一个差评的杀伤力被放大，因为你的评价基数本来就小。

所以地址表单是整个信任元素清单里最应该优先投入的一项。

它既不性感也不出现在任何营销汇报里，但它决定了后面所有努力有没有意义。

下面这张表是保哥常用的六市场对照，做多市场排期时先把这张表填满，再决定哪个市场先上。表里每一列的信息都能在半天内查到，但很少有团队在上线前认真填过——多数是上线三个月后被客服工单逼着一格一格补出来的。

市场 | 本地主流支付 | 地址关键字段 | 页面必标信息 | 本地信任标章 | 

德国 | 先货后款、银行转账 | 街道加门牌、五位邮编 | 经营者信息、按钮付款义务 | 本地商城认证 | 

荷兰 | iDEAL | 邮编加门牌可定位 | 经营者信息、退货期限 | 本地网店标章 | 

日本 | 便利店付款、货到付款、信用卡 | 邮编前置、都道府县到番地 | 特商法必标事项 | 隐私保护标识 | 

巴西 | 央行即时支付、分期 | 八位邮编、门牌与补充说明 | 纳税人识别号 | 消费者投诉平台评分 | 

俄语市场 | 银行卡、货到付款、本地钱包 | 街道、楼、单元、公寓四级 | 法人识别号、实体地址 | 本地聚合平台评价 | 

波兰 | 本地转账网关、自提柜 | 邮编带连字符、自提点编号 | 经营者信息、退货期限 | 本地比价平台评分 | 

这笔账还可以再算细一点。一单退回来的直接成本是双向运费加人工，间接成本是那个用户几乎不会再来。在订单基数小的市场，损失一个已经完成过付款的用户，比损失十个还在犹豫的访客更贵，而地址表单挡掉的正好是前一种。

## 页面上的地址和注册号该怎么摆？

## 法定标示义务不是可选项

很多市场要求线上经营者在网站上公开一组固定信息。

德国有专门的经营者信息页要求，内容包括名称、地址、联系方式、注册号、负责人。

日本的通信销售有必须表示的事项清单。

这些不是加分项，是门槛，缺了会被投诉甚至被处罚。

而对用户来说，这一页恰恰是判断你是不是一家真实存在的公司的主要依据。

所以它同时是合规文件和信任文件，两个身份对应的写法却不一样。

合规身份要求的是完整，信任身份要求的是可读。折中做法是这一页写完整版，另外在页脚放一段三行的精简版，包含公司全名、注册号和实体地址。页脚那三行是被扫得最多的信任元素，多数用户不会点进经营者信息页，但会瞟一眼页脚。

这一页还有个常被忽略的细节：它必须能从任何页面一跳到达。有些站把它藏在关于我们的三级子页里，合规上或许勉强过关，信任上等于没做。页脚固定位置放一个链接，是各国通行的做法，也是用户会去找的第一个地方。

## 注册号是本地用户唯一能自己核的东西

评价可以刷，徽章可以贴图，照片可以买。

注册号不行，因为它对着公开的登记库能查。

德国的商事登记号、荷兰的商会号、法国的企业识别号、印度的商品服务税号、俄语市场的纳税人识别号，都有对外的查询入口。

写上去的成本是零，效果却是所有信任元素里最硬的。

而绝大多数出海站的本地语言页面上不写这个，因为源市场的模板里没有这一格。

模板里没有的东西，本地化流程就不会去补，这是本地化最典型的盲区。

这条跟作者署名那件事是同一个逻辑：可查性比说辞更值钱。小语种站的作者署名与资质信号 (https://zhangwenbao.com/minor-language-eat-local-author-byline-credential-signals.html)那篇讲的是把资质换成能查的号码，公司这一侧的对应物就是注册号。用户不会真的去查，但他知道这个号码能查，这就够了——可核性起作用的方式是让造假变得不划算，不是让每个用户都去核一遍。

## 结构化数据里的地址和页面上的要一致

页面上写了地址，标记里也该有。

这里最常见的问题是两处对不上：页面上是本地语言的地址，标记里是英文翻译版。

更糟的是有些站在多个语言版本里复制粘贴同一段标记，地址永远是总部那个。

标记里的地址字段有专门的结构，国家、城市、街道、邮编各占一格，不该塞成一整个字符串。

客服的联系方式也有对应的结构，而且可以标出这个联系点支持哪几种语言。

支持语言这一格几乎没人填，它却正好对应本文讲的第三类信任元素。

把联系点这个类型 (https://schema.org/ContactPoint)和它的可用语言属性填对，等于把页面上的客服语言承诺同步给了机器。小语种站的结构化数据与语言字段 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)那篇讲过一条原则：页面上本地化、标记里国际化。地址字段是这条原则的典型应用——显示给用户的是本地写法，标记里的国家代码用标准的两位字母。

## 客服语言的承诺该写到什么程度？

## 三档承诺模型，先选一档再写文案

客服语言承诺可以分成三档。

最高一档是本地语言实时响应，有在线客服，有本地工作时间。

中间一档是本地语言工单，明确写出响应时限。

最低一档是英语兜底，但把这件事明说出来。

三档都可以接受，用户能接受的是明确，不能接受的是含糊。

最差的写法是写一句我们提供多语言支持，什么都没承诺，也什么都没否认。

选档的判据只有一条：你的团队实际能稳定做到哪一档。不要按竞品写，也不要按理想写，按上个月的真实工单数据写。下面这张表把三档的适用条件、页面写法和最容易翻车的地方并排列出来，选完档照着写就行。

档位 | 适用条件 | 页面上怎么写 | 翻车点 | 

本地语言实时 | 有本地时区的母语客服 | 写明语言、时段与渠道 | 时段写成全天候，实际按国内班次 | 

本地语言工单 | 有母语者但非全时 | 写明语言与响应时限 | 时限写二十四小时，实际两三天 | 

英语兜底并明示 | 暂无母语客服 | 明说以英语回复，并给出时限 | 不写，让用户以为有本地客服 | 

选档还有个隐含前提：三档之间可以随时间往上走，但不能往下走。用户会记得你上个季度承诺过什么。所以第一次定档宁可保守，等团队真的补齐了母语客服再升档。升档是好消息，降档在用户眼里是事故。

## 兑现不了的那一档必须从页面上删掉

这条听起来像废话，实际执行起来阻力很大。

因为删掉承诺意味着页面上少一个卖点，而这一改动的收益要过几个月才看得出来。

阻力通常来自一个误解：认为用户是被承诺吸引来的。

实际情况是用户被商品和价格吸引来，被承诺留下，再被落空的承诺赶走。

赶走的那一批人不只是不再买，还会在评价里写下这件事。

而小语种市场的评价传播范围往往比想象中小而密，一条负评的可见度高得多。

还有一个折中办法：把承诺从页面上收窄而不是删掉。比如从支持德语客服改成德语工单四十八小时内回复，档位降了，可信度反而升了。降档带来的转化损失通常是个位数，而承诺落空带来的退款和差评是两位数，这笔账在多数市场都算得过来。

删承诺这件事在内部最好有个明确的责任人。销售和市场倾向多写一点，客服和运营承受后果，两边的激励方向是反的。把承诺的最终审定权放在承受后果的那一侧，页面上的话会自动变得诚实，不需要谁去做思想工作。

## 响应时间和语言必须写在一起

只写语言不写时限，用户会自动脑补一个很快的时限。

只写时限不写语言，用户会假设是本地语言。

两个信息缺一个，误解就自动生成了。

所以这两项必须同句出现，而且要具体到小时或工作日。

写清楚之后还有个额外好处：客服团队自己有了明确的服务标准。

页面上的承诺变成内部的考核指标，这条链路一通，两边的动作就对齐了。

顺带提一句退货地址。写着本地退货，实际却要寄回源市场，这类落差跟客服语言是同一性质的问题，而且代价更高——用户已经付过一次运费了。这一项在页面上必须写实：有本地退货点就写清楚地址，没有就明说需要跨境寄回，并且把运费责任写明白。

还有个细节：时限要写成用户能自己核对的形式。写两个工作日内比写尽快好，写工作日又比写自然日诚实——周五下午发来的工单，用户要是按自然日算，周日就开始不耐烦了。含糊的时限省不下事，只是把矛盾往后推。

## 本地信任标章能不能自己做一个？

## 标章的价值在于可核，不在于那个图形

常有团队问，能不能自己设计一个看起来很正规的安全徽章放上去。

技术上当然可以，效果接近于零，风险却不低。

因为本地用户认的不是图形，是这个图形背后能不能点进去查到你的编号。

正规标章都有验证页，点一下就能看到发证机构、有效期、被认证的域名。

自制徽章点不进去，或者点进去是自己站内的一个介绍页。

这一点用户是会试的，尤其是首次购买的用户。

更实际的顾虑是：本地消费者社区对假标章相当敏感，被发现之后传播速度很快。网页设计中可信度的四个要素 (https://www.nngroup.com/articles/trustworthy-design/)里把可验证性列为核心要素之一，它的作用机制正是给用户一条自己去确认的路径。给不出这条路径的徽章，摆多少个都是装饰。

判断一个标章值不值得申请，有个快速办法：先看它的验证页长什么样。验证页能查到发证机构、有效期和被认证的域名，说明这套体系真的在运作；验证页只是一个介绍性页面，那它的可核性就存疑，摆上去的价值也有限。

## 各国用户认的标章不是同一批

德国用户认本地的商城认证，日本用户认隐私保护标识，巴西用户看的是消费者投诉平台上的评分。

这几样彼此不能替代，也不能靠一个国际通用标章覆盖。

国际通用的那类安全标识当然也有价值，但它解决的是技术安全，不是商家可信。

两类信号都要有，位置和权重不同。

本地标章放结账区，国际安全标识放页脚，是比较常见的分配。

决定放哪几个之前，先做一件很轻的事：翻十家当地同品类的站，看它们页脚都放了什么。

这个方法比查资料快，也更准确，因为它反映的是当前实际在用的那一批。本地竞品的页脚是一个信息密度极高的地方——它把这个市场所有约定俗成的信任元素都摆在了一起，包括你从没听说过的那几个。本地名录与社区里的外链机会 (https://zhangwenbao.com/minor-language-link-building-local-directories-media-communities.html)那篇讲的名录调研方法，在这里可以直接复用一遍，很多本地标章的发证方本身就是行业名录。

## 假标章的代价不是罚款，是被本地社区点名

监管处罚需要有人投诉、有人立案，周期长。

本地论坛和消费者社区的反应要快得多。

一旦被点名，这条内容往往会在品牌名的搜索结果里长期占位。

而品牌词的搜索结果页是新用户在决定下单前最后会看的地方。

这个损失没法用广告预算补，只能靠时间和后续的正面内容慢慢压。

相比之下，老老实实去申请一个真的认证，成本是可以预算的。

做个粗略的对比：正规认证的年费在多数市场是四位数级别，而品牌词结果页上出现一条负面内容，清理周期通常按年计算。这笔账不难算，难的是有人在赶上线的时候提出用一张图先顶着，而那张图往往就再也没人换过。

还有个更隐蔽的代价：假标章会污染你自己的判断。页面上摆着一排徽章，团队会默认信任这件事已经做过了，真正该做的注册号、退货地址、客服承诺反而一直空着。装饰性元素最大的害处不是骗到用户，是骗到自己。

## 上线顺序：先解开硬阻塞，再谈看起来专不专业

## 六步排期，每一步都有明确的判据

第一步是支付方式：查清目标市场的主流方式，配置通道，然后在商品页上把名字写出来。

第二步是地址表单：按国家拆字段，改校验规则，用当地真实地址测试下单一次。

第三步是法定标示：经营者信息、注册号、必标事项，一次做全。

第四步是客服承诺：按三档模型选一档，把语言和时限写进同一句话。

第五步是政策文本：翻译，并把数字换成当地法定值。

第六步才是标章与评价：申请本地认证，接入本地评价来源。

这个顺序的依据是从能不能完成交易，到会不会再来，最后才到看起来专不专业。前两步没做完就去做第六步，等于给一间还没装门的店挂招牌。判断当前该做哪一步，只要问一句：本地用户现在能不能顺利付款并收到货。

六步里最容易被跳过的是第二步。地址表单要动开发排期，而它的收益体现在退货率这种没人天天看的指标上。跳过它的团队通常会在半年后遇到一批集中退回的包裹，那时再回头改，成本里还要加上已经流失的那批用户。

## 按市场成熟度分档投入，别所有市场一视同仁

六步不必在每个市场都做全。

试水阶段的市场做前三步就够，投入可控。

已经有稳定订单的市场做到第五步。

准备重点投入的市场才值得做第六步，因为认证和评价接入是有年费和维护成本的。

这个分档还有一个作用：它给了团队一个停手的理由。

否则本地化很容易变成一件没有终点的事，每个市场都想做到满分。

分档的判据用订单量或者询盘量都行，关键是事先写下来。小语种的优先级与成本模型 (https://zhangwenbao.com/minor-language-seo-priority-language-cost-model.html)那篇里的分档思路可以直接套过来，把信任元素当成语言投入里的一个子项来排。没有停手线的本地化，最后总是在最不重要的市场上花掉最多的时间。

分档表还要写上退出条件。某个市场做到第三步之后订单一直没起来，就该停在那里，而不是继续往下投。本地化的投入是可以有止损线的，很多团队缺的不是判断力，是事先把这条线写下来的习惯。

## 上线之后怎么验收才不流于形式

验收不能靠看页面，要靠走一遍流程。

用当地真实地址、当地支付方式，完整下一单，再退一单。

这一步能同时验出支付通道、地址校验、退货流程、客服语言四件事。

成本是一件商品的往返运费，通常不到一千块。

对照之下，靠猜和靠看页面做出来的验收，几乎必然漏掉退货那一半。

退货流程是整条链路里最少被测试、却最影响复购的一段。

还有一个便宜的验收动作：把结账页的弃购原因做成一个可对照的清单，跟公开的行业统计比一比。弃购率的统计汇总 (https://baymard.com/lists/cart-abandonment-rate)里列出的原因排序在各市场大同小异，如果你某个市场的弃购结构明显偏离，偏离的那一项通常就是本地化没做到位的那一项。

验收还可以顺手把配送信息同步到标记里。配送细节这个类型 (https://schema.org/OfferShippingDetails)能表达配送区域、时效和费用，填对之后这些信息有机会出现在结果页上。它的取值必须跟页面上写的一致，正好并进这一轮验收清单一起核。

## 这套三分法能复用到别的元素上吗？

## 判据是一句话：这个元素的可信度来自谁

可信度来自文字本身的，属于能翻译那一类。

可信度来自本地实物或本地机构的，属于必须替换那一类。

可信度来自你后续行为的，属于必须兑现那一类。

三问一过，任何一个新元素都能归位。

比如免费退货这个承诺，可信度来自后续行为，归第三类。

比如本地仓发货，可信度来自实物，归第二类。

这个判据的价值在于它能处理没见过的元素。市场上不断出现新的信任形式，社交平台的官方认证、本地即时配送的时效承诺、分期付款的免息标示，每一个都可以用这一问归类，然后套用对应的处理动作。清单会过时，判据不会。

三问里最容易判错的是第二类和第三类的边界。一个简单的分辨法：如果这个元素的可信度取决于你未来会不会做某件事，就是第三类；如果它取决于此刻页面上写的东西对不对，就是第二类。承诺看未来，实物看当下。

## 评价、配送时效、退换货流程各归哪一类

评价属于第二类，因为本地用户信的是本地评价来源，不是你站内的评分数字。

配送时效属于第三类，写了就要做到，而且它是最容易被系统性高估的一项。

退换货流程横跨二三类：退货地址属于实物，退款时效属于承诺。

这种横跨的元素要拆开处理，不能整块归类。

拆开之后会发现，多数出错的地方都在被合并处理的那一半。

合并处理的原因通常是它们在页面上写在同一段里。

页面上的排版方式不该决定后台的处理方式，这是一条很容易违反的原则。政策页上退货地址和退款时效写在同一段，负责的却应该是两个团队——一个是物流，一个是财务。流量到转化之间的边界与交接 (https://zhangwenbao.com/seo-cro-boundary-handoff-collaboration.html)那篇讲的职责划分问题，在信任元素这块表现得特别明显。

再补一个横跨的例子：本地仓。仓在本地属于实物，配送时效属于承诺，而这两件事在页面上通常写在同一句里。仓的位置一旦调整，时效那半句要跟着改，这种联动最好一开始就用两个独立字段承载，别写成一句话。

## 跟转化优化那条线怎么分工

转化优化关心的是同一个元素放在哪儿、用什么颜色、要不要做成弹窗。

本文关心的是这个元素在这个市场里是不是同一个东西。

两条线的顺序是先确定是什么，再优化怎么摆。

顺序反过来，会出现一种很浪费的情况：花几周时间测试一个本地用户根本不认识的徽章该放在哪个位置。

测试本身没有错，错在被测对象一开始就选错了。

所以多语言站的转化优化清单里，应该有一道前置检查：这个元素在本市场存在吗。

把这道检查加进去，通常会砍掉候选测试项的三分之一，同时冒出一批新的候选——那些本地竞品都有、而你从来没做过的元素。本地化不是把已有的东西翻译过去，是先搞清楚这个市场的清单跟你手上的清单差在哪几行。

分工还有个实际好处：出问题时能快速定位是哪一层的事。转化掉了，先问是不是元素选错了，再问是不是位置摆错了。顺序反过来，会在一个错误的对象上做完整整一轮测试，而测试结论看起来还挺可信，这是最难被发现的一类浪费。

## 常见问题解答

## 预算有限，信任元素里先做哪一个？

先做支付方式和地址表单，这两项决定用户能不能完成交易并收到货，别的都排在后面。判断标准很直接：用当地真实地址和当地主流支付方式走一遍下单流程，卡在哪一步就先修哪一步。徽章、评价模块、精美的关于我们页面都属于第二梯队，它们提升的是意愿，而前两项决定的是可能性。意愿再高，付不了款也没用。

## 支付方式的名字真的会被当成关键词搜吗？

会，而且这批词的购买意图排在所有查询类型的前列。用户已经决定买了，他在筛的是谁支持自己习惯的付款方式。验证方法很轻：在目标市场的搜索框里打进品类词，看下拉建议里会不会跟出本地支付方式的名字，跟得出来就说明有量。这批词竞争度普遍很低，因为本地大商家不需要做，国际站又想不到要做。

## 客服只有英语，页面上要不要写出来？

要写，而且要明说。用户能接受英语客服，不能接受以为有本地客服结果收到英文回复。明说的写法是把语言和响应时限写在同一句话里，比如以英语回复、两个工作日内。这样做通常会让咨询量下降一些，但退款率和差评会明显下降，算总账是划算的。含糊的多语言支持是最差的写法，它既没承诺也没否认。

## 本地信任标章值不值得花钱申请？

看市场阶段。试水阶段不值得，那笔年费应该先花在支付通道和地址表单上。已经有稳定订单、准备重点投入的市场值得，因为标章的价值随流量规模线性放大。绝对不要做的是自制一个看起来正规的徽章，本地用户会点进去验证，验证不了的后果比没有徽章严重得多，而且被本地社区点名之后会长期占据品牌词的搜索结果。

## 地址表单要不要按国家做不同版本？

要，而且这是投入产出比最高的一项技术改动。不同国家的地址差的不是字段顺序而是字段集合，日本邮编前置并且有专用符号，俄语地址有四个层级，荷兰靠邮编加门牌就能定位。硬套一套字段会导致有的市场填不完整、有的市场把信息挤进备注栏，最终结果是货发出去又退回来。按国家切换字段集合的开发量不大，收益却是直接的。

## 页脚要放哪些信息才算够？

三行就够：公司全名、本地可查的注册号、实体地址。这三样是本地用户判断你是不是真实存在的公司的最快依据，也是唯一没法伪造的那一批。评价分数、社交链接、支付图标可以放，但它们的说服力都弱于这三行。多数用户不会点进经营者信息页，却会瞟一眼页脚，所以精简版比完整版更重要。

## 这些元素做完了，多久能看到效果？

支付方式和地址表单的效果几乎是立刻的，因为它们解除的是硬阻塞，改完当周的完单率就会动。客服承诺和政策文本的效果要一到两个月，它们影响的是复购和差评率。标章与评价接入最慢，通常按季度看。所以排期时不要把这三类的效果指标混在同一张报表里考核，节奏对不上的指标放在一起看，只会得出错误的归因。

## 权威参考资料



## 日语页面上那行小字是给孩子读的，抽答案的程序把它当成了正文

- URL：https://zhangwenbao.com/minor-language-ruby-annotation-phonetic-layer.html
- 分类：小语种SEO
- 发布：2021-08-24  |  更新：2026-07-29
- 摘要：页面上绝大多数文本一个位置只有一串字符，注音是唯一一处摞了两串，而两串都是给人看的。讲清取文本时两串怎么被粘成一串、回退括号为什么救不了、表单与表格里的读音还有两种形态，以及哪五个字段一个注音都不能留。
- 关键词：多语言SEO,日本市场,内容本地化,小语种SEO

> **TLDR**：摘要：日语商品页上那行浮在汉字头顶的小假名，是给读不出这个字的人准备的。屏幕上它规规矩矩待在上面，可程序去取这一段文字的时候，取回来的是汉字和假名首尾相接粘成的一串，页面上从来没有人写过那个词。页面上绝大多数文本，一个位置只有一串字符，注音是唯一一处同一个位置摞了两串，而且两串都是给人看的。这一篇讲这层字怎么被拼错、错在哪几个位置，以及不懂日语的人怎么用十行代码测出自己的页面被拼成了什么样。

> 摘要：日语商品页上那行浮在汉字头顶的小假名，是给读不出这个字的人准备的。屏幕上它规规矩矩待在上面，可程序去取这一段文字的时候，取回来的是汉字和假名首尾相接粘成的一串，页面上从来没有人写过那个词。页面上绝大多数文本，一个位置只有一串字符，注音是唯一一处同一个位置摞了两串，而且两串都是给人看的。这一篇讲这层字怎么被拼错、错在哪几个位置，以及不懂日语的人怎么用十行代码测出自己的页面被拼成了什么样。

## 为什么日语页面上会多出一行没人当回事的小字？

## 从一家日本儿童文具站的商品名说起

先说一件真事。

那是一家做日本市场的儿童文具站，主推小学生用的书包、笔袋和练习本。

商品名写得很讲究，汉字上面全都规规矩矩标了假名。

这是这个品类的规矩，不是设计师一时兴起。

面向小学生的东西，汉字要按学年配当来控制，超纲的字得给出读音。

页面在浏览器里看毫无问题，两行字上下错落，读着舒服。

问题出在别处：站内搜索里搜商品名一个结果都出不来，导出的商品表里商品名全是一串谁也读不懂的东西，投给比价平台的数据源被判成了乱码。三处故障，同一个原因，而这个原因在页面上根本看不见——它只在文字被程序取走的那一瞬间才成立。

保哥当时接手看了不到十分钟就找到了，因为这类事故的形状太固定了。

这三处故障还有一个共同的时间特征：它们都不是上线当天暴露的。站内搜索没结果被当成了收录还没跟上，导出表乱码被当成了编码没选对，平台打回被当成了字段格式问题。三条线各自查了两周，谁也没想到去问另外两条线在查什么。

## 这行小字有三个来源，都不是装饰

先把它是什么说清楚。

浮在汉字上方那一行小假名，日文里叫振假名，中文习惯叫注音。

它出现在页面上，通常出于三种理由中的一种。

第一种是法规和规范要求。日本内阁告示的常用汉字表 (https://www.bunka.go.jp/kokugo_nihongo/sisaku/joho/joho/kijun/naikaku/pdf/joyokanjihyo_20101130.pdf)划出了一般社会生活里使用汉字的范围，公文和面向大众的说明文字通常按它走，表外的字要么换写法，要么标读音。

第二种是年龄。日本小学各学年的汉字配当 (https://www.mext.go.jp/a_menu/shotou/new-cs/1387014.htm)把一千多个汉字分摊到六个学年，面向低年级的商品，超出该学年范围的汉字几乎一定要注音。

第三种是人名地名和难读词。日本人的姓名同一串汉字可以有好几种读法，表单和文书里因此常年并存两个字段，一个填汉字，一个填假名。

三种来源的共同点是，注音不是可有可无的修饰，它承担着实际功能。既然承担功能，它就不会因为工程上不方便而消失，你只能接住它。

这三种来源还有一个共同点常被忽略：决定要不要注音的人，跟决定页面怎么取文本的人，从来不在同一个会议室里。前者是内容和法务，后者是前端和数据。中间那道缝隙有多宽，这一层出问题的概率就有多高。

## 它跟你熟悉的那几种排版手段完全不是一类

加粗、斜体、下划线，这些手段改的是同一串字符的显示方式。

字号、颜色、字间距，改的也是同一串字符。

注音不一样，它往版面上放了第二串字符。

这第二串字符不是样式，是内容，它有自己的文字，有自己的长度，能被选中，能被复制。

换句话说，页面上绝大多数文本，一个位置只有一串字符；注音是唯一一处同一个位置摞了两串，而且两串都是给人看的。这句话是本文所有结论的来源。你熟悉的所有文本处理工具、抽取逻辑、导出脚本，背后都默认一个位置只有一串字。这条默认假设在拉丁字母的世界里从来没被挑战过，因为那个世界里确实如此。

还有一个更直接的分辨办法：把样式全部关掉，看那段文字还剩什么。加粗斜体关掉之后字一个不少，注音关掉之后要么那串假名还在、只是不再浮在上面，要么它跟正文挤成了一行。凡是关掉样式还留在页面上的，都是内容不是格式。

## 同一个位置摞了两串，浏览器怎么显示，程序怎么读？

## 三个标签分别管什么

浏览器显示这层字靠三个标签配合。

外面那个是注音标注元素 (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ruby)，它把被注音的字和注音本身框在一起。

里面那个是注音文本元素 (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/rt)，装的是浮在上方的小字。

还有一个是回退括号元素 (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/rp)，专门给不支持这套显示的环境准备，它装的是一对圆括号。

三者的分工很清楚：第一个划范围，第二个放注音，第三个负责在显示不出来的时候把注音变成括号里的一段说明。第三个标签的存在本身就说明了一件事——这套机制的设计者从一开始就知道，会有环境把两串字读成一串，所以预先给了一个降级方案。降级方案的存在是个信号，它等于承认了这一层不总是能被正确处理。

这三个标签之间还有一层嵌套关系值得注意：注音文本元素必须待在注音标注元素里面，不能单独存在。这条约束的实际后果是，你没办法用选择器把注音那一串整体挪走而不动它的容器，分流只能在取值那一步做，不能靠改结构做。

## 回退括号那对括号，藏着整件事的关键

回退括号这个设计值得单独说两句。

它的意思是：如果你的环境读不懂上下两层，那就把注音放进括号，跟在被注音的字后面。

于是同一段内容有了两种正确的读法，一种是上下两层，一种是括号并排。

两种读法都对，可它们产出的字符串完全不同。

问题在于，绝大多数程序既不显示上下两层，也不会替你补括号，它只是把所有文字节点按顺序连起来。不显示也不补括号的结果，是两串字直接首尾相接，中间什么都没有。汉字后面紧跟着这个汉字的读音，读起来像一个人说话结巴了一下。

这个信号还有一层意思：设计者预料到的是显示环境读不懂，没有预料到的是取值环境根本不看显示。二十年前那批环境是文本浏览器和老旧终端，今天真正大量读页面的是各类抓取和导出程序，而它们对回退方案完全无感。

这里还有一个时间上的巧合值得一提：这套标记进入正式规范的年代，正好是网页内容主要被人眼消费的年代。等到大量程序开始批量读取网页文本，它已经定型多年，没有人回过头来重新审视那条降级路径够不够用。

## 取一段文字，你以为取到的是哪一串

具体到代码这一层，事情更清楚。

取节点文本内容的那个属性，会把所有后代文字节点原样拼起来，注音那一串照收不误，这一点在文本内容属性的文档 (https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent)里写得很明白。

另一个取渲染后文本的属性会考虑样式，行为上更接近人眼看到的结果，但两者的差异在各家浏览器里并不完全一致，渲染文本属性的文档 (https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/innerText)里专门解释了这种差异从哪来。

更麻烦的是，你的商品数据往往不是从浏览器里取的，而是从数据库、从接口、从导出的表格里取的，那些地方连样式的概念都没有。

所以同一个商品名，在页面上、在剪贴板里、在导出的表里、在投给平台的数据源里，可能是四个不同的字符串。四份数据谁也不知道其他三份长什么样，而校验的时候人们只看页面。

要看清这件事，可以拿一段带注音的文字做个小实验：先用鼠标选中，看选区高亮的范围包不包括上面那行小字。多数浏览器里是包括的，这说明在浏览器眼里它们本来就是同一段文本，只是被排到了两行上。

## 粘出来的那个词，在这门语言里根本不存在

这里有个容易被忽略的细节。

拼接产出的不是一个错别字，是一个不存在的词。

它由正确的汉字和正确的假名组成，每个字符都合法，组合起来却谁也不认识。

日语的分词器面对它会给出一个荒唐的切法，因为词典里没有这条。

这跟拼错一个字母完全不同：拼错的词至少还落在拼写纠错能兜住的范围里，而这种粘出来的串形态上完全合法，只是没有意义，任何以合法性为判据的检查都放它过去。这也是为什么这类问题总能活很久——所有的校验器都觉得它没毛病。日语本来就不靠空格分词，切分完全交给词典和引擎，这件事在日语三套文字混排的关键词写法 (https://zhangwenbao.com/japanese-seo-hiragana-katakana-kanji-keyword-notation.html)那篇里展开过，这里只补一句：注音制造出来的那些串，是词典里最不可能收录的一类。

这类串还有一个特点会误导排查方向：它们的长度看起来很正常。汉字加上自己的读音，总长度往往还落在商品名的常见区间里，字数校验和字段长度限制都不会报警。如果它们长得离谱，反而早就被人发现了。

还有一个判断这类串有没有混进来的土办法：把一批商品名按长度排序，看长度分布有没有出现两个峰。带注音的那一批会整体偏长，在分布图上鼓出一个小包。看得出这个包，就说明数据里混着两种形态的商品名，而不是同一种。

## 这一层字是在哪一步被拼成一串的？

## 五个位置，各自出错的方式不一样

把链路一段段拆开看，出错的位置一共五处。

第一处是用户复制。选中一段带注音的文字复制出去，粘贴到别处得到的通常就是粘连串。

第二处是站内搜索的索引。索引程序取文本时几乎都用最原始的那种取法，注音一并进了索引。

第三处是数据导出。商品表导出成表格或者接口，出来的是拼接后的那一串。

第四处是抓取与摘录。外部程序读你的页面，读到的是拼接串，摘出来当作直接答案展示的时候也是。

第五处是各类文本统计。字数、可读性、关键词密度这些数字全都因此偏高，而且偏得很有规律。

这五处还可以按发现难度重新排一次序：越靠近用户的越容易被发现，越靠近数据管道深处的越难。而商业价值的排序恰好相反，管道深处那几处直接决定商品能不能被检索、能不能上架。难发现和高价值这两条，在这里是重合的。

## 五处里面，只有一处会被人看见

这五处的严重程度并不一样。

真正致命的是第二处和第三处，因为它们直接决定用户搜不搜得到、平台收不收你的数据。

而唯一有可能被人肉眼发现的是第一处，因为复制粘贴之后那串字就摆在眼前。

其余四处全在系统内部完成，没有任何界面会把结果展示给你看。

于是就有了这类事故的典型形态：用户抱怨搜不到，运营查页面一切正常，双方各自确信自己没错，因为他们看的根本不是同一份字符串。这种争论通常要持续好几周，直到有人偶然把商品名粘进记事本。

要打破这种僵局，最快的办法不是继续解释，而是当场做一次复制粘贴给对方看。这件事的说服力在于它不需要任何专业知识，双方看到的是同一屏幕上的两串字。技术争论一旦能被还原成一个五秒钟的动作，通常就结束了。

## 它为什么在英语站上从来不是个问题

顺手把这条讲清楚，免得有人觉得这是小题大做。

英语内容里没有这一层，所以整条工具链从来没有为它做过任何准备。

拼接所有文字节点这个做法，在只有一串字的语言里永远是对的。

它不是一个有缺陷的实现，它是一个在特定假设下完全正确的实现。

这跟大小写转换那件事同一个道理：一个函数如果没有语言参数，它不是通用的，它是选了默认值的。这条判据在小语种大小写折叠的那些坑 (https://zhangwenbao.com/minor-language-case-folding-lowercase-turkish-dotless-i.html)里已经验证过一次，这里第二次成立，只不过这回被选中的默认值不是英语的字母表，而是英语的版面结构。

这条还能推出一个采购层面的建议：评估任何一款内容工具时，不要问它支不支持日语，要问它取文本的时候怎么处理注音标记。前一个问题所有厂商都会答支持，后一个问题能答上来的很少，而后者才是真正的分水岭。

## 这跟看不见的字符、跟罩错词的标记差在哪儿？

## 三种问题，三个不同的层

小语种页面上有三类长得很像的麻烦，值得摆在一起比一比。

第一类是不可见字符，比如软连字符和零宽空格，它们藏在字符串里，屏幕上完全看不出来。

第二类是内联标记漂移，加粗和斜体在译文里罩错了词，屏幕上看得见，但看着很正常。

第三类就是本文这一层，屏幕上看得见，看着也正常，而且它比前两类多了一整串真实文本。

三者的共同点是都能通过所有自动校验，区别在于前两类是字符串被污染或者被标错，这一类是字符串本身多了一段。多出来的那一段不是杂质，它是内容，删掉是错的。这就把解法逼进了一条更窄的路。

三类问题还有一个共同的成因：它们都诞生在版面需求和数据需求打架的地方。断行是为了好看，强调是为了显眼，注音是为了读得出，三件事都由内容侧提出，都在标记层落地，而承担后果的全是下游的数据管道。

## 一个能删，一个不能删，这个差别决定了解法

把差别再说透一点。

软连字符可以删，删掉之后把断行交给样式层去做，页面照样好看，这件事在断行那一篇里给过完整的选型顺序。

加粗罩错了词可以改，把强调从版面手段换成句法手段，意思一点不损失。

注音删不掉。删了小学生就读不出那个字，删了姓名字段就填不了，删了法规要求就没满足。

所以这一层的处理方向跟前两类正好相反：不是想办法把它从字符串里清出去，而是想办法让每一条管道各自拿到它该拿的那一份。这是一道分流题，不是一道清洗题。想明白这一点，后面的所有具体做法就都顺了。

分流题和清洗题的区别还体现在验收方式上。清洗题的验收是查残留，扫一遍看还有没有漏网的字符即可。分流题的验收是查去向，得逐条管道确认它拿到的是哪一份，没有任何单点检查能替你完成。这也是它更费事的原因。

## 跟版面手段那一篇的关系

再补一句边界。

标记漂移那件事里，问题出在标签罩住的词跟原文不是同一个，解法是把强调改成句法结构，具体做法在译文里加粗错位的排查办法 (https://zhangwenbao.com/minor-language-emphasis-markup-anchor-drift.html)那篇里。

本文这件事里，标签罩住的位置一点没错，多出来的是标签里面的另一串文字。

两者唯一的共同点是都涉及内联标签，此外没有任何交集。

如果说标记漂移是把重音放错了地方，那注音就是同一个音同时被两个人唱着，而录音设备只有一条轨。前者调整位置就能修好，后者得先决定录哪一条。

再补一个反向的关系。标记漂移那件事里，译员是问题的来源，因为标签的位置由人摆。注音这件事里，译员完全无关，注音是模板或者编辑加的，出错的位置在取值环节。前者要靠改流程管人，后者只要改一次取值方式。

## 注音不只在正文里，它还在表单和数据源里各占一份

## 日本表单里那个假名字段是独立存在的

很多人以为这是排版问题，其实它在数据结构里也有位置。

日本的注册表单和收货地址表单，姓名通常拆成两组字段。

一组填汉字姓名，另一组填假名读音，后者常常还要求全用片假名。

这两组字段在数据库里是两列，不是一列的两种形态。

这件事的意义在于，注音在这里已经被当成独立数据处理了，而在正文里它还是内联的。同一个东西在你的系统里存在两种形态，一种规规矩矩有自己的列，一种混在一段文字中间，出问题的永远是后一种。姓名字段本身的排布规则跟别的市场差在哪，匈牙利语姓在前那一类字段设计 (https://zhangwenbao.com/hungarian-seo-eighteen-cases-vowel-harmony-keyword.html)里讲过一次，可以对照着看。

这个字段还有一个被低估的用途：它是你手上唯一一份由用户亲手填写的读音数据。用户自己填的读音，比任何自动转换出来的都可靠，积累一段时间之后，它可以直接拿来校准你对同一批汉字读法的判断，这份数据别的地方买不到。

## 商品数据源里的隐藏读音属性

还有一处更隐蔽。

日本客户给你的商品表格，通常是一份电子表格文件。

表格软件里的日语单元格有一个专门的读音属性，输入汉字时输入法把读音顺手存了进去，界面上默认不显示，有专门的函数可以把它取出来，微软的读音函数说明 (https://support.microsoft.com/en-us/office/phonetic-function-9a329dac-0c0f-42f8-9a55-639086988554)里描述了它的取法。

这个属性在另存为纯文本格式的时候会整块丢掉。

于是同一份商品表，用不同方式导出会得到不同的信息量，而丢掉的那一份恰好是排序和检索最需要的。日本的商品列表按五十音顺排序，靠的正是这一列，一旦丢失，排序就只能退回按字节比大小，出来的顺序在日本人眼里毫无道理。

这里还有一个更常见的丢失路径：表格文件在不同软件之间转一手。用开源办公软件打开再存回去，或者用脚本读取再写出，这个隐藏属性通常都不会被保留。而这两件事在数据对接里天天发生，谁也不会觉得自己丢了东西。

顺带说一句检查办法：拿到日方给的表格之后，先另存一份纯文本，再另存一份保留格式的，两份文件大小差得越多，通常说明藏在里面的附加属性越多。这个粗糙的判断只要两分钟，比逐列核对快得多。

## 三种形态各归各的地方

把三处归纳一下。

正文里，注音是内联的，跟被注音的字摞在一起。

表单里，注音是独立字段，有自己的列和自己的校验规则。

数据源里，注音是单元格的隐藏属性，取不取得到看你用什么方式读。

三种形态在同一个项目里同时存在，而团队里通常有三拨人分别负责，谁也不知道另外两处也有这个东西。把这三处画在同一张图上，是这类项目开工时最值钱的半小时。画完之后你会发现，很多人以为的排版细节，其实横跨了前端、表单和数据管道三条线。

这张图还有一个立竿见影的用处：它能挡住一类常见的重复劳动。三条线各自发现问题之后，往往会各自加一段清洗代码，三段代码规则不一致，互相之间还会打架。有了这张图，清洗只在一处做，其余两处只管取值。

## 阿拉伯语和希伯来语头顶那些点，跟这是同一件事吗？

## 方向正好相反的一对

这个问题问得好，因为答案是既是也不是。

阿拉伯语和希伯来语平时不写元音，元音靠读者根据上下文补。

需要的时候可以把元音符号标出来，标在字母的上下，宗教文本、儿童读物、教材里常见。

所以这两门语言的默认状态是不标，标是例外。

日语的默认状态是不注音，注音也是例外。到这一步两者看起来是一回事。真正的差别在于，不标元音会让一个词有多种可能的读法，而多标了注音会让一段文字多出一串字符。前者是信息不足带来的歧义，后者是信息过量带来的粘连。一个是缺，一个是多，处理方向完全相反。

缺和多这两种状态还有一个不对称之处：缺信息可以靠上下文补回来，人和机器都能补一部分；多出来的那一串却没有任何人能判断它该不该在这里，因为它本身完全合法。补是有希望的，删是有风险的，所以后者反而更棘手。

## 缺信息那一半，早就有人讲过了

信息不足那一半不在本文的范围里。

不写元音会造成多少歧义、词根三辅音怎么变成可用的选词方法，希伯来语不标元音的选词办法 (https://zhangwenbao.com/hebrew-seo-unvocalized-script-root-letters-keyword.html)那篇讲得很细。

阿拉伯语这边同一个字母的几种写法怎么把词表拆散，在阿拉伯语词根与破碎复数的词表拆分 (https://zhangwenbao.com/arabic-seo-rtl-layout-msa-dialect-keyword.html)里也有专门一节。

本文只接手另外那一半：当这些符号真的被标出来之后，你的字符串会发生什么。

结论跟日语惊人地一致——标了元音符号的词和没标的词，在字节层面是两个不同的字符串，精确匹配对不上，去重对不上，排序也对不上。阿拉伯语与波斯语排版需求文档 (https://w3c.github.io/alreq/)里对这些符号的排布有专门章节，可以看到它们在版面上的位置有多讲究。

这条分工线也提醒了一件事：同一门语言在本站可能被拆进好几篇里讲，不是因为写不完，而是因为机制不同。判据是这两件事出问题的时候，排查会走进不同的层。走进同一层的合成一篇，走进不同层的就得分开。

这条分工线还有一个实际好处，就是内链好写。同一门语言分在几篇里，彼此之间的引用关系天然成立，读者顺着链接走一圈能拿到完整的图景，而每一篇又都只回答一个问题，不至于写成一份什么都讲一点的说明书。

## 一个在字符内部，一个在标签外部

不过技术处理上，两者差着一层。

阿拉伯语和希伯来语的元音符号是组合字符，它们直接跟在字母后面，属于同一个字符串，这一类字符的行为在组合标记常见问题 (https://www.unicode.org/faq/char_combmark.html)里有系统说明。

日语的注音是独立的标签内容，它跟被注音的字之间隔着标记结构。

前者要在字符层做归一化处理，后者要在标记层做分流处理。

所以同一句话在两边的落地办法完全不同：阿拉伯语那边你要决定入库时剥不剥符号，日语这边你要决定取文本时收不收注音。剥符号是有损的，收不收注音是可逆的，这一点上日语的处境反而好一些。希伯来语那些元音点的独立码位可以在希伯来文码表 (https://www.unicode.org/charts/PDF/U0590.pdf)里逐个查到。

这个差别还决定了谁来动手。字符层的归一化通常由后端或者数据库配置负责，一旦定下来全站生效；标记层的分流由前端和取值代码负责，得逐个位置改。前者是一次决策，后者是一批改动，排期的时候要分开估。

## 关键词表要不要把注音那一串也收进去？

## 先问用户会不会这么打

这个问题的答案取决于品类，不是取决于语言。

日语用户在搜索框里打字，几乎总是先打假名再转换成汉字。

转不转换，取决于这个词在他脑子里的标准形态是什么。

商品品类词绝大多数会被转换成汉字，因为那是通行写法。

但有几类词不会：儿童向的商品名、拟声拟态词、部分外来语，用户打完假名就直接回车了。判据不是这个词有没有汉字写法，而是用户脑子里那个词长什么样。这跟工具给的搜索量没关系，工具那点数据在小语种上本来就靠不住，替代办法在工具没数据时的三条补救路径 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)里写过。

还有一个反直觉的现象：越是简单常用的商品词，用户越倾向于打完假名就直接回车，因为转换那一步本身要多按一次键。反倒是那些容易混淆的词，用户会耐心转换成汉字以确保搜的是对的东西。省事和求准这两股力，在不同的词上胜负不同。

## 收进去和收错了，差在一个空格上

假设你决定收。

要收的是注音本身，也就是那串独立的假名。

不能收的是拼接产物，也就是汉字紧跟着假名的那一串。

前者是用户真的会打的词，后者是这个世界上没有人会打的字符串。

可惜的是，如果你的词表是从站内搜索日志或者从页面文本自动扒下来的，扒到的十有八九是后者。词表里凡是出现汉字直接连着自己读音的条目，一律是污染，不是需求。这一条可以写成一行正则挂在词表的入库校验上，成本极低。

这条校验规则还能顺手抓到另一类问题。除了汉字紧跟读音，还有一种是同一个词在词表里连续出现两次、第二次多带了一小段假名尾巴。这两种形态都指向同一个源头，也就是某条自动采集管道用了最原始的取文本方式。

这条规则还有一个副产品：它能顺手把词表的来源标记出来。凡是被这条规则拦下来的条目，几乎都来自自动采集那一路，人工整理的词表几乎不会产生这种形态。拦截日志本身就是一份来源质量报告。

## 假名写法本身还有两派

还有一层。

就算决定收假名，同一个读音也有平假名和片假名两种写法。

外来语按规矩用片假名，固有词用平假名，可用户不总是按规矩来。

注音这一层通常用平假名，而表单里的读音字段常常要求片假名。

于是同一个词的读音在你的系统里可能同时以两种字符存在，这两种字符在字节上毫无关系。三套文字并存带来的写法分叉，日语关键词的写法覆盖 (https://zhangwenbao.com/japanese-seo-hiragana-katakana-kanji-keyword-notation.html)那篇有完整的展开，本文只提醒一句：注音这一层会把已经分叉的写法再分一次。

两派写法在检索侧的表现也不一样。片假名在日语里天然带着外来语和商品名的气味，平假名带着口语和儿童向的气味，同一个读音写成两种，落到的查询意图并不完全重合。所以这不只是字符层的分叉，它还是一次轻微的意图分叉。

## 哪些位置可以留注音，哪些位置一个都不能留？

## 能留的位置：正文与商品描述

先说能留的。

正文段落里可以留，这本来就是这套标记设计出来的用武之地。

商品描述里可以留，前提是导出数据源的时候走的是另一条管道。

面向儿童和面向老年人的说明性内容里应该留，这是可读性问题。

判据很简单：这段文字只被人眼消费，就可以留；它同时要被程序消费，就得先想清楚程序拿到的是哪一串。绝大多数纠纷都源于第二种情况被当成了第一种。

还有一个容易走偏的地方：有人会把这条判据理解成正文随便写。正文虽然能留注音，但正文同样会被摘取、被复制、被拿去做内容分析。能留的意思是不必因为数据管道而牺牲可读性，不是这一段就此不再产生任何字符串。

## 不能留的位置：标题、描述、替代文本

再说不能留的。

页面标题标签里不能留，标题在搜索结果里是纯文本，注音进去就是粘连串。

元描述里不能留，理由相同。

图片的替代文本里不能留，替代文本本来就是给读不到图的人和程序准备的，塞进去的注音会被读两遍。图片这一层在小语种站上本来是最容易捡的流量，具体写法在非拉丁文字站的图片替代文本写法 (https://zhangwenbao.com/minor-language-image-alt-text-non-latin-script-search.html)里有整套流程。

网址里更不能留，这一层的取舍在本地字母网址与拉丁转写的四种组合 (https://zhangwenbao.com/minor-language-url-native-script-vs-latin-transliteration.html)里单独讨论过。

这几处还有一个共同特征：它们的值往往不是人手写的，而是模板从别处拼出来的。标题从商品名拼，描述从卖点拼，替代文本从商品名加属性拼。只要源头那个商品名带着注音，这几处就会同时中招，而且错得一模一样。

## 最容易被忽略的是结构化数据

有一个位置几乎所有人都会漏。

结构化数据里的商品名、品牌名、描述这些字段，值经常是直接从页面元素里取的。

取法一旦用了最原始的那种，注音就跟着进了标记。

而结构化数据是全站唯一写错了没人会投诉的地方，因为它不显示给任何人看。

这一层的字段该怎么分类处理，小语种结构化数据的三类字段 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)那篇给过一张表，本文只补一条：凡是从页面元素取值的字段，都要单独确认一遍取到的是哪一串。

结构化数据这一处还有一个额外的坏处：它是被外部程序原样取走的字段。别的地方出了粘连串，至少还有人可能看到；这里出了粘连串，字面上就等于你亲口告诉外部这个商品叫这个名字。自己声明的错误，比被误读的错误更难解释。

## 锚文本这一处要分情况

最后一处是内链的锚文本。

锚文本里出现注音，本身不算错，因为它也是给人读的。

但锚文本会被各类工具当成纯文本收集，收集到的会是粘连串。

所以稳妥的做法是锚文本里不放注音，把注音留在锚文本外面的那句话里。锚文本本身该怎么划边界，屈折语那边的规则在锚文本在屈折语里的变形处理 (https://zhangwenbao.com/minor-language-internal-link-anchor-inflection-variants.html)里有六条位置判据，日语这边没有变格问题，但边界规则是通用的。

还有一种折中做法值得一提：锚文本用纯净形态，注音放在锚文本前后的句子里。这样读者依然能读出那个词的音，工具收集到的锚文本也是干净的。这类把两种需求错开摆放的做法，在这一层里往往比二选一更实用。

## 不懂日语，怎么测出自己的页面被拼成了什么样？

## 第一步：把眼睛看到的和程序取到的并排放

这件事不需要懂日语，只需要会做一次对比。

打开一个带注音的页面，选中一段文字，复制，粘贴到任何一个纯文本编辑器里。

然后把这段文字在页面上的样子截个图，两边并排。

如果粘贴出来的字数明显多于屏幕上那段，多出来的就是注音。

这一步能在三分钟内给出确定的答案，而且不需要任何工具。整件事最难的从来不是技术，是想到要做这个对比。

这个对比还有一个变体更适合拿给管理层看：把同一段文字分别贴进纯文本编辑器和聊天窗口，两处显示的结果通常还不一样。两三个窗口一并排，一句话都不用解释，对方自己就会问这是怎么回事。

这个动作还有一个副作用值得提前说明：一旦大家看到粘连串，往往第一反应是把注音全部去掉。这时候需要有人及时把话接住，说明这一层不能删，要解决的是取值方式。否则一个显示问题会被顺手改成一个合规问题。

## 第二步：在控制台里数一遍

要更精确一点，就在浏览器控制台里跑两行。

取那个元素的文本内容属性，看长度是多少。

再把元素里所有注音文本元素的内容单独取出来，看长度是多少。

两个数字一减，就知道注音在这段文字里占了多大比重。

比重超过两成，说明这一层已经足够改变任何按字数计算的指标了，包括可读性分数和关键词密度。这类靠计数得出的指标在小语种上本来就容易失真，多出来的这一层只会让它更没法看。

这两个数字还有一个更实际的用法：拿它去反推那些已经算出来的指标错了多少。假设注音占了两成，那么按字数算的所有指标都要按这个比例往回折算一遍。折算完之后，很多此前看起来莫名其妙的曲线会突然变得合理。

## 第三步：拿三条管道各取一次

最后一步是把关键的几条管道各走一遍。

页面上看一次，导出的数据文件里看一次，投给平台的数据源里再看一次。

三份结果贴在同一张表上，一眼就能看出哪条管道出了问题。

这张表还有一个额外好处：它把一件抽象的事变成了三行可以并排比较的字符串，跟别的部门讲的时候，一句解释都不用。把成本变成体感，永远比讲道理管用。

这张表还应该留一列写日期。三条管道各自会因为版本升级、模板改版、供应商更换而变化，而变化通常没有任何通知。留了日期，下次出问题的时候就能一眼看出是哪条管道在什么时候变过，排查范围立刻缩小到一条线上。

三条管道并排之后，还能顺手回答一个常被问到的问题：这件事到底影响多大。把三份字符串的差异算成比例，就是一个可以写进汇报里的数字，比任何定性描述都容易被接受。

## 一份可以照着走的注音层处理清单

## 先分流，再谈别的

处理顺序很重要，第一件事必须是分流。

在取文本的地方明确指定：给人看的走一条路，给程序用的走另一条。

给程序用的那条，把注音文本元素整个排除掉，只取被注音的那一串。

这件事在前端只是一行选择器的差别，在后端是一次取值方式的调整。

分流没做之前，后面所有的优化都是在错误的字符串上做的，做得越认真错得越远。

分流这一步还有一个常被跳过的前置动作：先确认现在到底有几条取值路径。多数团队报得出两条，实际跑起来往往是四五条，因为历史上不同时期的人各写过一份。没数清楚就开始改，改完总会剩下一条谁都不记得的管道还在漏。

## 字段级的取舍表

分流做完，把字段过一遍。

标题、元描述、替代文本、网址、结构化数据的值，这五处一律取纯净串。

正文、商品长描述、帮助文档，这三处保留完整的注音标记。

表单里的读音字段单独一列，不跟正文那一层混用。

这张表建议写进前端的组件规范里，而不是写进内容规范里，因为它是结构问题不是写作问题。

这张表还建议加一列写明由谁负责。前五处属于工程实现，后三处属于内容规范，两拨人的工作节奏完全不同。把负责人写在表上，最大的作用是避免出现那种双方都以为对方会处理的字段，这类字段是事故率最高的。

## 验收的时候看什么

验收要看三个数。

第一个是站内搜索里用商品名的纯净形态能不能搜到。

第二个是导出文件里随机抽二十条商品名，有没有粘连串。

第三个是结构化数据校验工具里那几个文本字段的值，肉眼过一遍。

这三个数每次上线新品类都值得重跑一次，因为新品类往往意味着新的模板，而模板是这类问题最常见的入口。母语审校那边也应该加一条对应的验收项，具体怎么把这类项目写进审校简报，小语种译文验收清单 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)那篇有现成的写法。

这三个数还有一个共同的好处：都可以在半小时内跑完，不需要任何专门工具。正因为便宜，才有可能真的每次上线都跑一遍。验收项一旦贵到要专门排期，它在实际项目里的执行率就会迅速掉到零，这一点比它本身查得准不准更重要。

## 哪些事不归语言层，一句话交出去

最后划一下边界。

注音标记在各家浏览器里的显示差异、竖排时它该落在哪一侧，这些属于排版实现，归前端。

日本本地搜索引擎在这一层的具体行为差别，归引擎那一侧，跟日本本地搜索引擎的机制差别 (https://zhangwenbao.com/yahoo-japan-seo-overseas-japan-search-engine-mechanism.html)那篇合起来看更完整。

字体缺字导致注音显示不出来，属于字体子集问题，小语种网页字体的字形集成本 (https://zhangwenbao.com/minor-language-web-font-glyph-set-first-screen-cost.html)里有完整的度量口径。

本文只管一件事：同一个位置上的两串文字，各自应该流向哪里。

这几件事交出去之后，还要留一句话给接手的人：他们各自那一层怎么做都行，唯一的硬要求是不能把两串文字合并成一串。把边界写成一句可验证的约束，比把它写成一个模糊的责任划分有用得多，接手的人也更容易照做。

## 常见问题解答

## 不做日本市场，这一篇跟我有关系吗？

有关系，但关系在方法不在语言。这套标记在中文的拼音标注、韩语的汉字括注里同样成立，只要你的页面上出现过一个位置摞两串字的情形，本文的分流思路就能直接搬。更重要的是那条判据本身：凡是给人看的东西和给程序用的东西共用同一个取值口，迟早要出事。这个道理在图片替代文本、在结构化数据、在锚文本上都成立过一次。

所以就算你的站上一个日文字都没有，把最后那份三条管道并排取值的自检表留下来也不亏。真正需要日语知识的部分，本文已经压缩到只剩一次复制粘贴。换个角度说，这一篇真正的对象不是日语，而是任何一处人机共用的取值口。真正需要日语知识的部分只剩一次复制粘贴，剩下的全是流程问题。

## 直接把注音全删掉，是不是最省事？

省事，但通常不允许。面向低年级儿童的商品，超出学年配当的汉字必须给读音，这是行业惯例也是家长的实际需求。姓名和地址表单里的读音字段是独立存在的，删了表单就不成立。真正可以考虑删的只有一种情况：这一层注音是模板批量加的，加得毫无道理，正文里连难字都没有。这种情况下删掉不但省事还能提可读性。

判断办法是抽二十个商品名，看被注音的汉字里有几个是常用字，如果超过八成都是常用字，那这一层大概率是模板加的，可以整层去掉。删之前记得先问一句这个决定谁能拍板。删之前还要确认一件事：这些注音是不是被别的系统当成数据源在用，比如排序或者搜索。这类决定最好由内容和法务一起拍板，工程侧只负责执行。

## 用回退括号那个标签，是不是就万事大吉了？

不是。回退括号只在不支持这套显示的环境里起作用，而绝大多数取文本的程序并不属于不支持的环境，它们只是根本不看显示。换句话说，回退括号解决的是显示降级，不解决取值污染。用了它之后，粘连串会变成带括号的串，比原来好读一点，但依然不是你想要的那个词。

它真正的价值是给一部分老旧环境一个体面的展示，以及提醒你这套机制天生就有两种读法。所以该写还是要写，但别指望它能替你把数据管道理顺。分流那一步一步都省不掉。另外它在无障碍那一侧也有作用，部分读屏软件会依赖这对括号决定要不要把读音念出来。把它当成一个提示信号来读，比把它当成解法有用得多。

## 站内搜索到底该索引哪一串？

两串都索引，但要分开索引，不能拼在一起。被注音的那一串进主字段，注音本身进一个独立的辅助字段，两者之间不做拼接。这样用户打汉字能搜到，打假名也能搜到，而且不会产生任何一个不存在的词。绝大多数搜索引擎都支持多字段检索，这不是什么高级功能。真正要避免的做法是把整段文本原样丢进索引，那样索引里全是粘连串，用户打什么都对不上。

设置完之后随手做一次验证：拿一个带注音的商品名，分别用汉字和假名各搜一次，两次都应该命中同一条。如果搜索引擎不支持多字段，退一步的办法是把注音那一串单独存成一条同义词记录，效果接近。配好之后每季度抽查一次，成本很低。

## 这一层会不会被判成关键词堆砌？

正常使用不会。注音的出现有明确的语言学理由，密度也受限于难字的数量，不构成异常重复。真正需要担心的是另一种做法：有人发现注音能往页面上多塞一层文字，就故意给不需要注音的常用字全都加上，甚至把注音写成关键词而不是读音。那种做法既伤可读性又确实属于操纵，风险自负。

判断自己有没有越界很简单，看被注音的字里有多少是真的需要读音的。如果一个面向成年人的页面上通篇都是注音，那已经不是语言问题了。按规矩用这一层，从来不需要担心这件事。还有一个简单的自查：看这一层的密度在各个页面之间是不是稳定，突然某一类页面高出一截就值得看看。按语言的实际需要用这一层，从来不会踩到这条线。

## 为什么校验工具一个警告都没报？

因为拼接产出的字符串在形式上完全合法。它由合法的汉字和合法的假名组成，编码正确，没有不可见字符，没有非法码位，长度也在范围内。所有以合法性为判据的检查器面对它都只能放行。这跟译文里加粗罩错了词是同一种处境：能自动校验的只有形式，语义那一层天然需要一个懂这门语言的人看一眼。这也是为什么这类问题的平均存活时间都以年计。

要想让机器帮你发现，唯一的办法是自己加一条针对性的规则，比如检测汉字后面是否紧跟着与之对应的假名，这条规则不难写，只是没有任何现成工具会默认带上它。这条规则最好挂在内容入库那一步，而不是挂在发布之后的巡检里，越早拦住修起来越便宜。规则本身十几行就能写完，难的是有人想到要写。

## 什么时候该把这件事排进日程？

三个时机。第一个是准备进日本市场之前，这时候改成本最低，因为模板还没定型。第二个是换了内容管理系统或者换了前端框架之后，取值方式很可能跟着变了。第三个是发现站内搜索命中率异常低、或者投给平台的数据源被打回的时候，这两种症状指向这里的概率相当高。除此之外不必主动排查，因为这一层稳定，规则不会自己变。

真要排一个优先级，它排在结构化数据之后、图片替代文本之前，因为它影响的是数据能不能用，而不只是能拿多少流量。已经出过一次事故的团队，一般不需要人提醒。如果三个时机都没赶上，那就等第一次导出数据被平台打回，那通常是它最后一次给你提醒。排查一次能管很久，因为这一层的规则本身不会变。

## 权威参考资料