印度的十一门语言分摊在九套书写系统上，做小语种SEO的预算得按后面那个数字算

摘要：印度的语言优先级不能按母语人口从大到小排。十一门有商业价值的语言分摊在九套书写系统上，而字体子集、输入法映射、排序规则、分词这些一次性工程成本按书写系统算，不按语言算。天城文那一簇装着印地语和马拉地语，孟加拉文那一簇装着孟加拉语和阿萨姆语，同簇的第二门语言边际成本只有第一门的三成上下；第十一个席位如果给了乌尔都语，书写系统数从九跳到十，还会多出全站唯一一条从右往左的前端分支。另一半麻烦在输入端：用户搜印地语时大量用拉丁字母硬拼，一个词能拼出五到八种写法，官方那套罗马化方案没人照着打。

为什么按母语人口从大到小排，第一步就排错了？

人口这个数字本身没错，错在它被当成了唯一输入

做印度市场的语言排期，几乎所有人的第一个动作都一样：拉一张母语人口表，从大到小排下去。

这张表本身是可靠的，来源是普查数据，粒度到具体语言，没什么可挑的。

问题出在它只回答了一个问题——有多少人说这门语言，而排期需要回答的是另一个问题：下一笔钱花在哪门语言上，回报除以成本最高。

人口只是分子。分母那一半，人口表里一个字都没写。

分母是什么？是把一门语言从零做到能上线要付的钱和工时。

而这笔钱在印度有一个反常识的结构：它不按语言的门数增长。

把十一门语言的人口数抄进排期表，看上去像是一份数据驱动的决策，实际上只是把一列数字重新排了个序。真正需要算的那一列——每门语言的一次性工程成本——不在人口表上，也不在任何现成报告里，得自己按书写系统数出来。保哥接过一个卖二手教辅书的客户，第一版排期就是照人口表排的，做到第三门语言才发现前两门的字体和输入法资产完全没用上，因为第二门挑错了。

排在第一位的那门语言恰好是成本最低的，容易掩盖后面的账

印地语的母语人口在普查里是5.28亿，远远甩开第二名。

它同时也是印度诸语言里资料最全、工具支持最好、可招人最容易的一门。

所以第一门做印地语，无论按哪套算法都是对的，这一步不会出错。

正因为不会出错，它掩盖了一件事：第一门语言的成本里有一大块是一次性的。

字体子集怎么切、输入法怎么处理、排序规则怎么配、URL怎么编码——这些在第一门语言身上全部要从零解决。

解决完了，它们对某几门语言完全可复用，对另外几门一点用都没有。

于是第二门语言的成本会出现两个截然不同的数字，差距能到三倍。挑对了，前面攒的资产直接接上；挑错了，等于把第一门的路重走一遍。这一步的判据不在人口表上，在书写系统的归组表上，而绝大多数排期表根本没有这一列。

真正决定顺序的是三个乘数

把人口当成起点是对的，把它当成终点就错了。

可用的算法是三个乘数相乘：市场规模的粗估、书写系统的成本档、语料存量的可用档。

第一个乘数是人口乘以线上购买力，粗到只分三档就够用。

第二个乘数是这门语言的书写系统是不是已经做过——做过就是0.3，没做过就是1.0。

第三个乘数是这门语言的网页语料存量，它决定关键词工具能不能给出数字、机器翻译能不能当草稿。

三个乘数里，只有第一个跟人口有关，另外两个都跟语言的技术属性有关。

这套算法的好处不是它精确，而是它把两个隐藏成本显式地写进了表里。做完之后你会看到一些反直觉的排序：某门人口只有印地语七分之一的语言，因为跟印地语共用书写系统，综合得分排到了第二位；而另一门人口更多的语言，因为要新开一套书写系统加一条独立前端分支，被排到了第六位之后。按语言人口排优先级的那笔账在欧洲市场也是这个结论，只是印度把差距放大到了极端。

十一门语言到底是哪十一门，这个数字怎么算出来的？

宪法名单上有二十二门，能进候选池的没那么多

印度宪法附表列了二十二门官方语言，这是最常被引用的数字。

但二十二这个数字对做站的人没有直接用处，它是行政意义上的名单。

里面包含梵语这样几乎没有日常使用者的语言，也包含母语人口只有几十万的语言，粒度对不对得先查印地语在ISO 639-3里的条目那种个体语言与宏语言的区分。

做电商站要的是另一个名单：有独立商业市场、有足够网页语料、有可招到的本地人。

按这三条筛下来，稳定进入候选池的是十一门左右。

再往下的语言不是不能做，是要等前面十一门都跑通、并且有具体订单数据支撑之后再说。

需要说清楚的是，十一这个数字不是权威结论，它是筛出来的结果，筛子换了数字就变。如果把标准放到有一千万以上母语者，名单会长到十四门；如果收紧到必须有成熟的分词工具和词典资源，名单会缩到七门。重要的不是记住十一，是记住那三道筛子分别在筛什么。

从二十二砍到十一的三道筛子

第一道筛的是母语人口下限，一般取三千万。

低于这个量级，单独一门语言的销售额通常撑不起本地化的固定成本。

第二道筛的是这门语言的使用者是否集中在一个有独立消费特征的地区。

语言分散在多个邦、且当地用户习惯用另一门语言上网的，先跳过，判断依据可以取印度各语言的使用人口与地域分布。

第三道筛的是网页语料存量，判据是这门语言的维基百科条目数与公开语料库覆盖情况。

语料太薄的语言，机器翻译输出质量不可控，关键词工具也基本是零数据。

三道筛子的顺序不能颠倒。先筛人口是因为它最便宜，一张表就能过；先筛语料会把一批人口大但资源少的语言过早排除，而这些语言恰恰是竞争最稀薄、最值得后期做的。关键词工具返回零数据的那些补数办法就是为这批语言准备的。

第十一位的席位一直在两门语言之间摇摆

过了前三道筛子，前十位基本没有争议。

第十一位的竞争者有两个：一门用天城文之外的另一套字母，一门用已经做过的字母。

按人口排，用另一套字母的那门略占优势。

按成本排，用已做过字母的那门优势明显。

这个席位怎么给，直接决定你的书写系统总数是九还是十。

九和十之间不是加一门语言的差别，是加一整条前端分支的差别。

把这个选择留到最后而不是最先做，是本文后面反复出现的一个动作：先把书写系统这一列填满，再回头看语言名单，才能看清哪个席位是便宜的、哪个是昂贵的。名单和成本是同一张表的两列，分开填就会出现批准了预算才发现少算一条分支的情况。

名单定下来之后先别排序，先做书写系统归组

名单确定的下一步不是排序，是归组。

把十一门语言按它们实际使用的书写系统分堆，同一套字母的放一起。

这一步只需要查语言子标签注册表，半小时能做完。

做完之后你手上会有一张簇表，每簇一到两门语言。

簇的数量就是你要付的一次性工程成本的份数。

语言的数量决定内容成本，簇的数量决定工程成本，这两个数字在印度差得很远。

做完归组再排序，排出来的顺序会跟按人口排的顺序有几处明显不同，而这几处不同就是这套方法真正省下的钱。归组这一步的输出物只有一张表，成本几乎为零，却能改掉排期表里最贵的那几个决定，性价比高到有点不像话。

九套书写系统怎么把十一门语言分成簇？

天城文这一簇装着两门语言

天城文的Unicode区块是U+0900，这个区块的逐字符码表里能看到它同时服务印地语和马拉地语。

两门语言共用同一套字母、同一套数字、同一套标点，字体文件可以完全共用。

输入法的键位映射也基本一致，音译输入的引擎不需要重做。

排序规则同源，能用同一份配置带一点参数差异搞定。

差异集中在字母表的边缘：马拉地语常用的一个辅音在印地语里几乎不出现。

还有一处排版差异出在某个辅音的连写形态上，字体里必须带对应的字形才不出错。

所以天城文这一簇的正确说法是共用九成，不是完全一致。字体子集切的时候要把两门语言的常用字符集取并集，而不是切完印地语再拿去装马拉地语——后者会在上线一个月后以某个商品名显示成空框的形式暴露出来，而这个空框只在马拉地语站上出现，印地语站怎么测都是正常的。

孟加拉文这一簇也装着两门，但差异比天城文那簇大

孟加拉文区块是U+0980，孟加拉语和阿萨姆语共用它。

Unicode把它们编在同一个区块里，字体文件同样可以共用。

但阿萨姆语有两个字母的字形跟孟加拉语不同，是实打实的字形差异，不是编码差异。

用孟加拉语字体渲染阿萨姆语文本，字能显示出来，本地读者会觉得别扭。

这种别扭不影响机器抓取，影响的是页面的可信度。

排序规则和分词可以共用，词表完全不能共用。

这一簇给出的经验是：同一个Unicode区块不等于同一套字形要求。判断能不能共用字体，得看这门语言有没有区域性的字形变体，而这件事Unicode区块表上不写，只能问本地设计师或者拿两门语言的样张放一起对比。共用字体是省钱，省到本地读者一眼看出别扭就不叫省钱了。

南部四门语言各占一套，没有任何合并空间

泰米尔语、泰卢固语、卡纳达语、马拉雅拉姆语各有自己的书写系统。

四套字母的Unicode区块分别是U+0B80、U+0C00、U+0C80、U+0D00。

其中两套的字形有历史亲缘关系，但对做站没有任何实际帮助。

字体不能共用，输入法映射不能共用，排序规则不能共用。

四门语言就是四份完整的一次性成本，没有折扣。

它们唯一共用的是非语言字段：支付、物流、尺寸表、商品图。

南部四语这一块是印度语言排期里最贵也最容易被低估的部分。按人口看它们排在中游，看上去可以放到第二批；按书写系统看它们是四份全价，等于第二批的预算要按四倍准备。东南亚三国那种一处都不能共用的情形在印度南部是同一个道理，只是它发生在一个国家内部。

剩下三套各带一门，成本都是全价

古吉拉特文、果鲁穆奇文、奥里亚文各带一门语言。

三套字母的区块分别是U+0A80、U+0A00、U+0B00。

它们跟天城文有共同的历史来源，字形上能看出亲缘。

但对工程来说亲缘等于零，字体和输入法都要单独准备。

把十一门语言的簇数点一遍：天城文2门、孟加拉文2门、其余七套各1门，合计九套。

九套书写系统，十一门语言。工程成本按九算，内容成本按十一算。

这张表最有用的一列是最右边两列。字体可共用意味着一次性成本能摊薄，词表不可共用意味着内容成本一分钱都摊不薄。所以印度的排期表里，工程预算和内容预算的增长曲线形状完全不同：工程预算是台阶状的，每开一套新字母跳一级；内容预算是线性的，每加一门语言涨一份。两条曲线混在一个总数里看，就永远看不清下一步该往哪走。

同一簇里的第二门语言，成本真的只有三分之一吗？

能复用的是字体子集、输入法映射与排序规则

同簇第二门语言能省下的第一笔是字体。

字体子集的工作量集中在切字符集、测渲染、验回退链这三件事上，做过一次就有现成流程。

第二笔是输入端的处理，音译输入的键位映射和候选词逻辑同源。

第三笔是排序规则，区域数据规范里排序那一部分写得很细，同一套字母的排序配置改几个参数就能用。

第四笔容易被忘：URL编码的处理方式、日志里的解码脚本、后台搜索框的规范化逻辑。

这几件事都是跟字母绑定的，跟语言无关，所以第二门语言完全免费继承。

字体这一块的省钱幅度最大，因为它不只是文件复用，是整套判断经验的复用。第一次给天城文切子集，光是搞清楚哪些组合字形不能被丢掉就要反复试，还得跟本地人确认几轮；第二门语言只需要把新增字符补进已有的字符集清单，一小时的活。小语种字体在首屏那笔KB账讲的是同一套流程，印度这边只是要跑九遍。

不能复用的是词表、分词与商品文案

共用字母的两门语言，词是两套词。

同一个商品品类在印地语和马拉地语里往往是不同的词，即使拼写相近也不能互相替代。

关键词表要重做，分词词典要重训或者换一份，同义词映射要重配。

商品标题、属性名、类目名、说明文案，一个字都搬不动。

母语审校要重新招人，会印地语的人不一定能审马拉地语。

所以内容侧的成本没有任何折扣，第二门语言的内容账等于第一门。

有一个容易踩的坑是拿印地语的词表机器翻译成马拉地语当草稿。这条路在通用文案上勉强能走，在关键词表上完全不能走，因为关键词的价值恰恰在于它是用户实际输入的字符串，翻译出来的是语义正确但没人搜的词。拿词典逐词换出来的关键词表那笔长期损失，换成机器翻译只是换了个工具，性质一样。

一份逐项对照的成本清单

把成本拆成十项逐个标注，比拍一个笼统的三成要好用得多。

标注的口径统一成三档：全免、半价、全价。

工程侧六项里有五项全免，一项半价。

内容侧四项全部全价，没有例外。

把两侧的工时按实际比例加权，同簇第二门语言落在三成到四成之间。

这个区间比一个准确的数字更有用，因为它提醒你剩下的六到七成是真金白银。

这张清单还有一个用法：拿它去核对报价。本地化服务商给印度多语言项目报价时，通常按语言门数乘以单价，不区分是不是同簇。手上有这张表，就能把同簇的第二门语言的工程部分单独砍掉，谈判时有具体依据而不是纯砍价。

第十一门语言选乌尔都语，预算表要重画哪几行？

它用的是另一套字母，而且是全站唯一从右往左的一套

乌尔都语的母语人口在普查里超过五千万，按人口它稳稳进前十一。

但它用的是阿拉伯字母的一个变体，跟前面九套里的任何一套都不沾亲。

更要紧的是它的书写方向是从右往左，而其余十门语言全部从左往右。

方向这件事不是一个CSS属性能解决的，它牵动整套版式的镜像逻辑。

把它算进名单，书写系统总数从九变十，而这第十套的成本不是全价，是一倍半。

多出来的半倍就是方向带来的那部分。

这就是本文标题那个意思的完整版：十一门语言分摊在九套书写系统上，预算按九算；一旦第十一个席位给了乌尔都语，分母变成十，而且最后那一份还要乘一点五。人口表上这门语言只是第七行的一个数字，预算表上它是一整条独立分支。

版式、图片、表单三处会同时开裂

版式层面，导航方向、面包屑顺序、分页箭头、进度条方向全部要镜像。

图片层面，带方向暗示的图要重做，箭头图标要翻转，商品图上的文字如果烧进去了就得重出。

表单层面，输入框的文字起始位置、数字与货币的混排、电话号码的对齐都会出问题。

这三处的共同点是它们在从左往右的语言上从来不需要单独测试。

所以团队没有对应的测试用例，也没有对应的验收清单。

第一次做的时候，问题会以零散的界面小毛病的形式陆续冒出来，修完一轮又冒一轮。

更麻烦的是手机端。窄屏上左右两侧的空间本来就紧，镜像之后原本靠右的元素挤到左边，跟返回按钮抢位置。桌面时代验过的那份从右往左清单在手机上有一半不作数，这条经验在乌尔都语上一样成立，因为印度的移动端占比比阿拉伯语市场还要高。

要不要做它，取决于你能不能承受一整条独立的前端分支

判断标准不是这门语言值不值得做，而是你的前端架构能不能容纳双向布局。

如果模板里已经用了逻辑属性、方向相关的样式都走变量，那增量是可控的。

如果模板里写满了左右方向的硬编码，那这条分支会长期需要单独维护。

单独维护的代价不在第一次上线，在之后每一次改版都要做两遍。

所以这个决定实际上是架构决定，不是市场决定。

可行的折中是把乌尔都语放到第二年，先用一年时间把模板改成方向无关的。

还有一个现实考虑：这门语言的相当一部分使用者在跨境场景里会切到另一门语言上网，实际的搜索需求分布跟人口数并不成正比。把它排在第十一位而不是第七位，理由不只是成本高，也包括这一层。真正的排期动作是先把它标成待定，等前十门跑完拿到真实数据再定，而不是在第一版排期表上就把它删掉。

语料存量这个乘数怎么查，查到之后怎么用？

三个免费入口能把十一门语言的语料量级排出来

第一个入口是各语言维基百科的条目数排名，一张公开列表就能看到全部语言。

第二个入口是公开语料库的覆盖情况，比如印度诸语言单语语料库那份数据集就逐语言列了规模。

第三个入口是全网网页的语言占比统计，粒度粗但能看出量级差。

三个入口给出的排序高度一致，交叉验证一遍就够了。

查完把十一门语言分成三档：语料充足、语料够用、语料稀薄。

这一档位不是学术分类，是给工具选型用的。

做这件事的时间成本大概两小时，产出是一张三档表。它的价值在于提前告诉你哪几门语言的关键词工具会给出可信数字、哪几门会返回零。多语言模型铺到七十多种语言之后，语料这个变量的重要性反而更突出了，因为模型在低资源语言上的表现跟它见过多少这门语言的文本直接相关。

语料量级直接决定工具能不能用

语料充足的语言，主流关键词工具能给出搜索量区间，虽然精度不高但方向可信。

语料够用的语言，工具能返回词但数据经常是零或者极小值。

语料稀薄的语言，工具基本只能当拼写检查器用。

机器翻译的可用度也跟着这三档走，第三档的输出不能当草稿，只能当术语提示。

分词工具同理，第一档有成熟实现，第三档往往只有学术项目的代码。

把工具的可用度提前标出来，排期时才能把对应的人力补上。

这里有个反直觉的地方：语料稀薄的语言不一定是最难做的那门，反而经常是搜索竞争最稀薄的那门。工具查不到数据的语言，同行也查不到，于是没人做，页面一上去就能排上第一页。难点从选词转移到了验证——你得自己想办法确认这个词有人搜。

语料薄的语言不是不能做，是要换方法做

换的第一个方法是把选词的依据从工具数据换成站内数据。

站内搜索日志、客服对话记录、商品评论里的用词，都是这门语言的真实输入。

第二个方法是拿自动补全当数据源，逐字符敲进去看引擎给什么建议。

第三个方法是从这门语言的本地论坛和社群里扒真实提问的句式。

这三个方法拿不到搜索量，能拿到的是词的存在性与拼写形态。

对语料薄的语言，存在性比搜索量更值钱，因为它决定你会不会写出一个没人用的词。

三个方法都要先有流量才能跑，所以语料薄的语言天然应该排在后面——不是因为它不重要，是因为它需要前面几门语言带来的流量当种子。这一点在排期表上要写成明确的依赖关系，而不是笼统的优先级低。

印度用户其实在用拉丁字母搜印地语，你的关键词表接得住吗？

输入法切换的成本决定了输入方式

做印地语站的人默认用户会用天城文输入，这个默认在很多场景下不成立。

手机上切换输入法要点两三次，切回英文再点两三次。

大量用户的解法是根本不切，直接用英文键盘把印地语的音拼出来。

输入法能把拼出来的音转成天城文，但用户经常不选候选词，直接把拉丁串发出去。

搜索框里进去的就是一串拉丁字母，而它代表的是一个印地语词。

这类查询在电商类词上占比不低，尤其是短词和口语词。

这件事的后果是：你的关键词表如果只有天城文，那它只覆盖了一半的查询。另一半用拉丁字母写的同义查询，页面上一个字都没有，引擎只能靠语义匹配去猜，而在口语化的短词上它猜得并不好。这跟希腊语市场的情形同源，越把页面写得规范就越接不住拉丁字母打出来的那半边搜索，印度只是把这个现象的规模放大了几十倍。

同一个词的拉丁拼法能有五到八种

希腊语的拉丁化有一套约定俗成的字母对应关系，虽然不统一但收敛。

印度的拉丁化不收敛，因为它拼的是音，而音怎么用英文字母写没有共识。

一个意思是买的动词，能写成kharidna、kharidana、khareedna、kharidne几种形态。

一个意思是鞋的名词，词典里的原形只有一个，用户却能写成jute、joote、jutte，还有人写juta。

长元音写成一个字母还是两个字母，送气音要不要带h，词尾的元音留不留，每一处都是分歧点。

把这些排列组合起来，常用词的拉丁写法轻松上五种。

最后一行是印度市场特有的现象：一个短语里一半是英语词一半是本地词，而且这种混合是稳定的、可预测的。像送货、退货、折扣这类电商词，用户经常直接用英语词，反而是商品名和形容词用本地语言。所以关键词表里必须有混合词这一类，纯本地语言的词表会漏掉相当一部分真实查询。

两套写法要不要都做，看的是页面类型

不是所有页面都需要覆盖拉丁写法，判据是这个页面靠哪种查询进来。

商品详情页和类目页的查询里拉丁写法占比高，值得覆盖。

内容页和帮助文档的查询以天城文为主，因为用户在这些场景下更愿意认真打字。

覆盖的方式不是建两套页面，是在同一个页面里让两种写法都出现。

天城文放标题和正文，拉丁写法放在商品别名、常见问法、页内搜索提示这些位置。

这样一个URL能同时接住两种查询，也不会产生重复内容。

需要说清的是别名的写法要挑，不是把五到八种全部堆上去。挑两到三种最主流的，剩下的靠引擎的模糊匹配兜。全部堆上去会让页面读起来像关键词列表，本地用户一看就觉得这站不正经，而且这种堆砌带来的收益远小于它损失的信任。

拉丁变体的收集只能靠三个来源

第一个来源是站内搜索日志，它记录的就是用户实际敲进去的字符串。

把日志里的拉丁串按频次排序，前二十条基本覆盖主流写法。

第二个来源是搜索框的自动补全，逐字符敲拉丁前缀看引擎给什么建议。

第三个来源是商品评论和客服记录里用户自己写的词。

三个来源的共同优点是它们都是真人写的，不是转写规则生成的。

用规则生成的变体清单会包含大量没人用的写法，反而把噪音带进词表。

收集这件事的最佳时机是站点已经有一点自然流量之后，所以印度市场的正确节奏是先用天城文上线一批页面，跑两个月拿到日志，再回头补拉丁别名。反过来先猜变体再上线，猜出来的清单跟真实日志的重合度大概只有一半。

一套官方罗马化系统摆在那儿，为什么没人按它打字？

那套系统是给地名标注设计的

联合国地名标准化机构在1972年批准了一套印地语罗马化方案，至今可查。

它规定了每个天城文字母对应的拉丁字母，包括附加符号的用法。

这套方案的设计目标是地图、护照、地名录的标注一致性。

它要求的是可逆——从拉丁串能唯一还原回原文。

为了可逆，它用了带附加符号的字母，而这些符号在普通键盘上打不出来。

用户不可能为了搜一双鞋去插入一个带点的字母。

所以这套官方系统和用户的实际输入是两个互不相交的世界。它有用，但用处在别处：当你需要给一个词定一个稳定的拉丁形态，比如做URL的slug、做数据库的排序键、做日志里的规范化形态时，照着它做能保证不同人做出来的结果一致。URL用本地字母还是拉丁转写那个决定就该照它做，关键词表则完全不该照它做。

用户拼的是自己听到的音，不是字母的对应关系

官方系统做的是字母到字母的映射，用户做的是音到字母的猜测。

同一个音，一个人写成oo，另一个人写成u，第三个人写成ou。

而且用户参照的是英语的拼写习惯，而英语本身的拼写就不规则。

受教育程度、年龄、母语方言都会影响一个人的拼法偏好。

所以拼法分布不是随机噪音，是有结构的，头部几种写法占大多数。

这也是为什么挑两三种主流写法就够，剩下的是长尾。

这里有个实用推论：拼法的头部集中度可以拿来判断一个词值不值得单独覆盖。如果一个词的前两种拼法占了日志里八成以上，那覆盖这两种基本就够；如果前五种加起来才六成，说明这个词的拼法极度分散，与其覆盖变体不如在页面上多写一段自然的本地语言描述，让语义匹配去兜。

离散度这个指标怎么算，算出来干什么

离散度的算法很简单：一个词在日志里出现的不同拉丁拼法数量，除以该词的总查询次数取对数后的档位。

实际用起来不必这么正式，数一下不同拼法的个数就够。

一到二种叫收敛，三到四种叫中等，五种以上叫分散。

收敛的词直接把拼法写进页面别名。

中等的词写前两种，剩下的靠正文里的自然出现。

分散的词不做别名，改成在正文里把这个概念用几种说法都提一遍。

这个指标的真正价值是它把一个看起来无边无际的问题变成了三档动作。印度多语言项目最容易失控的地方就是变体覆盖，一旦开始逐个词收集拼法，工作量能吞掉整个季度。用离散度分档之后，绝大多数词落在收敛和中等两档，需要特殊处理的分散词通常不到一成。

先上英语版兜住印度市场，会漏掉哪些品类词？

印度英语的品类词跟美式英语不是一套

先上英语版这个动作本身是对的，印度的英语搜索量很大。

错的是拿美国站的英语内容直接搬过来当印度英语版。

蔬菜类里茄子叫brinjal不叫eggplant，甜椒叫capsicum不叫bell pepper，秋葵叫ladyfinger不叫okra。

交通工具里两轮车统称two-wheeler，小巴叫tempo traveller。

还有一个动词只有印度英语里有：prepone，意思是把时间往前挪。

这些词不是俚语，是印度英语的标准用法，出现在正规媒体和商品页上。

品类词错了的后果比语法错了严重得多。语法别扭用户还能看懂，品类词不对等于这个词在你的站上不存在，用户搜brinjal你的页面写着eggplant，语义匹配未必接得住，尤其是当本地竞争对手页面上明明白白写着brinjal的时候。这跟西班牙人和墨西哥人搜的不是一个词是同一类问题，只是这次分叉发生在英语内部。

数量单位与价格表述也是本地的

印度英语里的大数用lakh和crore，分别是十万和一千万。

价格页面写1,50,000这种分节方式，逗号位置跟国际习惯不同。

重量和尺寸沿用公制，但服装尺码有本地的号型体系。

这些东西写错不会影响收录，会影响用户对价格的第一判断。

一个标着数字的价格如果分节方式不对，本地用户要多看一眼才能确认量级。

多看一眼在移动端就是一次犹豫，犹豫的下一步经常是返回。

数字格式这类字段有个规矩：页面上按本地习惯写，结构化数据里要还原成机器格式。这两个方向正好相反，正文越本地化越好而标记里要反着写回国际格式那篇专讲这件事，印度英语版是这条规则最容易被忽略的适用对象，因为它长得像英语，团队根本不会想到它需要本地化处理。

英语版该定位成什么，别当成兜底

英语版的正确定位是十一门语言之外的第十二个市场，不是它们的兜底。

它有自己的用户群：城市、高教育、跨邦流动、多语言切换。

它有自己的品类偏好：高客单、进口商品、专业设备。

它也有自己的关键词表，跟美国站的英语词表重合度大概七成。

把它当成兜底会导致一个具体后果：本地语言版本被无限延后。

因为英语版能拿到流量，看上去印度市场已经在做了。

保哥常跟客户说这句话：英语版拿到的流量是印度市场的天花板下面那一层，不是全部。它的增长会在某个点停住，而停住的原因不是优化没做到位，是剩下的需求根本不用英语表达。这个点通常出现在第二年，届时再从零启动本地语言，前面攒的域名权重能帮上忙，但语言侧的一次性成本一分钱都没省。

十一门语言的落地顺序怎么排成一张可执行的排期表？

第一门语言吃掉的是全部一次性成本

第一门做印地语，这一步没有争议。

它要解决的清单包括字体子集、输入法处理、URL编码策略、日志解码、排序规则、分词方案。

还要解决流程侧的：本地审校怎么找、怎么验收、术语表怎么维护。

这批工作里工程部分对同簇语言可复用，流程部分对全部语言可复用。

所以第一门的实际耗时通常是后面每一门的两到三倍。

排期表上给它留足时间，别按平均值排。

把第一门当成基础设施建设期来排，而不是当成一门语言的上线来排，后面的节奏才对得上。这个阶段最该多花时间的是流程而不是内容：验收清单、术语表格式、审校员的工作说明，这三样东西定得糙，后面十门语言都要跟着糙一遍。母语者说读着自然不能当验收判据那套清单在这一步就该定下来。

第二门按簇挑，不按人口挑

第二门语言的正确选法是从天城文这一簇里挑，也就是马拉地语。

按人口它排第三，按成本它是最便宜的一门。

做完它，天城文这一簇的资产就完全摊开了，而且验证了同簇复用这条路走得通。

如果第二门直接跳到孟加拉语，那等于同时开新字母和验流程，两件不确定的事叠在一起。

先做便宜的那门，是为了在成本可控的情况下把流程跑第二遍。

第二遍跑通了，后面开新字母才有底气。

这里的逻辑跟软件上线灰度是一个道理：第二个用例要挑跟第一个最像的，因为它的作用是验证流程可复制，不是验证方法在极端情形下也成立。挑一门跨字母的语言当第二门，一旦出问题你分不清是流程有毛病还是新字母有毛病。

三到六门进入拼装期，成本曲线开始平

第三到第六门可以按市场规模乘购买力排，这时候成本差异已经不是主要变量。

通常的顺序是孟加拉语、泰米尔语、泰卢固语、古吉拉特语这一带。

每开一门新字母要留出字体和渲染的验证时间，但流程已经是现成的。

这个阶段的瓶颈从工程转到了人：能审这门语言的人好不好找。

人的可得性有时会直接改变顺序，找不到审校员的语言只能往后放。

把这一条写进排期表的假设栏里，别等到要上线才发现招不到人。

拼装期的效率提升是最明显的，第一门可能要三个月，到第五门通常一个月能上线一批核心页面。这个加速不是团队变熟练了那么简单，主要来自资产复用：术语表格式、验收清单、渲染测试用例、日志脚本，全都是现成的，新语言只需要往里填内容。

什么时候该停下来

停下来的判据不是语言做完了，是最近两门语言的投入产出比掉到了阈值以下。

阈值怎么定各家不同，常见的做法是拿英语版的单位流量成本当基准的三倍。

连续两门语言超过这个阈值，就该停下来做深度而不是继续加语言。

做深度的意思是回头把已上线的语言的页面覆盖率、内链、结构化数据补齐。

加语言是横向扩张，补深度是纵向挖掘，后者的边际回报在某个点会反超。

反超的时间点通常出现在六到八门语言之后。

还有一种该停的信号更容易识别：本地审校的排队时间开始变长，翻译稿在队列里积压。这说明产能瓶颈已经从预算转到了人，这时候再加语言只会让每门语言的质量一起下滑，而质量下滑在小语种上的代价格外高，因为你自己看不出来。

常见问题解答

只做英语能不能覆盖印度市场？

能覆盖一部分，通常是城市高教育人群和高客单品类，但它是一个有天花板的子市场，不是全市场的代理。而且英语版本身也要本地化：品类词要换成印度英语的说法，大数要用当地的计数单位，价格分节要按本地习惯。拿美国站的英语页面直接搬过来，会在品类词这一层大面积失配，用户搜的那个词你的页面上根本没有。正确的定位是把英语当成第十二个语言市场来做，有独立的词表和独立的品类策略。

印地语做完了，第二门该选马拉地语还是孟加拉语？

先做马拉地语。它跟印地语共用天城文，字体子集、输入法处理、排序规则、URL编码这几项工程成本可以直接继承，综合成本大概是印地语的三到四成；孟加拉语要开一套新字母，成本接近全价。按人口孟加拉语更大，但第二门语言的战略作用是验证同簇复用这条路走得通，挑最便宜的那门跑第二遍流程，风险最低。孟加拉语放到第三门，那时候流程已经稳定，新字母带来的不确定性单独暴露，好排查。

印地语的关键词工具有数据吗，够用吗？

印地语在印度诸语言里资料最全，主流工具能给出搜索量区间，方向可信但精度一般。真正会返回大量零值的是南部四语之外的那几门和奥里亚语、阿萨姆语这一带。工具给零不代表没需求，只代表工具的语料里没有这门语言的足量样本。这种情况下改用站内搜索日志、自动补全逐字符探测、本地社群的真实提问三个来源补数据，能拿到词的存在性和主流拼写形态，拿不到搜索量。对语料薄的语言，存在性其实比搜索量更值钱。

拉丁字母拼出来的印地语查询，要不要单独建页面？

不要。同一个商品的两种查询写法背后是同一个需求，拆成两个URL会制造重复内容，也会把外链和内链的权重分散到两处。正确做法是在同一个页面里让两种写法都出现：天城文放标题、H2、正文主体，拉丁写法放在商品别名、常见问法区块、页内搜索提示这些位置。拉丁写法挑两到三种最主流的就够，别把五到八种全堆上去，堆上去会让页面读起来像词表，本地用户对这种页面的信任度很低。

十一门语言要用十一套域名，还是同一个域名下开目录？

这个问题属于架构层，跟语言本身无关，判据是团队的运维能力、外链资源的集中度、以及各语言市场是否需要独立的品牌形象。多语言站的域名结构与hreflang落地那份清单能直接照着走，印度这边没有额外的特殊性。语言层要操心的是另外几件事：每个语言版本的语言标签要带对书写系统子标签、内链的锚文本要用对应语言、以及别让同一门语言的两种书写形态互相当成不同语言声明。

南部那四门语言能不能合成一套内容？

不能，一个字都不能。四门语言分属同一语系但互不相通，四套书写系统之间没有任何复用空间，字体、输入法、排序、词表全部独立。它们唯一能共用的是非语言字段：支付方式、物流选项、尺寸表、商品图。所以在预算表上，这四门语言应该按四份全价计，而不是按一个南部市场计。把它们打包成一个南部预算是印度项目里最常见的低估来源，也是第二批预算最容易超支的地方。

印度英语页面和美国英语页面会不会互相抢排名？

会有一点，但这属于同语言多地区的架构问题，用地区定向的语言标签声明清楚就能大幅缓解，判据和落地步骤跟印度无关。语言层上要注意的反而是内容差异化：如果两个版本的品类词、单位、价格表述、货运说明全都不同，那它们实际上是两份内容，抢不起来；如果只改了货币符号，那它们确实是重复内容，声明得再规范也解决不了根本问题。差异化做够了，声明只是收尾动作。

权威参考资料