小语种关键词表里唯一一批全英文的词，从翻译到审校没有一个人动过它

摘要：关键词表里总有那么几行是全英文的大写字母，它们从翻译派单到母语审校一路顺畅通过，因为每个环节都默认这种东西不用动。可是同一个组织在五门语言里有五个不同的缩略语，芬兰语还要用冒号把格尾接在后面，而所有分词器都把冒号当成词边界。本文把缩略语分成三类给出各自的处理策略，附一张能直接查的变体覆盖清单。

为什么关键词表里那几行全英文的词从来没人改过？

它们在流水线上长得像常量

打开任何一份小语种关键词表往下翻，总会看到几行是纯大写的拉丁字母。

USB、LED、PDF、EU、VAT，它们夹在一堆本地文字中间特别显眼。

显眼归显眼，这几行往往是整张表里唯一没被任何人碰过的几行。

原因很朴素，它们看起来像代码里的常量，不像需要翻译的内容。

翻译记忆库对这类片段的匹配度是百分之百，工具直接标成已完成。

做芬兰乐器配件那个项目的时候，我第一次注意到这件事。整张词表交回来，只有几行英文缩略语一个字符没变，而它们恰好是全站商品参数里出现频率最高的几个词。当时我们以为那是好消息，说明流水线足够聪明，认得出哪些东西不该动。

这几行还有一个共同点，它们通常是整张表里字符最短的几行，在表格里看着就像凑数用的。视觉上最不起眼的行，往往是被处理得最草率的行，因为审阅一张长表的时候注意力天然流向长句子和陌生词，一串三个字母的大写缩写既不长也不陌生，眼睛会直接滑过去，连停顿都不会有。

匹配度百分之百的片段，就是没人看过的片段

这是我从这件事里带走的第一条判据，后来用在别的场合也一直成立。

翻译工具的完全匹配意味着这段内容被自动填充，不进人工队列。

不进人工队列意味着没有任何一双眼睛在上面停留过。

而缩略语正好是最容易触发完全匹配、也最需要人判断的那一类。

它同时占据了流程上最省事的位置和内容上最需要动脑的位置。

这条判据的用法是反过来的：拿到译稿之后不要先看被大改的部分，先把完全匹配率最高的那些行拉出来单独审一遍。改动多的部分至少证明有人在思考，而一个字没改的部分你连它有没有被看过都不知道。

这条判据还有个更一般的说法：自动化流程的成功率越高，它失败的那几次就越难被发现。翻译记忆库的匹配准确率如果只有六成，所有人都会逐条核对；准确率到了九成九，反倒没有人核对了，而剩下那百分之一恰好集中在缩略语这类特殊内容上，命中率高得不像巧合。

缩略语跟截短词不是一回事

这两件事经常被混着说，实际上机制完全不同。

截短是把一个长词砍短，比如把大学砍成前两个音节。

缩略是把一个短语的每个词取首字母重新拼成一个新串。

截短之后的形态还是原来那门语言的词，读音也跟着原词走。

缩略之后的形态是一串字母，读法要另外规定。

之所以要分清楚，是因为两者在关键词层面的处理方向相反：截短词要做的是把用户常说的那个短形式补进词表，而缩略语要做的是判断这一串字母在目标语言里到底该不该保持原样。前者是补，后者是换，用同一套流程处理必错一半。

还有一个区分它们的简单信号是读法。截短之后的形态仍然按原来的音节读，是一个能说出口的词；缩略之后的形态要么逐字母念，要么按拼读规则当成一个新词念，两种读法在不同语言里的比例还不一样。读法决定了它会不会进入口语，进入口语的形态才会大量出现在搜索框里。

实际操作里最省事的分辨办法是看长度比。截短之后的形态通常是原词的一半左右，缩略之后的形态往往只剩三四个字符，压缩比差着好几倍。压缩比大的那一类几乎必然需要重新规定读法，也就必然要走本地重组那条路。

同一个组织在五门语言里有五个缩略语，你的词表收了几个？

缩略语要经过两次转换，两步都可能断

一个英文缩略语要进入目标语言，中间有两个动作。

第一步是把它展开成完整名称，第二步是把完整名称翻成目标语言。

第三步才是按目标语言的词序重新取首字母，拼出本地缩略语。

三步里任何一步没做，出来的都是原样的英文串。

而流水线默认执行的正是零步，因为它压根没意识到这里有工作。

这三步说起来简单，落到实际操作里最容易断的是第三步。译者往往会把全称翻对，然后在缩略这一步犹豫，因为他不确定当地是不是真的有一个通行的缩写。这个犹豫是对的，答案不在他脑子里，在本地媒体和本地行业文章里，得去查。

值得留意的是这三步里只有第二步是翻译工作，另外两步都是知识查证工作，而翻译工单的计价方式只覆盖第二步。凡是工单不计价的步骤，都会系统性地被跳过，这不是态度问题而是激励结构问题，想让它被执行就得把它单独列成一项可以计价的任务。

词序一变，首字母跟着全变

联合国的英文缩写是三个字母，法语、西班牙语、俄语各有各的写法。

差别的根源是各语言的词序不同，取出来的首字母自然不同。

这不是翻译习惯问题，是构词规则决定的必然结果。

凡是修饰语位置跟英语不同的语言，这类缩略语几乎必然不一样。

罗曼语族和斯拉夫语族都属于这一类，德语和荷兰语也常见。

判断一个缩略语会不会本地重组，有个很快的办法：把全称翻成目标语言，看词序有没有变。词序没变的多半沿用英文缩写，词序变了的多半有本地版本。这个判断五分钟能做完一批，比逐个去查资料快得多，之后只需要对存疑的那几个做核实。

这条规律还有一个反向用法。如果你发现某个缩略语在目标语言里居然没有本地版本，那通常说明这个概念是随着英文材料一起进入当地的，本地媒体也直接用了英文缩写。DWDS收录的欧盟词条就是一个混合案例，德语有自己的缩写形式，同时英文缩写在专业语境里也通行。

本地缩略语的搜索量往往比英文原版高

这一点跟直觉相反，很多人默认英文缩写是国际通用的。

通用的意思是懂的人多，不等于当地人搜索时会用它。

本地用户在自己的语言环境里长大，接触到的是本地媒体的写法。

他们在搜索框里打出来的自然是从新闻和课本里学到的那一串。

英文原版更多出现在跨国企业内部和专业文献里。

芬兰乐器配件那次实测下来，本地缩略语的月查询量是英文版本的好几倍，而我们的商品参数表上一个本地版本都没有。这一层的漏损是完全静默的，报表上看不出来任何异常，因为你从来没有为那些查询建过词，自然也就不会在任何报告里看见它们。

这个差距在不同行业之间还不一样，越是面向普通消费者的行业差距越大，越是面向专业买家的行业差距越小。原因也不复杂，专业买家读的是英文技术文档，普通消费者读的是本地新闻。所以判断该重点做哪个形态，先看你的客户平时读什么材料，比看任何行业报告都准。

这个结论还有一个前提值得说清楚，它只在有本地媒体生态的市场里成立。如果一门语言的本地内容极少，用户接触到的材料本身就是英文的，那么英文缩写反而是他们唯一熟悉的形态，硬造一个本地版本是没有人会搜的。

词表要为缩略语单独留一个类型标记

把缩略语混在普通关键词里管理，早晚会出问题。

它们的变体规则跟普通词完全不同，需要单独的生成逻辑。

加一个类型列，值是缩略语、截短词、普通词三选一。

后续所有的批量操作都按这一列分流，不再一刀切。

这一列的成本是零，收益是让所有后续脚本都能正确分支。

通用依存标注体系里的Abbr特征就是干这件事的，它把是不是缩略形式当成一个独立的词层特征标出来，而不是靠字符串长相去猜。借这个思路给词表加一列，等于把语言学上已经想清楚的分类直接搬过来用。

这一列还能顺手解决另一个长期麻烦，就是词表去重。缩略语和它的全称在字符串层面完全不像，任何相似度算法都不会把它们判成重复，于是同一个概念在表里存两行谁也发现不了。有了类型列就可以按原串做分组，把同一概念的所有形态归到一起看，重复和遗漏同时浮出来。

哪三类缩略语要用完全不同的处理方式？

第一类：全球统一的技术规格

接口名、文件格式、材质代号这一类，全世界写法一致。

用户在任何语言环境里搜索它们，打的都是同一串字母。

这一类确实不需要翻译，流水线跳过它是对的。

要注意的只有连字符和空格的写法差异，那是另一个话题。

这一类通常占缩略语总量的一半以上，所以流水线的默认行为大体不错。

问题在于流水线不区分类型，它对第二类和第三类也执行同样的跳过。默认行为在多数情况下正确，反而让例外情况更难被发现，因为没有人会去检查一个大部分时候都对的规则。

这一类里唯一需要花心思的是连字符和空格。同一个接口规格，有人写带连字符的，有人写不带的，有人在字母和数字之间留一个空格。三种写法在字符串匹配上是三个不同的串，而用户三种都会打，商品标题里只能选一种，剩下两种就得靠正文和参数说明去接。

第二类：机构、组织与地理实体

国际组织、政府部门、国家名的缩写，几乎必然有本地版本。

这一类在内容里出现的位置通常是信任信号和合规说明。

写成英文缩写不会导致理解障碍，但会让页面读起来像译稿。

更实际的影响是，用户按本地缩写搜索时你完全不在场。

这一类的数量不多，一个行业十几个，人工列一遍就完。

这一类还有个特点是稳定，一旦确定下来几年不会变，维护成本几乎为零。所以尽管它需要人工判断，一次性投入之后就是一劳永逸的资产，跟工具返回的那个零是数据缺口而不是需求缺口一样，都属于必须靠人补一次、补完就能长期吃的那类工作。

判断某个缩写属不属于这一类，有个很省事的信号：看它有没有出现在当地的政府网站或者新闻媒体上。这两类内容天然使用本地规范写法，如果它们用的是本地缩写而你的页面用的是英文缩写，那这个词就必须补一个本地形态，不必再做别的论证。

第三类：商业与法务惯用缩写

税率、公司形式、单据类型这些，各国有各国的一套。

德语的增值税缩写、芬兰语的有限公司后缀，都是本地独有的。

这一类根本不存在英文对应版本，硬翻过去当地人看不懂。

它们在商品页上的出现频率极高，价格区、结算页、发票说明都有。

这一类是三类里最不能出错的，因为它直接关系到可信度。

DWDS收录的德语增值税缩写词条能看出这类词在真实文本里的用法密度，乘用车那一条是另一个典型，它在德语里是一个完全本地的缩略语，跟英文毫无关系。这类词漏掉不会有任何报错，但当地用户一眼就能看出这个站不是本地人做的。

这一类还有一个容易被忽略的位置，就是页脚的公司信息和条款页。公司形式的后缀写错了不影响任何功能，却是当地用户判断一个站是不是本地经营的第一个信号，而这批文字通常由法务或者行政提供，从来不进内容团队的工作流，也就没人从检索角度看过它。

这一类词的另一个特点是它们经常带点号，而点号在很多系统里会触发意想不到的处理，比如被当成句子结束、被当成文件扩展名、或者在生成链接时被截断。上线之前拿几个带点的缩略语跑一遍全链路，能提前发现不少这类小故障。

三类的处理策略要写进同一张表

把三类各自的处理规则写成三行，贴在词表的说明页上。

第一类保持原样，只做写法变体的覆盖。

第二类查本地媒体，确定本地版本后两个形态都进词表。

第三类完全按本地惯用来，英文版本根本不进表。

规则写清楚之后，新增缩略语的判断只需要三十秒。

这张表的真正价值是它把一个需要语言知识的判断，压缩成了一个任何人都能执行的分类动作。分类做完之后该查什么、该填几个形态都是确定的，不再依赖执行者对目标语言的熟悉程度。

这张表还要留一栏写清楚谁有权改动分类。缩略语的类型归属偶尔会变，比如某个技术规格在当地逐渐有了本地叫法，从第一类挪到了第二类。这种变化一年遇不上几次，但一旦发生，如果没有明确的责任人，改动往往会以某个人在某次会上口头说了一句的形式发生，然后没有任何记录。

芬兰语的缩略语要用冒号接格尾，分词器会怎么切？

格尾靠标点接在缩略语后面

芬兰语的名词要变格，缩略语进了句子同样要变。

可是缩略语是一串大写字母，直接把格尾粘上去读不出来。

解决办法是在中间加一个冒号，格尾写在冒号后面。

于是同一个缩略语在不同句法位置上会有好几种写法。

土耳其语用的是撇号，机制一样，符号不同。

芬兰语言办公室指南库里的缩略语条目把这套规则写得很细，包括什么时候该加冒号、什么时候直接接。这跟土耳其语一个词后面挂五层后缀的处理是同一类问题，只不过缩略语这一层多了一个标点符号作为分隔。

这套规则在别的语言里也有对应版本，只是符号不同。芬兰国家语言中心的语言服务页面汇总了这类规范材料的入口。要注意的是这些是书面规范，而用户在搜索框里未必照着写，规范给你的是应该有哪些形态这个清单，真实份额还得回日志里看。

标点在分词器眼里是词边界

这是整件事最要命的一环，也是最容易被忽略的一环。

几乎所有的分词器默认把非字母字符当作词与词之间的分隔。

于是带冒号的那个形态会被切成两段，前面是缩略语，后面是格尾。

切开之后，你的精确匹配永远命中不了用户打的那个完整串。

而用户打得出来，因为他们的输入法本来就这么打。

Unicode的文本分段标准附件定义了默认的词边界规则，冒号和撇号在这套规则里的处理值得逐条读一遍。这一层是唯一一类用户打得出来、机器切得开、你的词表却接不住的词，三个条件同时成立在别的词类上很难凑齐。

这一层还会引发一个更隐蔽的后果，就是数据被拆散。同一个缩略语的五个格尾形态，在报表里是五条各自独立的低频记录，每一条的量都不足以进入前一百名，于是这个词整体上就从你的视野里消失了。拆分不只让单条数据变小，它会让一个重要的词整个不出现。

索引侧和查询侧要一起改才有用

只改索引不改查询，或者反过来，都等于没改。

站内搜索引擎允许自定义字符过滤规则，把冒号排除在分隔符之外。

改完之后要重建索引，否则旧数据仍然按老规则切着。

查询侧同样要跑一遍归一化，让用户输入和索引对齐。

两侧都改完，再拿几个真实查询做一次回归测试。

数据库全文检索的词典配置文档说明了这类规则可以在哪一层调整，如果你的站内搜索直接跑在数据库上，改动点比想象中集中。开源检索引擎的语言分析文档则给出了按语言配置分析链的完整示例，芬兰语和土耳其语都在支持列表里。

做这类改动之前一定要先留一份基线数据，把改之前的零结果率和主要查询的命中情况存下来。检索配置的改动很容易顾此失彼，某一类查询好了另一类差了，没有基线的话事后完全说不清楚到底是变好了还是变坏了，只能凭感觉争论。

还有一件容易被忘掉的事是自动补全。补全的候选来自另一套索引，改了主索引不改补全，用户在输入框里打到一半看到的候选仍然是错的，而补全恰恰是影响用户最终打出什么字符串的那一环。

缩略语和全称，哪一个该进标题？

两者的搜索量和意图强度是分开的

缩略语好打，所以搜索量通常更高。

全称打起来费劲，愿意打的人往往目标更明确。

这就形成了一个典型的量与质分离的局面。

只做一个必然丢掉另一半，两个都做才是完整覆盖。

问题在于标题只有一个，容纳不下两个形态。

这个矛盾跟最高级词的形态多而落点少是同一个结构：意图集中的位置容量最小。解法也类似，把主形态放标题，次形态放正文和结构化数据，让两者在同一个页面上共现。

这个分离还有一个实际用处，它能帮你判断内容该写多深。搜缩略语的人可能只是随便看看，搜全称的人往往已经在比较具体方案了。同一个页面要同时接住这两批人，靠的是把浅层信息放前面、深层信息放后面，而不是为两批人各做一个页面。

首次出现时全称加括号缩写

这是写作规范里的老做法，在这里正好一举两得。

正文第一次提到时写全称，后面用括号带上缩略语。

这样两个形态在同一段里共现，语义关联被明确建立。

后续段落只用缩略语，读起来不啰嗦。

规范本身是为可读性设计的，副产品是关键词覆盖。

微软风格指南里关于缩略语的一章把这套写法的适用边界讲得很清楚，包括哪些缩略语常见到根本不需要展开。这份指南是英文写作的，但它给出的判断标准可以直接搬到别的语言上用。

这个写法还有一个副作用值得利用：它天然在页面上制造了一次概念定义。搜索引擎在理解页面主题的时候，这种全称加括号的结构是一个很强的信号，比单独出现任何一个形态都清楚。所以即使某个缩略语已经家喻户晓，在正文里展开一次仍然不亏。

结构化数据里放哪一个

结构化数据的字段值不需要考虑可读性，只需要考虑机器识别。

所以那里应该放最标准、最不容易产生歧义的那个形态。

多数情况下是全称，因为缩略语可能在别的领域里另有所指。

缩略语可以放进别名类的字段，让两者都被读到。

这一层跟正文的取舍逻辑完全不同，不要照抄。

这条跟小语种页面正文越本地化越好而结构化数据要反着写回国际格式是同一条原则的另一次应用：面向人的位置和面向机器的位置，优化目标本来就不同，写成一样反而两边都不讨好。

还有一个实操细节是别名字段能放几个。多数结构化数据的别名类字段接受数组，可以把本地缩写、英文缩写和常见变体一并放进去。这是全站唯一一个可以不加节制地放多个形态而不影响可读性的位置，不用白不用，成本只是模板里多拼一个数组。

有些语言几乎不用字母缩略语，规格表该怎么写？

不是所有书写系统都适合首字母缩略

首字母缩略这个做法有个隐含前提，就是字母能单独读出来。

拉丁字母和西里尔字母都满足这个条件，字母名是现成的。

阿拉伯字母的情况不同，书写不标元音，一串辅音很难念。

于是阿拉伯语里的字母缩略语数量远少于欧洲语言。

用户不用它，自然也不会拿它来搜索。

这跟阿拉伯语那些从右往左带来的坑属于同一个层面的问题：书写系统的性质会直接决定某一类语言现象存不存在，而不只是影响它长什么样。

这条限制还能推广开来看：一个语言现象存不存在，取决于它所依赖的那个底层条件成不成立。首字母缩略依赖字母可单独读出，词干还原依赖词有明确的边界，大小写变化依赖书写系统本身有大小写之分。做多语言方案之前把这些前提逐条列一遍，能省掉大量无效工作。

规格表全是缩写等于零可搜索性

商品参数表是缩略语密度最高的地方，接口、材质、认证全是缩写。

在缩略语不流行的语言市场上，这张表几乎没有检索价值。

用户搜的是完整说法，而你的页面上一个完整说法都没有。

更麻烦的是这张表通常由系统自动生成，内容团队碰不到。

于是它成了一块所有人都看得见、却没有人负责的区域。

我们的处理办法是在参数表旁边加一段自然语言的规格说明，用完整说法把关键参数复述一遍。这段文字对已经懂行的用户是冗余的，但它是那些按完整说法搜索的用户唯一能命中的落点，成本只有一段话。

这块区域没人负责还有一个结构性原因，参数表在多数团队的认知里属于商品数据而不属于内容，商品数据的归属往往在运营或者供应链那边。凡是跨部门归属的页面区域，检索优化几乎必然缺位，因为没有任何一方把它算进自己的指标里。

这块区域的改造还有个成本优势，因为它是模板生成的，改一次全站生效。不像正文要逐页去改，参数表的说明段落只要在模板里加一次，几千个商品页同时获得这段内容，单位成本低到几乎可以忽略。

希腊语和西班牙语的点号写法

希腊语的传统缩略写法要在每个字母后面加点。

西班牙语表示复数时会把字母重复一遍再加点。

这两种写法在字符串层面跟不加点的版本完全不同。

用户两种都会打，而词表里通常只有其中一种。

点号还会引发跟冒号一样的分词问题。

希腊语这一族的复杂度在用拉丁字母打希腊语那一层之上又叠了一层，同一个缩略语可以有带点的希腊字母版、不带点的希腊字母版和拉丁转写版三种写法，三种在真实查询里都有份额。

这三种写法的份额可以直接测出来，办法是把三种分别投一小笔广告跑一周，看展现量的分布。测出来的结果经常反直觉，规范写法的份额往往不是最高的那个，因为规范是给编辑用的，而搜索框里的写法是由输入便利程度决定的，两者的驱动因素完全不同。

大小写、点号和空格的变体，要不要都覆盖？

变体清单一共只有五种，列一遍就完

全大写、首字母大写、全小写，这是大小写的三种。

加点和不加点，这是标点的两种。

字母之间加空格和不加空格，这是间隔的两种。

三个维度交叉，理论组合十来种，实际常用的只有五种上下。

一个缩略语列五个变体，人工做完全扛得住。

Duden关于缩略语的词条能看到德语里带空格的规范写法，而真实查询里绝大多数人不打那个空格。规范写法和高频写法在这一层几乎总是不一致的，词表要收的是后者，正文要用的是前者。

列这张表的时候顺手记一个信息很有用，就是每种变体最可能出现在什么场景里。全大写常见于参数表和标题，首字母大写常见于正文句中，全小写常见于用户输入。知道变体的出没场景，比知道变体本身更有用，因为它直接告诉你该在哪个位置覆盖哪一个。

不必都覆盖，但必须都知道

覆盖和知道是两件事，很多人把它们混在一起了。

知道的成本是列一张表，覆盖的成本是给每个变体找落点。

先把变体列全，再看哪几个有真实搜索量，只覆盖有量的。

没量的留在表里当档案，将来趋势变了随时可以启用。

这样既不浪费落点位置，也不会遗漏。

把这两件事分开还有个好处，讨论优先级的时候大家看的是同一张完整清单，只是在争论哪几行值得做，而不是各自凭印象举例。清单本身消除了大部分无效争论。

这个区分还能防住一类常见的返工。有人半年后发现某个变体有量，回头翻记录发现当初根本没考虑过它，于是重新做一遍全面调研。如果当初的清单是完整的，只是标注了暂不覆盖，这时候只需要把那一行的状态改一下，前面的调研成果一点没浪费。

规范化要在存储层还是查询层做

这是个老问题，但在缩略语上答案比较明确。

存储层保留原样，绝对不要把用户的写法改掉。

归一化只在查询和索引这两个环节做，两边用同一套规则。

这样原始数据始终可回溯，规则改了重跑一遍就行。

把归一化写死在存储层，改规则就意味着数据回不去了。

这一条在图片文件名和替代文本要用两套字母写同一个词那种场景里同样成立：凡是会改变字符串本身的转换，都不能发生在唯一的那一份数据上，必须发生在派生环节。

这条原则在缩略语上格外重要，因为大小写转换看着无害。把用户输入统一转成大写存进数据库，是这一层最常见的一次不可逆操作，转完之后你永远不知道当初用户打的是哪种写法，而那个分布正是决定标题该用哪个形态的唯一依据。

判断某个转换可不可逆有个十秒钟的测试：把转换后的结果再转回去，逐字节跟原串比较。回得去的可以放心用在存储层，回不去的一律只能用在派生环节。这个测试不需要懂目标语言，写十行代码就能跑完整张表。

abbr元素和括号并列，哪种写法真的有用？

标记层能表达的和搜索能利用的不是一回事

HTML里有专门的缩略语元素，可以把全称写在属性里。

这个元素的设计目的是可访问性，让辅助技术读出完整名称。

属性值里的文本会不会被搜索索引，这件事从来没有明确答案。

所以不能把全称的覆盖寄托在这个属性上。

正文里明明白白写一遍，才是确定有效的做法。

这个元素的文档和规范里的文本级语义一章都强调了它的语义用途，两份材料里都没有任何关于检索权重的承诺。凡是规范不承诺的行为，工程上就不能当作依赖项。

这里还有一个更一般的判断方法：看规范文档里用的是描述性的词还是承诺性的词。规范中关于文本级语义的表述说的是这个元素表示什么，而不是处理器必须如何对待它。表示什么是语义约定，必须如何是行为承诺，只有后者才能当依赖项。

可访问性收益是真的，别因此不用

说它对检索没把握，不等于说它没用。

屏幕阅读器确实会利用这个属性给出更完整的朗读。

在缩略语密集的规格表上，这个差别对使用者是实打实的。

成本几乎为零，加上就是了。

只是别把它算进关键词覆盖的账里。

这类工作的正确记账方式是把它记在可访问性那一栏，而不是往搜索那一栏里凑数。记错栏的后果是将来复盘的时候，你会以为搜索侧的某个提升来自这一步，从而在别的项目上重复一个其实没有作用的动作。

把可访问性和检索这两笔账分开记，还有一个组织上的好处。这两件事在多数公司归不同的人管，混在一起汇报会导致谁都不认领。分开记之后，可访问性那一栏的进展可以独立展示，不必依附在搜索的成绩上，长期看反而更容易拿到资源。

括号并列的位置有讲究

全称在前缩写在后，还是反过来，取决于哪个更常用。

用户更熟悉缩写的时候，把缩写放前面读起来更顺。

但从关键词角度，放前面的那个更容易进摘要片段。

两个考虑打架的时候，优先照顾正文的可读性。

因为摘要片段的截取位置本来就不完全可控。

实操上我们定了一条简单规则：标题和第一段用主形态，第二段用括号把另一个形态带出来，之后全篇统一用主形态。这样既保证了两个形态在页面上共现，又不会让全文读起来像在反复自我解释。

还有一个位置容易被忘掉，就是图片的替代文本。参数表如果做成了图片，里面的缩略语在检索层面完全不存在，替代文本就是唯一的补救位置。这时候写全称还是写缩写要按图片的用途定，说明性的图片写全称，装饰性的图片干脆留空更好。

词表里怎么给缩略语单独立一层

四个字段就够：原串、类型、本地形态、变体组

原串是英文或原始语言里的那一串，作为跨语言对齐的锚。

类型是三类里的哪一类，决定后续走哪条处理分支。

本地形态是目标语言里的通行写法，可能跟原串相同。

变体组是一个数组，装着大小写和标点的各种写法。

四个字段能覆盖这一层几乎所有的操作需求。

字段设计上唯一要留心的是变体组不要拆成多列，因为变体数量是不定的。拆成固定的五列，遇到有七个变体的词就装不下，而多数词只有两三个变体，剩下的列全是空的，看着乱还容易被人误填。

这四个字段还要配一个隐含约定：原串那一列永远不许翻译，它的作用只是当锚。有人会好心地把它也翻成本地语言，理由是保持表格语言统一，翻完之后跨语言对齐立刻断掉，而这个断裂在单语言视角下完全看不出来，要等到做多语言对照的时候才会暴露。

这四个字段还有一个扩展位可以考虑加上，就是废弃标记。缩略语偶尔会被官方改掉，旧形态还有人在搜但已经不该出现在新内容里，用一个布尔字段标记比直接删掉安全得多，删掉之后没人记得当初为什么删。

本地形态的确定要有出处

不要凭译者的印象填这一列，要求写出依据。

依据可以是本地媒体的用法、官方文书、或者行业协会的材料。

把出处链接直接填在旁边一列，将来复核不用重新查。

没有找到出处的，宁可先留空也不要猜一个填进去。

留空至少是个明确的待办，猜错了则会一直错下去。

这条要求刚提出来的时候会遇到阻力，因为它明显增加了工作量。缓解办法是只对第二类和第三类要求出处，第一类不需要，这样实际需要查证的行数只占全表的一小部分，抵触感会小很多。

出处这一列还有一个附带收益，它能让你看出某个缩略语的通行程度。如果三条出处来自三家不同类型的机构，说明这个形态是真正通行的；如果三条都指向同一个来源，那可能只是某一家的用法。来源的独立性比来源的数量更能说明问题，这一点在任何需要举证的场合都成立。

跟品牌自造缩写划清界限

公司内部常有一套自己的缩写，写文档时用得很顺手。

这些缩写在公司外面的搜索量是零，一次都没有。

它们进标题就是纯粹的字符浪费，还会让页面显得费解。

判断办法很简单，拿去搜索框查一次，没有结果就是自造的。

自造缩写只能出现在内部文档里，一律不进对外内容。

这跟品牌名在当地叫什么不由你定是同一条道理的延伸：命名权在市场那一边，公司能决定的只是自己的说法，决定不了别人的搜法。

自造缩写还有一个变体形式更难识别，就是行业内部通行但消费者完全不用的那些词。它们在搜索框里有量，只是搜的人全是同行和供应商，转化率接近零。这类词最好在词表里单独标一个内部词的标记，可以做内容但不该占用商品页的核心位置。

交付给外包时要附什么

外包最容易在这一层上出错，因为他们更依赖工具的默认行为。

交付包里要带三样：三类的定义、已确定的本地形态表、出处要求。

还要明确说明哪些行不许改，避免好心办坏事。

验收时抽查的重点放在第二类和第三类上。

第一类基本不会出错，不必浪费抽查名额。

这套交付物准备一次就能反复用，换一门语言只要替换本地形态表那一份。母语者说读着自然不能当验收判据这一条在这里格外适用，因为缩略语在句子里读起来永远都是自然的，无论它是不是当地人真正会用的那一个。

交付包里还要写清楚哪些位置允许出现英文缩写。参数表可以，正文第一段不行；筛选项的标签可以，页面标题不行。位置级别的规则比词级别的规则好执行得多，因为执行者不需要判断这个词属于哪一类，只需要看它出现在哪儿。

上线后怎么验证这一层做对了

第一个动作：拿本地缩略语搜一遍自己的站

用站点限定的搜索语法，把本地缩略语逐个查一遍。

返回零结果的，说明这个形态在站上一次都没出现过。

这个检查十分钟能做完一批，不需要任何工具。

它给出的是最直接的在场证明，比任何排名数据都清楚。

零结果和排名靠后是两件事，前者连候选池都没进。

这个动作最好在上线当天做一次，一个月后再做一次。当天做是为了确认内容确实上去了，一个月后做是为了确认索引确实收了，两次之间出问题的比例比想象中高。

这个动作还有一个变体值得一起做，就是用本地缩略语加品类词的组合去搜，看返回的是不是你想让它返回的那个页面。有时候站上确实有这个词，但它出现在一个不相干的页面上，用户搜到之后立刻跳出，这种情况比完全不在场更难从数据上看出来。

做完这个动作要把结果记在一张固定的表里，每次检查覆盖上一次的数字，保留时间序列。单次的检查结果只能告诉你现在的状态，连续几次的结果才能告诉你事情在变好还是变坏，而后者才是决定要不要继续投入的依据。

第二个动作：看站内搜索的零结果查询

站内搜索的零结果列表是这一层最好的诊断材料。

带冒号或撇号的查询如果大量返回零结果，说明分词没改对。

本地缩略语大量出现在零结果里，说明词表漏了这个形态。

这份列表每周看一次，五分钟能扫完。

它同时暴露词表问题和检索配置问题，性价比极高。

看这份列表的时候要留意查询的书写形态而不只是它的意思，同一个意思用不同形态打进来是两条不同的记录。按意思归并之后你会觉得问题不大，按形态分开看才能发现某一个特定写法的失败率高得离谱。

这份列表还有一个用法是反向验证词表。把零结果查询里出现频率最高的二十条拿出来，逐条对照词表看有没有对应行，对不上的就是词表的空白。用户已经替你把需求写出来了，你只需要把它抄进表里，这比任何关键词工具给出的建议都更接近真实需求。

第三个动作：对照本地同行的写法

挑三家本地头部同行，看它们的商品页怎么写这些缩略语。

重点看参数表和价格区，那是缩略语最集中的地方。

它们用的形态就是当地的通行形态，比任何词典都准。

这个对照每半年做一次就够，形态变化很慢。

如果三家写法不一致，说明这个词还没有形成共识。

没有形成共识的词处理起来反而简单，两种形态都覆盖就行，反正总量不大。真正要小心的是三家高度一致而你不一样的那几个词，那说明你用的形态在当地是明确的少数派，而不是一个可以并存的选项。在多语言市场里按书写系统分簇的那套做法在这里同样管用，同一簇里的语言往往共用同一批缩略语习惯。

做这个对照的时候顺便看一眼同行的页面标题结构，注意他们把缩略语放在标题的什么位置。位置反映的是他们对这个词权重的判断，而他们的判断是长期试出来的。这不是让你照抄，而是当你的判断跟三家都不一样的时候，值得回头再确认一次自己的依据。

同行对照还有一个容易被忽略的对象，就是本地的比价站和垂直目录。这类站点的商品命名往往是各家数据汇总后的产物，某种程度上代表了当地市场的最大公约数写法，比单看一家同行更有参考价值。

常见问题解答

缩略语这一层的工作量大概有多大？

按行业算，一个垂直行业需要单独处理的缩略语通常在三十到六十个之间，其中第一类占一半以上不需要动，真正要查证的是二三十个。一个人两天能把清单列完并找到出处，之后进入维护状态，每季度新增不超过三五个。相比它带来的覆盖提升，这是整个小语种项目里投入产出比最高的几件事之一，前提是你得先意识到这里存在工作。需要提醒的是这份清单要按行业而不是按语言来列，同一门语言在不同行业里的缩略语几乎没有重合，把上一个项目的清单直接搬过来通常只能复用其中很小的一部分。

为什么翻译公司不会主动提这件事？

因为在翻译的行业规范里，保留原文中的专有缩写本来就是一个合规的处理方式，甚至在很多场合是被推荐的做法。译者按规范交付，工具标记为完全匹配，审校读一遍觉得通顺，三个环节各自都没有失职。问题出在这套规范服务的目标是译文的准确与一致，而不是搜索覆盖，两者在这一层恰好指向相反的方向。所以正确的做法不是要求翻译公司改流程，而是把这一层作为独立的一项工作从翻译工单里拆出来，交给懂目标市场的人做，或者干脆自己做，因为它需要的是市场知识而不是语言能力。

带冒号的形态到底要不要收进关键词表？

要收，但不必给每一个格尾都建一行。收的方式是把基础形态和最高频的两三个格尾形态放进表里，其余的靠站内搜索和检索配置去兜。判断哪几个高频，看站内搜索日志里的实际分布，通常主格和一两个常用格就占了绝大部分。全部穷举既做不到也没必要，剩下的长尾形态贡献的量非常有限。另外要注意带格尾的形态在标题里通常不合适，因为标题多数是名词短语，用的是基础形态。这些形态真正的落点在正文的自然句子里，那里本来就需要它们，写对了顺手就覆盖掉了。

如果目标市场同时通行英文缩写和本地缩写呢？

这种情况很常见，处理办法是两个都收，然后按位置分工。搜索量高的那个进标题和一级导航，另一个放正文第一段和结构化数据的别名字段。关键是让两者在同一个页面上共现，建立起明确的等价关系，而不是分散到两个页面上互相竞争。判断谁的量高不要凭感觉，用广告后台跑一小笔预算测一周就有结果。还有一种情况是两个形态在不同人群里通行，比如专业买家用英文缩写、普通消费者用本地缩写，这时候按人群分页面比按形态分位置更合理，因为两批人要看的内容深度本来就不一样。

规格参数表由系统自动生成，改不动怎么办？

不必去改那张表，在它旁边加一段自然语言的说明就行。这段说明可以由模板从同样的字段生成，只是把缩写替换成完整说法并串成句子。工程量比改参数表小得多，也不会影响任何下游系统。对已经懂行的用户来说这段话是冗余的，但它是那批按完整说法搜索的用户唯一能命中的位置，这个交换很划算。如果连这段说明都不好加，退一步的做法是在页面的常见问题区里放一两条问答，用完整说法把最关键的那两三个参数讲一遍，成本更低，而且问答区本来就是接长尾查询的位置。

怎么判断一个缩略语在当地有没有本地版本？

最快的办法是把全称翻成目标语言，看词序有没有变化。词序变了的多半有本地缩写，没变的多半沿用原版。这个初判五分钟能做一批，之后只对存疑的几个做核实，核实的材料首选本地新闻媒体和政府文书，其次是本地同行的页面。不要用机器翻译反查，它在这一层的输出几乎全是英文原版。还有一个信号可以辅助判断，就是看这个概念是什么时候进入当地市场的。进入得早的概念通常已经沉淀出本地缩写，最近几年才进来的新概念多半还在直接沿用英文缩写，本地版本尚未形成。

这套做法在中文站上有对应的场景吗？

有，机制是一样的，只是表现形式不同。中文里的对应现象是英文缩写和中文全称并存，用户两种都会搜，而内容里往往只出现其中一种。判断方法也一样：把两个形态都列出来，看真实查询里的分布，然后按位置分工让它们在同一页共现。差别在于中文不存在格尾接标点的问题，所以分词那一层的麻烦要少很多。另外中文站上还有一类特殊情况是同一个英文缩写对应两个不同的中文译名，两个译名各有各的用户群。这时候不是选一个的问题，而是必须在页面上把两个译名都提一次，让搜任何一个的人都能落到这里。

权威参考资料