孟加拉语的关键词表按一门语言建，交付那天才发现国界两边根本不是一套词

摘要：孟加拉语有2.7亿母语者，可它最大的市场不在印度。保哥把国界两边的18个新闻站抓了81万个孟加拉文字符实测，发现一件反直觉的事：词汇分叉是单向的。西孟加拉那边水这个概念几乎只用一个词，比例11比1；孟加拉国那边两个词都在用，几乎五五开。按对称分叉的思路建词表，两边会同时漏掉一半。

一门语言两个国家，为什么第一步不是找译者而是先划国界？

一家做家用净水设备的站，孟加拉国那边的自然流量一直起不来

有个客户做家用水处理，主力品类是台上式净水器、滤芯、储水桶和管路配件。

他们先做的是印度市场，英语版加印地语版，跑了将近两年，数据能看。

第三步团队决定加孟加拉语，理由听上去无懈可击：印度东部本来就有存量流量，孟加拉国还有一个1.7亿人口的邻国，一套内容两边都能用。

译者是从加尔各答找的，母语者，做过本地化，交付质量挑不出毛病。

上线半年，印度西孟加拉邦那一侧的自然流量涨得很正常，孟加拉国那一侧几乎是平的。

团队第一反应是物流和支付没打通，查了三个月的转化漏斗，最后发现漏斗上面根本没人进来。

问题不在译文质量，在一个谁都没想到要问的问题

保哥看这个案子的时候先问了一句：这套词表是给哪一边写的。

团队愣了一下，说是给孟加拉语写的。

这个回答本身就是答案。孟加拉语不是一个市场，它是被一条1948年画下来、1971年又重画了一次的国界劈成两半的一门语言。

孟加拉国1.7亿人，印度西孟加拉邦加上特里普拉邦接近1亿人，两边说的确实是同一门语言，同一套文字，字体文件完全共用。

但用户在搜索框里打进去的那个词，两边不一定是同一个。

这跟西班牙语在西班牙和拉美的分叉、葡萄牙语在巴西和葡萄牙的分叉是同一类问题，只是孟加拉语这一门几乎没人拿中文写过，多数团队做到这一步才第一次听说。

本站以前写过孟加拉语，但写的是另外半件事

本站讲印度十一门语言分摊在九套书写系统上那一篇里，孟加拉语出现过，但它是作为一个成本单位出现的：孟加拉文这个Unicode区块里装着孟加拉语和阿萨姆语两门语言，字体可以共用，词表不能共用。

那一篇的坐标系是印度国内的预算排期，孟加拉语在里面排第几、边际成本几成。

这一篇要处理的是那个坐标系装不下的部分：这门语言最大的那半个市场根本不在印度境内，而印度境内的排期表里没有一格是留给它的。

换句话说，上一篇算的是把孟加拉语加进印度站要花多少钱，这一篇算的是加进去之后那套词表能覆盖多少人。

这一层为什么归语言层管，而不是归国际化架构管

先把边界划清楚，免得后面越说越乱。

域名怎么分、hreflang怎么写、要不要按bn-BD和bn-IN分成两套页面，这些是架构层的事，跟孟加拉语这三个字没关系，换成任何一门跨国语言都成立。

本篇要处理的是把语种换成英语就不存在的那一半：同一个概念在国界两边被写成两个不同的词，而这两个词在字符层没有任何交集。

这个差别很要紧。架构做对了，用户还是搜不到你，因为他打的那个词你页面上一次都没出现。

三种常见的做法，各自会在哪一步塌掉

第一种是只做一套，找一个母语译者，交付什么用什么。

塌在译者身上——他一定属于某一边，写出来的自然是那一边的说法，而他不会觉得自己做了任何选择。

第二种是做两套页面，但共用一份关键词表。

塌在词表上——页面拆了，词没拆，等于花了两倍的钱买同一批流量。

第三种是查工具，看哪个词量大用哪个。

塌在工具上——这一点后面第五节会用实测数据说明，孟加拉语的工具口径里压根没有把两个国家分开的入口。

顺带说一句这门语言的体量

孟加拉语的母语人口排在世界第六到第七位，跟俄语在同一个量级，比德语和法语都多。

但在中文的出海资料里，它出现的频率大概跟冰岛语差不多。这个反差本身就是机会的形状：需求在那儿，写的人不在那儿。

孟加拉国那一侧的电商还在爬坡期，客单价低、货到付款占比高，这些都是真实的门槛。可门槛低的市场从来不缺人，门槛高又没人写的市场才是那种做进去就很难被追上的地方。

把国界两边的报纸抓了81万字，只有一对词给出了干净的答案

实验是怎么设计的

要证明分叉存在，得先有语料。孟加拉语没有现成的分国别商业语料库，所以保哥用了最笨的办法：抓新闻站。

孟加拉国那一侧选了9个站，印度西孟加拉那一侧也选了9个站，都是各自市场里日更的主流媒体。

每个站抓首页，再顺着首页链接抓至多14个内页，把正文剥出来合并成两份语料。

最后拿到的规模是孟加拉国侧326003个孟加拉文字符，西孟加拉侧486380个，合计81万出头。

然后挑了8组词对，每一组是同一个概念在两边的两种常见说法，分别数它们在两份语料里出现多少次，再按语料大小归一化成每十万个孟加拉文字符出现几次。

先看那一组给出干净答案的词

水这个概念，孟加拉国惯用一个源自波斯语的词，西孟加拉惯用一个源自梵语的词。

实测结果是这样的：

频率单位是每十万个孟加拉文字符出现的次数。

横着看，পানি 在孟加拉国侧的密度是西孟加拉侧的3.9倍，জল 在西孟加拉侧是孟加拉国侧的2.8倍。方向完全符合预期。

竖着看才是这个实验真正的收获，下一节专门讲。

再看那一组把预设打回去的词

消息这个概念也有两个常见词，一个偏口语一个偏书面。做这个实验之前保哥的预设是它也会分叉。

结果是两边都是同一个词占绝对上风：孟加拉国侧55.8对15.0，西孟加拉侧108.1对21.8。

两个市场给出的答案不但一致，连比例都接近，一个是3.7比1，一个是5比1。

这条反例的价值比那条正例还高。它说明分叉不是一门语言的整体属性，而是逐词发生的。

凭感觉列一张两边不同的词表，你会把一批根本不分叉的词也拆成两份，然后为不存在的差异付两倍的内容成本。

还有六组词，一次都没出现

洗澡、邀请、肉、鞋这几组，在81万字符里几乎全是零。

洗澡那一对，孟加拉国侧出现3次，西孟加拉侧0次；鞋那一对两边都是0；肉那一对两边各1次。

这个数字不能读成两边都不用这些词。它只能读成一件事：新闻不谈鞋，也不谈洗澡。

保哥这次踩的坑值得写下来——语料选错了。新闻语料能测出的是时政、天气、体育里的高频词，测不出商品品类词，因为报纸根本不写那些东西。

换句话说，这不是两边都不用，这是尺子不够长。第四节会讲这种情况下还能怎么办。

为什么不直接用电商站的语料

这是最先想到的办法，也是最先撞墙的办法。

孟加拉国那一侧的主流电商平台和生鲜平台，商品列表基本是前端脚本渲染出来的，抓回来的页面里孟加拉文字符只有个位数。

本站讲屏幕上是好好的泰语、机器复制走的是另一串字符那一篇讲过一个类似的结构：人眼能读到的东西不等于程序能取到的东西。这次是同一个结构换了个位置，人眼在浏览器里看得见整页商品名，程序拿到的是一个空壳。

所以本篇的品类词那一半是靠另外两个实验补的：搜索建议接口，以及字符层的实测。它们分别在第五节和第六节。

分叉为什么是单向的，这件事对选词意味着什么？

把那张表竖着读一遍

上一节那张表横着读是符合预期的，竖着读就不是了。

在西孟加拉那份语料里，জল 是35.2，পানি 是3.1，比例11.4比1。这一侧基本只用一个词。

在孟加拉国那份语料里，পানি 是12.0，জল 是12.6，比例0.95比1。这一侧两个词都在用，而且用得几乎一样多。

也就是说，这条分叉线只有一半是硬的。

硬的那一半和软的那一半，落地方式完全不同

硬的那一半是西孟加拉侧。在那边写孟加拉国那个词，等于把词写在了一个几乎没人搜的位置上，密度低到3.1，而且那15次里有相当一部分是在引用孟加拉国的新闻。

软的那一半是孟加拉国侧。在那边只写本地那个词，你会漏掉将近一半的表达面，因为另一个词在那边同样活跃。

所以两个市场的动作是不对称的：西孟加拉侧要做的是替换，孟加拉国侧要做的是并列覆盖。

如果按对称分叉的思路做，两边各写一个词，结果是西孟加拉侧对了，孟加拉国侧漏了一半。

这个不对称是怎么来的

成因不在语法里，在两边的语言规范化路径不一样。

西孟加拉那一侧的书面语标准形成得早，参照系是加尔各答的文学传统，梵语来源的词被系统性地留了下来。

孟加拉国那一侧在建国之后经历了一轮独立的语言规范建设，波斯语和阿拉伯语来源的日常词被写进了标准，但原有的那一批并没有被赶走。

一边是筛选过的，一边是叠加过的。筛选产生排他，叠加产生并存。

这条规律不止孟加拉语适用。凡是两个市场里有一边做过一次自上而下的规范化、另一边是自然沉淀的，多半都会出现这种一边硬一边软的形态。

验证的时候要小心一个陷阱

用词频判断分叉有一个天然的坑：你数到的那个词可能根本不是在讲那个概念。

孟加拉语里 জল 除了水本身，还进了不少复合词和固定表达，比如一种橄榄类水果的名字前两个字符就是它。保哥在核对的时候把这类命中挑出来单看过，比例不算高，但它确实在把数字往上抬。

比较稳妥的做法是把词频当方向指标，不当绝对值。方向对了就足够做决策，精确到小数点后一位没有意义。

这一点跟本站讲同一门语言在两个市场的意图漂移那一篇的口径是一致的：分叉率算出来是用来排优先级的，不是用来做四舍五入的。

那些一次都没出现的词，是两边都不用还是我的尺子不够长？

先承认这是一次测量失败

81万字符听上去不少，可放到词频统计里它其实很小。

一个词如果在真实语言里的密度是每十万字符0.5次，在这份语料里的期望出现次数是4次左右，方差大到没法做判断。

而商品品类词的密度普遍就在这个量级甚至更低。鞋、水壶、床单这类词在报纸上一天出现不了一次。

所以那六组零命中不是结论，是一次没测出来。把它写成两边都不用这些词，就是拿测量工具的局限当发现。

换尺子的第一个办法：改用搜索建议做代理

词频测不出来的东西，搜索建议接口能测出一部分，因为那个接口背后是真实查询日志。

做法很简单，把候选词丢给搜索建议接口，看它返回什么，返回几条，返回的长尾里带的是哪些修饰词。

返回的条数本身就是信号。一个词如果连建议都拉不出来，说明真实查询量低到没进候选池。

这套办法本站讲关键词工具在小语种里返回零那一篇里完整写过，这里只是把它用在一个具体语种上。第五节会给出实测结果，那个结果里有一个意外。

换尺子的第二个办法：找一份说人话的语料

新闻语料的问题是题材偏。要测品类词，得找题材本身就是商品的语料。

可选的有三类：本地分类信息站的商品标题、本地论坛的求购帖、以及本地零售商的印刷宣传单。

第三类最容易被忽略，也最好用。宣传单上的品类词是给本地人看的，写法一定是本地最通用的那个，而且它经常以图片形式发布，反而躲开了前端渲染的问题——代价是得先做一次文字识别。

这三类语料的共同点是它们都不在关键词工具里，得自己去攒。攒的过程本身就是这门语言的进入成本，本站讲按母语人口排小语种优先级会排反那一篇算的就是这笔账。

换尺子的第三个办法：把判断权交出去，但要问对问题

找母语者问是最快的，前提是问法得改。

问这个词你们那边说不说，得到的答案永远是说的，因为母语者对被动认得的词和主动会用的词分不清。

要问的是：你去店里买这个东西，开口第一句话怎么说。

还要追加一句：如果你在手机上打字搜这个东西，会不会打得跟说的不一样。

这两个问题分别对应口语形态和查询形态，它们经常不是一回事。本站讲母语审校说读着自然不能当验收通过那一篇里的核心判据也是这个：把主观评价换成可观察的行为描述。

什么时候该停手

不是每个词都值得这么折腾。

保哥的判据是看这个词在不在页面的承重位置上。品类名、筛选项、标题里的核心名词，值得单独验；正文里的修饰词，跟着译者走就行。

一个站真正需要逐词确认的词，通常在40到80个之间，两天能问完。超过这个数量说明你在验的不是词表，是译文。

关键词工具那一侧，有没有把两个市场分开的入口？

这个实验的结果超出预期

保哥拿4组词、8个查询词，分别按孟加拉国和印度两个国家参数请求了一次搜索建议接口，想看看同一个词在两个国家会不会给出不同的建议。

结果是8组里有6组返回的建议列表完全相同，连顺序都一样。

只有洗澡和肉那两组出现了差异，而且差异也只是前几条的排序不同，词本身重合度很高。

这意味着什么

意味着在这个数据源上，孟加拉语这门语言没有被按国家切开。

你把国家参数从孟加拉国改成印度，返回的还是同一份候选池。

换个说法：工具告诉你的孟加拉语搜索量，是两个国家加在一起的那个数，而且你没有拆开它的入口。

这跟西班牙语、葡萄牙语那种情况差得很远。那两门语言至少能按国家拿到不同的数据，剩下的问题是数据准不准。孟加拉语这里是连接口都不给你。

为什么会这样，以及这个判断的边界

合理的解释是候选池的切分粒度跟着语言走，而不是跟着语言和地区的组合走。对英语、西班牙语这种有大量地区变体商业需求的语言，切分做得细；对孟加拉语这种量级的语言，切分停在语言这一层。

这个推测保哥没法证实，只能观察到现象。所以下结论的时候要收着说：不是搜索引擎不区分两个市场，而是这个特定的建议接口在这门语言上不区分。

排名结果那一侧完全可能是区分的，那是另一套系统。官方关于多地区多语言站点的说明里讲的也是索引与展示这一侧的机制，跟建议接口不是同一条链路。

那这份合并数据还能不能用

能用，但只能用来做一件事：判断一个概念整体有没有需求。

不能用来做的事有三件。

第一，不能用它比较两个词的优劣，因为两个市场的偏好被平均掉了，平均之后那个占优的词很可能只在人口多的那一边占优。

第二，不能用它估单个市场的流量盘子，误差方向不确定。

第三，不能用它做词表取舍，尤其是二选一的取舍——上一节那个不对称结论说明，正确答案在有些市场根本不是二选一。

接着往下挖，挖出了一件比合并数据更要紧的事

既然接口不按国家分，保哥换了个问法：不比国家，比词。同一个概念的两个词，各自拉出来的长尾是不是同一批意图。

做法是给每个词分别加三种商业修饰词——价格、购买、在线，看返回条数和返回内容。

鞋这一组的结果最干净，干净到有点吓人。

裸词那一行两个词打平，看上去平分秋色。

往下两行就散架了。জুতা 加上价格能拉出10条完整的商业长尾，鞋码、鞋架、男鞋女鞋、在线订鞋、想在线买鞋，全是要掏钱的人打的字。

জুতো 加上价格只剩2条，而这2条返回的建议词里用的居然是另一个词形——接口自己把 জুতো 换回了 জুতা。加在线那一条同理。

这说明日常口语和商业查询走的不是同一条分叉线

জুতো 在西孟加拉的书面语和口语里都很常见，裸词的建议列表也证明了这一点：图片、词义、俗语、修鞋的叫什么，一应俱全。

可一旦查询里出现了买东西的意图，这个词形就基本消失了。真正在商业查询里活动的只有一个词形。

水那一组是另一种形态。পানি 拉出来的是净水器滤芯、水箱价格、水瓶、水龙头，一水儿的商品。জল 拉出来的是橄榄、狂犬病、水彩颜料、玫瑰水、净水咒语，一个净水设备都没有。

而这两个词在同一批新闻语料里的频率是接近的。也就是说，词频告诉你的是这门语言的表达面，搜索建议告诉你的是这门语言的钱在哪，这两张地图不重合。

还有一组的方向是反的

肉这一组，孟加拉国惯用的那个词加上价格只拉出1条，而且那一条问的是切肉机多少钱。西孟加拉惯用的那个词加上价格拉出10条，牛肉羊肉鸡肉水牛肉的价格全在里面。

方向跟鞋那一组正好相反。这条反例把一个偷懒的结论掐死了：不能得出孟加拉国那一侧的词形在商业查询里更强这种规律。

规律只有一条，而且是逐词的：每个概念在商业查询里都有一个主词形，它未必是这一侧口语里最常用的那个。要用哪一个，得逐词问一遍搜索建议接口，一个概念两分钟。

这条发现该怎么落地

词表要多记一列，叫商业词形。它跟市场归属那一列是独立的两件事。

页面上的分工也跟着变：标题、面包屑、结构化数据这些冲着交易查询去的位置，用商业词形；正文、常见问题、评价区这些冲着阅读体验去的位置，用当地口语词形。

本站讲两个市场的关键词表可以一字不差、落地页却得拆成两种那一篇讲的是意图在语言里编码的位置，孟加拉语这里给出的是同一件事的一个极端样本：意图不但改变落地页，它先改变了词形本身。

那正确的数据源在哪

在你自己站上。

站内搜索日志按国家分开看，是这门语言上唯一能拿到真实分国别查询形态的地方，而且它一分钱不要。

如果站还没上线，退而求其次的办法是先上一个能覆盖两种写法的版本，跑三个月，用真实日志替代工具数据。这个做法的代价是前三个月的词表是猜的，收益是从第四个月起你有了别人拿不到的数据。

一个孟加拉语的词到底算几个字符？

先看一个例子

孟加拉语里健康与美妆这个品类名，屏幕上看是8个视觉字符。

放进程序里量，它是20个码位、60个字节。

如果你的字段限制写的是20个字符，那么这个品类名恰好把额度用光，一个字都加不进去；而同样20个字符的额度，英语能写下twenty characters这样一个短语再加几个空格。

这不是极端例子。保哥把20个真实品类词全量量了一遍，下面是结果。

五把尺子量同一批词

字素簇就是人眼看到的那个字。孟加拉语里一个视觉字符平均占5.15个字节、1.79个码位。

换算成字段额度是这样的：一个限100字节的字段，孟加拉语实际能写19.4个视觉字符；如果那个字段限的是100个码位，能写55.7个。同一个100，两种口径差了将近3倍。

本站讲平台给每个卖家的搜索词字段一样长那一篇算的是字节这一层的账，孟加拉语在字节之上还多出一层：码位和视觉字符之间还差1.79倍。两层乘起来，同样的额度英语写一句话，孟加拉语写不下半句。

最后那一行才是真正会咬人的

前四行都是标准算法，差异是可预期的。第五行不是。

手写的组合字符分组，指的是很多截断函数里那段自己写的逻辑：遍历字符串，遇到组合类字符就并到前一个字符上，其余都当独立字符。这段逻辑写起来只要五行，看上去也很像那么回事。

它错在不认识那个叫做维拉马的止音符号。孟加拉语用它把两个辅音粘成一个合体字，粘完之后是一个视觉字符，可维拉马本身不是组合类字符，于是这段逻辑会把一个字数成两个甚至三个。

实测结果是：20个词，20个都不一致，一致率0。手写分组一共多数出83个字符，虚高61%。

虚高的后果不是崩溃，是静默截短。你以为还剩5个字符的额度，实际上早就满了，后台不报错，页面上少半个词。

同一份字节，换个库就换个数

更麻烦的是标准这一侧本身也在动。

Unicode从15.1版起改了文本分段的规则，把维拉马后面的那个辅音算进同一个字素簇，孟加拉文、天城文、古吉拉特文都在这次改动的范围里。

这意味着同一个合体字，跑在实现新规则的库上算1个字素簇，跑在实现旧规则的库上算2个。保哥本机这次用的库跑的是Unicode 16的规则，所以上面那张表里的136是新规则下的数。

如果你的前端用浏览器的分段接口计数、后端用一个几年没更新的库计数，两边给出的字数会不一样，而且不一样的地方全在合体字上——也就是全在孟加拉语最常用的那批词上。

这个结构跟本站讲前端往标题里塞了个看不见的字符那一篇很像：单独看每一层都合规，合起来结果对不上。

横向对照一下，孟加拉语在几种文字里排第几

光看倍数不够直观，换成同一句话来量。把厨房用具这个品类名写成六种语言，各自量三次。

孟加拉语这一行值得盯一会儿：字节是英语的2.9倍，视觉字符反而比英语少44%。

换句话说，同样一句话，它在传输和存储上贵将近三倍，在屏幕上占的位置却不到英语的六成。

日语那一行是另一个极端，字节跟英语打平，视觉字符只有三分之一，所以日语站几乎从来不会因为字段额度出事。

这张表可以当成一份粗略的风险排序：字节列越大、视觉字符列越小的语言，越容易在字段额度上翻车，而团队越不容易发现，因为屏幕上看着还很空。

该用哪一把尺子

按用途分，别想着统一。

• 数据库字段长度、平台额度、传输限制：用字节。这一层的限制本来就是按字节定的，换算成字符只会自己骗自己。
• 给用户看的字数提示、编辑器里的剩余字数：用字素簇。用户数的是眼睛看到的字。
• 截断：用字素簇，而且必须用标准算法，不能自己写。
• 去重、比对、排序键：用规范化之后的码位序列。

四种用途四把尺子，听起来很啰嗦，可孟加拉语这门语言把它们之间的差距放大到了5倍，糊弄不过去。

为什么按首字母排的索引和前缀匹配，有一半会排错？

这门文字里有几个元音符号写在辅音左边

孟加拉文属于元音附标文字，元音符号挂在辅音周围。大部分挂在右边或上下，有三个挂在左边。

挂在左边这件事，麻烦不在于它挂在哪儿，在于它在字节里的位置和它在屏幕上的位置是反的。

按照Unicode的规定，存储顺序是逻辑顺序：先写辅音，再写元音符号。渲染引擎负责把那个元音符号搬到辅音左边去显示。

所以一个词的第一个码位，和它在屏幕上最左边那个符号，可能不是同一个东西。

实测：15个常见品类词里有8个是反的

保哥拿15个常见品类词做了一遍对照，结果是8个词的视觉首字符不等于码位首字符，占53.3%。

蛋糕、桌子、玩具、水壶、椅子、腰带、线缆、床，这几个词都在里面。它们的共同点是第二个码位是那三个左置元音符号之一。

另外7个词是一致的，比如手机、衬衫、冰箱、电脑。

五五开这个比例很讨厌。全错反而好办，一半错最难查，因为你随手抽查两个词很可能都是对的那一半。

这会在哪几个地方结算

第一是字母索引。做一个A到Z那样的首字母导航，如果你取的是第一个码位，得到的结果是对的；如果哪一层代码取的是渲染后的第一个可见字符，得到的结果就把一半的词归错了组。

第二是前缀匹配。用户在站内搜索框里打前两个字符，输入法送出来的是逻辑顺序，你的匹配逻辑如果按视觉顺序切过，就永远对不上。

第三是自动补全的高亮。补全列表里给命中部分加粗，加粗范围按码位算，视觉上会出现一个词从中间被劈开、加粗跑到了左边那个符号上的效果。这跟本站讲德语页面上加粗的那个词是个介词那一篇是同一类现象的另一种成因，那边是翻译移位，这边是渲染移位。

第四是排序。这一层反而不容易错，因为排序规则本来就工作在码位序列上，只要没人手工干预就是对的。

怎么自己测一遍

不需要懂孟加拉语，十分钟能做完。

找20个你站上的孟加拉语品类词，一列一列做四件事：打印每个词的码位序列，看第二个码位是不是那三个左置元音符号之一；在浏览器里把这个词放进一个盒子里，看最左边显示的是什么；对比两者；数不一致的比例。

如果不一致比例接近一半，说明你抽到的是正常样本，可以往下走。如果远低于一半，多半是你挑的词偏了，重挑。

这个测法的好处是它完全不依赖语言知识，只依赖码位表。本站讲转成小写这一步在土耳其语站上把词改成了另一个词那一篇里的自检思路是一样的：不懂那门语言，就退到字符层去验。

这门语言的词表该按什么结构建？

比常规词表多三列

孟加拉语的关键词表，在词、量、意图这三列之外，还需要三列。

第一列是市场归属，取值是三个：只在孟加拉国用、只在西孟加拉用、两边通用。注意这一列不是二值的，通用那一档在这门语言里占比不低。

第二列是硬软标记，记这个词在对面那个市场是完全不用还是也在用。前面那个不对称结论决定了这一列的存在——同样是分叉词，处理动作不一样。

第三列是视觉首字符，专门给索引和前缀匹配用，避免每次都重算。

建表的顺序

第一步，从站上现有的品类树里把承重词捞出来，通常40到80个。

第二步，每个词过一遍搜索建议接口，记返回条数和长尾修饰词。返回零的先不删，标记为待验。

第三步，把待验的那批交给两位母语者，一位来自孟加拉国，一位来自西孟加拉，按上一节那两个问法分别问一遍。

第四步，填市场归属和硬软标记两列。凡是两位给出的答案不同的，就是分叉词。

第五步，字符层过一遍，填视觉首字符，同时用标准算法算出字素簇数，跟各个字段的额度对一遍。

词表填完之后，页面上怎么摆

西孟加拉侧的页面：分叉词只写本地那个，另一个连同义词表都不用配，因为那一侧的用户不用它。

孟加拉国侧的页面：分叉词两个都要出现，但位置分开。标题和面包屑用本地那个，正文和常见问题区里让另一个自然出现一到两次。

通用词：两边一样，不做任何处理。这一档是最大的一档，别去动它。

站内搜索的同义词表：两边都要把两个词互相映射上，因为搜索框里什么都可能出现。这一层是纯收益，成本几乎为零。

内链的锚文本要不要跟着分

要，但不是分两套锚，是分两套目标页。

孟加拉语没有格变化，锚文本不会像波兰语匈牙利语那样长出十几种形态，本站讲屈折语站的锚文本报告里精确匹配那一栏是假的那一篇里的麻烦在这门语言上小得多。

真正要注意的是别让两个市场的页面互相内链到对方的分叉词上。这不是权重问题，是用户点进去看到一个不熟悉的说法，信任会掉一格。

上线之前，哪几项检查能自己跑完？

字符层的四项，不懂孟加拉语也能做

第一项，拿站上所有孟加拉语的标题和品类名，用标准分段算法算一遍字素簇数，跟各个字段的额度对一遍。凡是字素簇数乘以5.15超过字节额度的，标出来。

第二项，全站搜一遍自己写的截断函数。凡是按码位或者按组合字符分组截的，全部换成标准分段算法。这一步通常能翻出三到五处。

第三项，把品类词的第二个码位打印出来，标出那三个左置元音符号，看首字母索引和前缀匹配的实现取的是哪一个位置。

第四项，检查一遍规范化。孟加拉文里有两个字符可以用组合形式也可以用预组合形式写出来，入库前统一规范化，否则站内搜索会出现搜得到看不到的现象。

词表层的三项，需要两位母语者

第五项，承重词逐个过市场归属，两位母语者答案不同的就是分叉词。

第六项，分叉词逐个填硬软标记，确认对面市场到底是完全不用还是也在用。这一列填错的代价，前面第三节算过。

第七项，站内搜索同义词表把所有分叉词双向映射一遍。

数据层的两项，最容易被跳过

第八项，结构化数据里的语言标签写清楚。孟加拉文只有一套书写系统，所以书写系统子标签可以省，但地区子标签不能省——bn-BD和bn-IN是两个不同的目标。本站讲正文越本地化越好而结构化数据里要反着写回国际格式那一篇里的三分法在这里照样成立。

第九项，商品数据源按市场拆成两份，别指望一份数据同时喂两个市场。属性值那一列尤其要拆，因为品类词就藏在属性值里。

开头那家净水站后来改了三处

第一处是把品类词按市场归属重排了一遍。他们那套词表是加尔各答译者写的，水这个概念全站只有梵语来源那一个词形，孟加拉国那一侧等于把一半的表达面留在了门外。改法不是替换，是在孟加拉国版的正文和常见问题区里把另一个词形补进去，标题不动。

第二处是把标题里的品类词换成了商业词形。这一处是照搜索建议接口逐词问出来的，滤芯、水箱、水龙头这三个承重词各花了两分钟。

第三处最不起眼，是把商品标题的截断函数换了。原来那段是遍历字符遇到组合符号就往前并，换成标准分段之后，商品列表页上被切掉半个字的品类名少了一批。这一处没带来流量，带来的是客服那边再没收到过看不懂商品名的反馈。

三处改动里前两处属于选词，第三处属于字符层。团队原本只打算做前两处，第三处是做字符层自检的时候顺手捞出来的——这也是保哥一直建议把字符层那四项排在词表层前面的原因：它不需要任何语言知识，一个下午能跑完，而且经常能捞到别的收获。

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

域名怎么分、hreflang怎么配、要不要按地区做跳转，这三件事跟孟加拉语没关系，属于国际化架构层，换成任何一门跨国语言都是同一套做法。

孟加拉文字体的体积、首屏加载被字体拖住多少，归字体那一层，本站算过非拉丁文字的字形集有多大。

孟加拉国和印度两个市场在支付、物流、税这几件事上的差别，比语言层的差别大得多，但它不是语言问题，别混在同一张表里管。

孟加拉语的问答式长尾该不该做，判据在本站讲小语种问答长尾的供给密度那一篇里，跟本篇的分叉问题是两条独立的账。

三种看着合理、实际在帮倒忙的做法

第一种：把两个词都塞进同一个标题

既然孟加拉国那边两个词都用，那就在标题里都写一遍，看起来很划算。

问题是标题的长度在这门语言上本来就紧张。前面算过，字段限100字节只能写19.4个视觉字符，塞两个同义词进去，留给真正区分度的部分就没剩多少了。

正确的做法是分层：标题写一个，正文和常见问题区里让另一个自然出现。这样两个词都在页面上，但只有一个占用最贵的那块地。

第二种：为两个市场各建一套完整内容

这个做法的问题不是浪费，是浪费得没道理。

本篇实测的8组词里，只有1组给出干净分叉，1组明确不分叉，6组测不出。就算把测不出的那6组全算成分叉，分叉词在整个词表里的占比也远达不到需要两套内容的程度。

本站讲捷克语和斯洛伐克语哪些内容能原样照搬那一篇里的三档判据在这里可以直接套用：能整块照搬的、改词就能过的、必须重写的。孟加拉语两个市场之间的绝大部分内容落在第二档。

做成两套的代价还不只是钱。两套内容之后就有两套更新节奏，半年之后它们会自己漂开，而没有人负责对齐。

第三种：用机器翻译在两个变体之间转换

这个想法很自然：既然是同一门语言，找个工具把孟加拉国版转成西孟加拉版不就行了。

不行，因为机器翻译系统眼里这两边是同一门语言，输入什么输出什么，它不会替你换词。

真要自动化，可行的是一张词对映射表加一次替换，而不是一次翻译。表就是第八节那张，替换只对分叉词生效，通用词一个都不能碰——碰了就是把好好的文章改出翻译腔。

还有一个反面提醒：别把这套方法当通用模板

不对称分叉这个结论是从孟加拉语这一门语言上测出来的，成因是两边规范化路径不同。

换一门语言，方向可能是反的，也可能两边都是硬的。本站讲荷兰语在荷兰和比利时的两个市场那一篇里的形态就跟这里不一样。

要搬的是方法：抓两边的真实语料、按词逐个数、把结果按硬软分档。别搬结论。

常见问题解答

孟加拉语只做一个市场的话，该选哪一边？

看品类。如果卖的是价格敏感的日用消费品，孟加拉国那一侧人口更多、电商渗透还在爬坡，长期盘子更大；如果卖的是客单价较高、依赖支付和物流成熟度的品类，印度西孟加拉那一侧基础设施更好。另外还有一条容易被忽略的：西孟加拉那一侧的用户里，用英语搜索的比例明显更高，这会把孟加拉语内容的实际覆盖面往下压。先看这三个变量，再决定。

两边共用一套页面，只把分叉词做成同义词，可行吗？

技术上可行，效果打折。同义词只在站内搜索那一层有用，它不改变页面上真正出现的那个词，而搜索引擎匹配的是页面上出现的词。可行的折中是共用一套页面骨架，只把标题、品类名和常见问题区这三处按市场生成两个版本，其余共用。改动量比想象的小，因为分叉词集中在这三处。

词频实测那八组里六组是零，是不是说明这套方法不管用？

说明的是语料选错了，不是方法不管用。新闻语料的题材决定了它测不出商品品类词，报纸不写鞋和水壶。方法本身没问题，换成分类信息站的商品标题或者本地零售商的宣传单，同一套数法照样能跑。测量失败的时候先怀疑尺子，别急着改结论。

为什么不能直接信关键词工具给的孟加拉语搜索量？

因为在这门语言上，工具那一侧没有把两个国家分开的入口。实测8组查询词，切换国家参数之后有6组返回的建议完全相同。这意味着你看到的那个量是两国合并值，而两国的用词偏好不一样，合并之后占优的那个词很可能只在人口多的一边占优。这个数只能用来判断一个概念整体有没有需求，不能用来在两个词之间做取舍。

字段长度到底该按字节算还是按字符算？

按用途分开算，别求统一。数据库字段、平台额度、传输限制这三处按字节，因为它们的限制本来就是字节；给用户看的剩余字数和做截断按字素簇，因为用户数的是眼睛看到的字；去重和排序按规范化之后的码位。孟加拉语里这三把尺子之间差到5倍以上，混用一定会出事。

自己写的那段截断逻辑，为什么在别的语言上一直没出过问题？

因为它在拉丁字母上恰好是对的，在有变音符号的语言上也基本对，这两类占了大多数团队的日常。它错在不认识把两个辅音粘成一个字的那个止音符号，而这个机制只在南亚和东南亚的几套文字上大规模出现。实测20个孟加拉语品类词，这段逻辑和标准算法给出的数字20个全都不一样，平均虚高61%。虚高不会报错，只会静默截短。

做孟加拉语之前，最该先花半天做的是哪件事？

把承重词捞出来，找一位孟加拉国的母语者和一位西孟加拉的母语者，各问一遍同一批词。问法要具体到行为：你去店里买这个东西开口第一句怎么说，你在手机上搜这个东西会打什么。半天就能拿到一张带市场归属的词表，而这张表决定了后面所有内容的走向。跳过这一步，后面每一篇文章都要重做一次。

权威参考资料