语言代码注销实测：ISO 639-3十八年间385个退役代码的去向

摘要：把ISO语言代码从2006年到2024年的全部变更记录逐条翻完，一共1423条申请、2250行变更。截到2024年底，累计有385个语言代码被注销，其中46%是并进了别的语言、26%是被拆开，判定为查无此语言的只占19%。七成以上的注销，语言本身还在，只是换了归属，机械替换会把一门语言静默换成另一门。在册的7921门语言里，有两位代码的只有184门，占2.32%。你在hreflang里最顺手的两位码写法，覆盖不到在册语言的四十分之一。

有个问题被问过很多次，却很少有人真去查：挪威语在hreflang里该写no还是nb。

提问的人通常会得到一个模棱两可的回复：两个都行，看情况，挑一个别乱换。这个回复不算错，但它绕开了更根本的一点：no和nb由两个不同的机构、按两套不同的规则、为两件不同的事发出，两者的关系是写在一份文件里的，并非天然如此。

保哥今年秋天把那份文件认真翻了一遍。准确说是翻了一整个库：ISO 639-3的变更申请库。从2006年这套体系上线开始，每一次新增、改名、合并、拆分、注销，都有申请编号、提案和生效日期，全部公开挂在网上。

翻完之后会发现，自己一直当常量用的那两三个字母，其实是一份有人受理、有人评议、有生效日期的行政档案。它会变，而且变过很多次。

下面的数字全部截到2024年12月31日，按结果生效日期统计，不按申请年份。这个口径有实际差别：2021年提交的闽南语拆分申请，到2024年10月15日才出结果，按申请年份截会把它整条漏掉。

语言代码由哪些机构维护？

先把各方角色理清楚，后面的数字才有着落。

ISO 639分为好几册，并非一份标准

很多人把ISO 639当成一张表，其实它长期是分册的：两位字母一册、三位字母一册、覆盖更全的一册，还有语系一册，各有各的编号规则和维护机构。

2023年这几册被整合进同一份标准，编号规则不变，称呼变了。注册机构自己那页讲各分册关系的说明现在写的是Set 3，不再写Part 3。

这件事对你没有任何技术影响，一个字母都不用改。它提醒的是：连这套编号体系本身的组织方式都会变，里面具体的代码更会变。

顺带一提，网上很多讲hreflang的文章还在用老称呼，包括我自己早年写的那篇。称呼不影响正确性，但能看出一份资料是哪年写的。

对做SEO的人，只需记住一点：日常打交道的两位码来自其中一册，三位码来自另一册，两册的维护机构不是同一家，更新节奏也不同。

三位代码的注册机构是一家语言调查机构

三位代码这一册的日常维护，交给了一家长期做少数语言田野调查的机构。它负责受理申请、组织评议、撰写裁决，并每年发布更新后的码表。

这个安排能解释后面很多现象。受理方的知识背景是描写语言学和田野调查，所以它判断一门语言够不够格，几乎全看语言本身的证据，跟这门语言在政治上、商业上有多重要基本无关。

这也解释了这个库的样子：申请要写提案、附参考文献、接受公开评议，整个流程更像投一篇论文，而不像提一个工单。

还有一点要留意：受理方本身也在出版一份全球语言数据库，两边的语言划分高度一致。你在其他资料里看到的语言数量，很可能和这份码表同源。

这本身没问题，但意味着没法用那份数据库交叉验证这份码表。两者出自同一家，对得上是应该的，对不上才奇怪。

码表一年只更新一到两次

把2250行变更按生效日期铺开，最显眼的是分布，而非总量。2008年1月14日一天生效409行，2012年2月3日一天231行，2013年1月23日一天202行。

再看每年有几个生效日：2019年全年只有1月25日一天，2023年是1月20日和12月15日两天，2024年是4月3日和10月15日两天。

这张表一年只开一到两次闸，并非随时在变。语言代码对表一年做两次就够了，做十二次是浪费。知道这一点，这件事就从一个隐忧变成了日程上的一个条目。

2011年更极端，全年只有5月18日一个生效日期。2019年也一样，全年只有1月25日那一天。

语言代码为什么值得SEO人员花半天核对？

语言代码是少数能同时出现在站上五六个位置的东西：页面的语言声明、每一条hreflang、结构化数据里的语言字段、商品数据源的语言设置、分析报表的语言维度。

这几处分属不同的人维护，各自都以为写的是同一套东西。hreflang的完整用法讲的是这些标签之间怎么互指，这里要回答的问题更靠前：互指用的那串字符本身还成立吗？

还有一个更实际的理由：这几处只要有一处写着已注销的代码，排查时第一反应通常是怀疑代码写错了，很少会想到代码本身已经作废。方向一错，半天就没了。

这个坑我自己踩过一次。当时一个站的某个语言版本，在两个分析工具里的量差了接近一倍，查了两天配置，最后发现一个工具按新代码归类、另一个还按老代码，而两个代码指的是同一批人。

7921门在册语言中，有几门能用两位语言代码？

先给数字，再解释它为什么让人别扭。

7921门在册，184门有两位码

翻开2024年10月那次变更生效后的在册表，一共7921门语言。按类型拆：在用7076门、已灭绝602门、历史语言215门、人造语24门，另有4个特殊代码。

再数有两位代码的那一栏：184门。2.32%。

按这个比例，hreflang里那种两个字母的写法，能覆盖的语言不到在册语言的四十分之一。剩下的97.68%要么写三位码，要么在你的系统里根本没法表示。

顺便一提，这7921门里已灭绝的有602门。排语言优先级时，如果清单是从某个全量表直接拉的，记得先把这一栏筛掉，否则会算进一批已经没有人在说的语言。

184门两位码里有35门是宏语言

再细一层：这184门里，有35门的范围标注为宏语言，只有149门是个别语言。

宏语言后面有一整节专门讲，这里先给结论：你写zh、ar、ms这几个最常见的两位码时，写的并非一门语言，而是一个装着若干门语言的口袋。

再往细看，184门按语言类型拆，是174门在用、5门历史语言、5门人造语。这份最短、最好用的清单里，还挤着拉丁语这类没人日常说的语言，以及世界语这类人造语言。

它们当然可以有代码。问题在于，把两位码当作重要语言的近似值时，这份名单的构成会让近似值偏得比想象的多。

反过来看也成立：有两位码的149门个别语言，是这套体系里表示得最完整的一批。它们在几乎所有系统里都能被正确处理，这正是它们和其余七千多门语言最大的差别。

两位码短缺是设计使然，并非历史遗留

有人会觉得这是历史包袱，早晚会补齐。补不齐。两位字母一共只有676个组合，扣掉保留段和已用段，剩下的位置装不下七千多门语言。

RFC 5646定义的语言标签规则写得很清楚：有两位码的用两位码，没有的用三位码。这条规则本身就承认了两套编号会长期并存。

所以别等它补齐，从一开始就假定你的链路要同时支持两位码和三位码。做印度、非洲、东南亚市场时，这一点几乎必然会碰到。

这条规则还有个不太直观的后果：同一门语言在不同系统里可能写成不同长度的代码，而两种写法都合规。做数据对齐时，得先做一次归一化。

归一化应该统一到三位码，因为三位码是全集，两位码是子集。反过来做会丢掉97.68%的语言。

两位码覆盖率怎样限制小语种的取舍？

做小语种优先级和成本测算时，有一个很少写进模型的成本项：这门语言在你的技术栈里能不能被表示。

能不能表示有具体的检查点：分析工具的语言维度里有没有这个选项，广告后台的定向里有没有，内容管理系统的语言下拉里有没有，翻译服务商的语言列表里有没有。

这几处的清单长度差别很大。按两位码建的，可用的就是184门；按三位码建的，才是七千多门的量级。先查自己链路上最短的那一环，它决定了这门语言在你这里的上限。

另一个观察：越靠近内容生产端的工具，语言清单越长；越靠近投放和分析端的工具，清单越短。所以卡住你的通常是量不出来，而非写不出来。

顺手可做的一次语言代码自查

找一个下午，把站上所有出现过语言代码的位置列出来，逐个记下用的是两位还是三位、允许填几位、填错会不会报错。

保哥帮一个做户外装备的独立站做过一次，一共找出七处：三处只接受两位码，两处两位三位都收但不做校验，还有两处的下拉框是几年前手工维护的，里面留着两个早已注销的代码。

后面会讲到的正是这类已注销代码，它们是本文的重点。

这次自查还有个副产品：有几处位置压根没有语言这个概念，比如某些老的商品导入模板。那几处并非写错，而是从没设计过，属于另一类问题。

语言代码注销有哪几种理由？

截到2024年底，累计有385个语言代码被注销。这个数字本身不算大，问题出在注销的方式上。

四种注销理由的比例与直觉相反

官方退役表把注销理由分成几类，逐条数下来：并进别的语言177个，占46%；被拆开102个，占26%；判定为查无此语言72个，占19%；重复登记33个，占9%；另有1个是换了代码。

翻这张表之前，我估计查无此语言会占大头，理由很简单：早年登记得粗，后来发现有些语言根本不存在，或者是同一门语言的两个名字。

实测结果相反。真正判定为根本不存在的只有19%，而72%的注销属于它还在，只是换了地方。这一条推翻了预期，也恰好是实际后果最大的一条。

这几类的比例这些年变化不大。早期注销里查无此语言的比例略高，后期几乎全是重新划界，符合一个逐渐成熟的登记体系应有的走向。

语言还在但换了归属，为什么最难排查？

这个区别要紧，是因为两种情况在你的系统里表现完全不同。

如果代码是因为查无此语言被注销的，页面拿它声明语言，最坏结果是被当成未知语言忽略，难看，但不会错到别的语言头上。

如果代码是并进另一门语言后注销的，那从注销那天起，按标准口径，这个代码背后的内容就属于另一门语言了。你还在按老代码分类、按老代码出报表、按老代码给用户匹配版本，而所有下游系统都已经按新代码理解它。

这种错不会报错。它的表现是报表里某个语种的量莫名下降，另一个语种莫名上涨，而两个数字都是对的。

更麻烦的是，如果站上确实有用那门语言写的内容，这批内容的语言标注从注销那天起就和标准对不上了，而没有任何环节会提示你。

三个可直接查证的注销案例

看三个具体例子。第一个是Yinglish，代码yib，2007年7月18日并进English，即eng。这门混合语被判定不构成独立语言，归到了英语下面。

第二个是比利时手语，代码bvs，同一天被拆成两个：法语区手语sfb和弗拉芒手语vgt。荷兰语和佛兰芒市场那道分界在这里又出现了一次：语言的分界跟着语言社群走，不跟着国界走。

第三个最彻底：孟加拉国的吉大港语，代码cit，被拆成罗兴亚语rhg和吉大港语本身，而留下来的那一半也换了新代码ctg。原来的cit现在不指向任何语言。

这三个例子对应三种典型情况：混合语归到主语言下，一门语言按社群边界拆成两门，一门语言拆分后两半都换新号。你涉及的那几门语言，大概率能对上其中一种。

为什么拆分后的老代码没有唯一迁移目标？

第三个例子反映了一条反直觉的规律：合并时，老代码至少有明确去向；拆分时，按规则老代码必须整体退役，再给拆出来的每一部分发新代码。

所以，如果你的表里存着一个后来被拆分的代码，不能简单换成拆出来的任何一个，因为你不知道这条记录当初指的是哪一半。

102个被拆开的代码，每一个都需要人工判断。批量替换脚本在合并那一类上能跑，在拆分这一类上必须停下来问人。

还有一种更麻烦的情形：拆出来的几门语言里，有一门沿用了原来的名字。如果你的表按语言名而非代码存储，这时名字对得上，代码却已经换了，两边各自都不报错。

2024年注销了几个语言代码？

看近期的量级：2024年全年只注销了2个代码。2023年14个，2022年10个，2021年9个。

注销最多的是2008年，83个。2016年39个，2015年25个，2012年27个。

由此可见，越早期的代码越危险，因为它经历过那几个大清理年份；2015年之后进表的代码相对稳定。词表里那些从十几年前老项目继承下来的语言代码，应该优先核对。

这条对老站尤其要紧。一个运营了十年的站，语言配置很可能是十年前建的，恰好在注销最密集的几年之后不久，中间又积累了两轮变更。

语言代码退役为什么集中在一月生效？

把385个注销按生效日期铺开，会看到很整齐的分布。

六成注销集中在六个生效日

最集中的几天：2008年1月14日一天注销75个，2009年1月16日48个，2016年1月15日39个，2012年2月3日27个，2015年1月12日25个，2020年1月23日21个。

这六天加起来235个，占全部注销的六成。其余散落在十几个其他日期上。

原因很简单：这个库按年度节奏工作，一批申请集中受理、集中评议、集中裁决、集中生效。所以对表的最佳时机是每年一月底和年中各一次，正好在两个生效窗口之后。

还有一个更早的高峰：2007年7月18日一天生效了149行变更，那是三位码体系上线后第一次大规模整理。今天还能查到的很多老代码，都是在那一天注销的。

一次批量整理的实际规模

2018年提交的那批修改申请有88行，全部在2019年1月25日同一天生效。按语系拆，其中76行属于澳大利亚语系；按地区拆，79行属于太平洋地区。

这显然不是八十几个人各提了一份申请，而是一次针对澳大利亚原住民语言的系统性梳理，一次性提交上来。

这类批量整理修改的是名称和指称范围，代码本身不动。代码没变，但它指的对象变了。这种变更最容易被忽略，因为你表里那一行字符串一个字符都没改。

这类整理往往来自某个学术项目或某国的语言调查成果，一次性把某个语系的登记信息校准一遍，所以变更高度集中在一个语系、一个地区。

对你来说，如果目标市场正好在某次批量整理的覆盖范围内，那一年的变更值得逐条看；不在的话，扫一眼就行。

改名比改码更常见

把所有修改类变更按改动属性分：参考名占32.0%、指称范围占30.8%、附加名称占23.9%、宏语言成员关系占10.2%、范围类型占2.7%、语言类型占0.3%。

合起来，将近九成的修改改的是名字和代码覆盖的范围。代码本身相当稳定，不稳定的是代码背后指的对象。

这条对做语言选择器里那些语言名怎么写的人特别要紧：界面上的语言名可能在某一年被官方改过，而代码一个字母没变，所以没有任何机制会提醒你。

指称范围的改动最需要警惕。它表示这个代码涵盖哪些话语变体被重新划分了，代码字符串一个字母没变，覆盖的人群却变了。

把码表生效日期当作版本号

实操上有个省事的做法：不必记哪个代码变了，只记上次对表用的是哪个生效日期的版本。

官方的码表下载页提供制表符分隔的纯文本文件，包括在册表、宏语言成员表、退役表三份，加起来不到两兆。

把这三份文件按日期存进仓库，下次更新时做一次文本对比，变更内容一目了然。这件事唯一的技术要求是记得保存上一版。

如果团队用版本控制系统管理配置，直接把这三份文件提交进去最省事：每次更新提交一次，差异对比现成，还自带时间线。

被合并注销的语言代码指向了哪里？

177个并进别处的代码，去向都能查得清清楚楚，并非随意指定。

177个合并代码指向118个不同目标

先纠正一个直觉。原本以为合并应该是大量小语言被少数几门大语言吸收，形成几个巨大的汇聚点。

实测结果不同。177条合并指向118个不同的目标语言，吸收最多的一门也只有9条。这不是几个汇聚点，而是一百多次各自独立的局部整理。

这条修正了一个实用判断：不能假设某个消失的代码多半是并进了当地的主流语言。它更可能是并进了一门你同样没听说过的邻近语言。

吸收最多的是危地马拉的一门玛雅语系语言，并入了9条，全部是它自己的地区变体。第二名6条，第三名5条，数量下降得很快。

奥克语合并案例

2007年3月14日，五个代码同一天并进奥克语oci：奥弗涅语、加斯科涅语、利穆赞语、朗格多克语，还有最有名的普罗旺斯语prv。

普罗旺斯这个词在中文互联网上的知名度，比奥克语高得多。而在这套标准里，它从2007年起就不再是一门有独立代码的语言。

一个代码的知名度和它的存续状态完全不相关。凭印象觉得眼熟的代码，可能十七年前就注销了；没听说过的代码，反而可能是现役的。

这五个名字在中文世界的知名度差别也很大。加斯科涅、朗格多克在旅游和红酒语境里出现得相当频繁，而它们作为语言代码已经消失了十七年。

语言代码合并的判据是什么？

翻这几条的申请文档，理由几乎都是同一个模式：这几个变体之间可以互相听懂，且没有各自独立的书面标准，因此不构成不同的语言。

互相能否听懂这条判据，下一篇会拆开细讲，它是整个受理流程里最严格的一道关。这里只需记住：合并的理由是语言学上的，与行政无关。

这也解释了合并目标为什么那么分散：判据是逐对比较的，比较结果如何就是如何，没有人在做全局规划。

有一个例外值得记住：如果几个变体之间可懂度足够高，但各自有长期存在的独立身份和成熟的书面标准，标准里另有一条通道允许它们保留各自的代码。这条通道是下一篇的主线。

合并类注销代码在表里怎么处理？

合并是四种注销里最好处理的：老代码有唯一去向，直接替换即可，历史数据也可以合并统计。

唯一要注意的是报表的连续性。如果某门语言的历史数据按老代码存储，替换之后新代码的历史曲线会突然抬高一截，而这一截并非增长。做趋势分析时，要在代码合并那天的位置画一条竖线。

见过一次因为没标这条线，团队开会讨论了半小时某个语种为什么在某个月突然增长四成。

还有一处容易遗漏：翻译记忆库和术语库通常也按语言代码分区。代码合并后，如果两个库不合并，同一门语言会有两套互不相通的记忆，命中率会莫名偏低。

宏语言成员变更是一种更隐蔽的合并

除了代码被整体注销，还有一种情况：代码没变，但被划进某个宏语言，成了成员之一。

这种变更在退役表里查不到，只在宏语言成员表里体现，而多数人的对表流程根本不下载那份文件。

2024年10月那次变更就是一例：创建了两个新代码，同时更新了中文这个宏语言的成员清单，把两个新代码加了进去。成员表变了，在册表和退役表都没有相应记录。

所以完整的对表要下载全部三份文件。只下在册表会漏掉注销，只下在册表和退役表会漏掉成员关系变更。

语言代码拆分为什么比合并更难迁移？

102个被拆开的代码，是这张表里真正需要人工判断的部分。

拆分后原代码必须整体退役

规则是：如果一个代码原本涵盖的范围被认定为两门或更多门不同的语言，这个代码不能保留给其中任何一门，必须整体注销，再为每一门发新代码。

吉大港语最典型：cit拆成罗兴亚语rhg和吉大港语ctg，连沿用原名的那一半也换了新号。

这样设计有道理：把原码留给其中一半，会让所有历史数据的含义变得模糊。代价是，你手里那条写着老代码的记录，从此没有唯一正确的迁移目标。

这条规则背后的逻辑是：一个代码的含义在整个生命周期里必须保持稳定。宁可让所有人重新映射一次，也不允许同一个代码在不同年份指不同的对象。这个选择对档案有利，对你的迁移不利。

一拆五和一拆十一的拆分案例

拆分粒度差别很大。2007年南部壮语ccy被拆成五门语言，2023年泽姆语zua被拆成五个，波尔奇语plj被拆成四个。

2024年10月那次闽南语申请，提出一次拆成十一门，最后只通过了其中两门。这是下一篇的主要案例。

拆得越碎，迁移越难自动化。判据很简单：拆出来超过两个，这批数据就只能靠人按内容判断，脚本能做的只有把它们挑出来。

拆分申请的通过率也随粒度下降。粗粒度拆分（一分为二、一分为三）的通过率明显更高，一次拆成十来门的申请，多半会被砍掉大部分。

语言代码拆分集中在哪些地区？

把139行拆分类变更按地区看，太平洋、东南亚、非洲三块占了大头。原因不难理解：这几个区域当年登记得粗，一个代码常常涵盖一大片方言连续体。

这对做东南亚三国那一层语言差异和非洲市场语种选择的人是个提醒：这两个区域用到的语言代码，后续被拆分的概率明显高于欧洲和美洲。

欧洲拆分很少，但驳回率极高，原因完全不同，下一篇会讲。

反过来，如果市场在南美或南亚，拆分风险相对低。这两个区域早年的登记工作做得较细，后来需要重新划界的情况少。

拆分记录在退役表的哪里查？

退役表里，拆分类不填合并去向那一栏，改填一段文字说明，写明拆成了哪几个。比如泽姆语那条写的是拆成图莱语等五门语言，并逐个列出新代码。

这段说明是纯文本，格式不统一，没法直接解析成结构化数据。想批量处理拆分类注销，第一步就是把这102行逐条读一遍。

好在102行读完不到二十分钟，读完之后，对自己业务涉及的那几门语言会有非常具体的了解。

读的时候有个技巧：先按自己业务涉及的语系筛一遍，一百多行里相关的通常不超过五行，其余可以直接跳过。

宏语言代码是语言学分类还是向后兼容层？

这一节是全文最重要的一段，也是翻这个库最大的意外发现。

宏语言代码的定义

在册表里有63个代码标为宏语言，下面登记了459条成员关系。成员最多的是萨波特克语59个，其次是克丘亚语44个、马来语37个、阿拉伯语30个、苗语26个、中文19个、壮语18个。

另一端，只有两个成员的宏语言多达26个，挪威语就是其中之一：两位码no指的是宏语言，下面挂着书面挪威语nb和新挪威语nn两门个别语言。

回到开头的问题。no和nb既非同义词，也非新旧两种写法，而是口袋和口袋里的一件东西。写no，指的是挪威语整体；写nb，指的是其中一种书面形式。两者在语义上并不等价，只是多数系统在实现时把它们当成了等价。

官方对宏语言的定义大意是：某些情况下，多门个别语言在使用中被当作一个整体，需要一个代码来指代这个整体。听起来像语言学分类，往下看就会发现并非如此。

加泰罗尼亚语申请暴露了宏语言机制的用途

2006年有一份编号2006-129的申请，请求把加泰罗尼亚语拆成两个代码，一个给瓦伦西亚语，一个给不含瓦伦西亚的加泰罗尼亚语。

这份申请的公开文档里有一段近乎自白的话。注册机构说，按标准的管理规则，这样拆意味着原代码退役、发两个新代码，所有已在用这个代码的应用都要做大量拆分工作，对应两位码的含义也会变得模糊；考虑到这个代码已有的存量应用规模，简单地拆成两个新代码不是一个可接受的处理方案。

这句话的意思是：存量规模本身，被当成了不批准拆分的一条理由，与这两个变体在语言学上的关系毫无关联。

接着注册机构提出了一个折中方案：把加泰罗尼亚语重新定义为宏语言，同时为两个具体变体各发一个新代码。这个方案被公开征求意见。

加泰罗尼亚语拆分申请为什么最终被驳回？

一开始我以为故事到这里就结束了，宏语言机制就是这样被逼出来的。翻到文件末尾才发现，最终裁决是不批准，加泰罗尼亚语至今仍是个别语言，并非宏语言。

驳回理由回到了唯一的硬性判据：互不相通。文件里写得很直接，连支持这份申请的评议人都承认两者可懂度很高，区域外的语言学者也一致把它看作一门语言；这里的差别更多关乎可接受性，而非可懂度。

这句话值得抄下来。可接受性不是判据，可懂度才是。一门语言的使用者觉得自己说的是另一门语言，这种认知在这套体系里不产生任何效力。

另外，瓦伦西亚语最后拿到的是一个地区子标签，写作ca-valencia，由语言标签登记表授权，并非语言代码。标准这一层不发新代码时，标签那一层可能给一个子标签。对做地区变体的人，这是一条很实际的出路。

十七年后的梵语申请用同一套说法获批

只有一个案例的话，可以说是特例。但2023年12月15日生效的梵语申请，把同样的逻辑又说了一遍，而且这次获批了。

那份申请原本只请求为吠陀梵语创建代码。注册机构采纳了，但做了修改：同时创建古典梵语的代码，并把梵语本身升格为宏语言，下面挂这两门历史语言。

这份裁决书里的原话是：这个方案在既有应用继续使用单一代码的需要，和学界把古典梵语与吠陀梵语当作不同语言的要求之间，取得了平衡。

两个独立案例相隔十七年，一个被驳回、一个获批，但注册机构描述宏语言这个工具的说法是同一套。据此可以下结论了。

宏语言身份可以被撤销

前面提到2007年3月14日有五个代码并进奥克语。那次变更还有后半部分：奥克语本身的范围，同时从宏语言改回了个别语言。

一门语言可以在某一年升格为宏语言、下面挂几个成员，几年后又降回个别语言、成员代码全部退役。这是已经发生过的事，并非理论推演。

如今查在册表里的oci，范围一栏写的是个别语言。那六个曾经存在的变体代码，只留在退役表里。

这条推翻了一个很自然的假设：宏语言是更稳定、更上层的分类。实际上它不代表层级，只是一次判断，而判断会被推翻。

结论：宏语言代码是兼容层

把三个案例放在一起：存量规模可以作为驳回理由；升格为宏语言被明确写成对既有应用的照顾；宏语言身份可以被撤销。

宏语言不是一个语言学概念，是为了不打断已经在用这个代码的系统而设的向后兼容层。

这一点能解释几件长期让人困惑的事：为什么中文一个代码下面挂着十九门语言，为什么阿拉伯语下面挂着三十门，为什么印尼语和马来语算不算一门语言这个问题在标准里的答案那么别扭。

标准并没有回答这个问题。它提供了一个中间层，让不想回答的人可以继续不回答。

宏语言代码在实操中怎么用？

三条。第一，看到宏语言代码要往下查一层：写zh时要明确到底指哪一门，写ar时更要明确，因为标准阿拉伯语和各地方言之间的差距比想象的大。

第二，宏语言的成员清单会在没有提示的情况下变化。前面说过，2024年10月中文这个宏语言多了两个成员，退役表里查不到，在册表里也只是多了两行。

第三，如果系统必须在宏语言和成员语言之间二选一，页面上选宏语言更安全，因为兼容层的设计目的就是覆盖不确定的情况。但报表要按成员语言拆开，否则永远看不到增长发生在哪一门成员语言上。

还有一个隐蔽的坑：塞尔维亚-克罗地亚语这个宏语言，两位码是sh，在语言标签登记表里已标为不推荐使用，替代值指向具体的三门语言。做塞尔维亚语和保加利亚语市场时，如果老系统里还留着sh，需要主动清理。

ISO 639-3变更库十八年的工作重心怎么变化？

把2250行变更按年份铺开，能看出一条清楚的走势。

新建语言代码的数量已趋于平缓

按生效年统计新建的语言代码数：2008年145个是峰值，2012年137个，2013年125个，之后一路下降，2019年只有16个，2024年14个。

十八年累计新建944个代码，前六年就占了六成。

这个库的工作重心已经从新建语言转向修改名称。这对你有个直接好处：现在维护的代码表，未来几年受新增项冲击的概率很低，真正的变数在改名和调整范围这一侧。

这也解释了为什么这些年新出现的语言代码你多半没见过。它们集中在非洲和太平洋那些原本登记就粗的区域，一般不在你的目标市场里。

变更申请量在哪一年最低？

按申请年份统计，2007年是峰值，258条；2011年166条，2012年151条。之后逐年下降，2022年34条，2023年只有5条。

2023年的数字低得有些异常。合理的解释是那一年标准本身在修订，很多事情在等结果。

2024年提交的申请回升到十九条，但到年底一条都还没生效。从提交到出结果大约滞后一年，慢的能拖到三年以上。

有个细节：申请量的最低点和变更行数的最低点不在同一年。行数最少的是2024年，只有29行；申请数最少的是2023年。两者之间隔着大约一年的处理周期。

一份变更申请要等多久？

说到等待，这个库里等得最久的几份申请值得单独列出来。

2006年提交的一份中古希腊语申请，2023年12月15日才有结果，整整十七年。2009年提交的两份希腊语相关申请，也在同一天出结果，等了十四年。2011年那份梵语申请等了十二年。

这几份为什么等这么久，裁决书里写明了：它们涉及历史语言能否作为宏语言拆分这一先例问题，而这个问题在ISO 639整套标准修订期间一直悬而未决。它们等的不是评审，是标准本身。

对你的实际影响是：没法靠盯申请队列来预判变更。队列里的申请可能十年不动，而真正影响你的变更往往来自一次批量整理，根本不在你关注的名单上。

修改类变更的驳回率是多少？

前面列过修改的属性分布，这里补一个更有用的角度：修改类变更的驳回率只有6.5%，新建是25.3%，拆分是25.9%。

修改一门已有语言的属性很容易通过，新立一门语言的难度大约是它的四倍。

这条判据下一篇会展开成全文主线，因为它反映了这套体系真正的价值取向。

还有一组数字：合并的驳回率是9.8%，注销是8.4%，都不高。减少一门语言比增加一门语言容易得多。

语言代码对表怎么落到站点配置和报表上？

前面是背景，这一节是可以直接照做的部分。

先统计站内语言代码出现的位置

典型的多语言站，语言代码至少出现在这几处：页面根元素的语言声明、每一条hreflang、站点地图里的语言备用链接、结构化数据里的语言字段、商品数据源的语言与目标国家设置、分析工具的语言维度、内容管理系统的语言配置，以及翻译记忆库的语言对。

一共八处。结构化数据里那个语言字段该怎么填那一篇讲过其中一处的特殊要求，这里要说的是：这八处很少由同一个人维护，也很少有哪一处会校验另一处。

所以第一步是统计，先别急着改。把这八处当前的取值导出来，放进同一张表里横向对比。

统计时建议把每一处的负责人一并记下。这份清单的价值主要在协作：它把一件横跨四五个团队的事，整理成了一张可以拿到会上讨论的表。

hreflang取值应该对照哪一份登记表？

有个容易混淆的点：hreflang能填的值，规则并非直接来自三位码那份标准，而是来自语言标签注册表。

IANA维护的语言子标签登记表是实际生效的清单。它从ISO码表同步，但有延迟；对已废弃的子标签，它的处理方式是标注为不推荐并给出替代值，不会直接删除。

这个差别对你有利：在ISO那边已注销的代码，在语言标签登记表里通常还保留着，并带有一条指向替代值的说明。这条说明是做迁移时最可靠的依据。

所以对表顺序应该是：先看ISO退役表，了解发生了什么；再看语言标签登记表，拿到官方推荐的替代值。

这两份表还有一个结构差别：ISO那边一个代码只有在册和注销两种状态，语言标签登记表还有一个中间状态，叫不推荐使用。这个中间状态是专门给迁移用的。

四种注销理由分别怎么处理？

按注销理由分别制定动作，比统一处理省事得多。

并进别的语言的177个：可以用脚本自动替换，历史数据合并统计，图上标一条竖线。重复登记的33个：同样可以自动替换，因为本来就是同一门语言的两个编号。

判定为查无此语言的72个：直接删掉这一行，同时检查内容库里有没有真正标着这个语言的页面；如果有，那批内容的语言标注从一开始就是错的。被拆开的102个：脚本只负责筛出来，逐条人工判断，不要自动替换。

把这四类动作写成四行处理规则，放在对表脚本的注释里。下次换人接手时，这四行比任何文档都管用。

语言维度报表里不报错的异常怎么识别？

语言维度出问题，典型症状不是报错，而是数字看着正常却解释不通。

常见的三种：某个语种的量在某个月阶梯式变化，而内容没动过；两个语种的量此消彼长，总量不变；某个语种的转化率长期明显异常，高得或低得没有道理。

第三种最需要警惕，因为它常常是页面语言被机器认错和代码注销两个原因叠加的结果。先查代码，再查识别，顺序反了会绕很久。

还有一种更隐蔽：某个语种在报表里从未出现过。这通常并非没有流量，而是这门语言的代码不在报表工具的维度取值里，那部分访问被归到了其他一栏。

把语言代码对表排进一年两次的日程

最后给一个可以直接写进日历的方案。

每年二月和十一月各做一次，每次不超过两小时。步骤是：下载三份码表存进仓库；和上一版做文本对比；把变更行按四种理由分类；对照站上八处位置的清单，找出交集；处理交集，其余归档。

八处位置的清单只需建一次，之后每年复用。第一次建清单大约要半天，之后每次两小时，这就是这件事的全部成本。

如果实在挤不出两小时，退一步只做一件事：拿退役表和站上的语言配置取一次交集。这一步五分钟，能挡住九成的问题。

语言代码变更实测推翻了哪些预期？

翻这个库之前，我先写了一份预期清单，翻完后逐条核对。猜错的几条比猜对的更有参考价值。

预期一：以为注销的主要理由是查无此语言

这条错得最离谱，价值也最高。实测查无此语言只占19%，而语言还在、只是换了归属的两类加起来占72%。

猜错的原因是把注销想象成纠错。实际上这个库里绝大多数注销是重新划界，与对错无关。

纠错和重新划界，在数据迁移里是两件完全不同的事：前者该删，后者该换。猜错这一条的人，会把该换的也删掉。

由此还能引出一个更普遍的教训：看到一份像在做清理的记录，先别默认它清理的是错误。它更可能是在重新划界，而划界本身没有对错。

预期二：以为合并会集中到少数几门大语言

实测177条合并指向118个不同目标，最多的一门只吸收9条。

这条猜错影响的是策略：如果合并真的集中，只需关注几门大语言就能覆盖大部分风险；实际情况是分散的，只能按自己涉及的语言逐个查。

好在涉及的语言通常不超过二十门，逐个查也就半小时。

顺带修正一个相关直觉：合并方向并不总是小并进大。有几条合并的目标语言，使用人口比被合并的那门还少，判据只看语言学关系，不看规模。

预期三：以为修改类里参考名会占四成以上

实测参考名32.0%，指称范围30.8%，两者几乎持平。

这条猜错不算严重，但改变了一个判断：如果改名占绝对多数，对表主要是显示层的事；实际上指称范围的改动占了差不多同样的份额，而指称范围变了意味着代码覆盖的对象变了，那是数据层的事。

附加名称一类占23.9%，也常被忽略。它表示一门语言多了个别名，而别名恰恰是用户会在搜索框里输入的写法。做词表的人应该关注这一栏。

猜对的一条：那批修改确实是批量整理

猜对的是2018年那批修改：确实是一次批量整理，88行全部同一天生效，76行属于同一个语系。

猜对本身不稀奇，但它引出了一个原本没想到的问题：批量整理不改代码，只改代码的含义，所以在任何基于字符串比对的监控里都看不到它。

最容易发现的变更最不重要，最难发现的变更最要紧。这个顺序不太友好，但知道了就能反过来用：对表时先看修改类，再看注销类。

所以更实用的对表顺序是：先看修改类里指称范围和成员关系两栏，再看注销表，最后才扫新建。这和大多数人的直觉正好相反。

哪些问题不属于语言代码这一层？

最后划清边界，避免把不同层的问题混在一起处理。

有语言代码不等于软件里能选这门语言

一门语言在标准里有代码，不代表用户的设备能设置成它。安卓、火狐、Chrome三家界面语言清单的实测那一篇统计过：三家里最多的一份只有181门，和七千多门差了两个数量级。

标准这一层管身份，软件那一层管可达性。身份是可达性的前提，但远不是充分条件。

一门语言同时满足两个条件才算真正可用：标准里有代码，并且用户的设备和浏览器清单里有它。只满足前一个，你能写出合法的标签，但覆盖不到用户。

有语言代码不等于本地化数据齐全

拿到代码只是拿到一个编号。这门语言的日期怎么写、数字怎么分节、一周从哪天开始，属于另一套数据。本地化数据的自有率实测和非公历纪年数据的缺口两篇讲的都是那一层。

常见的误判是：拿到了三位码，就以为这门语言在系统里能正常显示日期和金额。这两件事之间没有任何自动关联。

判断方法很简单：拿到代码后，查一下这门语言的本地化数据文件有多大。几百字节的多半是空壳，真正有自有数据的文件通常在几十KB以上。

语言代码层不负责市场决策

最后一条最要紧。这套体系判定两个变体是否为不同语言，用的是语言学判据；你判定要不要为它们各做一套内容，用的是市场判据。

这两套判据经常给出相反的答案。捷克语和斯洛伐克语有两个代码，但内容能大量复用；北欧三语的复用边界又和代码数量对不上；克罗地亚语和斯洛文尼亚语在两个方向上都不成立。

标准告诉你这是几门语言，不告诉你该做几套内容。后一个问题要靠你自己的转化数据回答。

反方向的错配同样常见：两个市场共用一个代码，但用户搜索的词分化得很厉害。乌克兰语和俄语那种双语市场是典型，代码层完全看不出来。

所以两层的分工是：代码层负责把技术链路配置正确，市场层负责决定投入多少。前者是及格线，后者才是策略。

常见问题解答

怎么快速查一个语言代码是不是已经被注销了？

去注册机构的码表下载页下载退役表，这是一个制表符分隔的纯文本文件，共几百行。用表格软件打开，第一列就是被注销的代码，直接搜索即可。同一个下载页还有在册表和宏语言成员表，建议三份一起下载，对表时交叉核对。整套操作不到五分钟。

发现代码被注销了，直接替换成新代码就行吗？

要分情况。如果注销理由是并进了另一门语言，去向唯一，可以直接替换。如果理由是被拆开，就不能自动替换，因为原代码涵盖的范围现在对应两个或更多新代码，你得逐条判断这批内容属于哪一个。如果理由是查无此语言，应该删除，同时回头查清为什么会有标着这门语言的内容。

hreflang里到底该写两位码还是三位码？

规则是有两位码就写两位码，没有就写三位码。在册的七千多门语言里只有184门有两位码，所以做小语种基本必然会遇到只能写三位码的情况。判断依据应该是语言标签登记表，不能凭印象，登记表里对每个子标签是否推荐使用都有标注。

宏语言代码和它的成员代码，该用哪一个？

页面上和hreflang里通常写宏语言代码更安全，因为它的设计目的就是覆盖不确定的情况，下游系统对它的支持也更完整。但内部报表建议按成员语言拆开统计，否则某一门成员语言的增长会被整个宏语言的数字掩盖。两套写法并存不冲突，页面写宏语言、报表拆成员，是比较稳妥的组合。

这些代码变更会影响已经收录的页面吗？

不会直接影响收录，搜索引擎不会因为某个语言代码被注销就把页面移出索引。实际影响在匹配环节：如果用户的语言偏好指向新代码，而页面声明的是老代码，两边对不上，语言协商和地区版本匹配就无法命中这个用户。这种影响是逐步显现的，所以不容易被发现。

多久对一次这张表比较合适？

一年两次足够。这个库的变更集中生效，多数年份只有一到两个生效日期，而且往往在年初。所以二月和十一月各做一次，正好在生效窗口之后。每次的步骤是下载三份码表、和上一版做文本对比、按注销理由分类处理，两小时内可以完成。