德语版页面上加粗的那个词是个介词，而翻译校验一路全绿放行

摘要：加粗和斜体在源语言里罩住的是一个词，在文件里存的却是一段位置。语序一变，同一段位置罩住的就是另外一个词，而所有翻译校验查的都是标签的数量和名字，没有一项在问它罩住的意思对不对。本文把这层错位拆开，顺带解释为什么斜体和粗体在好几套书写系统里根本不成立，最后给出一条不依赖版面的替代路线。

为什么德语版页面上加粗的那个词是个介词？

一次真实的错位长什么样

那是一家做德语市场的户外装备站，主力品类是冲锋衣。

英文原页上有一句话，把最核心的那个卖点词加了粗。

德语页面上同样的位置也有加粗，粗体一个不少。

但被粗体罩住的，是一个只有两个字母的介词。

那个真正的卖点词，就在粗体外面，一个像素都没沾上。

这不是个别页面的手滑。同一批上线的一百多个商品描述里，凡是源文有句内强调的，德语版几乎都有类似的偏移，只是错得没那么显眼——有的罩住了半个词，有的罩住了冠词加名词的前半截，有的干脆把标签闭合在了词的中间。

更要命的是，从上线到被发现，中间隔了七个月，期间没有一个人报错。

这个站后来把三个语言版本各统计了一遍，德语的错位率最高，法语居中，荷兰语最低，顺序正好跟这三门语言相对英语的语序差距一致。这个巧合后来成了排查的第一条线索，也让人第一次意识到根源在语序而不在某个译者。

源句和译句的词序差在哪一步

英语的形容词几乎总是紧贴在名词前面。

德语这句话为了表达同一个意思，用了一个不同的句式。

最高级的那个词被推到了名词前面的另一个位置。

句子长度也不一样，德语比英语长了将近三成。

于是同样从句首数过去的第几个词，两边指的不是一回事。

德语复合词和格变化那篇里讲过一个类似的道理：德语的名词短语内部是有强制配合关系的，冠词、形容词、名词三者要一起变。这意味着译者在处理这句话时，改动的不是一个词，而是一整个短语的构造，词的顺序和数量都会跟着变。

而标记是在这一步之前就已经定好位置的。

值得留意的是，这一步的错位跟译者水平几乎无关，甚至是反着来的。译得越地道、语序调整得越大，标记偏得越远；反倒是那种硬按英语语序直译的译文，标记还能凑巧落对位置。责任归属最容易在这里被误判。

这件事为什么没有人报错

本地读者读到的是一句完全正确的德语。

意思对、语法对、术语对、语气也对。

唯一不对的，是有个词被莫名其妙地加粗了。

这在读者眼里最多算排版有点怪，不构成一个错误。

没有人会为了排版有点怪去提工单。

保哥在几个项目上反复见到同一件事：凡是不构成错误、只构成怪异的问题，反馈链路是彻底断的。用户不报，因为报了也说不清；客服不转，因为这不影响下单；母语审校不提，因为审校单上没有这一项。于是它可以在站上安安静静地待很多年。

还有一个更结构性的原因：反馈渠道本身是有语言的。客服后台、工单表单、评价入口多数只有一两种界面语言，本地用户要跨过一道门槛才能把这件小事说出口。愿意为一个排版怪异跨门槛的人，实际上一个都没有。

内联标签在译文里到底是怎么错位的？

标签在文件里存的是偏移量不是词

把一句带格式的话交给翻译流程，它不会以富文本的样子过去。

格式会被抽成一组标记，插在纯文本的某几个位置上。

行业里通用的交换格式是XLIFF，它把这些标记单独编号。

标记本身不带任何关于它罩住了什么的信息。

它只知道自己该出现在这段文字的哪个地方。

XLIFF 2.0规范里定义的内联标记族把成对标记、独立标记、代码片段分成了几类，每一类都有id属性用来跟源文对应。设计上这套东西解决的是“标记不能丢、不能重复、配对不能乱”的问题，它从来就不负责保证标记两端夹着的还是同一个语义单元。

这句话可以再直白一点：标签标的是位置，而你要的是词。

可以拿一个更熟悉的东西类比：这就像给一段录音打时间戳，时间戳记的是第几秒，而不是“那句话”。同一段内容重录一遍，语速一变，原来的时间戳指向的就是另一句话了。标记跟译文之间的关系，正是这么一回事。

译员看到的是占位符不是加粗效果

在多数翻译工具里，译员看到的句子长这样：源文里那对粗体标签显示成两个灰色小方块。

方块上没有“这里是粗体”的提示。

它们看起来跟一个换行符、一个变量占位符没什么区别。

译员的任务是把句子译对，顺手把方块摆回去。

摆哪儿呢？多数人凭直觉摆在差不多的位置上。

这里有个很不直观的地方：译员越是不熟悉这个标记的含义，摆得越保守——保守的意思是尽量贴着原来的相对位置摆，而这恰恰是错得最厉害的摆法。真正摆对的前提是知道那对方块是粗体、而且知道这一句里该加粗的是哪个概念，这两条信息在工作界面上都没有。

做本地化的人管这叫标记盲摆，做站的人根本不知道有这回事。

这里其实有个成本很低的改进：在给译员的句段备注里，把每一对标记原本罩住的源文词单独列一行。多数工具都支持这类附注，配置一次长期有效。做过这件事的项目，标记错位的比例通常能降到原来的三分之一以下。

机器翻译把标签当成一个无意义符号

直接上机器翻译的站，这一层的错位只会更普遍。

模型看到的输入里，标签是一串跟正文混在一起的字符。

它会尽力把这串字符原样搬到输出里去。

搬到哪儿取决于模型学到的对齐关系，不取决于语义。

短句还好，长句和从句一多，位置就开始飘。

机器翻译直接发布那篇讨论的是内容质量的下限在哪里，标记错位是那条线之外的另一类损伤：它不影响句子的可读性，所以任何以可读性为准的质量评估都测不到它。你把译文丢给一个打分模型，它会给出很高的流畅度分，因为流畅度确实很高。

换句话说，这是一类专门躲开质量评估的损伤。

另一个容易被忽略的细节是，不少机器翻译接口对带标记的输入有专门的处理模式，跟纯文本模式的结果并不一样。有的会先剥掉标记再还原，有的整串直接处理。接口文档里通常写了，但接的人一般不看，默认是什么就用什么。

富文本字段直接复制粘贴的那一类

还有一条更土的链路，反而最容易出问题。

运营在后台的富文本编辑器里直接编辑各语言版本。

做法通常是把英文那一版整段复制过来再逐句改写。

改写的时候，粗体是跟着原文的字符一起继承下来的。

你改掉了词，格式还留在原来那几个字符上。

这条链路的隐蔽性在于它连一次机器处理都没有经过，所以任何针对流水线的检查都覆盖不到它。真要查，只能去数据库里把各语言版本的富文本字段拉出来对着看。

顺带说一句，这条链路上的错位比例，在保哥经手的项目里是最高的。

这条链路还有一个特有的坏毛病：编辑器会把粘贴进来的样式一并保留，包括从文档软件带过来的那些行内样式。于是同一个页面上既有语义标签，又有一堆写死颜色和字号的样式，后者在别的语言版本里连该不该存在都没人判断过。

翻译工具的标签校验为什么一路全绿？

校验项检查的是集合相等

主流的本地化平台都带一整套自动校验。

标记这一块的检查项一点都不少。

Weblate的校验项清单里，XML标记这一项的判据写得很明白：译文里的标签跟源文不一致就报错。这里的不一致指的是标签的集合——少了一个、多了一个、名字对不上、配对没闭合，都会被抓出来。

这些检查确实有用，而且抓到的问题不少。

问题在于，集合相等是个跟顺序无关的条件。

两个粗体标签，源文有、译文也有，集合就相等了。

至于它们在句子里夹住了谁，检查项里没有这一条。

集合相等这个设计其实有它的历史原因：这套校验最初服务的是软件界面文案，那些字符串又短又简单，一句话里通常只有一个占位符，位置也基本不会动。规则搬到长句富文本上就不够用了，但没人回头改，因为在原来的场景里它一直很好用。

连标签周围的字符都有专项检查

这一层最讽刺的地方在这儿。

同一份清单里还有一项，专门检查标签周围的字符对不对齐。

也就是说，标签前面有没有多一个空格，是被检查的。

标签后面紧跟的是不是标点，也是被检查的。

唯独标签之间夹着的那个词是不是同一个意思，没人管。

这不是工具做得不够细，恰恰相反，它已经细到了字符级。能够被自动校验的只有形式，语义锚点这件事天然需要一个懂两门语言的人看一眼，而这一眼恰好是整条流水线上最贵的一步，所以它被省掉了。省掉之后所有指示灯还是绿的，这才是真正麻烦的地方。

类似的另一家平台，Crowdin的质量检查设置页列的项目结构几乎一样，标签一致性也是按集合判的。

想验证这一点很容易：随手挑一段带加粗的译文，把那对标签整体往右挪三个词，再跑一遍全套校验。所有指示灯依然是绿的。这个小实验做完，团队里对“校验通过等于没问题”的那点信心通常当场就没了，比讲十遍道理管用。

这跟术语一致性检查不是一回事

有人会说，术语库不是能管住关键词吗。

术语检查管的是“这个概念译成了哪个词”。

它确实能保证卖点词在译文里出现，而且出现的形态正确。

但术语检查完全不关心这个词有没有被格式罩住。

两套检查各管一段，中间那块正好是空的。

更细一点说，术语检查是在纯文本层跑的，跑之前标记通常已经被剥掉了；标签检查是在标记层跑的，跑的时候不认识哪些是术语。两个检查器看的是同一句话的两个投影，而错位只在把两个投影叠回去的时候才看得见。

所以这件事不是靠加一条规则能解决的，得换一个看的角度。

顺着这个思路能养成一个通用的排查习惯：凡是两个检查器分别在不同的抽象层上工作，它们中间就有一条缝，而缺陷最爱藏在缝里。找缝的办法是把每个检查器的输入画出来，看看有没有哪个维度在所有输入里都被丢掉了。

哪几类页面最容易出现标记漂移？

商品描述里那种半句话加粗

风险最高的是句内强调，也就是一句话里只加粗其中几个词。

整段加粗、整个标题加粗，反而不太出事。

原因很简单：整段的边界跟句子的边界重合。

句子怎么改写，边界都还在两头。

句内强调的两个边界都落在句子内部，语序一动就跟着动。

这条判据可以直接拿去排查：先把全站的句内强调找出来，整段强调可以先放一边。在那家户外装备站上，句内强调只占全部加粗的四成，但错位的案例百分之百都出在这四成里面。

找出来之后再按语言排序，语序差别越大的语言排越前面。

还有一类介于两者之间的情况：整句加粗，但这句话在译文里被拆成了两句。这时候标记通常只跟着前半句走，后半句悄悄失去强调。这种错位比句内偏移更隐蔽，因为页面上看着挺正常，只有对着源文才能发现少了半句。

判断一段强调是不是句内强调，有个不用读句子的土办法：看强调片段前后紧挨着的是不是标点。两头都贴着标点的，多半是整段或整句；有一头贴着的是词，那就是句内强调，收进待查清单。

帮助中心与退换货条款

第二类是条款型内容，尤其是退换货和配送说明。

这类内容里加粗用得特别多，因为要突出时限和例外。

而这些内容通常是法务或客服提供的，不走内容团队的流程。

它们进翻译流程的时候往往已经是一堆带格式的富文本。

校对的时候大家看的是意思对不对，没人看粗体在哪儿。

这里的代价不只是搜索层面的，还有一层实际风险：条款里加粗的通常是对用户不利或者需要用户注意的那一条，如果粗体在译文里罩到了别处，你在事实上削弱了一次提示。这一点在有强制披露要求的市场上不是小事。

处理办法是把条款型内容单独拉一条线，不跟营销文案混着走。

条款类内容还有一个特殊之处：它的更新往往由法务单方面推动，改完直接覆盖，不走内容排期。于是即使某次全站排查把格式修好了，下一次条款更新又会把旧格式原样带回来。要根治，得把这条线的更新流程一并纳进来。

从英文模板批量生成的落地页

第三类是模板化生成的页面。

一套模板，几十个变量，铺出成百上千个落地页。

模板里的加粗是写死在模板上的，位置固定。

变量替换进去之后，加粗罩住的可能是变量也可能是变量旁边的词。

不同语言的变量长度和位置一变，罩住的东西就不一样了。

模板类内容的特点是错一次错一片。查这类问题的顺序应该反过来：不查页面，查模板。一套模板抽三个语言各看一条，比抽一百个页面有效得多。

查模板还有个额外好处：模板的数量是有限且可枚举的，而页面数量是无限增长的。把有限集合查干净，无限集合就自动干净了。这个思路在很多本地化排查上都成立，凡是能找到生成源的，就别再去查生成结果。

模板类内容还有个特点：它的强调位置往往是设计稿定下来的，而设计稿只出过一版英文的。也就是说这些位置从来没有针对任何一门目标语言被重新审过，风险是设计阶段就埋进去的，不是翻译阶段产生的。

斜体和粗体在非拉丁书写系统里成立吗？

这两个手段是从哪儿来的

粗体和斜体不是天然存在的排版概念。

斜体来自意大利手写体，最初是一整套独立的活字。

粗体是后来为了在同一页上做出层次才铸出来的。

两者都是围绕拉丁字母这套字形长出来的东西。

它们能表达强调，是因为读者从小就在拉丁字母里见惯了。

把这层历史摊开，一个问题就自然浮出来了：一个从某一套字母的书写传统里长出来的手段，凭什么假设它在别的书写系统里也成立。这个问题在做多语言站的时候几乎没人问，因为编辑器上就摆着那两个按钮，按一下就有效果。

有效果不等于成立，这两件事差得很远。

顺着这条线还能问出第二个问题：既然强调手段是跟着书写传统长出来的，那么强调这个动作本身的强度和使用频率，也未必跟英语一样。有些书写传统里，正文中频繁强调本身就被看作不得体，这一层比选哪种记号更根本。

日语的重点标记是傍点不是斜体

日语正文里几乎不用斜体。

假名倾斜之后可读性下降得很厉害，读者也不习惯。

日语传统的做法是在要强调的字旁边点一串小点。

竖排时点在字的右侧，横排时点在字的上方。

这套记号在中文里也有，叫着重号。

日语排版处理需求这份文档把这类记号的位置、形状和适用场合都写得很细，它是这一层最完整的一份参考。日语的三套文字怎么记关键词那篇讲的是字符层的选择，这里讲的是同一门语言在版面层的另一套约定。

浏览器这边有对应的属性，叫文字强调，可以直接生成这类点。

实际做的时候有个细节要留意：傍点是逐字标注的，所以它对标注范围的敏感度比加粗高得多。范围多包进一个助词，视觉上立刻看得出来，因为那个助词头上多了一个点。这反过来是件好事，错位在日语版上比在德语版上更容易被肉眼抓到。

中文的着重号与波浪线

中文的情况跟日语接近但不完全一样。

着重号是标准的强调方式，写在字的下方。

书名和篇名另有专门的标记，跟强调不是一回事。

中文正文里加粗是可以的，斜体则很少见。

汉字倾斜之后笔画关系会变形，看着别扭。

中文排版需求这份文档里对着重号的位置和样式有明确描述，做中文站的人反而很少去翻它。这里有个挺有意思的现象：越是母语，越容易觉得排版这件事“就那样”，反而不去查规范。

做面向中文读者的页面时，这一层其实值得单独过一遍。

中文这边还有一条实践建议：着重号在移动端小字号下辨识度不高，正文里用加粗其实更稳妥，着重号留给需要精确到字的场合。规范给的是可选项不是必选项，具体选哪一个要看实际的阅读环境，这一点规范本身也没替你决定。

还有一点值得提醒：中文的书名号和引号本身也带一部分强调功能，正文里如果标点已经把重点圈出来了，再叠一层加粗就显得吵。多语言站上尤其要注意，因为源文的英语没有书名号这一层，译文很容易叠加过度。

俄语的字距加宽是一种强调

西里尔字母这边有另一套传统。

把一个词的字母之间拉开距离，就是在强调它。

这种做法在俄语印刷品里有很长的历史。

它在网页上对应的是一个纯样式属性，不动字符串。

但历史上在打字机时代，它是靠在字母之间真敲空格实现的。

这条历史线索值得记一下：同一个强调手段，用样式实现和用字符实现，在检索层面是天壤之别。真敲了空格的那种写法，分词器看到的是若干个单字母，这个词在索引里直接消失。俄语格变化那篇里讨论的词形问题，在这种情况下连词都拼不出来了。

好在现在没人这么干了，但类似的思路换个形式又回来了，下面会讲到。

这条传统今天还有一个活着的变体：社交媒体和广告里常见把词拆成单个字母、中间加空格的写法，用来抢注意力。这类内容一旦被搬进商品页或者用户评价区，就会在索引里留下一堆单字母词条，而且几乎不可能靠后期清洗还原。

浏览器合成出来的粗体和斜体会带来什么？

字体缺字面的时候浏览器不会告诉你

一套字体不一定包含粗体和斜体的独立字面。

拉丁字母的商业字体通常都带，很多其他字体不带。

缺了怎么办？浏览器会自己算一个出来。

粗体靠给笔画描边加粗，斜体靠把字形整体倾斜。

页面上看着有效果，实际上那不是设计师画的字。

MDN关于字体合成属性的说明把这件事讲得很直接：用于中文、日文、韩文以及其他表意文字的字体通常不包含这些变体，合成它们可能损害可读性，甚至改变文本的含义。最后半句值得多读一遍——不是变丑，是改变含义。

这条跟做站的直觉是反的：默认行为不是“没实现”，而是“替你编了一个”。

判断有没有走合成，最直接的办法是把同一段文字用真粗体字面和默认设置各截一张图，放大对比笔画的末端。合成出来的粗体，笔画两端会显得圆钝而且粗细均匀；真字面则保留了原本的粗细变化。看过一次就再也不会认错。

合成倾斜会打断连写

问题最严重的是连写类文字。

阿拉伯字母的字形要根据在词中的位置改变形状。

字母之间还要连成一条连续的基线。

整体倾斜之后，连接处的角度全乱了。

读者看到的是一串接不上的笔画。

阿拉伯语的排版与方言那篇处理的是版面方向和语言变体，这里是同一门语言在字形层的另一类损伤。阿拉伯语与波斯语排版需求文档专门讨论了这类字形连接规则，它解释了为什么倾斜这个动作在这套文字上根本没有对应物。

MDN那一页给的示例代码，恰好就是给阿拉伯语关掉合成。

需要说明的是，这类文字并非没有强调手段。传统上会换用一套结构不同的字体，或者加大字号、改变颜色。这些手段的共同点是不去动字形本身的几何关系，而倾斜恰恰是唯一一个去动它的操作，所以只有它在这里不成立。

实际排查的时候，这类问题往往不是在浏览器里发现的，而是在生成分享图或者导出文件的时候暴露出来。同一段文字换一个渲染环境，合成的规则就变了，字形错乱得更明显。留一条导出通道当探针，比反复截图有效。

合成加粗会把笔画糊在一起

表意文字这边是另一种坏法。

汉字的笔画本来就密，小字号下间距很紧。

描边加粗一上，密集区域的空隙先被填满。

结果是几个笔画粘成一团，字变成一个黑块。

笔画少的字没事，笔画多的字先糊，同一句话里粗细不均。

网页字体的字形集与首屏成本那篇算的是要加载多少字形的账，这里是同一笔账的另一半：你为了省流量只加载了常规字重，代价不是没有粗体，是浏览器替你造了一个质量不受控的粗体。这笔代价不在流量报表上，只在截图里。

真要用粗体，就得老老实实把粗体那一套字面也加载进来。

这一层还有一个常被忽略的连带影响：糊掉的通常是笔画最多的那批字，而笔画多的字在专业术语和品牌名里出现的比例偏高。也就是说，被糊掉的恰好是页面上最不该糊的那几个词，这跟随机分布完全不是一回事。

强调该换成什么载体才不出事？

载体分三层：字符、标记、样式

强调这件事，落到实现上只有三个位置可选。

第一种是直接改字符串，比如在字母之间插空格。

第二种是加标记，比如那对粗体标签。

第三种是写样式，比如那个文字强调属性。

三种都能在页面上做出效果，代价完全不同。

第一种的代价最容易算清楚：凡是改动了字符串本身的动作，机器都会一起读到，软连字符和零宽空格都算在里面。本篇讲的是第二种——标记不改字符串，所以检索层是干净的，但它带来了一个字符层没有的新问题，就是锚点会漂。

第三种的好处是既不动字符串，也没有锚点可漂。

三层之间还有一个撤销成本的排序：字符层的改动散落在每一条数据里，撤回来要动全部内容；标记层集中在模板和富文本字段里；样式层通常只在一两个文件里。选载体的时候，先想清楚三个月后你想撤的时候要动多少东西。

样式载体的好处是不动字符串

用样式实现强调，本质上是把这件事交给了选择器。

选择器可以按语言选，按位置选，按类名选。

按语言选这一点特别有用。

同一个类名，在日语页面上出成傍点，在德语页面上出成粗体。

内容那边一个字都不用改。

用语言属性做样式选择的那篇问答把这套写法的注意事项列得很清楚，核心是别用类名去冒充语言，页面上的语言属性本来就该填对。文字强调属性的文档则给出了各种记号形状和位置的取值。

这条路的代价是需要前端配合，而且需要有人真的去填语言属性。

这条路还有一个附带收益：强调的样式一旦集中到样式表里，就有了统一调整的可能。想把全站的强调从加粗改成换色，改一行就行；如果强调是散在内容里的标签，那就得重新过一遍所有内容。集中带来的灵活性会被语言数量放大。

每个字包一个标签是最坏的一种

有一种做法要单独拎出来说，因为它看着很聪明。

为了实现傍点效果，有人给每个字都套一层标签。

然后用背景图或者伪元素在每个标签上点一个点。

页面上的效果跟标准做法一模一样。

但正文提取器看到的是一串各自独立的节点。

很多提取实现会在元素边界断词，于是一个完整的词被切成了若干个单字。泰语分词那篇讲的是一门本来就没有空格的语言怎么建词边界，而这里是反过来，一门本来有边界的语言被人为拆掉了边界。这跟俄语打字机时代真敲空格的做法是同一个错误换了件衣服——一个是在字符层插东西，一个是在文档结构层插东西，落到分词那一步的后果没有区别。

判断办法很简单：把渲染出来的页面复制一段文字，粘到记事本里看看还连不连着。

这种做法通常不是前端主动想出来的，而是从某个还不支持文字强调属性的旧浏览器时代继承下来的兼容代码。麻烦在于兼容代码往往没有退场机制，浏览器早就支持原生属性了，那段代码还在跑。定期清一遍历史兼容层，值得排进技术债清单。

把版面手段换成句法手段的三种改写

把要强调的词挪到句首

最省事的一种改写是调整语序。

要强调哪个概念，就把它放到句子最前面。

多数语言里，句首位置本身就带强调功能。

这个位置不依赖任何标记，也不依赖字体。

翻译过去之后，译者会自然地保住这个位置。

之所以能保住，是因为译者处理的是意思不是位置。你要求的是“这个概念要突出”，这是一条译者能理解、能执行、也能自检的指令；而“这两个标签之间要夹住它”不是，那是一条只有工程才看得懂的指令。凡是能用语言本身表达的要求，都比用标记表达的要求更容易穿过语言边界。

代价是句子要重写，而且不是每句话都能这么改。

这一招在语序自由度高的语言上效果最好，比如俄语、波兰语、芬兰语，把成分挪到句首基本不用改动句子的其他部分。语序刚性的语言麻烦一些，往往要改成分裂句或者强调句式，代价高一点，但仍然是译者熟悉的常规操作。

把它单独拆成一句短句

第二种改写更彻底一点。

把要强调的那部分从长句里拆出来，自己成一句。

短句在长句之间天然显眼，不需要任何格式。

这一招在中文和德语上都特别管用。

德语的长句本来就多，一个短句插进去对比强烈。

这种写法还有个副作用是好事：短句更容易被摘出来当答案。长句里的一个粗体词，在被摘引的时候通常连格式一起丢掉；而一个独立的短句本身就是一个完整的语义单元，摘走了还是完整的。

代价是文风会变，得跟内容团队商量。

拆句子还有一个跨语言的好处：句子越短，翻译时语序重排的空间越小，其他类型的错位也跟着减少。写作时把长句拆开这件事，通常被当成可读性优化，其实它同时是一项本地化风险优化，两笔收益是一起拿的。

还有一个很实际的好处：短句在被机器翻译处理时的错位率明显更低，因为可供重排的成分本来就少。如果你的站有一部分内容注定要走机翻，把这部分内容的句子长度压下来，是一项一次性投入长期见效的改动。

换成一个短列表

第三种是把并列的强调点改成列表。

三个要强调的卖点，与其在一段里各加粗一次，不如列三条。

列表的结构是标记表达的，但它的边界是整条不是句内。

整条的边界不会因为语序变化而漂移。如果站内搜索给强调词加了权，记得连权重配置一起复核，光改内容不改配置等于只修了一半。

这是它比句内加粗稳的根本原因。抽样时一定要跨内容来源，营销文案、条款、模板页各抽几条，只抽一类很容易得出错误结论。

顺带一提，列表在被摘引的时候保留率也更高。内链锚文本的形态变体那篇讲过一个方向相反的招：句内锚在屈折语里做不到精确匹配，就把精确匹配的需求整体挪到列表、卡片、面包屑这些非句内位置上去，把语法问题变成版面问题。这里是反过来的，把版面问题变成句法问题，两条路的共同点是都不硬碰句子内部。风险最高的是源语言与目标语言语序差别大的组合，英语对德语、英语对日语都属于这一类。

列表要用得对，有一条得注意：每条的措辞结构要一致，否则译文里很容易被译成参差不齐的几句话，看着反而不如原来整齐。在给译者的说明里写一句“这几条请保持相同的句式”，比事后返工便宜得多。

怎么扫一遍全站把罩错词的标记找出来？

先扫强调标签里的文本做词频

排查的第一步不需要任何工具，写十几行脚本就够。

把每个语言版本的页面拉下来，抽出所有强调标签之间的文本。

不做分词，先直接按空格切，统计出现频次。

然后把频次最高的三十个词打印出来。还要确认字体文件里真的有粗体那一套字面，只在样式里写了粗体而字体没带，效果一样是合成的。

一眼就能看出这个站在强调什么。

健康的站上，这份榜单顶部应该是品类词、卖点词、材质词。出了问题的站上，顶部会出现冠词、介词、系动词这类东西。这份榜单是整个排查里性价比最高的一步，因为它不需要跟源语言对照，本语言内部就能看出不对劲。

那家户外装备站的德语榜单，前五名里有三个是冠词。可以先在一个品类上试点两周，对比转化和停留数据再决定要不要铺开，这类改动不必一次到位。

这份榜单还有一个副产品：它能顺便告诉你这个语言版本到底在强调什么概念，跟你的关键词策略对不对得上。经常会发现强调最多的是运营顺手加粗的几个形容词，而真正的品类词一次都没被强调过。这跟错位无关，但同样值得改。

功能词占比是最快的信号

把这个观察量化一下，就是一个可以长期盯的指标。

统计强调标签内文本里功能词所占的比例。两个问题同时出现在同一句话上时优先级要提，那通常说明这条链路上的人工环节整个是空的。

功能词就是冠词、介词、连词、代词这一类。

每门语言的功能词表都是封闭的，几十个词而已。

健康值应该很低，因为没人会故意去加粗一个介词。

这个指标的好处是跨语言可比：英语版本的功能词占比是多少，德语版本就该在同一个量级。差出好几倍，基本可以断定有系统性偏移。要注意功能词占比在不同语言之间本来就有基线差异，所以看的是相对倍数不是绝对值。

把它挂到定期任务上，改版之后自动跑一次。

这个指标还可以再拆一层：把强调片段按长度分桶，一个词的、两到三个词的、更长的各算一份占比。错位通常集中在最短的那一桶里，因为短片段一偏就整个偏掉，长片段偏一点还能罩住一部分正确内容。分桶之后信号会干净很多。

跟源语言的同位置对照

前两步能定位到有问题的页面，第三步才能确认。

把源语言和目标语言的同一段落并排放。

各自把强调标签里的文本抽出来。

然后问一个问题：这两组词是不是同一个概念。

这一步没法自动化，需要人看。

但要看的量已经很小了。经过前两步筛选，一个上千页的站通常只剩几十段需要人看，一个懂两门语言的人半天能看完。母语审校验收清单那篇里讲的分级验收思路在这里正好用得上：不是所有内容都值得逐句核，值得核的是那些自动检查覆盖不到的维度。

人看这一步的时候，判断标准要写得极简单，只留对和不对两个选项，别让人当场写理由。理由留到统计完再补。判断和解释分开，看的速度会快好几倍，而且判断的一致性反而更高，这是做任何人工标注都适用的一条经验。

这套排查该怎么排进本地化流程？

在验收单上加一条标记锚点

长期解法只有一条：把它变成一个验收项。

验收单上加一行，写清楚要核的是什么。

措辞很重要，别写成“检查格式是否正确”。

要写成“确认加粗罩住的是源文强调的那个概念”。

前一种写法谁都会打勾，后一种写法必须真去看。

保哥的经验是，验收单上的条目措辞决定了它会不会被认真执行。凡是可以在不看内容的情况下打勾的条目，最终都会在不看内容的情况下被打勾，这跟执行者是否负责没有关系，是条目设计的问题。

这一条还可以再加一个约束，就是留下证据：要求勾选的人贴一张源文与译文强调部分的对照截图，附在验收记录里。有没有真看过，从拿不拿得出证据就知道了。这个要求不会增加多少工作量，但会明显改变执行的质量。

措辞之外还有一个细节：这一条要放在验收单靠前的位置。放在最后一条的检查项，被草草打勾的概率显著高于前几条，这跟内容无关，是清单本身的行为规律。把最需要动脑的那几项放前面，是清单设计的常识。

这一项该由谁来看

看的人必须同时懂源语言和目标语言。

纯母语审校看不出来，因为他们手上没有源文。

纯工程也看不出来，因为他们读不懂那句话。采购来的内容还要多查一处：对方交付时用的强调规范可能跟你的不一样，合并前先统一一遍。

最合适的是做译审的那个人，或者项目经理。

这一项加进去，每批内容多花不了多少时间。

需要提前把材料准备好：源文和译文的强调部分要抽好、并排放好，别让人自己去页面上找。准备材料这一步可以脚本做，看的人只负责判断。把判断和检索这两件事分开，是让人工环节不失控的通用办法。

如果项目上实在没有同时懂两门语言的人，还有一个折中办法：让母语审校只看目标语言那一侧，判断被强调的词在这句话里算不算一个有意义的强调对象。介词、冠词、系动词被强调，母语者一眼就看得出不合理，不需要看源文。

每次改版之后重新跑一遍

这类问题有个特点，会随改版复发。

模板改一次，加粗的位置可能整体挪一格。

内容批量重灌一次，之前修好的又可能被覆盖回去。

所以一次性排查是不够的，得变成周期动作。

周期不用太密，跟着发版走就行。

前面那个功能词占比指标在这里就体现出价值了：它足够便宜，可以每次发版都跑；跑出来是个数字，可以画成一条线；线一抬头就知道该去查了。真正难的从来不是修，是知道什么时候该去修。

还有一类触发时机容易被漏掉：翻译记忆库的批量更新。库里的旧句段被替换之后，下一批内容会大面积复用新句段，如果新句段里的标记位置本身就是错的，错误会被成倍复制出去。库的更新应该跟发版一样，也触发一次检查。换个角度说，它伤的不是搜索引擎对你的判断，而是你自己系统里那几个依赖强调信号的环节。

发版之外还有第三类触发点：换字体。换了字体之后，原本有粗体字面的语言可能变成没有，页面上的加粗从真字面悄悄退化成合成。这一类退化在功能词占比指标上完全看不出来，只能靠截图对比，换字体时要单独过一遍。

什么情况下这件事可以先放着

最后说一句反方向的话，免得排查变成负担。

如果你的站上根本没有句内强调，这件事跟你无关。

如果所有语言版本都是各写各的原创，也不用管。看的时候顺便记一下错位的方向，是整体右移还是罩到了冠词上，方向一致说明是同一个原因。

只有当格式是跟着内容一起跨语言搬运的，风险才存在。

判断只要一句话：这个页面的格式，是有人在这门语言里重新决定的，还是从别的语言继承来的？另外句子里的从句数量也是个好用的预警，超过两个从句的句子，格式基本别指望能自动摆对。

继承来的就查，重新决定的就不用。这条判据可以推广到很多本地化问题上：凡是从源语言继承而来、在目标语言里没有人重新做过一次决定的东西，都是高风险项，格式只是其中一类，字段结构、图片、数值单位、链接目标都适用同一条判据。

还有一种情况可以先放：站上语言虽多，但强调只出现在标题和小标题这类整段位置。这类位置的边界跟句子边界重合，天然不会漂移。判断只要看一眼富文本字段里强调标签的位置分布，全都落在段首段尾就基本安全。还有一点，中日文页面上少量加粗最有效，满屏加粗等于没加粗，这在哪门语言里都一样成立。

常见问题解答

加粗标签罩错了词，会直接影响排名吗？

直接的排名影响很小，主流搜索引擎早就不把加粗当成强相关性信号了。真正的影响在两个别的地方。一是被摘引的时候，很多摘要生成会优先取被强调的片段，罩错了词意味着摘要里出现的是个介词。二是站内搜索和内部权重计算，如果你的搜索实现给强调词加了权，那这个权重就加错了对象。所以它不是一个排名问题，是一个表现问题加一个内部数据问题。真要保留句内强调，至少把强调对象在术语库里登记一次，让译审知道这句话该突出哪个概念。

怎么快速判断我的站上有没有这个问题？

最快的办法是抽三个页面手动看。挑那种商品描述里有句内加粗的页面，把英文版和目标语言版并排打开，各看一眼加粗的是哪个词。三个页面里有一个对不上，就说明存在系统性问题，值得跑全站扫描。三个都对上也别急着放心，换一个内容来源再抽三个，特别是条款类和模板类的页面。这一步花不到二十分钟，比读任何一份报告都直接。如果只能修一个，先修那些出现在商品页首屏和条款页的，这两处的每一次错位都直接对着用户。页面上没有源文的时候，先看目标语言那一侧够不够合理，也能筛掉一大半。

用机器翻译的站，标记错位是不是必然的？

不是必然，但概率明显更高，而且跟句子长度强相关。短句和标题基本不会出错，长句、带从句、带并列结构的句子出错率高得多。如果一定要用机器翻译，一个可行的折中是把带格式的句子单独挑出来，把格式先剥掉再翻译，翻完人工把格式加回去。剥格式这一步可以自动做，加回去这一步必须人做，但需要人做的量已经很小了。还有一条经验，同一批内容里句子最长的那百分之十，值得单独抽出来人工过一遍。

日语和中文页面上到底能不能用加粗？

可以用，加粗在这两门语言里都是被接受的强调方式，只是要确认你加载的字体真的带粗体字面。斜体则建议直接避开，效果不好而且读者不习惯。如果想更地道一点，可以用文字强调属性做傍点或者着重号，这是这两门语言的传统做法，浏览器支持已经足够好。需要注意的是傍点会占用行外的空间，行高要留够，否则会跟上一行挤在一起。另外这两门语言里，加粗和着重号不要在同一段里混用，读者会以为它们表示不同的层级。

把强调改成句法手段，会不会影响文案的表现力？

短期看会有一点，因为写惯了加粗的人会觉得句子平了。但这件事有个补偿：句法手段是所有语言都有的，改完之后各语言版本的表现力是一致的；而版面手段在有些语言里本来就打折扣，改之前的一致性是假的。实际操作中不必一刀切，营销页面可以保留句内强调但单独走一遍核对，条款和模板类内容优先改成句法手段，两条路并行成本最低。实际推进时，先在新写的内容上执行新规范，存量内容随改版顺手改，别单独立一个清理项目。

标记漂移和术语不一致，哪个更值得先修？

术语不一致优先，因为它同时伤可读性和检索，而且用户看得见。标记漂移排第二，它只在检索和表现层面有影响，用户基本无感。但两者的修复成本不一样：术语不一致要重写句子，标记漂移多数情况下只要移动两个标签的位置。所以实际排期上可以并行——术语交给译审慢慢改，标记交给脚本先把清单拉出来，谁有空谁先动。还有一点，标记漂移修完之后要顺手复核一次，别让修的人凭直觉把标签挪到了另一个错的位置。

只有一种语言版本的站需要担心这件事吗？

基本不用。这个问题的根源是格式跨语言搬运，单语言站上格式是在同一门语言里决定的，不存在漂移。但有一个例外值得注意：如果你的单语言站用了从别处买来或者翻译过来的内容，哪怕最后只发一种语言，中间也经过了一次跨语言搬运，风险照样存在。判断依据仍然是那一条，看这段内容的格式有没有人在最终语言里重新决定过。还有一种情况要留神，站上如果嵌了第三方评价或者问答插件，那部分内容的格式也不归你决定。另外一种要留意的情况是自动生成的摘要，它可能保留了原文的格式而丢掉了上下文。

权威参考资料