安卓能选181门系统语言，Chrome桌面版只有53门，差的那批人设不成自己的母语

摘要：把安卓、Firefox、Chrome三家的界面语言清单下下来逐条对了一遍。安卓系统能选181门语言，Firefox出货88门，Chrome桌面版只有53门，同一门语言在三家的待遇差出3.4倍。更要紧的是进出这份清单的判据：翻开工单，写的是这个社区还在不在，不是这门语言有多少人说。用户设不成这门语言，你的报表里就没有这门语言的用户。

有个动作很多人做过一次就再没做过：拿起手机，进设置，翻到语言那一页，看看目标市场那门语言在不在里面。

这个动作之所以做一次就不做了，是因为看到目标语言在里面之后，事情就结束了。看不到的时候呢？多数人的反应是换一部机器再看看，然后把这件事当成个例放过去。

保哥上个月把这个动作做成了一件正经事——不是翻手机，是把安卓系统、Firefox、Chrome三家的界面语言清单从源码仓库里下下来，逐条对齐。三份清单都是公开的文本文件，加起来不到200KB，一个下午能对完。

对完之后有两件事跟原来的印象不一样。

第一件是量级。安卓的清单有181门语言，Chrome桌面版只有53门。中间差的那128门语言，它们的使用者拿着安卓手机可以把系统调成母语，打开电脑上的Chrome却只能在53个选项里挑一个不是自己的。

第二件更意外。翻开这些清单的改动记录，一门语言进来或者出去，理由从来不写“这门语言使用者太少”。写的是另一句话，而那句话跟语言本身没关系。

下面这些数字是为了把这两件事说清楚。口径全部锁在2020年年中：安卓10、Firefox那时候的出货版本、Chrome 83。三份文件都能按版本号翻回去，谁都可以自己核一遍。

为什么要先查一遍这份清单？

先说这件事跟做小语种到底有什么关系，因为它看起来像是操作系统厂商的家务事。

用户设不成，请求里就没有这门语言

浏览器每发一个请求，都会在头部带上一行语言偏好，服务器靠它判断该给哪个版本。这一行的值不是用户手打的，是从系统设置和浏览器设置里读出来的。MDN关于这个请求头的说明写得很直白：它反映的是用户在客户端配置的偏好，不是用户会说什么语言。

这一行长什么样值得看一眼。它是一串带权重的语言标签，比如先写用户的第一偏好，再跟上几个备选，每个后面挂一个零到一之间的数字表示优先级。服务器拿到之后按顺序挑一个自己有的版本。

于是就有了一条很别扭的因果链。用户会说老挝语，但他的笔记本上装的Chrome里没有老挝语这个选项，他只能把界面留在英语。他打开你的站，请求头里写的是英语。

这条链上的每一环单独看都没错。系统按用户设置报语言，浏览器按系统设置报语言，服务器按报上来的语言发版本，统计工具按报上来的语言归类。四步全对，结论是错的。

你的服务器照着这一行给他发英语版，你的统计后台把他记成英语用户，你的语言维度报表里老挝语那一格是零。

更麻烦的是这个错误不会报警。它不产生任何异常，不进错误日志，页面照常打开，转化照常发生。你唯一能看到的症状是那门语言的用户占比小得不像话，而这个症状太容易被解释成市场本来就小。

这不是理论上的可能，是一个可以数出来的比例

本站这几年写过的小语种里，有27门是真正被当成市场认真讨论过的。把这27门丢进三份清单查一遍：能在Chrome桌面版里被选中的只有5门，泰米尔语、孟加拉语、阿姆哈拉语、斯瓦希里语、波斯语。

这个查法本身很粗暴：把语言代码丢进三个文本文件搜一遍，能搜到就算有。没有加权，没有折算，就是有和没有两种状态。粗暴有粗暴的好处，它不需要任何假设。

剩下22门里，老挝语、蒙古语、豪萨语、约鲁巴语、伊博语、祖鲁语、普什图语这7门更极端——两家浏览器的正式清单里一门都没有，只有安卓那份系统清单收了它们。

顺带说一句这7门的分布：三门在东南亚和东亚内陆，三门在西非，一门在南亚。它们的共同点不是穷，是各自的技术社区没在这两家浏览器的流程里露过面。

它跟内容量、跟需求是三把不同的尺子

判断一门语言值不值得投入，这几年常用的输入项是内容供给和搜索需求。这两把尺子本站量过，一把在按母语人口排优先级那一篇里，一把在关键词工具返回零的那一篇里。

这两把尺子有个共同的毛病：它们量的都是内容侧，而内容侧的数据本身就依赖这门语言在网上的存量。存量少的语言，两把尺子都会给出偏低的读数，而且是同向偏低，叠加起来会把结论推得比事实更悲观。

界面语言清单量的是第三件事：这门语言在软件世界里有没有落脚点。它跟前两把尺子给出的排序不一样，而且它便宜到不用申请预算——三个公开文件，半小时。

它还有一个别的尺子没有的性质：它是离散的。有就是有，没有就是没有，不需要抽样，不需要置信区间，不会因为你换一个时间跑就得出不同的数。这类硬边界在小语种这一层很少见，遇到了就该用上。

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

能回答的是清单本身：有多长、谁在里面、什么时候进的、什么时候被拿掉的、判据是什么。

另外这三份清单都是公开源码里的文件，任何人都能翻回任意一个历史版本重新数一遍。本文里的每个数字都能被独立复核，这一点在小语种这一层同样不常见。

不能回答的是清单里的那些语言翻得好不好。一门语言在清单里，只说明有一份语言包存在，不说明这份语言包是完整的。那是另一层的问题，本文不碰。

三份清单分别有多长？

先把三个数摆出来，因为它们的差距比多数人预估的大。

安卓：514个区域组合，181门语言

安卓系统支持的语言写在一个叫区域配置的资源文件里，安卓10那一版的这份文件公开可查，一行一个条目。数出来是514条。

这份文件的格式很朴素，就是一长串条目，每条写一个语言加地区的组合，比如英语加美国、法语加加拿大。它决定的是系统设置里那个语言列表能列出什么，也决定了应用能拿到哪些区域参数。

有一点容易被忽略：这份清单同时也是应用能拿到的区域参数的上限。你的应用想按某个地区格式化价格和日期，前提是这个地区组合在清单里。清单没有的，运行时会往上一级回落，这跟本站在区域数据那一篇里量过的回落是同一条链。

但514是区域组合数，不是语言数。把地区后缀去掉、按语言去重之后，剩181门。

这一步不能省。后面几乎所有关于清单长度的误读，根子都在把这两个数混着用。

这181这个数字，是三家里最大的一个，也是本文后面所有对照的基准线。

Firefox：97个出货版本，88门语言

Firefox把正式出货的语言版本写在一份叫出货清单的纯文本文件里，一行一个。2020年年中这份文件里有97行。

这份文件旁边还有一份更长的，叫全部语言清单，里面记着所有正在被翻译的语言。两份的差别就是“在翻”和“已经能下载到”的差别。做判断要看出货那一份，看在翻那一份会系统性高估。

同样去掉地区后缀，88门语言。比安卓少了将近一半。

Firefox的地区变体比安卓少得多，97比88，只多9个。这跟安卓的514比181形成鲜明对照，也说明两边的清单是按完全不同的粒度在维护的。

Chrome：桌面53门，全部算上78门

Chrome这边有意思。它把界面语言清单写在构建配置里，而且不是一份，是好几份变量。

这个设计本身透露了信息：一份清单要拆成好几个变量，说明不同平台拿到的东西真的不一样，而且这种差别是有意做出来的，不是历史遗留。

总清单87条，里面有27条标着只给安卓。也就是说，你在Windows或者macOS上装Chrome，能在设置里选到的界面语言是60个区域组合、53门语言。

顺便说，那87条里还混着四对历史遗留的旧代码——菲律宾语、希伯来语、印尼语、挪威语，每一门都有一个上古写法和一个现行写法同时在列。数语言的时候要把它们合并，不然会凭空多出四门。

53门。这个数字跟安卓那份181门比，差3.4倍。

三家都有的只有62门

把三份清单按语言层求交集，结果是62门。

62这个数比想象中小。三家加起来涉及的语言有两百多门，能同时被三家都收下的只有不到三分之一。

换个说法：安卓收的181门语言里，有95门是安卓独有的，两家浏览器一家都没收。而按“Chrome桌面能不能选”这个最严的口径算，安卓有而Chrome桌面没有的是132门。

这三个数不该被拉到同一张表里直接比

先把口径说清楚，免得后面越说越乱。安卓那份是系统级清单，装机就在里面；Firefox那份是官方出货的语言包，要下载对应版本或者装语言包；Chrome那份是打进安装包的资源。三者的门槛不一样，安卓最松是正常的。

还有一个口径要提前说：本文数的是“能不能把界面设成这门语言”，不是“能不能显示这门语言”。显示是字体和渲染的事，本站在网页字体那一篇里量过，两者经常被混为一谈。

所以本文的用法不是给三家排名，是拿它们互相当参照。一门语言三家全有，跟三家只有安卓有，是两种完全不同的处境。

Chrome桌面版那份清单，五年一个字没动过？

把Chrome的清单按版本拉成一条时间线，看到的东西挺出人意料。

能这么拉，是因为这份构建配置从2014年9月就在仓库里了，每次改动都留着记录。整个十年里它一共只被改过三十几次，其中一多半还是重构和改名，真正动到语言名单的没几次。

2014到2019，只减不增

Chrome 40（2014年11月）那份文件里，界面语言53门。Chrome 45、Chrome 50，还是53门。

到了Chrome 55（2016年12月），数字变成51门——不是加了两门，是少了两门。此后Chrome 60、65、70、75、79，一路到2019年12月，全都是51门，一个字没改。

减掉的那两门不是被删除，是被并进了别的写法。但净效果一样：用户在设置里能看到的选项少了两个。

整整五年，全球份额六成以上的桌面浏览器，界面语言清单是净减少的。

2020年初那次，一口气加了27门

转折出现在Chrome 80，2020年2月。那份构建配置突然多出一批新变量，总清单从51跳到86。

这次改动的记录留在2019年11月到12月之间，几次提交连着来，其中一条的说明写得很直接：给安卓的应用包新增25门语言。之后又零星补了几门，凑成27。

新进来的27门是这些：南非荷兰语、阿萨姆语、阿塞拜疆语、白俄罗斯语、波斯尼亚语、巴斯克语、加拿大法语、加利西亚语、亚美尼亚语、冰岛语、格鲁吉亚语、哈萨克语、高棉语、吉尔吉斯语、老挝语、马其顿语、蒙古语、缅甸语、尼泊尔语、奥里亚语、旁遮普语、僧伽罗语、阿尔巴尼亚语、乌尔都语、乌兹别克语、香港中文、祖鲁语。

这份名单几乎就是一份小语种花名册。南亚、东南亚、中亚、高加索、巴尔干，本站写过的那批语言在里面能找到一大半。

把它跟本站写过的语种篇对一下：老挝语、缅甸语、僧伽罗语、高棉语、蒙古语、格鲁吉亚语、亚美尼亚语、哈萨克语、乌兹别克语、乌尔都语、阿尔巴尼亚语、马其顿语、冰岛语——十几篇文章的主角一次性全在这份名单里。这不是巧合，是同一批语言在同一个时间点被同一套流程处理了。

但这27门只给了安卓

然后就是那个转折。这27门在构建配置里带着一个明确的标记：只给安卓。桌面版的清单一条都没多。

“只给安卓”这个限定在构建配置里是一行代码，在用户那里是一个存在与不存在的差别。它不会出现在任何一份宣传材料里，也不会出现在任何一份支持语言列表的文档里。

所以2020年上半年的实际状况是：同一个Chrome，装在安卓手机上能选老挝语，装在电脑上不能。一门语言在你的手机和你的电脑上待遇不同，而这两台设备装的是同一个牌子的同一个浏览器。

这次改动还把两个平台的关系整个反转了

这里有一条我事先猜错的。改动之前，Chrome的安卓版是比桌面版少的——构建配置里有一个变量专门列着安卓版拿不到的9门语言，孟加拉语、爱沙尼亚语、古吉拉特语、卡纳达语、马拉雅拉姆语、马拉地语、马来语、泰米尔语、泰卢固语。

那9门里有7门是印度的语言。也就是说2020年之前，Chrome的安卓版在印度市场上反而比桌面版少支持一批印度语言，这听起来很荒唐但确实如此。这跟本站在印度多语言那一篇里说的那种复杂度是一脉相承的。

改完之后，那个变量没了，换成了“只给安卓”的27门。一次构建配置的重写，让同一个浏览器在两个平台上的语言支持关系从“安卓少9门”变成了“安卓多27门”。

而iOS版一直是最少的那一个

顺带说一句iOS。Chrome的构建配置里另有一份清单，列着iOS版拿不到的13门语言：阿姆哈拉语、孟加拉语、爱沙尼亚语、菲律宾语、古吉拉特语、卡纳达语、拉脱维亚语、马拉雅拉姆语、马拉地语、斯洛文尼亚语、斯瓦希里语、泰米尔语、泰卢固语。

把这13门跟安卓版少的那9门逐条对，重合的有8门：孟加拉语、爱沙尼亚语、古吉拉特语、卡纳达语、马拉雅拉姆语、马拉地语、泰米尔语、泰卢固语。只有安卓缺的仅马来语一门，iOS额外缺的是阿姆哈拉语、菲律宾语、拉脱维亚语、斯洛文尼亚语、斯瓦希里语这5门。

顺带一提，这三份缺失清单里的语言几乎没有重叠的例外——泰米尔语和泰卢固语在两个移动平台上都被砍，而它们各自的使用者都在七千万以上。使用人数在这套流程里显然不是第一顺位的判据。

这8门重合项里有6门是印度的语言。两个移动平台各自砍掉的，基本是同一批印度语言，而这件事在任何一份面向用户的支持语言说明里都看不到。所以“Chrome支持这门语言”这句话本身没有信息量，必须问是哪个平台上的哪一版Chrome。

两家浏览器收的是不是同一批语言？

本来以为是包含关系，大的那份把小的那份包住。实测完全不是。

验的方法很简单：两个集合互相做差。如果是包含关系，其中一个方向的差集应该是空的。结果两个方向都不空，而且都不小。

Firefox有而Chrome完全没有的22门

这份名单很有特点：阿乔利语、阿拉贡语、阿斯图里亚斯语、布列塔尼语、卡克奇克尔语、威尔士语、下索布语、世界语、富拉语、弗里西亚语、爱尔兰语、苏格兰盖尔语、瓜拉尼语、上索布语、国际语、卡拜尔语、利古里亚语、新挪威语、奥克语、罗曼什语、桑海语、特里基语、科萨语。

另外这份名单里有两门是人造语——世界语和国际语。它们没有任何一个国家的市场，却在清单里稳稳待着，因为它们各自有一群极其稳定的爱好者在翻。这是社区驱动这套机制最纯粹的样本。

再看一眼使用人数：威尔士语约五十万常用者，罗曼什语不到五万，上索布语和下索布语加起来两三万，利古里亚语和阿斯图里亚斯语都是几十万量级。按人口排，这些语言没有一门能进世界前三百。

一眼看过去：欧洲的区域语言占了一大半，加上几门美洲原住民语言，再加两门人造语。

Chrome有而Firefox没有的那些

反方向的名单短一些，去掉三个历史遗留代码之后是10门：阿姆哈拉语、阿萨姆语、菲律宾语、吉尔吉斯语、老挝语、马拉雅拉姆语、蒙古语、奥里亚语、斯瓦希里语、祖鲁语。

斯瓦希里语的使用者以亿计，马拉雅拉姆语三千多万，阿姆哈拉语三千多万，祖鲁语一千多万。按人口排，这一批全部远远排在前面那一批之上。

把两份名单的人口加总更夸张：Firefox独有那22门加起来大概几百万人，Chrome独有那10门加起来接近三亿。两份清单量的东西差了两个数量级，而它们在产品界面上长得一模一样，都叫“选择语言”。

这一批的画风完全不同：亚洲和非洲，而且几乎都是使用人口以千万计的语言。

一边按社区收，一边按市场收

两份名单摆在一起，机制就露出来了。

这两套机制的产出物看起来是同一种东西——都是一份语言清单——但它们回答的完全不是一个问题。一份回答“谁愿意做”，一份回答“做了值不值”。

Firefox的语言包靠志愿者社区做，谁组织起来了、谁翻完了、谁跟得住，谁就进清单。所以它收了威尔士语、奥克语、上下索布语这种使用者只有几万到几十万、但有一批人几十年如一日在维护的语言。

这套机制的好处是它对小语种极其友好，坏处是它完全依赖具体的人。人在，清单就在；人散了，清单里的条目就会被拿掉，本文后面那两张工单讲的就是这件事。

Chrome的清单是公司排的，判据是市场规模。所以它收了斯瓦希里语和马拉雅拉姆语，没收罗曼什语。

这套机制的好处是稳定，一旦进了就不太会掉出去；坏处是没有申请通道。一门语言的社区再热情，只要市场规模不到线，就一直在门外。

同一门语言的命运，取决于它掉进了哪一套决策机制里，跟它自己是什么样子关系不大。这一条对做市场判断的人特别实用：你查到一门语言在Firefox里有、在Chrome里没有，得出的结论不该是“做的人少”，而是“这门语言有社区、没市场规模”，那是两句意思相反的话。

这条分野还能反过来用

如果一门语言两家都收了，说明它同时通过了社区那道关和市场那道关。这在做优先级时是个不错的加分项，而且不用花钱查。

反过来，一门语言两家都没有但安卓有，说明它是被系统级的清单顺手带进来的，既没有社区也没有市场投入，这是最需要警惕的一档。

本站写过的27门语言里，两家都收的有十几门，包括僧伽罗语、缅甸语、高棉语、尼泊尔语、格鲁吉亚语、亚美尼亚语、乌兹别克语、哈萨克语、阿塞拜疆语、阿尔巴尼亚语、马其顿语、冰岛语、巴斯克语、乌尔都语、波斯语、泰米尔语、孟加拉语。

一门语言凭什么进这份清单，又凭什么被拿掉？

这一节是全篇最值钱的部分，因为答案写在公开的工单里，有名有姓有日期。

能查到这些，是因为浏览器厂商把这类决定放在公开的工单系统里讨论。这一点跟很多闭源产品不同，也是本文能做出来的前提。

缅甸语进清单那天的工单是怎么写的

2017年4月，缅甸语加进Firefox的正式出货清单。那张工单里的原话是：缅甸语已经连续几个版本周期跟上了翻译，测试也没发现什么特别的问题，可以随54版进入测试版和正式版了。

注意这句话里没有的东西：没有提缅甸有多少人口，没有提缅甸的手机保有量，没有提市场潜力。

整张工单从头到尾也没有提缅甸语在网上有多少内容，没有提搜索量，没有提竞争对手做没做。这些在做市场判断的人眼里最重要的指标，在这套流程里一个都不出现。

写的是“连续几个版本周期跟上了翻译”。入场判据是有没有一个人在持续跟，不是这门语言有多少人说。

出场的判据写在另一张工单里

2014年1月，Firefox一次关掉了好几门语言的桌面版构建。那张工单的第一句话是：下面这几个本地化工作组早就解散了，Firefox桌面版上他们的用户就算有也非常少，我们打算把这些构建关掉，直到有新的一拨人接手。

工单里那句“就算有也非常少”值得注意：用户量是被写进来了，但它是第二个理由，跟在“工作组解散了”后面，而且用的是一种明显不确定的说法。真正确定的那件事是前半句。

后面跟着一份名单：斯里兰卡泰米尔语、阿肯语、卢干达语、北索托语、萨哈语、沃洛夫语。

解散这个词的分量

“早就解散了”这五个字值得停一下。它说的不是翻译质量不行，不是版本落后，是那个组织本身没有了。

放到做市场判断的语境里，这句话的信息量比任何一份市场报告都大：它等于说这门语言在那个时间点上，找不到一支能把一份软件翻完并且持续跟下去的队伍。你要在当地找本地化供应商，面对的是同一个人才池。

还有一个细节：这张工单没有说永久移除，说的是关掉，直到有新的一拨人接手。也就是说门是留着的，只是没人推。

这跟本站量过的另一件事严丝合缝：一门语言的软件本地化不是一个项目，是一条订阅——软件在长，字符串在增，你停手不是原地不动，是往回退。

本站在机器翻译直接上线那一篇里说过一个相近的账：省下的那道人工，最后要分期还。软件本地化这一层的还款方式更直白，就是清单里少你一行。

2019年3月还有第二次，工单标题直接写着“把陈旧的语言从Firefox桌面构建里移除”，那次拿掉的是阿萨姆语、南非英语、迈蒂利语、马拉雅拉姆语、奥里亚语。

安卓这边也掉过

别以为系统级清单就只进不出。安卓8.0有477个条目、182门语言，到8.1变成474个条目、180门语言。掉出去的两门是恩甘贝语和提格里尼亚语。

安卓的清单在这十年里整体是涨的，7.0是476条181门，10是514条181门，12跳到583条197门。但涨的过程里穿插着这种局部的减少，而减少从来不带解释。

提格里尼亚语是厄立特里亚的官方语言之一，也是埃塞俄比亚提格雷州的主要语言，使用者数百万。它就这么从系统清单里消失了，而且到安卓10还没回来。

这跟本站在非公历纪年那一篇里遇到的情况是同一个方向：提格里尼亚语在那份数据里同样是整段不存在，用户看到的纪年名是程序里的占位符。同一门语言在两套完全无关的数据里同时缺席，这种巧合通常不是巧合。

所以这份清单量的到底是什么

把三条线索并起来：进来靠有人持续跟，出去靠那批人不在了，跟语言的人口规模没有直接关系。

这一条推翻了一个很常见的默认假设：以为这类清单是按使用人数排的。按人数排的话，豪萨语、约鲁巴语、伊博语这三门加起来两亿多使用者的语言，不该一门都进不了浏览器的正式清单。

这份清单量的不是一门语言有多少人说，是这门语言有没有一个还活着的技术社区。对做市场判断的人来说，后面这件事其实更有用——它预测的是你能不能在当地找到会做本地化的人。

清单长度是被谁撑起来的？

回到那个514。它比181大得多，多出来的部分值得单独看一眼。

英语一门语言占了103个条目

安卓那份清单里，条目数排前面的语言是这样的：英语103个地区版本、阿拉伯语55个、法语46个、西班牙语27个、葡萄牙语9个、塞尔维亚语8个、德语和荷兰语各7个。

这个分布本身就说明清单是怎么长出来的：它不是按语言一条一条加的，是按市场一个一个加的。每开一个新市场，主流语言就多一个地区条目。

光英语一门就占掉了整份清单的两成。这103个里有美国英语、英国英语，也有加拿大、澳大利亚、印度、南非、爱尔兰、新西兰、尼日利亚、肯尼亚，一路排到一些人口只有几十万的岛国。

阿拉伯语那55个也是一样的道理，从摩洛哥一路排到阿曼。这跟本站在阿拉伯语那一篇里讲的方言分布对得上——系统愿意分55个地区，说明这些地区之间的差别是被承认的。

130门语言只有一个地区版本

另一头是这样的：181门语言里，有130门在清单里只有一个条目，没有任何地区变体。

更值得看的是这130门里绝大多数连语言加国家的写法都没有，只有一个孤零零的两位或三位代码。在很多系统里，这种没有地区的写法会走到一套默认参数上，而那套默认参数不一定适合任何一个具体市场。

这130门里，有61.5%在两家浏览器的清单里一条都找不到。只有一个地区版本，往往意味着这门语言在这套系统里只是被登记了一下，不是被认真分市场对待。

地区版本数量本身是一个商业信号

反过来看更明显：有5个以上地区版本的语言只有10门，阿拉伯语、德语、英语、西班牙语、法语、荷兰语、葡萄牙语、俄语、塞尔维亚语、中文。

塞尔维亚语出现在这个名单里有点意外，它的使用者不到一千万。原因是它有两套书写系统，西里尔和拉丁各要一份，再乘上几个国家，条目数就上去了。这跟本站在双字母体系那一篇里说的是同一件事。

这10门全部出现在浏览器清单里，一门不落，命中率100%。地区变体这件事要花人力去分，谁愿意分谁就是真在做这个市场。

这跟本站在西班牙语两个市场那一篇和葡萄牙语那一篇里说的是同一件事的两个面：肯拆地区，说明拆了有收益。

别拿区域组合数当语言数用

这一节最实用的一句话是个提醒。你在任何地方看到“支持超过五百种语言”这类说法，先问一句数的是不是区域组合。

这类说法在采购和立项材料里出现的频率相当高，而且往往被当成一个正面指标写进去。

514和181之间差着一个英语的103和阿拉伯语的55。报数的时候不说清口径，同一份文件能报出差2.8倍的两个数。这跟本站在区域数据自有率那一篇里踩过的坑是同一类：数格子之前要先问格子里装的是什么。

这件事怎么落到你的报表和你的站上？

数据讲完了，说落地。这一层的坑几乎全部长在同一个地方：你以为你在观察用户，其实你在观察用户的设备。

下面这几条按能落地的顺序排，从改口径开始，因为那是唯一一件当天就能做完的事。

语言维度报表会系统性低估小语种

最直接的一条：统计工具里那个“浏览器语言”或者“用户语言”维度，读的是设备设置，不是用户会说什么。

这个维度在做多语言站的人那里通常权重很高，因为它看起来比地理位置更贴近“用户是谁”。实际上正好相反，地理位置至少是从网络层测出来的，语言维度是从一个用户可能从来没碰过的设置项里读出来的。

目标语言不在设备清单里的市场，这个维度在报表上会稳定地偏向英语或者当地的第二语言。你看到老挝语用户占比0.3%，不代表老挝人不来，代表他们的机器发不出老挝语这个信号。

怎么验这个猜测？找一批已知来自该国的会话，看它们报上来的语言分布。如果本地语言的比例远低于当地的语言使用比例，而英语或者前殖民语言异常高，基本可以确认。

可操作的替代口径是：拿地理位置维度当主口径，语言维度只当辅助。两个数打架的时候，信地理位置那个。

自动跳转与语言协商会一起失效

按语言偏好自动跳转这套做法，在清单外的语言市场上是空转的——那批用户的请求头里根本没有你要匹配的那门语言。

更糟的一种情况是自动跳转做成了强制的：用户报英语，站点直接把他甩到英文版，还不给回头路。这批用户可能正是最需要本地语言的那批人，而他们连选一次的机会都没有。

语言标签匹配的那份规范定义了两种查找方式，一种要求前缀逐级回落，一种允许通配。两种算法都只能在用户实际发出的那几个标签里挑，用户没发出来的，任何算法都变不出来。

所以这类市场上，页面里那个明显的语言切换入口不是可选项，是唯一可用的通道。这一层的架构做法归国际SEO那一侧，本站在多语言站的标注与切换那一篇里写过，这里不重复。

入口的位置也有讲究：这批用户第一次落地大概率是在一个内容页而不是首页，所以切换入口不能只放在首页顶部。

桌面和手机会给你两套语言信号

还有一条更细的：同一个人在两台设备上给你的语言信号可能不一样。

这件事在做归因的时候会造成一个隐蔽的后果：同一个人的两次会话被判成两种语言，跨设备的路径就断在这里了。

他的安卓手机出厂就是本地语言，他的公司电脑装的Chrome只能选英语。这不是假设，是三份清单的差值直接推出来的结果——差的那128门语言，全都会产生这种分裂。

本站在阿拉伯语手机端那一篇里讲过一个相近的现象：中东有相当比例的用户系统界面是英文的，页面内容却是本地语言，所以判断页面方向绝不能去读系统语言。这两件事的根子是同一个——设备设置和用户身份不是一回事。

报表按设备拆开之后才对得上

落地动作很简单：把语言维度和设备类型交叉着看。

具体做法是拉一张两维表，行是语言、列是设备类型，看每一门语言在移动和桌面之间的比例。正常情况下这个比例在各语言之间应该大致接近，出现明显离群的那几门就是被清单卡住的。

如果一门语言在移动端的占比明显高于桌面端，而且高得不合常理，多半就是这个机制在起作用，不是移动端用户真的更爱说母语。

写内容那一侧要跟着调

最后一条落到内容上。清单外的语言市场，用户看到的界面是英语，看到的输入法可能也是拉丁字母的，他打进搜索框的东西会更像本站在希腊语拉丁转写那一篇里描述的那种混合形态。

还有一层影响在输入法上：桌面端如果系统语言是英语，用户装本地输入法的动力也会低一些，打出来的东西更容易是拉丁转写。本站在品牌名由输入法决定那一篇里说过，可输入性从来不是语言的属性。

做词表的时候把拉丁转写那一栏留出来，比纠结本地字母的十几种变形更划算。

这份清单能不能当语言优先级的一个输入项？

能，但要限定它回答什么。

半小时能查完的三个地方

第一，安卓的区域配置文件，搜你的语言代码，看在不在。第二，Firefox的出货清单，同样搜一遍。第三，Chrome的构建配置，注意区分总清单和只给安卓的那一份。

要查历史版本也简单：把网址里的版本标签换掉就行，安卓换成别的系统版本号，Chrome换成别的版本号。想知道一门语言是哪一年进的，二分几次就能定到具体版本。

搜的时候注意两位和三位代码可能都要试。有些语言在不同清单里用的位数不一样，只搜一种会漏。

三个文件都在公开仓库里，纯文本，浏览器直接打开就能搜。整个过程不需要任何账号和工具。

三档判读

三家都有：这门语言的软件基础设施是完整的，语言协商能正常工作，报表里的语言维度可信，可以按常规做。

这一档还有一个附带的好处：这门语言大概率有可用的拼写检查、断行规则和排序规则，做站的时候不用为这些底层能力单独想办法。

只有安卓有：移动端能用，桌面端的用户会被记错语言，切换入口必须显眼，报表要按设备拆。

这一档是本文最想提醒的一档，因为它最容易被误判成第一档。查的人只查了安卓，看到有就放心了，而实际的坑全在桌面端。

三家都没有：这门语言在软件世界里几乎没有落脚点，别指望任何自动机制帮你识别用户，页面上一切都要写死并显式提供。

这一档还有一个连带后果值得提前想到：这门语言大概率也没有可用的排序规则和断行规则，本站在大小写转换那一篇里写过这类底层能力缺失的具体样子。

落到这一档也不等于不能做，只是所有靠自动机制省下来的活都得自己干一遍，成本要按这个前提重新估。

它回答什么，不回答什么

它回答的是“有没有落脚点”，不回答“这门语言有没有需求”，也不回答“翻得完不完整”。

它也不回答用户实际把设备设成了什么。清单里有，不代表用户就选了；很多人拿到手机就没动过语言设置。所以这把尺子给的是上限，不是现状。

本站量过的其他几把尺子——内容存量、译入比例、页面阅读中位数——各自回答另一个问题。这几把尺子给出的排序不一致是常态，比如阅读中位数那一篇里排在前面的老挝语，在本文这份清单里两家浏览器都没有。尺子给出矛盾结论的时候，不要挑一个信，要去问它们各自在量什么。

什么时候可以不查

做的是三家都有的那62门语言之一，可以跳过。做纯移动端的产品，只查安卓那一份就够。

不过就算跳过，也建议在立项文档里留一句说明为什么跳过，免得后面接手的人重新纠结一遍。

需要查的是这几种情况：目标语言不在常见清单里、报表的语言维度看着不对劲、准备上语言自动识别、或者要给一门没做过的语言写立项材料。

写进立项材料的时候怎么说

建议写成一句带数字的话，别写成结论。比如“这门语言在安卓系统清单里有、在两家主流浏览器里都没有，因此桌面端流量的语言归属不可信，切换入口需要显式设计”。

顺便一提，这类查得出来、复核得了的一手事实，在评审里的分量比任何第三方报告都重，因为它不需要对方相信你，只需要对方愿意点开链接。

这句话既给了事实也给了动作，评审的人不用去查也能判断你是不是编的。

我一开始猜错了哪几条？

开工前写了八条预期，跑完发现错了七条。

把预期先写下来这个习惯，本站这几批一直在坚持。它的价值不在于证明自己聪明，恰恰相反，在于逼出那些“听起来完全说得通但事实不是这样”的判断。

以为Chrome桌面清单在稳步增长

这是错得最没道理的一条。默认印象是这类清单每年都会加几门，实测2014到2019五年是净减少，从53到51。

为什么会有这种默认印象？大概是因为软件的其他方面确实一直在长——功能在加，平台在加，支持的格式在加。语言这一项被顺手放进了同一个心理模型里。

顺着这条错误往下想会得出“再等两年就有了”的判断，而真实情况是等了五年什么都没等到，然后在2020年一次性给了安卓。

以为两家浏览器是包含关系

以为大的清单会把小的包住，实测两边各有各的独家：Firefox独有22门、Chrome独有10门，而且方向完全相反，一边是欧洲区域语言，一边是亚非大人口语言。

这条错误还有一个副产品：它说明拿一家的清单当代表是不行的。你查了Chrome没有就下结论，会漏掉整整22门在Firefox里活得好好的语言。

这条错得有价值——它逼出了那个机制解释，也就是社区驱动和市场驱动的分野。

以为安卓少的和iOS少的是同一批，这条猜对了

这条猜对了，9门里重合8门。但它差点被自己的统计脚本毁掉：第一版脚本拿Chrome 83去比两份缺失清单，算出交集为零，而零这个结果看起来比八更像一个发现，差一点就写进结论里了。

回头查才发现问题出在版本上：安卓那份缺失清单在80版重构时就被删掉了，83版里它根本不存在，两个空集合当然交集为零。跨版本比两份清单之前，要先确认这两份在同一个版本里都还活着，否则算出来的不是差异，是其中一份的消失。

这条错误也留下一条判据：同一个产品在不同平台上的语言支持可以完全不同步，而这种不同步在任何面向用户的文案里都不会被写出来。

猜对的那一条

唯一猜对的是量级：预估三家清单差2到3倍，实测3.4倍。方向和数量级都对，只是低估了一点。

低估的那一点也有解释：预估的时候心里想的是两家浏览器之间的差距，忘了系统级清单跟应用级清单本来就不是一个量级。

另有一条不在预期里的意外收获：那10门有5个以上地区版本的语言，命中浏览器清单的比例是100%，一个例外都没有。这种干净的100%在这类数据里很少见。

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

最后划一下边界，免得把不属于这一格的东西塞进来。

划边界的原因不只是为了不越界。这几件事的负责人不一样，混在一起写进一份文档，最后谁也不会认领。

还有一类问题也不在这里：这门语言的内容该怎么写、该找谁审。那属于交付质量，本站在母语审校验收那一篇里单独讲过。

翻译完成度不在这里

清单里有这门语言，只说明有一份语言包在。这份语言包翻了多少、哪些位置先翻、哪些位置留在最后，是另一件事，本文一个字都没量。

本站在别的批次里量过这一层，结论是完成度会随着软件长大而往回掉，跟本文这份清单是两条独立的线。一门语言可以在清单里待着，同时语言包完成度一路下滑。

内容的语言不在这里

界面语言和内容语言是两条线。用户把系统设成英语，不代表他不看本地语言的内容；反过来，系统是本地语言也不代表他只搜本地语言的词。查询语言的切换行为归关键词调研那一侧管。

本站在两个市场关键词表一样落地页不一样那一篇里讲过相近的分层：同一份输入在不同层上会导出不同的动作，把层混了，动作就会互相打架。

hreflang与站点结构不在这里

多语言站怎么标注、用什么域名结构、切换器怎么放，全部归国际SEO那一层，跟具体是哪门语言无关。本文只管“这门语言在不在清单里”，这是语言层的事。

一个简单的分界法：把语种换成英语之后这个问题还成立的，归架构层；不成立的，才归语言层。本文这份清单显然属于后者，因为英语从来不会不在清单里。

交给谁

查清单这件事归做市场判断的人，二十分钟。报表口径的调整归数据那一侧。语言切换入口的设计归前端和产品。最容易掉在缝里的是第一步——因为它看起来不像任何一个岗位的活，但不做它后面三件事全都建在错的前提上。

最后给个时间账：三份清单查完二十分钟，报表口径改完半天，切换入口重做一到两天。这三件事的成本差一个数量级，而第一件的成本最低、决定性最强。

常见问题解答

怎么快速查一门语言在不在这三份清单里？

三份文件都是公开的纯文本。安卓的叫区域配置资源文件，在系统框架仓库里；Firefox的叫出货清单，在浏览器的本地化目录下；Chrome的写在构建配置里，文件名带locales字样。用浏览器打开原始文件，直接搜两位或三位语言代码就行。要注意Chrome那份得分清总清单和只给安卓的那一份，前者会让你高估。

安卓清单里有这门语言，是不是就等于用户能设？

基本等于，但有两个例外。一是厂商定制系统可能会裁剪清单，中低端机型尤其常见。二是清单里有条目不代表这门语言的字体一定在机器上，字形缺失的时候会显示成方框。所以查完清单之后，最好还是在目标市场找一台真机看一眼。

浏览器清单里没有，用户是不是就完全用不了这门语言？

不是。用不了的是浏览器自己那套界面，网页内容照样能正常显示和输入。影响主要在两处：一是这个用户发出的语言偏好里没有这门语言，你的自动匹配接不住他；二是浏览器自带的翻译提示可能会误判，把本地语言页面当成需要翻译的外语页面。

这份清单跟一门语言的搜索需求有关系吗？

相关性很弱，别当同一件事用。清单反映的是有没有技术社区和市场投入，需求反映的是有没有人在搜。两者可以严重背离，最典型的是一门语言有健全的软件支持但商业搜索几乎为零，也有反过来的。判断投入优先级至少要两把尺子一起看。

只有安卓有的那批语言，站该怎么做？

三件事。第一，语言切换入口做得足够显眼，不能藏在页脚，因为自动识别对这批用户是失效的。第二，报表按设备拆开看，桌面端的语言维度直接放弃，只用地理位置。第三，词表里把拉丁转写那一栏补上，这批用户在桌面端很可能是用拉丁字母输入的。

这个数字过一两年会不会变？

会变，但变得很慢，而且方向不一定是增加。从公开记录看，主流浏览器每年新增的语言是个位数，同时还会有移除。所以这份清单可以一年查一次，不用盯着。真正要盯的是你自己那门语言有没有出现在移除名单里，那通常意味着当地的技术社区出了状况。