你能不能在这门语言上做站内搜索，取决于几个志愿者今年还有没有提交代码

摘要：同一套站内搜索，换一门语言就变笨，差别不在你的代码里。保哥把那个公共词典仓库逐门语言查了一遍：越南语、爱沙尼亚语、斯瓦希里语的词典内容最后一次改动是2012年，而那次改动是挪目录，不是加词。这一层的能力由几个志愿者的提交记录决定。

同一套站内搜索，为什么换一门语言就明显变笨？

一家做乐器配件的站，波兰站好用，爱沙尼亚站不好用

有个客户做乐器配件，吉他弦、拾音器、琴包、谱架这几条线。

他们的站内搜索是同一套服务，同一份配置，连索引模板都是复制过去的。

波兰站上线之后表现不错，用户搜单数搜复数、搜带格尾的形态，都能召回。

爱沙尼亚站上线之后，搜索转化率只有波兰站的三分之一。

技术那边查了两周，索引正常、分片正常、查询语句正常、日志里没有报错。

最后是运营发现的：用户搜一个带格尾的词，返回零结果，把词尾去掉再搜，商品全出来了。同一套系统在两门语言上的差别，不在他们自己写的任何一行代码里。

再往下查一层，希腊站的问题又是另一种

同一批人接着看希腊站。

希腊站的召回没问题，词形变化基本能对上。

出问题的是拼写容错，用户少打一个重音符号，结果就完全不一样。

更奇怪的是，这个站的相关词推荐几乎不工作，推出来的永远是同一批热门商品。

三个站，三种毛病，而技术栈是同一套。本站另有一篇算过尺码这类值不是翻出来是算出来的，那一篇的错出在没人负责的一道算术上，这一篇的错出在没人负责的一份文件上，两笔账的形状很像。

到这一步，问题已经不能用配置来解释了。真正的差别在于，这套系统在每门语言上调用的是不同的外部资源，而那些资源的成色差得极远。

你的语言能力不是你的，是借来的

这件事说破了很简单。

你的搜索、拼写纠错、断词、排序、自动补全，在每一门语言上都要依赖一份语言数据。

这些数据你没写过，你的供应商也没写过。

它们躺在几个公共仓库里，由一批志愿者维护，免费，随便用。

英语站上的人从来不需要想这件事，因为英语那几份数据永远是完整的、最新的、被无数人盯着的。

换成小语种，这条假设立刻不成立，而且不成立的程度差别极大，有的语言比英语还认真，有的已经停在十四年前。

这跟工具没数据不是同一件事

这里要跟一个老问题划清界限。

本站写过关键词工具在小语种上返回零的那笔账，那是数据缺口，是别人没采集你的市场。

这一篇讲的是另一层：不是没人给你数据，是处理这门语言的能力本身缺了一块。

两者的表现也不一样。前者是你查不到量，后者是你的系统跑出来的结果不对。

前者可以靠自己数、靠日志补，后者补不了，因为缺的是算法和词库，不是样本。

把这两件事混在一起，最常见的后果是团队一直在补数据，而系统那一侧的能力缺口从来没被看见过。

这一层为什么值得单独拿出来讲

小语种SEO的讨论里，绝大部分注意力在两个地方：词怎么选，内容怎么写。

再往上一点是引擎那一侧，收录、排名、算法更新。

底下这一层几乎没人提，因为它不在任何一个岗位的职责里。

技术团队认为语言的事归本地化，本地化团队认为系统的事归技术，双方都对。

而它的影响面偏偏很大：站内搜索、筛选器、拼写容错、相关推荐、自动补全、断词换行，这几件事全部踩在同一层地基上。

更要命的是，它坏掉的时候不报错。系统照常返回结果，只是结果差一点，而差一点的东西没有任何监控会告警。

你的站在一门语言上的能力，具体是从哪几个文件来的？

第一份：拼写词典，管的是这个词形算不算合法

最基础的一份是拼写词典。

它由两个文件组成，一个装词根，一个装词缀规则。

装词根的那个文件第一行写着词条数，后面每行一个词，词后面挂着这个词能接哪些规则。

装规则的那个文件写着每条规则怎么加词尾、什么条件下能加。

浏览器里的红波浪线、办公软件的拼写检查、很多站内搜索的容错，用的都是这一份。

它的重要性在于，它是唯一一份把这门语言的形态知识写成机器可读格式的公共资产，别的能力大多建在它上面。

第二份：断词规则，管的是长词怎么折行

第二份是断词文件。

它规定一个词能在哪几个位置断开加连字符。

德语、芬兰语、匈牙利语这类长词多的语言，没有它排版会很难看。

本站算过一笔账，为了让长词在手机上不撑破，前端往标题里塞了个看不见的字符，那篇讲的正是断词缺位之后的补救动作。

断词文件的特点是它跟拼写词典分开维护，一门语言可能有词典没断词。

而这一格缺不缺，前端通常要到上线之后被设计师投诉才会发现。

第三份：同义词库，管的是相关词推荐

第三份是同义词库。

它给每个词列出近义词，办公软件的同义词功能和一部分搜索的查询扩展用的是它。

希腊站那个相关推荐不工作的毛病，根子就在这里。

这一格的缺失率是三份里最高的，因为它最不影响基本功能，最容易被排在后面。

它缺了不会让任何东西报错，只会让推荐质量默默降一档。

而推荐质量这种东西，除非你拿两个语言站并排比，否则永远看不出来。

第四份和第五份：词干器与分词器

再往上是两个算法层的东西。

词干器负责把一个词的各种形态还原到同一个词根，搜索能不能召回不同词形靠它。

爱沙尼亚站那个搜带格尾就零结果的毛病，属于这一层。

分词器负责在没有空格的文字里切出词，泰语、日语、中文这类语言必须有它。

这两样都不在词典仓库里，它们在别的项目里，各有各的语言覆盖清单。

关键在于三份清单互相不重合：有词典不等于有词干器，有词干器不等于你的搜索服务集成了它。

第六份：区域格式数据，管的是日期货币怎么写

最后一份跟前面五份的性质完全不同。

它是公共区域数据，规定日期、数字、货币、单位在每个地区该怎么写。

操作系统、浏览器、开发框架的格式化函数全从这里取值。

把它放在这里，是因为它跟前面五份构成了一个很有意思的对照组。

同样是公共资产，同样免费，同样没人给你SLA。

但它的成色跟词典那几份完全不在一个水平上，后面会专门算这笔账，那个对比是这一整篇里最值得记住的部分。

这些文件最后一次有人动，是什么时候？

先说清楚这次实测怎么做的

保哥把那个公共词典仓库整个拉了一遍。

仓库里有67个语言目录，一共859个文件，葡萄牙语占了两个目录，巴西和葡萄牙分开。

然后挑了27门语言逐个查：这门语言有没有词典、有没有断词、有没有同义词库、词条数多少、最后一次提交是什么时候、提交的人是谁、那次提交改了什么。

查最后一次提交这一步有个坑，目录级的提交记录会被一些无关的批量操作污染，比如统一改个标签、修个注册文件。

所以真正有意义的是词典文件本身的最后一次改动。

保哥两个都查了，下面的结论用的是后者，因为它反映的才是内容有没有被更新过。

最上面那一档：今年还在提交

先说活着的。

法语和罗马尼亚语最近一次更新在2026年7月，波兰语和立陶宛语在2026年6月，乌克兰语在2026年2月，匈牙利语在2025年12月，泰语在2025年9月。

这七门语言的共同点是，最近一次提交做的是实事：升级到上游的新版本、加词、修编码问题。

匈牙利语那一条尤其有意思，提交人是那套拼写检查方案的作者本人，版本号写着1.9。

这套方案当年之所以被写出来，正是因为匈牙利语一个词能派生出几千种形态，穷举词表的老办法根本不适用。

三十年过去，这门语言在这个仓库里的那一格，还是他在管。

2026年更新的那四门语言，出自同一个人之手

还有一个细节，保哥是把提交人这一列并排看的时候才发现的。

法语、罗马尼亚语、波兰语、立陶宛语这四门语言，2026年那次更新的提交人是同一个名字。

换句话说，四门语言在这一年里的唯一一次维护，来自一个人的一轮批量同步。

这不是说这个人做得不好，恰恰相反，没有他这四门语言今年一次更新都没有。

但它说明了这一层的供给结构：不是四个语言社区各自在维护，是一个志愿者顺手把上游的新版本搬了过来。

你的技术栈在这四门语言上的能力上限，实际上系在这一个人的空闲时间上。

中间那一档：停在五到十年前

往下一档更常见。

希腊语的词典文件最后一次改动在2015年9月，提交信息里写着更新到0.9版。

十一年过去，版本号还没走到1.0。

希伯来语停在2017年，冰岛语停在2016年，克罗地亚语停在2018年，塞尔维亚语停在2019年。

拉脱维亚语最后一次是2020年，捷克语是2021年，印尼语是2023年。

保加利亚语那一条最像黑色幽默：目录级最后一次提交是2020年1月，改的内容是把一个单词的拼写错误修正过来，而那个被拼错的单词正好是语言这个词本身。

最底下那一档：内容停在2012年，而且那次不是加词

最底下的三门是越南语、爱沙尼亚语和斯瓦希里语。

这三门语言的词典文件，最后一次改动都是2012年10月16日，提交信息写着把词典目录结构往上挪一层。

这是一次仓库重构，不是内容更新。

目录级的最后一次提交要晚八天，2012年10月24日，提交信息是删掉散落的打包配置文件。

保哥把那次提交点开数了一下：它一口气改了47个目录，新增0行，删除0行，删的全是零字节的空文件。

所以严格说，这三门语言的词典内容已经十四年没有任何人加过一个词，而这十四年里，越南的电商市场从零长到了今天这个规模。

把这张表按你的市场清单排一遍，只要二十分钟

这件事的好处是它完全可查，不需要任何工具和权限。

打开那个仓库，找到你要做的语言目录，看文件列表和提交历史。

三个数字就够：词典文件最后改动时间、有没有断词文件、有没有同义词库。

二十分钟能查完十门语言。

查完之后你会得到一张分档表，而这张表能直接改写排期。

停在2012年那一档的语言，别指望站内搜索开箱可用，要么预算里加一笔自建词表的钱，要么把搜索这块功能降级处理。

还有一个值得顺手记下的动作：看提交人这一列有几个不同的名字。

一门语言的提交记录里如果长期只有一个名字，说明它是单人维护，那个人一旦不做了，这一格就会停住，而不会有人来接。

如果有三五个名字轮换，说明背后有个小社区，抗风险能力完全不同。

这一列不需要额外查，翻提交历史的时候顺眼就看到了，但它比任何一个数字都更能预测这门语言未来两年的走向。

词典文件存在，等于这门语言被支持了吗？

越南语那份词典，打开一看根本不是词表

越南语的词典文件第一行写着6631。

这个数字本身就很可疑，因为同一批语言里波兰语是348892条，希腊语是828806条。

保哥把文件头几百行拉出来看了。

前二十几行是ABC、ASCII、GIF、HTML、JPEG、PDF、PNG、RAM、URL这样的缩写。

再往下是a、ai、am、an、ang、anh、ao、au、ba、bai、ban这样的条目。

这不是一份词表，是一份音节表。越南语的正字法把词写成一个个带声调的音节，这份文件收的是合法音节，而不是用户会搜的词。它能判断一串字母是不是越南语的合法音节，但你想用它做词形还原、同义扩展或者品类词识别，一个都做不到。

而它的规则文件里只有变音等价，一条词缀规则都没有

再看配套的规则文件。

整个文件的实质内容是十几条映射声明，作用是把带各种声调符号的元音归为一组。

换句话说，它只做了一件事：告诉系统这几个字母长得不一样但算同一个。

这确实是越南语最需要的一条规则，本站写越南语声调记号那一篇算过，丢了声调等于把词打散。

但一条词缀规则都没有，意味着这门语言在这一层拿到的是最低限度的支持。

对做电商的人来说，结论很直接：越南语站的搜索容错要自己建，别指望这份文件。

土耳其语相反，词条不多但文件有36兆

另一个极端更有意思。

土耳其语的词典第一行写着75909，比波兰语少得多。

可这个文件有36136702字节，也就是36兆，是波兰语那份的将近七倍。

保哥把文件头拉出来才明白怎么回事：每个词根后面挂着上百个规则编号，一行动辄几百字符。

再看规则文件，里面是几万条一次性的后缀规则，每条只生成一个特定的后缀串，长的能到十几个字母。

这是把黏着语的形态硬展开成了一张巨表。本站写土耳其语后缀堆叠那一篇讲的是这门语言怎么把一个词接成另一个词，这份文件就是那件事在工程侧的账单：能用，但代价是三十六兆和一张没人看得懂的规则表。

所以词条数这一列不能横向比

看到这里，词条数这个指标基本可以扔掉了。

希腊语82万条，是因为它把大量形态直接展开成了独立条目。

波兰语34万条配一套精简的规则，实际覆盖的形态远多于条目数。

越南语6631条，因为它收的是音节。

土耳其语7万条却有36兆，因为规则全在词条后面。

四门语言的数字完全没有可比性，把它们放进同一张表按大小排序，得到的排名是无意义的。真正该看的是三件事：规则文件里有没有真正的形态规则、最后改动时间、有没有配套的断词与同义词库。

缺席的那两列，比数字更能说明问题

断词文件这一列，土耳其语、越南语、希伯来语、波斯语、印地语、斯瓦希里语全部空着。

同义词库那一列空得更厉害：法语、捷克语、克罗地亚语、塞尔维亚语、立陶宛语、爱沙尼亚语、希腊语、土耳其语、越南语、希伯来语、波斯语、印地语、斯瓦希里语都没有。

法语出现在这份缺席名单里，很多人会觉得意外。

这恰好说明这一层的成色跟语言的商业价值没有必然关系，它取决于有没有人愿意做这件具体的事。

还有一整类语言连目录都没有：马来语、格鲁吉亚语、阿塞拜疆语、威尔士语在这个仓库里找不到。

要注意的是，这四门语言在别的地方并不算冷门，它们在区域格式数据里全部是最高等级，这个反差正好引出下一节。

为什么格式数据那一层全达标，词典这一层却差了十四年？

先看格式数据那一层的实测数字

公共区域数据里有一份覆盖等级清单，它给每个地区标了三档：完整、中等、基础。

保哥把那份清单拉下来数了一遍：一共174个条目，其中完整档104个，中等档13个，基础档57个。

然后拿前面那27门语言去比对。

结果是全部落在完整档，一个例外都没有。

连仓库里连目录都没有的马来语、格鲁吉亚语、阿塞拜疆语、威尔士语，在这份清单里也是完整档。

马耳他语是少数几个落在基础档的，而它的使用人口只有几十万，这个位置合理。

同一批语言，两层的成色差出一个数量级

把两组数字并排放，反差非常刺眼。

日期怎么写、货币符号放哪边、数字用什么分隔符、星期从哪天开始，这些在104门语言上是完整的、有版本节奏的、有人专职审核的。

而同一批语言里，有三门的拼写词典内容停在2012年。

这两层都是免费的公共资产，都没有人给你任何承诺。

差别在供给结构：格式数据那一层背后是一批科技公司在投人投钱，因为他们自己的操作系统和浏览器要用；词典这一层背后是个人。

一个是被大公司的产品需求拉着走，一个是被某个母语者的业余时间推着走，成色差一个数量级不奇怪，奇怪的是几乎没人意识到它们是两回事。

这条差异直接决定了你该信哪一层

结论很实用。

凡是靠区域格式数据实现的功能，可以放心用默认值：日期格式、数字格式、货币写法、单位偏好、星期起始。

本站写结构化数据里的语言与地区字段那一篇讲过正文本地化而标记走国际格式的分工，靠的就是这一层的可靠。

凡是靠词典和算法实现的功能，都要先查再用：拼写容错、词形还原、同义扩展、断词、自动补全。

这条判据能省掉大量无谓的排查。

爱沙尼亚站那个搜索问题，如果一开始就按这条分类，两周的排查可以压缩到二十分钟。

为什么这一层的问题特别难被发现

还有一个结构性的原因。

这一层的缺失不产生错误，只产生退化。

搜索还能搜，只是召回少了一批；推荐还在推，只是推得平庸；换行还在换，只是断点难看。

监控系统盯的是错误率、响应时间、可用性，这三样一个都不会动。

而人眼的对比基准通常是主语言站，主语言站好用是常态，小语种站不好用会被归因成用户不习惯、市场不成熟、内容还不够多。

本站写过按语言拆开看数据的口径，那条方法在这里同样是唯一的破法：全站平均值永远是正常的，只有把搜索转化率按语言拆开，那个三分之一才会跳出来。

把这一层写进技术选型的验收项

更长远的做法是把它变成一条选型标准。

选站内搜索服务的时候，别只问支持多少种语言。

要问的是：这几门语言各自集成了哪一层能力，词干还原用的是哪一份实现，拼写容错的词库来源是什么，多久更新一次。

供应商答不上来的时候，通常不是保密，是他们自己也没查过。

这一问的价值不在于能问出多少，在于它把一个隐形依赖变成了合同里的一行字。

保哥的经验是，问过这个问题的项目，后面遇到搜索问题时的排查路径会短很多，因为大家一开始就知道下面垫着什么。

站内搜索、拼写纠错、自动补全，各自吃的是哪一份资源？

词干还原：两份清单加起来才是你的真实覆盖

词干还原有两个常见来源。

一个是那套开源的词干算法项目，保哥数了一下它的算法页面，一共37个条目，其中有几个是英语的历史算法变体，实际语言数比这个略少。

另一个是搜索引擎自带的语言分析器，主流那家的内置清单是36个。

两份清单不完全重合，比如保加利亚语和拉脱维亚语在搜索引擎那份里有，在词干算法项目那份里没有。

而越南语、希伯来语、斯洛文尼亚语、斯洛伐克语、乌克兰语、克罗地亚语、冰岛语、斯瓦希里语在两份清单里都找不到。

爱沙尼亚语在两份里都有，所以那个客户的问题不是没有词干器，而是他们的索引模板压根没有为爱沙尼亚语指定分析器，全站用的是默认那一套。这是这一层最常见的实际故障：能力存在，但没人打开它。

分词：只有少数几门语言需要，但缺了就是硬伤

分词跟词干还原完全是两回事。

它只在没有空格的文字里成为问题：泰语、老挝语、高棉语、缅甸语，加上中日韩。

这几门语言的分词依赖的是另一套词典，装在国际化组件里。

本站写泰语没有空格那一篇说过，标题里找不到一个空格，切在哪儿由引擎的词典说了算，站内搜索这一侧的道理完全一样，只不过说了算的换成了你自己集成的那份词典。

这一格的特点是没有中间状态：有分词就基本可用，没有就完全不能用。

好消息是这几门语言的分词词典维护得都不错，泰语那一格去年还在更新。

拼写容错：吃的是词典，所以停更的语言这一格最弱

拼写容错有两种实现。

一种是纯字符距离，跟语言无关，谁都能用，代价是会把不相干的词也拉进来。

另一种是带词典的，先判断这个词形合不合法，再在合法词里找最近的，效果好得多。

后者直接吃那份拼写词典，所以词典停在哪一年，这个功能的知识边界就停在哪一年。

具体表现是新词全军覆没：近几年才出现的品牌名、品类词、技术词，在系统眼里全是拼写错误，于是被纠正成了某个形近的老词。

希腊站那个重音符号少打一个就出不来的毛病，属于同一层：那份词典把带重音和不带重音当成两个词，而它十一年没更新过，用户的实际输入习惯早变了。

自动补全：它的语料通常不是这些文件

自动补全要单独说一句，因为它常被误归到这一层。

自动补全的语料主要来自你自己的查询日志和商品标题，跟公共词典关系不大。

所以它在小语种上的问题往往不是资源缺失，而是冷启动：新市场没有足够的查询量，补全列表空着。

这一格的解法也不同，是拿商品标题和分类名先灌一批种子，等真实查询积累起来再切换。

把它跟前面几格分开，能避免一个常见误判：看到补全不好用就断定这门语言的支持有问题，实际上只是站太新。

断词换行：影响的是版式，但根子在同一层

最后一格是断词。

断词文件缺席的语言，长词在窄屏上要么撑破容器要么被硬切。

浏览器有一个按语言自动断词的能力，它背后用的正是这套断词规则，所以缺了文件这个能力就无效。

前端常见的补救是往词里塞不可见字符，本站算过这个做法的代价：那个字符会进搜索索引，也会被复制走。

更稳的做法是给这几门语言单独调版式，别靠断词兜底。

这一格的判断很简单：查那个仓库里有没有以断词开头的那个文件，两分钟出结果。

哪些能力你能自己补，哪些补不了？

能补的第一类：同义词表

同义词库缺失是最好补的一格。

你不需要覆盖整门语言，只需要覆盖你卖的那几个品类。

做法是从三处捞词：站内搜索日志里的零结果查询、客服工单里的用户原话、竞品页面上的品类词写法。

一个中等规模的品类，两三百行就能明显改善召回。

本站写母语审校验收清单那一篇给过一个顺序，能用规则判定的先跑规则，剩下的交给人，建同义词表这件事正好适用。

成本上，一门语言两天，之后每季度补一次，是保哥见过性价比最高的语言层投入之一。

能补的第二类：形态映射表

词干器缺失也能补，但补的方式不是写算法。

做法是维护一张形态映射表，把品类词的常见变形全部指向同一个词根。

这张表跟同义词表可以合并管理，因为在检索层它们的作用一样。

规模上，一个电商品类通常一两百行够用，别一上来就想覆盖整门语言。

要覆盖的是高频那几十个品类词的形态，不是词典里所有的词。

本站写过好几门语言的格变化和词尾，那些文章里列的形态表，本质上就是这张表的语言学版本。

能补的第三类：停用词与查询清洗

第三类是停用词表和查询清洗规则。

这一格几乎不需要语言学知识，从日志里按频次排序就能得到大半。

要注意的是别照抄英语那套逻辑，有些语言里的高频虚词恰好是品类词的一部分。

清洗规则里最值钱的一条是变音符号的等价处理，用户经常不打记号，两种写法要能互相召回。

本站写德语变音符号那一篇算的就是这笔账，页面侧和检索侧的处理方向是一致的。

这一格的投入通常是半天，收益立刻可见。

补不了的第一类：分词

分词是补不了的。

它需要一份大规模的词典加上一套概率模型，不是几百行表能解决的。

如果你要做的语言在这一格缺席，实际选择只有两个：换一个已经集成了分词的搜索服务，或者接受搜索功能降级。

降级的具体做法是把搜索入口做窄，主推分类导航和筛选器，别让用户依赖搜索框。

这个决定听起来消极，但它比让用户在搜索框里连续失败三次要好得多。

好在需要分词的语言就那么几门，而且它们的分词资源反倒是维护得比较好的。

补不了的第二类：排序规则

字母排序规则也补不了，但好消息是它几乎不缺。

排序规则住在区域格式数据那一层，也就是成色最好的那一层。

本站写过两套字母的排序要配几套，那些差异在标准数据里都已经写好了。

你要做的只是别用二进制排序，把排序交给按语言的排序函数。

这一格的常见故障不是资源缺失，是代码里图省事直接按字节比大小。

那样排出来的结果在带变音符号的语言上全是错的，而它是一个改一行代码就能解决的问题。

决定要不要做一门语言之前的那三十分钟

第一步：查词典那一格的三个数

打开公共词典仓库，找到这门语言的目录。

记三件事：词典文件最后一次改动的年份、有没有断词文件、有没有同义词库。

年份是最重要的一个。

近三年内有实质更新的，这一层可以当作可用；停在五年以上的，按缺失处理；停在十年以上的，直接把搜索容错这块从需求里划掉。

顺手看一眼规则文件有多大、里面是不是真的规则，越南语那种只有映射声明的情况一眼就能认出来。

这一步三分钟一门语言。有个小技巧能省不少事：直接看目录里的文件名列表，以断词二字开头的那个文件在不在，一眼就能确认，不需要点进提交历史。词典文件的体积也顺手记一下，它跟词条数一起看能大致判断这份词典是规则驱动还是硬展开的。

第二步：查算法那一格在不在两份清单里

第二步是查词干还原和分词。

去词干算法项目的算法列表看有没有这门语言，再去你打算用的搜索服务的语言分析器文档里看一遍。

两份都有，最省事。

只有一份有，要确认你的索引模板是否真的指定了它，这一步最容易漏。

两份都没有，就要评估自建形态映射表的成本，或者接受降级。

是不是需要分词，看这门语言写字用不用空格，这一条不需要查。

第三步：查格式那一层的档位

第三步查区域格式数据的覆盖等级。

完整档的语言，日期、数字、货币、排序全部可以放心用默认。

中等档和基础档的语言要多留一个心眼，某些细粒度的格式可能是回退来的。

这一步一分钟就能查完，而且结论通常是好消息。保哥查过的市场里，只有极少数几门语言落在基础档，而它们的共同点是使用人口都在百万以下，跟大多数跨境生意要做的市场没有交集。

值得记住的是它跟第一步的结论经常相反：格式全绿而词典全红，是小语种最典型的画像。

把两张结论并排写进立项文档，比任何一句这门语言支持得还行都有用。

第四步：看这门语言的公共内容体量

最后一步是看这门语言的公共知识体量，最方便的指标是维基百科的条目数和活跃编辑人数。

要看的是两个数一起看，只看条目数会被带偏。

威尔士语有28万多条条目，活跃编辑只有一百多人。

冰岛语6万条，活跃编辑两百多。

马耳他语更极端，条目不到8千，活跃编辑44人。

这个数字的用处不是判断市场大小，是判断你能不能找到本地语料、本地审校和本地外链资源，本站写过按母语人口排优先级会排错的那笔账，这一列正是那套算法里最容易被忽略的输入。

把四步的结论写成一句话结论

四步做完，每门语言可以压成一句话。

词典近三年更新、有词干器、格式完整档，这门语言的技术层可以按英语站的默认预期做。

词典停更但有词干器，搜索能跑，容错要自己补，预算里加两天。

词干器缺席，搜索按降级设计，导航和筛选器要做厚。

需要分词而分词缺席，这门语言的搜索框可以先不做。

这四句话写进立项文档的技术风险那一栏，是保哥这些年见过投入产出比最高的三十分钟。

三个把结论带偏的常见误判

把维基条目数当成语言的活跃度

第一个误判前面提过一次，这里展开。

很多语言版本的维基条目是机器人批量生成的，一个模板套着数据库刷出几十万条地理条目。

威尔士语那个比例就是典型：条目很多，人很少。

这类语言的条目数虚高，但它反映不出有多少人在用这门语言写东西。

更接近真相的指标是活跃编辑数和编辑总数。

本站写过怎么手工估一门语言的内容供给有多稀缺，那套办法比任何单一数字都准，代价是要花一个小时。

把格式数据的完整档当成全套支持

第二个误判更常见，也更贵。

有人查到这门语言在区域数据里是完整档，就下结论说技术栈支持得很好。

这两件事之间没有任何关系。

马来语、格鲁吉亚语、阿塞拜疆语、威尔士语在格式数据里全是完整档，在词典仓库里连目录都没有。

格式数据管的是怎么把一个日期写出来，词典管的是怎么理解一个词，前者不需要语言学知识，后者需要，而且需要持续投入。

把这两层分开问，是这一整篇里最值钱的一个习惯。

把供应商说的支持一百种语言当成能力保证

第三个误判发生在采购环节。

云服务的宣传页上写着支持一百多种语言，这句话通常是真的，但它说的是接口能接受这些语言的文本，不是每门语言都有对应的语言学处理。

真实情况往往是：一小批语言有完整的分析链路，一大批语言走的是通用处理，也就是按空格切、不做词形还原。

判断办法很直接：让对方给出这门语言的分析器配置，或者你自己发一个带词形变化的查询试一下。

本站写生成式搜索的语言覆盖那一篇有一句话，底层模型的语言覆盖远大于产品的语言覆盖，那条判据在这里同样成立。

合同里那一行数字，跟你的搜索框里发生的事，中间隔着好几层。

顺带说一个反向的误判

还有一种反过来的误判，也值得提。

看到词典停在2012年，就断定这门语言不能做。

这个结论跳得太快。

词典停更影响的是搜索容错和推荐质量，不影响收录、不影响排名、不影响内容本身的价值。

越南这些年的电商增长跟那份2012年的词典毫无关系。

正确的用法是把它当成一条预算输入：这门语言的站内体验要多花两天，仅此而已。

这一层的结论不该影响选语言的顺序

再补一句边界。

选哪门语言先做，判据是市场规模、竞争密度、内容复用率和履约能力。

基础设施这一层排不进前四。

它影响的是排期里的工作量估算，不是优先级排序。

保哥见过一个团队因为查到某门语言资源差就把它整个推迟了一年，而那个市场恰好是当年增长最快的。

把一条成本项误当成一条否决项，是这类实测数据最容易被用错的地方。

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

引擎那一侧的能力是另一套账

搜索引擎怎么处理这门语言，跟你的技术栈用什么资源，是完全独立的两件事。

引擎有自己的分词、自己的词库、自己的形态处理，规模比这些公共资源大得多。

所以会出现一种局面：你的站内搜索在这门语言上很笨，而外部引擎把你的页面理解得很好。

这两件事互不影响，也不能互相推断。

本站的桶边界一直是这么划的：引擎那半边归平台与多引擎那一类，这里只算你自己这一侧的账。

模型侧的语言能力也不在这里

生成式检索和大模型在小语种上的表现是另一条线。

那一层的瓶颈是训练语料和检索来源，本站写低资源语言容易出幻觉那一篇算的是那笔账。

它跟这里讨论的词典、词干器、断词文件没有共用的资源。

唯一的交集是心态：两条线都容易让人从一个数字跳到一个过大的结论。

模型支持这门语言不等于答案可靠，词典存在也不等于这门语言被支持，两句话是同一个结构。

字体和渲染是另一层地基

还有一层地基是字体。

字形集不全会导致缺字，本站算过小语种站的字体文件比英文站大多少，那是加载成本的账。

字体跟词典没有任何关系，一个管长什么样，一个管算不算词。

把它们放在同一次排查里，通常会互相干扰判断。

实际操作上建议分两轮查：先查语言处理能力，再查渲染与版式。

两轮的负责人往往也不是同一个人。

翻译质量不在这一层

最后一条界限。

这一层管的是机器怎么处理这门语言，不管你的文案写得好不好。

词典再新也救不了一份直译稿，词典停在十四年前也不妨碍你写出这门语言里最好的品类页。

两件事唯一的连接点在验收环节：拼写检查工具在停更语言上会报出大量假阳性，别让审校被那些红波浪线牵着走。

知道这一点之后，很多团队的语言验收流程会立刻轻松一截。

说到底，这一层是地基，地基决定你能盖多快，不决定你盖成什么样。

常见问题解答

怎么快速判断一门语言的技术支持成色？

查三处，二十分钟能查完十门语言。第一处是公共词典仓库里这门语言的词典文件最后改动年份，近三年内有实质更新算可用，停在十年以上按缺失处理。第二处是词干算法项目和你要用的搜索服务的语言分析器清单，看这门语言在不在里面。第三处是区域格式数据的覆盖等级。三处结论经常不一致，而不一致本身就是最有价值的信息。

词典停在十几年前，这门语言还值得做吗？

值得，这是一条成本项不是否决项。词典停更影响的是站内搜索的容错、拼写纠错和相关推荐，不影响收录、排名和内容本身的价值。正确的做法是在排期里加上自建同义词表和形态映射表的两天工时，把搜索入口做窄一点，导航和筛选器做厚一点。因为资源差就把一个增长中的市场推迟一年，是把成本误当成否决。

站内搜索在某门语言上召回很差，第一步该查什么？

先查索引模板有没有为这门语言指定语言分析器。实际故障里最常见的一种是能力存在但没人打开，全站用的是默认的通用分析器，按空格切词、不做任何词形还原。这一步排除之后，再去查这门语言有没有对应的词干器，最后才怀疑词典本身。倒过来查会浪费很多时间。

同义词表和形态映射表，规模要做多大？

按品类做，不按语言做。一个中等规模的电商品类，两三百行通常就能明显改善召回，覆盖的是高频那几十个品类词的常见变形和说法，不是整门语言。词源可以从三处捞：站内搜索的零结果查询、客服工单里的用户原话、竞品页面上的品类词写法。之后每季度补一次即可。

供应商说支持一百多种语言，这句话可信吗？

字面上通常是真的，但它说的是接口能接受这些语言的文本，不等于每门语言都有专门的语言学处理。可行的验证办法有两个：让对方给出这门语言的分析器配置，或者自己发一个带词形变化的查询试试召回。真实情况往往是一小批语言有完整链路，其余走通用处理。

这一层的问题为什么监控发现不了？

因为它产生的是退化不是错误。搜索还能搜，只是少召回一批；推荐还在推，只是推得平庸；换行还在换，只是断点难看。错误率、响应时间、可用性这三个指标一个都不会动。唯一能让它显形的办法是把关键指标按语言拆开看，全站平均值永远正常，因为流量集中在主语言上。

需要分词的语言如果没有分词资源，还能做站内搜索吗？

能做，但要按降级设计。具体是把搜索入口做窄，主推分类导航和多级筛选器，让用户少依赖搜索框，同时把商品标题里的关键属性拆成独立字段以便精确匹配。好消息是需要分词的语言就那么几门，而且这几门的分词词典维护得反倒不错，真正缺席的情况很少见。

权威参考资料