语言选择器里写Deutsch还是German，179门语言里有136门这两个词毫无关系

摘要：把179门语言的自称和英文名逐条摆在一起对了一遍。四分之三的语言，这两个名字连词根都不沾边，德语自己写作Deutsch，芬兰语写作suomi。近三成的自称根本不是拉丁字母，在一份按字母排的列表里没有位置。更要命的是排序键：按语言代码排跟按英文名排只差5位，跟按自称排差28位——按代码排序不是中立的技术选择，它就是按英语排序。

上一篇算完了一件事：你的目标语言在不在设备和浏览器的清单里。这一篇往前挪一格，问一个更早发生的问题。

这一格的问题比清单本身更早发生，也更容易被跳过——毕竟“把语言名写上去”看起来不像一个需要做决定的动作。

假设它在清单里。用户打开那个列表，往下翻，翻到第几行会停下来？

他要找的是自己那门语言的名字。问题在于，那个列表上写的是不是他认得的那个词，以及那个词有没有排在他会去翻的位置。

这两件事互相牵扯：写哪个名字决定了用户认不认得，按什么排决定了他要翻多久。而这两个决定通常由不同的人在不同的时候做出，谁也没跟谁商量。

保哥把这两件事量了一遍。样本取的是安卓系统清单里那181门语言，逐门去公共区域数据仓库里取三样东西：这门语言自己怎么称呼自己、英语里怎么叫它、中文里怎么叫它。有179门三样都拿到了。

数据源用的是公共区域数据仓库2020年4月那一版，每门语言在自己的文件里都会写一遍自己叫什么，这就是自称的来源。英文名和中文名分别取自英语和中文那两份文件。三个数都可以按版本号翻回去复核。

结果里有一条数字比预想的高出一倍：179门语言里，自称和英文名连词根都对不上的有136门，占76.0%。

用户在你的语言列表里找得到自己吗？

先说这件事为什么值得单独量，因为它看起来像个体验细节。

一个德国用户的十秒钟

你的站有一个语言切换器，里面按字母排着二十来个选项。一位德国用户想切成德语。

他不会读整份列表。眼睛会先估一个大致位置，跳过去，再上下微调。这个估位置的动作依赖的是他脑子里那个名字的首字母，而不是别的。

如果列表写的是英文名，他要找的是German，排在G。如果列表写的是自称，他要找的是Deutsch，排在D。这两个位置在一份二十项的列表里差着七八行，在一份一百项的列表里差着几十行。

更麻烦的是第三种做法：列表按英文名排序，但每一行显示自称。于是屏幕上出现的是一串按看不见的规则排列的陌生词，用户既没法按首字母定位，也没法一眼扫到。

这种组合在实际站点上并不罕见，因为排序往往写在后端，显示名往往写在前端模板里，两边各自都很合理，合起来就成了这样。

这不是德语一门语言的问题

德语只是最好举的例子。同一类的还有一长串：芬兰语自称suomi，英文名Finnish；匈牙利语自称magyar，英文名Hungarian；巴斯克语自称euskara，英文名Basque；威尔士语自称Cymraeg，英文名Welsh；爱尔兰语自称Gaeilge，英文名Irish。

反方向也一样成立：一个只知道Finnish的运营，在一份写着自称的列表里找芬兰语，他要找的是suomi，排在s。这不是母语用户专属的麻烦，是两套名字之间的双向不透明。

这一层跟词表那边的分裂是同一个形状。本站在品牌名转写那一篇里写过：一个东西在两个语言环境里有两个名字，而你的页面标题只能写一个。语言本身的名字也逃不掉这条。

这几对里没有一对能靠首字母对上，也没有一对能靠拼写猜出来。

有意思的是这几门语言的国家在国际上一点都不小众。这说明名字对不上跟这门语言的地位没关系，跟它历史上是被谁命名的有关系。

量化之后的比例

把179门语言逐条比对，判据取得很宽松：只要自称和英文名的前三个字母重合，或者其中一个是另一个的前缀，就算共享词干。

之所以放这么宽，是想让结果尽量偏向“其实对得上”这一边。判据越宽，最后算出来的不同比例就越保守，结论也就越站得住。

这么宽松的判据下，共享词干的只有43门，24.0%。剩下的136门，也就是四分之三，两个名字之间没有任何字面线索。

那43门里多数是本来就同源的，比如Nederlands跟荷兰的关系、italiano跟Italian、português跟Portuguese。也就是说对得上的那批，是拉丁语系内部互相借词的结果，不是有人刻意统一过。

这一篇要回答什么

三个问题。一，两个名字差多远，用数字说。二，按什么排序，用户的定位成本最低。三，你的切换器上到底该写哪一个。

这三个问题的共同点是：它们都不需要多语言能力就能自己验，只要一份对照表和一次排序。这跟本站在工具没有数据时自己补那一篇里的思路一致，能自己量的东西就别等别人给。

不回答的是翻译质量、语言检测、以及切换器放在页面哪个位置。最后那件事归站点结构那一层。

自称跟英文名到底差多远？

光说“不一样”不够用，得知道不一样到什么程度。

下面四个数分别从四个角度量同一件事：字面关系、书写系统、跨语言的名字数量、以及有多少语言压根没有名字。

四分之三没有字面关系

前面那个76.0%是第一个数。它的意思是，一个只认得自称的用户，看到英文名列表时，四分之三的情况下连蒙都蒙不出来。

反过来读更直观：一个只认得英文名的运营，看一份写着自称的列表，也是四分之三的情况下认不出来。这个双向对称性说明问题不在谁的英文好不好。

而且这不是小语种特有的现象。荷兰语自称Nederlands英文名Dutch，希腊语自称 Ελληνικά 英文名Greek，阿尔巴尼亚语自称shqip英文名Albanian——全是有独立国家、有完整教育体系的语言。

这一条对做判断的人挺重要：不要指望“大语言应该没问题”。德语、荷兰语、希腊语、匈牙利语、芬兰语，全在对不上的那一边。

近三成的自称压根不是拉丁字母

第二个数更硬：179门语言里，自称不用拉丁字母写的有51门，占28.5%，横跨27种书写系统。

27种书写系统这个数字本身值得停一下——它意味着这份清单如果原样排出来，会同时出现二十多套互不兼容的字母表，而排序算法只能选一套规则。

西里尔字母12门，阿拉伯字母6门，天城文5门，汉字3门，孟加拉文和藏文各2门，剩下的埃塞俄比亚文、切罗基文、希腊文、古吉拉特文、亚美尼亚文、彝文、格鲁吉亚文、高棉文、卡纳达文、谚文、老挝文、马拉雅拉姆文、缅甸文、奥里亚文、古木基文、僧伽罗文、泰米尔文、泰卢固文、泰文、提非纳文各一门。

这里面几门本站单独写过：希腊语的自称 Ελληνικά 全是希腊字母，而希腊语那一篇里量过，希腊用户自己在搜索框里大量使用拉丁转写。也就是说他打得出Ellinika，你的列表却只写 Ελληνικά，搜索框仍然接不住。

这批语言的名字在一份拉丁字母序的列表里，物理上没有位置——它们要么被一股脑堆在最后，要么按码位排出一个跟任何人的直觉都无关的顺序。

更麻烦的是不同的实现会给出不同的结果：有的按码位排，有的按语言无关的默认排序规则排，有的干脆保持原始顺序。同一份数据，三个前端框架能排出三种顺序。

同一门语言在十份清单里有几个名字

再换个角度。取十种常见的界面语言，看同一门语言在这十份清单里分别叫什么。

这十种界面语言的选择不是随便挑的：它们各自的区域数据文件里都收了五百门以上的语言名，样本足够密，能横着对。

德语这一门：英语叫German，中文叫德语，法语叫allemand，俄语叫 немецкий，阿拉伯语叫 الألمانية，而它自己叫Deutsch。六种叫法，六个不同的词根。

再看一门非拉丁的：格鲁吉亚语自称 ქართული，英语叫Georgian，中文叫格鲁吉亚语，法语叫géorgien，俄语叫 грузинский。前四个还有点词根上的亲缘，俄语那个跟自称和英文名都不搭。

把179门语言全跑一遍，一门语言在十份清单里平均有6.7个互不相同的名字词头。换句话说，语言的名字不是一个标识符，是十份互不兼容的本地知识。

顺带说一句，中文这一份的名字几乎全是从英文名音译过来的，不是从自称音译的。芬兰语不叫“苏欧米语”，匈牙利语不叫“马扎尔语”。中文用户脑子里那张语言地图，底稿是英语的。

这条对做中文站的人有个直接后果：你在中文界面上写“芬兰语”，一个芬兰用户完全认不出来；写suomi，中国运营完全认不出来。中文站的语言列表比英文站更需要两个名字都写。

规范其实说得很清楚

这件事不是没人管过。区域数据标记语言规范里关于显示名的那一部分把语言名定义成一种需要逐语言翻译的数据：每一份区域数据文件里都有一整块，写着这门语言怎么称呼其他所有语言。

给译者的那份翻译指引写得更细，连什么时候该用简称、什么时候必须带限定词、名字该不该首字母大写都规定了。这类规则本身就说明这件事复杂到需要一份规范。

也就是说，语言名从设计上就不是全局唯一的，它是一个二元函数——你用哪门语言问，得到哪个答案。

这跟语言代码的性质正好相反：代码是全局唯一的，名字不是。很多系统把两者当成一回事，用代码当主键、把名字当代码的属性，这个模型从一开始就少了一维。

能拿到名字的语言只有一小撮

还有一个数值得记住。语言子标签的官方注册表里登记了八千多门语言，而公共区域数据仓库能给出英文名的只有620门，7.5%。

差距还不止在数量上。那620门里，越靠后的语言名越可能是英文名的原样照抄，也就是说“有名字”和“有本地化的名字”之间还有一层落差。

能被安卓选成系统语言的181门，占登记语言的2.19%。绝大多数被正式登记过的语言，连一个可以显示在界面上的名字都没有。

这个2.19%可以当成一条粗判据：如果你的目标语言不在那181门里，那它大概率在剩下97.8%里，界面这一层的一切自动机制都指望不上。这跟本站在界面语言清单那一篇里的三档判读是同一套输入。

按字母排序，对哪批用户成立？

排序这件事平时没人当回事，因为在英文语境里它天然成立。

英文名和英文界面天然共用一套字母表，所以在英语环境里，用户脑子里的顺序和屏幕上的顺序是同一个。这个巧合让整件事看起来根本不存在。

一个可以直接量的指标

做法很简单：把179门语言按英文名排一遍，记下每门语言的位次；再按自称排一遍，记下位次；两者相减取绝对值。

非拉丁字母那批怎么处理？统一放在拉丁字母之后，组内按码位排，这也是多数默认实现的做法。换一种放法数字会变，但方向不会变。

这个差值就是“用户按自称去找、列表按英文名排”时，他实际要跨过的行数。

它量的不是认知负担，是物理距离。用户可能一眼就认出自己的语言，但如果那一行不在他估计的位置附近，他还是得翻。

中位数34位

结果是：中位漂移34位，均值50位，最大167位。179门语言里，漂移超过50位的有68门，占38.0%。

均值50比中位34高不少，说明分布是右偏的——大多数语言漂移不算太远，但有一批漂得极远，把均值拉了上去。这批就是非拉丁字母那51门。

34位是什么概念？一屏能显示十几行，34位意味着用户要多翻两三屏，而且他不知道该往哪个方向翻。

而且方向是随机的。有的语言按自称排更靠前，有的更靠后，用户没法形成一个稳定的习惯，每次都得重新找。

漂移最大的十门

排在最前面的是阿姆哈拉语，位次差167，几乎是整份列表的长度——英文名Amharic排在最前面那一段，自称 አማርኛ 用埃塞俄比亚字母写，在拉丁字母序里被甩到最后。

阿姆哈拉语这个例子还有一层：它在上一篇那份清单里是Chrome桌面版仅有的5门本站关注语言之一，也就是说它是少数几门“能选到”的语言，结果在列表里被排到了最远端。能选到和找得到，是两件事。

后面依次是威尔士语159位、约鲁巴语155位、粤语152位、切罗基语150位、阿萨姆语147位、缅甸语145位、中文144位、弗里西亚语143位、孟加拉语142位。

威尔士语这个例子特别值得看：Cymraeg和Welsh，两个词一个字母都不重合。而威尔士语是英国境内的官方语言之一，双语标识随处可见，这仍然没能让两个名字靠近一点。

这十门里有七门是非拉丁字母，另外三门是威尔士语、约鲁巴语、弗里西亚语——自称是拉丁字母，但首字母跟英文名差得远。

中文那144位也很典型：自称写作中文，英文名Chinese。中文这两个字在拉丁字母序里没有位置，只能被归到最后那一堆。一门使用者最多的语言，在按字母排的列表里排在最不显眼的地方。

拉丁字母那一半也没好到哪去

把非拉丁字母的51门剔掉，只看自称也用拉丁字母的128门。这一批理论上是最容易对上的。

这一批之所以值得单独看，是因为很多人会想当然地觉得“拉丁字母的至少能对上个大概”。

实测下来，首字母跟英文名不同的有64门，正好一半。捷克语自称 čeština英文名Czech，克罗地亚语自称hrvatski英文名Croatian，冰岛语自称 íslenska英文名Icelandic，卢森堡语自称Lëtzebuergesch英文名Luxembourgish。

还有更绕的：斯洛文尼亚语自称slovenščina，斯洛伐克语自称slovenčina，两个词只差三个字母，而它们的英文名Slovenian和Slovak差得明显。按自称排，这两门最容易被认混的语言会紧挨着；按英文名排，它们中间还隔着几行。本站在克罗地亚语与斯洛文尼亚语那一篇里说过这两个市场的距离，名字这一层又给它加了一道。

所以按字母排序对谁成立

结论其实挺尴尬：一份按英文名排序的语言列表，只对已经知道自己语言英文名的用户成立。

这句话可以再往前推一步：一份按英文名排的列表，是给已经不需要它的人设计的。

而这批用户恰恰是最不需要这个列表的那批——他们的英文足够好，看英文版也没什么障碍。列表的排序方式，把定位成本精确地压在了最需要切换语言的那批人身上。

怎么破？后面那一节给具体做法，核心是排序键换成自称，非拉丁的单独分组。

按语言代码排序是不是中立的？

很多站的语言列表是按语言代码排的，因为代码是数据库里的主键，排起来最省事，而且看起来最中立。

“按代码排”这个决定通常压根没被当成一个决定。数据库里的顺序是什么，前端拿到的就是什么，谁也没想过要重排。

三种排序键放在一起比

那就把第三种排法也量一遍：按语言代码排序，跟前两种各差多少位。

这一步是整篇最有说服力的一步，因为它把一个看起来是技术细节的选择，翻译成了用户要多翻几屏。

结果是这样：按代码排跟按英文名排，中位只差5位；按代码排跟按自称排，中位差28位。

5位和28位的意思

5位差不多就是同一屏之内。也就是说，你按代码排出来的顺序，跟按英文名排出来的顺序，用户几乎感觉不出区别。

换个说法：如果你的产品经理坚持按代码排、而设计师坚持按英文名排，两边其实在吵同一个方案。

28位则要翻两屏。按语言代码排序不是一个中立的技术选择，它在用户那里就是按英语排序。

因为代码本身就是按英语缩的

这个结果有个很直接的原因。把179门语言的代码前两位分别跟自称、英文名比对：跟英文名对上的54门，跟自称对上的只有9门，两者都对上的22门（词根本来就同源），两者都对不上的94门。

那94门两边都对不上的，多数是三位代码的小语种，它们的代码来自更早的编目体系，缩的既不是英文名也不是自称，而是当年编目者用的那个称呼。

这批代码的隐蔽麻烦在于它们看起来很随机，没法靠记忆校验。这跟本站在母语审校验收那一篇里说的是同一类问题：读着顺、格式对，都不等于对。

只看两位代码那113门：像英文名的31门，像自称的8门，差将近四倍。三位代码那66门更极端，像英文名的23门，像自称的只有1门。

三位那一批更极端是有道理的：三位代码大批量分配的时候，编目的人手上拿的是英文清单，一门语言的自称往往根本没被记录下来。

几个具体的例子

匈牙利语的代码是hu，来自Hungarian，不是来自magyar。芬兰语是fi，来自Finnish，不是suomi。威尔士语稍微好一点，代码cy来自Cymraeg，属于那9门里的。

再补两个：巴斯克语的eu来自Euskara，属于取自自称的；阿尔巴尼亚语的sq来自Shqip，也是。这两门都是自称跟英文名毫无关系、但代码跟着自称走的例子，正好说明这件事没有统一规则。

德语的de来自Deutsch，中文的zh来自中文的拼音，希腊语的el来自Elliniká——这几门是取自自称的。但它们是少数。语言标签的规范只规定代码怎么组合，不规定代码从哪个名字缩来，历史上就是各缩各的。

这也解释了一类特别隐蔽的事故：僧伽罗语是si，绍纳语是sn，两个代码只差一个字母，而它们的自称和英文名毫无相似之处。把si写成sn，格式完全合法，任何校验都放行，光看代码没有任何提示能让人警觉，只有把语言全名打印出来才看得见。

这条对做站的人意味着什么

意味着“我们按代码排，一视同仁”这句话在评审里说得过去，在用户那里说不过去。

补一句：这条不只对语言列表成立。任何一份用英文标识符当排序键的清单，在非英语用户那里都不是中立的，国家列表、时区列表、货币列表全一样。

如果你的列表超过十几项，而且面向的是非英语市场，按代码排等于把英语用户的定位成本转嫁给了所有人。

成本能不能量？能：中位28位乘上你的列表长度占比，就是平均每个用户多翻的行数。这个数拿去评审比任何形容词都管用。

为什么一整族语言挤在同一个字母下？

量首字母分布的时候撞见一件没预料到的事。

本来只是想画个首字母直方图看看分布均不均匀，结果有一根柱子明显比旁边高出一截。

字母k那一段特别拥挤

自称用拉丁字母的128门语言里，首字母是k的有25门，占19.5%。而这128门语言的英文名里，首字母是k的只有10门，7.8%。

英文名那一侧的分布倒是挺平的，最高的s占15门，m占11门，l和k各10门，没有哪一根柱子特别突出。

两倍半的差距，不像是随机波动。

随机波动能解释一两门的差别，解释不了25比10。

因为很多语言的名字自带一个类前缀

翻开那25门一看，规律非常明显：Kipare、Kitaita、Kimachame、Kikamba、Kishambaa、Kihorombo、Kinyarwanda、Kiruwa、Kiswahili……

这些名字的英文对应分别是Asu、Taita、Machame、Kamba、Shambala、Rombo、Kinyarwanda、Rwa、Swahili——除了基尼亚卢旺达语，英文名里都没有那个前缀。

这些是班图语族的语言。在这一族里，名词按类分组，每一类有自己的前缀，而“某某语”这个意思的名词恰好归在一个用ki- 打头的类里。于是十几门互不相干、分布在几个国家的语言，因为一条语法规则，在字母表里被挤成了一堆。

顺着这条线还能推一步：既然前缀表示“语言”这个类，那把前缀去掉剩下的部分往往是族群名或者地名。Kiswahili去掉ki- 是Swahili，Kikamba去掉是Kamba。英文名取的正是去掉前缀之后那一截。

不只是ki这一个前缀

同一族的还有别的写法：Ichibemba的ichi-、Ikirundi的iki-、Ekegusii的eke-、Rukiga和Runyankore的ru-、Luganda和Luluhia的lu-、Chimakonde的chi-、Gikuyu的gi-、isiZulu的isi-。

isiZulu这个写法尤其值得注意：它的前缀是isi-，所以按自称排会落在i那一段，而英文名Zulu在z，一头一尾。

把这些算上，179门语言里带类前缀的自称有23门。它们的英文名分别是Bemba、Rundi、Gusii、Chiga、Nyankole、Ganda、Luyia、Makonde、Kikuyu、Zulu——散落在B、R、G、C、L、N、Z各处，一点都不挤。

23门在179门里占12.8%，不算多，但它们全部集中在字母表的很小一段上，这个集中度才是关键。

这件事对排序的直接后果

如果你的产品面向东非市场，列表里同时有斯瓦希里语、卢干达语、基尼亚卢旺达语、基库尤语，按自称排它们会紧挨着，按英文名排它们会散开。

顺带一提，东非这几门语言在界面语言清单那一篇里的处境差别很大：斯瓦希里语在Chrome桌面版里有，卢干达语连Firefox都被移除过。列表里放在一起的选项，背后的软件成熟度可以差很远。

哪种更好？看用户是谁。对当地用户，挨着是对的——他一眼扫到那一段就知道自己的语言在附近；对总部做多市场配置的人，散开更符合他脑子里的地图。这不是审美问题，是两批人的检索路径不同。

如果实在拿不准，用分组解决：把同一地区的语言放一组，组内怎么排都不影响大局。

顺带纠正一个常见的写法

还有个细节：这类语言的自称在正式场合是带前缀的，缩写场合会去掉，比如Kiswahili和Swahili都能见到。

做搜索匹配的时候则要反过来：带不带前缀都要能搜到，输入swahili和kiswahili应该落到同一项。

做多语言字段的时候，别自作主张把前缀砍掉统一格式。这跟本站在地名的本地名与外来名那一篇里说的是同一条：名字的形态本身携带信息，规范化会把信息抹掉。

一半的语言，自称根本打不出来？

还有一个维度平时完全没人考虑：这个名字用户能不能敲进搜索框。

这个维度只有在给长列表加搜索框的时候才会浮出来，而加搜索框通常是列表变长之后的补救动作，那时候前面的决定都已经定死了。

能用纯英文键盘打出来的不到一半

把179门语言的自称逐条检查，看它们是不是只由ASCII字符组成。

判据取的是纯ASCII，也就是标准英文键盘不用切换输入法、不用组合键就能直接敲出来的字符集。

结果是87门，48.6%。超过一半的语言，它的自称在一台只装了英文键盘的机器上打不出来。

这个数字的另一半含义是：如果搜索框只匹配自称，你等于要求用户先有能打出自己语言名字的输入环境。而这批用户里有相当一部分正处在没有本地输入法的机器前——不然他也不至于要来切语言。

拉丁字母也不等于打得出来

非拉丁那51门打不出来是意料之中的。意外的是拉丁字母那128门里，有41门带非ASCII字符，占32.0%。

32.0%这个比例比预想的高。原因是欧洲语言的自称几乎人手一个变音符号，而英文名把这些符号全都抹平了。

čeština的 š 和 č、íslenska的 í、Gàidhlig的 à、español的 ñ、français的 ç、Ɓàsàa的 Ɓ、Kĩembu的 ĩ、Asụsụ Igbo的 ụ、Eʋegbe的 ʋ——这些字符在标准英文键盘上都要绕一道。

还有一类更隐蔽：字符看起来像ASCII，实际不是。比如某些语言用的是带钩的字母或者特殊形状的辅音，在小字号下跟普通字母几乎分不出来，复制粘贴过去却匹配不上。

这直接决定了搜索框该怎么做

很多站给长语言列表加了搜索框，这本来是对的。但如果搜索框只按显示名匹配，那对上面这批用户等于没有。

这类搜索框还有个常见毛病：只做前缀匹配。用户输入nemet想找德语，前缀匹配对Deutsch和German都没用。做成子串匹配加多字段匹配，成本几乎没有增加。

可用的做法是让搜索框同时匹配三样：自称、英文名、语言代码，并且对变音符号做归一化，输入ceska也要能匹配到 čeština。这一层的坑本站在法语重音符号那一篇里写过，机制是一样的。

如果想再进一步，把常见的第三方叫法也塞进匹配表，比如用户可能用自己母语里的叫法去搜另一门语言。这份表可以直接从区域数据仓库里导，一门语言一行。

大小写这一层还有一个雷

做归一化的时候要小心土耳其语。土耳其语的i转成大写不是I，做全局大小写折叠会把词改成另一个词，本站在大小写转换那一篇里专门写过这件事。

顺带还有一个跟排序有关的：不同语言对同一批字母的排序规则不一样，比如某些语言把带变音的字母当成独立的字母排在最后。做语言列表的时候通常用不区分语言的默认规则就够，但要知道自己用的是哪一套。

语言列表的搜索框正好是最容易踩这个雷的地方，因为它天然要做不区分大小写的匹配。

一条容易被忽略的收益

把自称、英文名、代码三样都做成可匹配，还有个附带好处：站内搜索和客服工单里，用户提到自己语言时用的词五花八门，这份对照表可以直接复用。

另外这张表还能用来做一件小事：把用户提交的自由文本语言字段归一化。表单里那个“您使用什么语言”的填空框，收上来的答案会同时包含自称、英文名和各种缩写。

那你的切换器上该写哪个名字？

数据讲完了，说落地。这一节给的是可以照着做的判断。

下面这几条按决策顺序排：先定写什么，再定怎么排，最后才是搜索框这类补救措施。

默认答案：写自称

先说结论。语言切换器上的每一项，应该用那门语言自己的名字写，而不是用当前界面语言的叫法。

这条结论在多数国际化指南里也是默认推荐，本文的贡献是给它配上了数字：76.0%的语言两个名字对不上，所以写错的代价不是偶发，是常态。

理由很直接：会来点这个切换器的人，是当前界面他看不懂或者不想看的人。用他看不懂的那门语言去标注他要切去的语言，等于让他在看不懂的东西里找看不懂的东西。

有个反例经常被拿出来：如果用户的英语足够好，写英文名他也认得。这话没错，但它把设计目标从“所有人都能用”降成了“会英语的人能用”，而这恰恰是切换器要解决的问题本身。

但有两种情况要例外

第一种：面向企业采购或者内部管理后台的语言配置界面。用的人是运营，不是终端用户，他脑子里的地图是英文名，这时候写英文名反而对。

这一类界面还有个特点：使用者要在几十上百种语言之间做批量操作，他需要的是可预测的顺序，不是可辨认的名字。两种需求是冲突的，分开做是对的。

第二种：列表极短，三五项，而且用国旗或者地区名做主标识。这种情况下语言名只是辅助信息，写哪个都行。

不过就算只有三五项，也建议顺手把自称写上——成本是零，收益是那批英语不好的用户不用猜。

两个名字都写行不行

行，而且在中大型列表上通常是最优解：主行写自称，后面用较小的字号跟一个当前界面语言的叫法。

两个名字的主次不能反。自称在前、当前界面语言的叫法在后，因为主要读者是前一种人。反过来放会让整份列表在视觉上还是一份英文列表。

这样按自称找的人和按英文名找的人都能扫到。代价是每一行变宽，在窄屏上要多占一行，这个账要自己算。

还有个附带好处：搜索引擎抓到的这一段文本会同时包含两套名字，这对本站在锚文本变形那一篇里讲的那种匹配问题有一点点帮助，虽然不多。

不要用国旗代替语言名

这条老生常谈但还是得说：国旗标的是国家，语言不是国家。西班牙语该挂哪面旗，阿拉伯语该挂哪面旗，英语该挂哪面旗，这些问题没有正确答案。

还有个更实际的理由：国旗图标在很多市场是政治敏感的，一个选错的旗子造成的麻烦比找不到语言大得多。

本站在西班牙语两个市场那一篇里说过，同一门语言在不同市场是两套词表；用一面旗去代表它，第一步就把这件事抹平了。

把语言标签写对

切换器每一项的链接上，把语言标签写进标记里。MDN关于语言属性的说明里提到一个很实用的细节：链接可以带一个属性声明目标页面的语言，这跟元素自身内容的语言是两回事。

具体写法是两处：一是给这一项的文本声明它自己的语言，这样浏览器和读屏知道该用哪套规则处理；二是给链接声明目标页面的语言。两者容易被混成一个。

这一条对读屏软件影响很大——切换器里那一串外语词，如果不声明语言，读屏会用当前页面语言的发音规则去念。一个中文页面上的Deutsch，读屏会按中文的规则拼读，念出来的东西没人听得懂。语言列表恰好是全站外语词密度最高的一个控件，也就是最需要逐项声明的地方。

排序和分组具体怎么做？

知道了写什么，还得决定怎么排。

排序这件事的判断依据只有一个：列表有多长。长度决定用户是扫还是找，扫和找需要的顺序不一样。

先问列表有多长

十项以内：怎么排都行，按流量大小排最实用，把主力市场放前面。

这一档反而要注意别过度设计。十项以内加搜索框、加分组，都是给自己找麻烦。

十到三十项：按自称的字母序排，非拉丁字母的单独成组放在后面或前面，组内按各自的顺序。

这一档是最需要认真做的，因为它长到不能一眼扫完，又短到用户不会想到去用搜索框。

三十项以上：必须加搜索框，排序退居次要，但仍然建议按自称排，因为用搜索框的人会先扫一眼。

这一档还建议在列表顶部单独放一个最近使用或者推荐的小组，三五项，直接命中大多数人。

非拉丁字母那一组怎么放

最省事也最不容易出错的做法是按书写系统分组，每组给一个小标题。拉丁字母一组，西里尔一组，天城文一组，东亚一组，其余合并。

分组这件事还有个额外收益：它顺手把字体问题也分好了组。同一组内的语言共用一套字形，加载策略可以一起定，本站在网页字体那一篇里算过这笔账。

分组的标题用什么语言写？用当前界面语言，因为组标题是导航信息，不是内容。这跟组内条目用自称写并不矛盾，两者承担的功能不同。

分组之后每一组内部的排序压力就小多了，因为组内条目通常不超过十几条。

东亚那一组要特别处理一下：中日韩三门语言的自称都是两三个字，按任何字母规则排都没有意义，按使用者规模排反而最直观。

印度那一组同样要单独想：本站在印度十一门语言九套书写系统那一篇里算过，光印度一个市场就能在你的列表里塞进七八套互不相同的字母表，按书写系统分组之后这一段会立刻清爽很多。

不要按代码排，除非列表很短

前面量过，按代码排等于按英语排。列表短的时候无所谓，长的时候这是一个实打实的成本转嫁。

如果你的列表是从某个开源组件里直接拿的，多半就是按代码排的。检查一下，这类默认值很少有人改。

如果因为技术原因必须按代码存储，那就在渲染时按显示名重排一次，这是前端几行代码的事。

重排的时候记得用一个稳定的排序，不然每次渲染顺序可能不一样，用户的肌肉记忆会被打乱。

验收怎么做

找三个母语者，让他们在你的列表里找自己的语言，记录用了几秒、翻了几屏、有没有走错方向。三个人就够，问题会立刻暴露出来。

如果找不到母语者，退而求其次：把列表里的名字全部换成你完全不认识的语言，自己找一遍。这个土办法能重现大部分问题。

另外可以顺手验一件相关的事：切换之后落地页对不对。很多站的切换器会把用户丢回首页，这在内容站上是实打实的流失，本站在小语种URL那一篇里提过相近的路径问题。

顺带把语言代码逐个丢进注册表反查一遍语言全名，人工扫一眼。同族易撞的代码不少，僧伽罗语是si不是sn，老挝语是lo不是la，斯洛伐克语sk和斯洛文尼亚语sl只差一个字母。

这个动作花不了五分钟，但它抓到的是那种格式完全合法、任何校验都放行、只有把全名打印出来才看得见的错误。

这套东西要不要做成配置

建议做成一张表，三列：语言代码、自称、当前界面语言的叫法。这张表跟本站在界面语言清单那一篇里说的那份查询结果放在同一个文档里，因为它们的输入是同一批语言代码。

如果要更完整，可以加第四列：这门语言的书写系统，用来做分组；第五列：常见的别名与旧称，用来做搜索匹配。五列就足够支撑一个上百项的列表了。

这张表的维护成本几乎为零，因为语言名不会变。它是本站这几年做过的所有对照表里唯一一份可以做完就不管的。

做成表还有个好处：以后加语言只用加一行，不用回头改模板。

我一开始猜错了哪几条？

这一批的预期错得比上一批还狠。

开工前写了八条，最后只有一条完全猜对。这个比例本身也算一条信息：语言名字这一层，日常直觉的可靠度接近于零。

以为自称跟英文名不同的占三四成

这是错得最厉害的一条。实测76.0%，比预估高出一倍还多。

低估之后会怎样？会觉得“大部分语言其实对得上，少数例外单独处理一下就行”，于是把一个需要系统性方案的问题当成了打补丁。

错的原因大概是脑子里的样本偏了——最先想到的例子是日语Japanese、韩语Korean、俄语Russian这类看起来对得上的，而这类恰恰是少数。

以为排序漂移的中位数在十几位

实测34位，均值50位。低估了一倍以上。

这条错误跟上一条是连着的：既然以为名字大多对得上，自然也就以为位次差不了多少。两个错误互相加固，这是最难自查的一种情况。

顺着低估的判断会得出“差几行而已，用户翻一下就到了”的结论，而34位在多数屏幕上是两三屏。

以为语言代码多半取自自称

这条错得有点丢人。因为最熟的两个例子德语de和中文zh恰好都是取自自称的，就默认这是常态。

而且这两个例子还都是本站最常用来举例的语言，等于把一个错误的样本反复强化了很多遍。

实测像英文名的是像自称的六倍。两个最熟悉的例子同时是例外，这种情况在做判断时几乎防不住，唯一的解法是把样本拉全再看比例。

补一句方法上的教训：判断“某类东西通常是什么样”的时候，先数一遍再说话，别从自己最熟的两三个例子外推。本站在译入比例那一篇里也吃过同一种亏。

顺带一提，本文这套量法有个明确的局限：它假设用户是按首字母定位的。对于自称和英文名都不认识、只认国旗或者只认地区名的用户，位次漂移这个指标解释不了他们的行为。

以为班图语的前缀不成规模

以为会有几门，实测ki- 一个前缀就11门，算上同族的其他写法23门，把字母k那一段的占比从7.8%推到19.5%。

这条错得倒是愉快，因为它带出了整篇最有意思的一个机制——一条语法规则可以改变一整族语言在界面上的位置。

猜对的只有一条：非拉丁字母的自称约占三成，实测28.5%。

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

照例划一下边界。

这一层的边界特别容易糊，因为语言选择器同时长在结构、交互、内容三个人的地盘上。

切换器放在哪儿不归这里

切换器该放页头还是页脚、该不该跟着滚动、要不要在没匹配到语言时弹提示，这些属于站点结构和国际化架构，跟具体是哪门语言无关。

同理，切换语言之后是留在当前页面还是回首页，也是结构层的决定。它很重要，但跟这门语言叫什么无关。

自动识别与跳转不归这里

按用户偏好自动选语言是另一套机制，而且它在很多小语种市场上是失效的——上一篇量过原因。本文假设的是用户已经决定自己动手切。

两者的关系是：自动识别越不可靠的市场，手动切换器越重要，于是本文这些细节的权重越高。

地名的两套叫法不归这里

语言名和地名都有本地叫法与外来叫法的分裂，但两者的落地位置完全不同：语言名长在界面控件上，地名长在内容和标题里。后者归地名那一篇。

还有一个相邻但不同的分裂：品牌名的本地写法。那个你能自己规定，语言名和地名都规定不了。

交给谁

那张三列对照表归做本地化的人，一门语言两分钟。排序和分组归前端。最容易掉在缝里的是“该写哪个名字”这个决定本身——它看起来像文案，实际上是一次检索路径的设计，而文案通常不做这类决定。

验收也建议交给同一个人，因为他是唯一能一眼看出“这个名字写错了”的人。让做前端的人验收这份表，等于让他去核对一批他不认识的词。

常见问题解答

语言切换器上到底该写自称还是英文名？

面向终端用户的站写自称，因为会来点这个切换器的人正是看不懂当前界面的人。面向运营的后台配置界面写英文名，因为使用者脑子里的地图就是英文名。列表超过十几项的时候，两个都写是最稳的方案：主行自称，后面小字跟一个当前界面语言的叫法。

按语言代码排序有什么问题？

它不中立。实测下来按代码排出来的顺序跟按英文名排只差5位，跟按自称排差28位，因为大多数语言代码本身就是从英文名缩来的。列表短的时候没关系，长的时候等于把定位成本转嫁给所有非英语用户。技术上必须按代码存的话，渲染时重排一次就行。

非拉丁字母的语言名在列表里怎么排？

按书写系统分组，每组一个小标题，拉丁一组、西里尔一组、天城文一组、东亚一组、其余合并。分组之后组内一般不超过十几条，排序压力就小了。不分组的话这批语言会按码位排出一个跟任何人的直觉都无关的顺序，而它们占到整份清单的近三成。

为什么很多非洲语言的名字都以ki开头？

因为班图语族的名词按类分组，每类有自己的前缀，而表示某某语的那一类恰好用ki- 打头。这不是巧合，是一条语法规则。后果是十几门互不相干的语言在字母表里挤成一堆，而它们的英文名散落在各处。做字段的时候别把前缀砍掉统一格式，那个前缀是词的一部分。

语言列表加了搜索框还需要管排序吗？

需要，但优先级降低。用搜索框的人通常会先扫一眼列表，扫不到才开始打字。更要紧的是搜索框本身要能同时匹配自称、英文名和语言代码，并且对变音符号做归一化——超过一半的语言，自称在英文键盘上打不出来，只按显示名匹配等于对这批用户没有搜索框。

用国旗代替语言名可以吗？

不建议。国旗标的是国家，语言不是国家，西班牙语、阿拉伯语、英语该挂哪面旗都没有正确答案。而且同一门语言在不同市场往往是两套词表，一面旗会把这个差别整个抹平。国旗只适合真正按国家分站的场景，而那时候它标的也不是语言。