多语言网站界面文案漏翻：字符串抽取、伪本地化检测与补救顺序

摘要：页面上的字分两类：进过翻译文件的，和写死在代码里的。前一类按字数计价、有交付物、有验收；后一类从没被交出去，所以在荷兰语页面上一直是英文。这批字只有几十到几百个，位置却很关键：按钮、筛选器、面包屑、空结果提示、发货邮件，都是页面上文本最少、阅读最多的地方。缺口在报价时就看不见，因为字数统计只数得到已抽出来的部分。本文说明字符串抽取做什么、哪五类位置最容易漏、怎么用伪本地化在没有任何译文时先测一遍，以及上线三年的老站按什么顺序补。

多语言页面为什么有的界面文案翻了、有的没翻？

一家母婴站的荷兰语页面，八个英文词暴露了整个站

有个客户做母婴用品，主营婴儿推车、安全座椅、背带、辅食工具几类。

荷兰语站上线半年，内容侧做得相当扎实：品类页、商品页、指南文章全部由本地写手产出。

转化率却一直只有同类市场的六成，团队查了支付、物流和价格，都没找到原因。

保哥用手机打开那个站，第一屏还没滑完就发现了问题。

正文确实是荷兰语，可商品图下面那排筛选按钮写着Sort by、Filter、In stock、Sold out，购物车按钮写着Add to cart，页脚的面包屑写着Home。

一共八个词，全站每一页都有，全是英文。团队里没人把它当问题，因为这些词在内容管理后台里根本不存在：后台文章列表里有三百多篇荷兰语稿子，一个字不缺。这八个词存放在另一个地方，内容团队从来不会打开那里。

漏翻的原因不在译员，而是这些字没被交付翻译

追查只用了二十分钟。

翻译供应商交付的是一批文档和一份界面词条表，词条表里有一百四十条。

前端模板里实际写着的英文短语，数下来有一百九十多条。

差出的五十多条从没出现在任何交付清单上，因为它们从没被抽出来。

它们直接写在模板文件里，和结构标签在同一行，通常是一个标签中间夹着一个单词。

译员没有漏翻，供应商没有偷工，项目经理也没有失职。这批词在整条链路上都不可见：不在待翻译文件里，所以没人报价；不在交付物里，所以没人验收；不在内容管理后台里，所以没人复核。三方都完成了各自的工作，缺口落在三份工作之间。

页面文字分两类，只有一类进过翻译流程

问题的根源是一条多数人没注意到的分界。

页面上展示给用户的文字，来源只有两种。

一种是内容，存在数据库里，由编辑撰写、译员翻译、内容管理系统输出。

另一种是界面文案，存在代码里，由工程师编写、构建流程处理、前端渲染。

用户分不出这两类字，它们在同一个页面上，字体和颜色都一样。

但这两类字走两条互不相交的管道，各有负责人、工具和排期。内容管道非常成熟，从选题到发布每一步都有人跟进；界面文案管道在多数团队里没有本地化环节，默认终点就是英语。本文后面描述的现象，都由这条分界线推出。

漏翻与翻译质量无关，它发生在翻译之前

这个问题在多语言讨论里几乎没人提，因为这类讨论大都默认手里已经有一份待翻译的材料。

讨论的是翻得准不准、地不地道、要不要用机器翻译、要不要请母语者复核。

这批词的问题出在更早一步：它们没进入待讨论的范围。

翻译质量做到满分，这批词仍然是英文。

由此还能推出一个更让人不舒服的结论：本地化完成度取决于三年前写模板的那位前端，而不取决于译者水平。他当时把一个词直接写进标签，还是写成变量，决定了这个词今天能否出现在荷兰语页面上。这个决定当时不需要评审，也没人知道。

界面文案的字符串抽取是怎么回事，漏抽为什么不报错？

字符串抽取这道工序具体做什么

多数内容岗没接触过这道工序，这里先讲清楚。

在原始状态下，用户能看到的一句话直接写在代码里。

抽取是指把这句话从代码里移走，换成一个引用。

代码里只留一个键名，文字本身移到专门的资源文件里。

资源文件按语言各存一份，运行时按当前语言读取对应的那份。

这套做法在工程侧叫国际化，通常缩写成首尾两个字母加中间的字母数。它和后续的翻译是两件事：国际化让文字可以被替换，翻译才是实际替换。国际化组织在自己的问答文档里写清了两者的边界，混淆两者是这个领域最常见的错误，本地化与国际化的区别那篇专门解释了为什么必须先做国际化。

抽取后的字符串以什么格式存放

抽出来的文字存进一个文件，格式取决于技术栈。

历史最久的一种是每条一个原文、一个译文，原文那行叫msgid，译文那行叫msgstr。

另一种是键值对，左边是自定义键名，右边是要显示的文字。

移动端各有格式，一边是扩展名为strings的文件，一边是strings.xml。

行业内做数据交换用的是另一套标准格式，翻译公司的工具基本都支持。

无论哪种格式，这批文字到这一步才成为可以清点、计价、发出去的资产。抽取之前它属于代码，抽取之后才算内容。分水岭就在这里：抽出来的按内容处理，没抽出来的按代码处理，而代码不会被送去翻译。

哪句话要抽取，由谁决定

决定权在写这行代码的人手里，而且是写的时候当场决定。

写一个按钮时，他可以直接把文字写进去，也可以调用一次翻译函数。

前者只要一秒；后者要起键名、到资源文件里加一条，慢得多。

只做英文站的阶段，两种写法渲染出来的页面完全相同。

于是多数团队早期都选了快的写法，也没人觉得有什么不妥。

两年后要出海，这个决定的代价才开始显现，而且很分散：几百个文件里各埋着一个小坑，没有一笔集中的大账。GNU的gettext手册专门有一节准备字符串，讲写代码时该怎么写才不留坑，可读这份手册的人和写商品页模板的人通常不是同一批。

字符串漏抽不会报错，所以长期存在

软件工程里的大多数错误有个共同点：会报错。

变量名拼错，程序跑不起来；少一个括号，构建通不过。

漏抽不会报错。一句写死在代码里的英文，在任何语言下都能正常显示。

页面不崩，测试不红，监控不告警，用户也不会投诉。

它唯一的表现，是一个荷兰用户打开你的站，看到一个英文按钮。

因此这类问题只能主动排查，不能等它暴露。它和前端为了让德语长词不撑破手机屏幕塞进标题的那个看不见的字符属于同一类：正常渲染下完全无害，只在某门语言的某条链路上才出问题。区别在于那个字符还能用工具扫出来，这批词连该扫什么都不知道。

还有一种更隐蔽的情况，字符串已经抽取过了。资源文件里某一条在英语版里有、在荷兰语版里缺，运行时框架不报错，而是静默回退到默认语言，页面照常显示英文。所有主流框架默认都这样处理，设计初衷是宁可显示点内容也不留空白，代价是缺译从此没有任何可见信号。

这条回退机制说明：抽取率高不等于本地化覆盖率高。一个抽取率百分之百的站，如果译文文件缺了三十条，页面上照样有三十处英文，而且比没抽出来的那批更难查。它们在资源文件里有键、有原文，只缺译文，任何按键名清点的检查都会把它们算作已存在。

界面文案漏翻最常出现在哪五类位置？

第一类：按钮、标签与状态词

这一类最常见，外人也最容易一眼看出来。

典型的有加入购物车、立即购买、排序、筛选、清空、返回、下一页。

状态词属于同一类：有货、缺货、售罄、预售、新品、促销中。

它们都很短，一到三个词，开发者很容易直接写进代码。

也因为短，它们在页面上出现得很密，一个商品列表页能出现几十次。

这类词还有一个额外的损失：它们常常也是用户的搜索词。缺货、现货、包邮这类词在很多小语种市场是带搜索量的修饰词，页面上写成英文，这一层长尾流量就全部拿不到。落地页上那几个最像装饰的信任元素其实是搜索量最高的购买词讲的是同一问题的另一面。

第二类：只在出错时出现的提示文案

这一类漏检率最高，原因很简单：日常测试走不到这些路径。

包括表单填写错误提示、搜索无结果提示、支付失败提示。

还有页面不存在时的页面、系统维护时的页面、权限不足时的页面。

它们出现得少，但出现时正是用户最焦虑、最容易放弃的时候。

荷兰用户在结账时看到一句英文报错，第一反应通常是关掉页面，而不是去读懂它。

这一类在结构上也很尴尬：出错时刻最需要本地化，报错文案却通常离业务逻辑最近、离内容团队最远，写它的人关心的是把状态交代清楚，没考虑读起来是否顺。于是这批文案同时欠两笔账：信息量不够，语言也没处理。两笔账里，语言这一笔更容易还，也应该先还。

这一类里最难处理的部分来自第三方：支付网关返回的错误提示、物流查询组件的状态文案、验证码服务的提示语。它们既不在你的模板里，也不在你的资源文件里，是别人的系统直接展示给用户的。多数服务商提供语言参数，但需要调用时显式传入，不传就用服务商自己的默认值，而默认值通常是英语。

检查方法很直接：把结账流程故意走到失败一次，把每个第三方组件的提示都截图。这一步值得单独安排一小时，因为这是整条链路上唯一一处页面要替别人的系统向用户解释问题的地方，而且这几句话恰好出现在用户已经拿出银行卡的时候。

第三类：拼接出来的半句话

这一类更隐蔽，因为看起来已经抽取过了。

页面上显示的是一句完整的话，比如还剩三件、七天内可退。

代码里它却由三段拼成：前半句、数字变量、后半句。

抽取出来的是两个半句，各自成条，进了资源文件。

译员拿到两个残句，不知道它们会被拼在一起，也不知道中间夹着什么。

后果在后文详述，这里只说一点：这一类在字数统计里合规，在交付清单里齐全，验收时也挑不出毛病，每一条都翻译了。出错的是拼接那一步，而拼接没有记录在任何交付物里。

第四类：非字符串但用户要读的元素

这一类严格来说不算字符串，但对用户来说效果相同。

包括烧进图片的文字，尤其是横幅图和尺寸对照图。

包括日期写法、货币符号位置、小数点用点还是逗号。

包括度量单位，以及数字分组符号。

这些内容很可能写死在代码里，因为它们看起来不像文字。

但它们都随语言变化。国际化组织维护的地区数据里，仅日期与数字格式就按语言列了几千条，地区数据总览图表可以直接翻到自己要做的语言那一页。图片烧字另有一笔账，非拉丁字母站上同一张商品图的文件名和替代文本要用两套字母写同一个词那篇算过图上的文字会让一张图的可复用范围缩小多少。

图片烧字有一条实用判据：一张图要在几门语言下复用，就别把任何随语言变化的信息烧进去。价格、促销文案、尺码标签、功能说明都属于这类。确实需要时，把文字层单独留出，用页面元素叠加，换语言时只换文本不换图。这条判据影响的不只是本地化成本，还有图片能否被检索：烧进像素的文字，搜索引擎一个字也读不到。

第五类：通过其他渠道发出的文案

最后一类根本不在页面上，但同样是你发给用户的内容。

订单确认邮件、发货通知、退款通知、验证码短信、推送消息。

这些模板通常放在另一个系统里，可能是营销工具，也可能在订单系统里。

它们和站点的语言资源文件是两套东西，各自都会漏。

这一类的阅读率非常高，订单确认邮件的打开率在多数品类里超过五成。

一个用户可能没读完你认真本地化过的商品页，但一定会逐字读那封发货邮件。这批模板留着英文，就是在整条链路上唯一一处用户必读的位置出了错。这批模板通常由运营维护，不归工程，所以前面讲的抽取率统计也覆盖不到它们。

这一类还有一个附带问题：即使运营认真翻译了邮件模板，用词也未必和站内一致。站上的按钮用一个词，发货邮件用另一个词，退款政策页又用第三个词。用户不会意识到这是三套系统，只会觉得这家店前后说法不一。把邮件模板里的品类词、状态词和站内词表核对一遍，通常一个下午能理顺，好处是整条售后沟通的用词统一。

翻译报价的字数统计为什么漏掉未抽取的界面文案？

字数统计只覆盖已抽取的字符串

本地化项目的报价方式在行业里基本统一：按源语言字数或词数计价。

字数来自你交出去的那批文件。

翻译工具打开资源文件，逐条统计，给出总数。

没抽取的词不在文件里，工具自然统计不到。

结果是报价单上写着四万字，页面上实际露出的那几十个英文词一个都不在其中。

这一点需要单独记下，因为它最能解释这个问题为什么长期没人发现：缺口在报价时就已经不可见，而报价是整个项目中第一次有人认真清点内容。第一次清点就漏了，后续每次核对都以这份有缺漏的清单为基准。

缺口为什么没人追问

再往下看，这个机制还会自我强化。

甲方拿到报价单上的字数，会和预算比，和上一次比。

字数少了会被追问，字数多了会被砍。

没有哪个环节会问：这个数字覆盖了页面上百分之多少的文字。

回答这个问题需要另一份数据，而谁都没有这份数据。

保哥后来在几个项目里试过一个很原始的办法：让人用手机把某个语言版本的关键页面逐个截图，圈出截图里所有英文词，再把这个数量和资源文件里的条数对比。这个方法不需要任何工具，一个下午能做完三十个页面，得到的数字比任何报表都直观。

验收同样查不出，因为对照的是同一份清单

验收本应是最后一道关。

但验收的做法是拿交付文件逐条对照原文件。

核对的是这一百四十条翻得对不对，没有核对这一百四十条够不够。

清单本身是否完整从来没人检查，因为清单就是这项工作的定义。

这和母语者说读着自然不能当成验收通过的判据是一对孪生问题：那一篇讲验收深度不够，这一篇讲验收范围不对。

两者合起来说明一个更普遍的规律：以清单为工作对象的流程，发现不了清单本身的缺项。要发现缺项只能换参照物，在这件事上唯一可靠的参照物是渲染出来的页面，任何文件都不行。

未翻译的界面文案对多语言SEO有什么影响？

这类文字集中在正文最少的页面

如果这批词散落在长文章里，影响会小很多。

实际分布正好相反：页面文字越少，这批词占比越高。

一个筛选结果页，正文可能只有一个标题和一排商品名。

其余可见文字全是筛选项、排序选项、分页控件和状态标签。

这类页面上界面文案的占比可以超过一半，有时达到七成。

这类页面在电商站里数量最多，也最接近交易意图。站上字最少的那几类页面最赚钱，也最容易被机器认成另一门语言那篇算过这类页面的价值，这里补充一点：它们的语言纯度也是全站最低的。

英文残留会干扰页面语言判定

在上一条的基础上再推一步。

搜索引擎判断页面语言，依据的是页面上的实际文本。

页面上的语言声明是一个信号，但不是唯一信号，也不是权重最高的。

当荷兰语页面上有四成可见文字是英文时，判定结果会变得不稳定。

不稳定的表现通常不是判成英语，而是同类页面之间的判定结果来回变化。

这种摇摆比误判更难查，因为抽查十个页面可能七个正常。问题出在另外三个上，而它们和那七个用的是同一个模板。反映到报表上，就是某一批页面的表现无故低于同批其他页面，根因在字符层面，与内容无关。

有个不用工具的验证办法：把筛选结果页的可见文本全选复制，粘贴到纯文本编辑器，删掉明显属于本地语言的词，看还剩多少。剩余比例超过三成，这一页的语言信号就已经不干净了。一个页面模板三分钟就能查完，而同一个模板通常覆盖几千个页面，投入很小。

用户搜本地词，页面显示英文词

第三笔账是关键词覆盖。

相当一部分界面词同时是搜索查询的组成部分。

免运费、货到付款、七天无理由、当日发货，这些词在多数市场都有搜索量。

它们出现在按钮、角标和筛选项里，都属于界面文案。

页面上留着英文，这几组长尾词在这门语言下就一个都承接不到。

这和关键词表里唯一一批全英文的词从翻译到审校没有一个人动过那篇是两个平行问题：那篇讲词表里留了英文，这篇讲页面上留了英文。成因不同，一个是有人主动决定不译，一个是流程根本没覆盖到；后果完全一样。

结构化数据与可见文本不一致会带来什么问题

还有一个容易忽略的位置：结构化标记里的值。

库存状态、配送方式、商品状况等字段，标记里填的是标准化英文值。

这样做是对的，标记里的枚举值本来就应该用规范值，不做本地化。

问题在于页面上的可见文字应该是本地语言，两层需要分开处理。

写死在代码里的那批词让两层变成了一样：标记是英文，页面也是英文。

小语种页面的正文越本地化越好，结构化数据里却要反着写回国际格式讲的就是这两层怎么分开。这里补充一种特殊情况：界面文案没有抽取时，标记层看起来合规，实际上两层都停在默认值上，并没有做过处理。

如何用伪本地化在没有译文时检测漏抽的字符串？

伪本地化是什么，替代了哪一步

这一节介绍本文最有用的一个方法，操作却很简单。

伪本地化是指生成一份假译文，用它把整个站跑一遍。

假译文不是随意编写的，而是按固定规则由英文原文变换得到。

变换后仍能认出原意，但每个字符的外观都改变了。

然后把这份假译文当作一门真实语言接入站点，人工走查一遍。

它替代的是真实项目里无法做到的一步：在译文交付前验证本地化是否可行。微软把这套方法写进了官方的伪本地化方法论文档，安卓也内置了两套伪地区，可以直接开启。这个方法并不冷门，只是长期留在工程侧，做内容和做搜索的人很少知道。

伪本地化字符串的每一部分分别检测什么

一条典型的伪本地化字符串是这样的：把Add to cart变成方括号加三个感叹号，中间是Àdd tô càrt，末尾加几个波浪线。

每一部分都对应一项具体检测，并非装饰。

首尾方括号检测截断：页面上看不到右方括号，说明这句话被截掉了。

字母上的重音符号检测编码：变成问号或方块，说明链路上某一环丢了字符。

末尾波浪线检测膨胀：欧洲语言普遍比英语长，文字加长后布局能否撑住。

最关键的一条是：页面上没有变形的字，就是没被抽取的字。这一条不需要懂任何语言，也不需要工具，看一眼就能发现。这个方法把原本要靠语言能力才能发现的问题，变成了靠肉眼就能发现的问题。

末尾波浪线的数量有依据，业界按源文本长度分档设定膨胀比例：十个字符以内的短词预留三倍以上空间，十到二十个字符预留一倍，长句预留三成左右。词越短，膨胀比例越高，而按钮上的词恰好都在最短的一档。所以常见的情况是按钮出问题，段落不出问题。

按语言看，德语和芬兰语膨胀最大，俄语和法语居中，日语和中文反而会变短。如果假译文只按一个固定比例加长，测试结果对德语偏乐观、对中文偏悲观。稳妥的做法是按计划上线语言中膨胀最大的那门来定比例，这样测出的布局才可靠。

在自己的站上执行伪本地化测试

落地方式分三档，按团队技术条件选择。

第一档最规范：让工程按上述规则生成一份伪语言资源文件，并加一个仅内部可访问的语言开关。

第二档居中：只针对一个语言版本，复制一份资源文件，用脚本批量变换后覆盖到测试环境。

第三档最简单：什么都不改，把线上某个语言版本的页面逐个截图，人工圈出英文。

三档成本相差十倍，能发现的问题却是同一批。

建议从第三档开始：先花两天圈出三十个关键页面的英文残留，再拿这份带截图的清单推动第一档落地。只说站上有英文，没人会重视；会上摆出三十张画了红圈的截图，排期通常当场就能定下来。

测试结果按三类问题分别记录

跑完一遍会得到一批现象，需要分三类分别派给不同的人。

第一类是没变形的字，属于抽取缺口，归工程，处理方式是补抽取。

第二类是变成方块或问号的字，属于编码或字体缺口，归前端，处理方式是补全字体子集。

第三类是被截断或撑破布局的位置，属于布局缺口，归设计，处理方式是调整宽度或折行规则。

三类问题表面上都是页面显示异常，负责人却各不相同。

字体问题另有一笔账，网页字体在英文站只占几十KB，到了小语种站就变成拖慢首屏的最大一块算过这部分开销怎么节省。分开记录是因为三类里只有第一类属于本文讨论的问题，另外两类是顺带发现的，发现了也不要混在一张单子上提交，否则三个团队会互相等待。

字符串抽取后译员缺少上下文，怎么解决？

上下文丢失是字符串抽取的副作用

抽取解决了一个问题，同时带来一个新问题。

文字从代码里移走后，也离开了原来所在的位置。

译员打开资源文件，看到的是一长串孤立的短语。

他不知道某一条会显示在按钮上还是标题上，不知道旁边是什么，也不知道可用宽度。

更严重的是，他不知道这个词在当前场景下的确切含义。

只做英文站时不存在这个副作用，因为写代码的人清楚自己在写什么。抽取把文字和语境拆成两份，只把文字交了出去。所以抽取率高不等于本地化质量高，它只是把缺失问题变成了歧义问题。

同一个英文单词在界面上有几种含义

下面是几个实际遇到过的例子，都很短。

Free在价格旁边是免费，在库存旁边是有空位，在筛选器里可能是无限制。

Back在导航上是返回，在商品属性里是背面，在配送里可能是退回。

Order在按钮上是下单，在列表标题上是订单，在排序控件上是顺序。

这三个词在英文里不用区分，但在荷兰语、波兰语、日语里各自要用完全不同的词。

译员手上只有一个孤立的单词，只能猜，而且多半猜最常见的意思。这也解释了一个常见现象：明明请了母语者，界面上仍有几个词读着别扭。原因通常不在译员水平，而是交给他的信息不足以支撑判断。

资源文件的键名与注释该怎么写

解决方法不复杂，成本也低，只要在写代码时多花十秒。

键名不要起成btn1、text2这类，要能看出位置和用途。

比如商品页加购按钮、结账页支付失败提示，译员看键名就知道场景。

进一步可以在每条旁边加一行注释，说明出现位置、周边元素和最大宽度。

主流资源文件格式都支持注释，翻译工具也基本都会把注释显示给译员。

这件事投入很小、回报很高：一条注释十秒钟，省掉的是一次返工加一次上线。但它很难推动，因为写注释的人和承担返工的人不是同一个人，中间隔着两个部门和三个月。

为什么屏幕截图是成本最低的上下文

还有一种更彻底的做法，行业里叫上下文内翻译。

做法是让译员直接在页面上看到自己翻译的句子实际显示效果。

成熟的工具支持实时预览，改一个词，页面立刻更新。

没有这类工具的团队可以退一步：每个页面截一张图，和资源文件一起发出。

截图几乎没有成本，效果却相当于半页说明文档。

这一步在小语种项目上的收益比大语种更高，因为小语种译员通常得不到产品培训，也很少有机会实际用一遍你的站。每一张截图都在帮他补充对产品的理解。这一条和前面的注释建议不冲突，两者同时做效果最好。

字符串拼接为什么在其他语言里必然出错？

字符串拼接的三种形态

前文提到过这一类，这里展开说明。

第一种是句子被切成两半，中间插入数字或名字。

第二种是单独抽取一个词，和不同前缀组合复用。

第三种是按条件拼接，比如按数量选择不同的后半句。

三种写法在英文里都能拼出通顺的句子，所以开发者不觉得有问题。

原因在于英文的语法特点让拼接代价最小：词序固定、名词几乎不变形、形容词不随之变化。换一门语言，这三个前提一个都不成立。国际化组织专门写过一篇处理组合消息，列出了拼接在各种情况下的出错方式。

词序不同的语言会把变量挪到句子另一端

最直观的出错方式是位置错乱。

英文的还剩三件，切成还剩和件两半，中间插入数字。

日语里的同一句话，数量词的位置和修饰关系与英文完全不同。

德语从句会把动词放到句末，前后两个半句都无法独立成立。

土耳其语和芬兰语更复杂，变量本身要根据在句中的成分改变词尾。

结果是译员拿到两个半句，怎么翻都拼不出一句正常的话，只能选一个最不难看的错误译法。芬兰语的十五个格只是开胃菜，真正难住关键词工具的是词干自己也会变那篇讲过格的数量，放到拼接场景里就是：每插入一个变量，前后两半都可能需要跟着变形。

正确做法：整句加占位符，不要把句子切碎

工程侧已有成熟方案，只是很少被当作本地化问题看待。

把整句作为一条完整资源，变量写成句中的占位符。

译员拿到整句，可以按目标语言的语序自由安排占位符位置。

行业里有一套标准消息格式，占位符、数量分支、性别分支都能写进同一条资源。

主流框架都支持这种格式，前端和移动端各有实现，语法基本一致。

这里要和另一件事区分开：波兰语站的商品标题自动模板为什么必然拼错讲的是按语法规则用商品数据拼标题，属于内容侧模板；这里讲的是界面句子被切碎后发给译员，属于工程侧资源。两者的解决方向相反：那边要减少拼接，改为人工确认的形式；这边要把碎片合并回整句。

已上线三年的多语言站，按什么顺序补抽取界面文案？

先测量：抽取率怎么计算

动手前先拿到一个数字，否则说服不了任何人。

分子是资源文件里的条数，分母是页面上实际出现的可翻译文本条数。

分母很难精确统计，可以抽样：挑十五到二十个有代表性的页面，人工计数。

页面类型要覆盖首页、品类页、商品页、购物车、结账页、订单页、报错页。

两者的比值就是抽取率，多数首次统计的站落在六成到八成之间。

这个数字的主要用处在于可以按页面类型拆分，绝对值倒在其次。拆开后会发现抽取率分布很不均匀：内容型页面通常在九成以上，交易链路上的页面往往只有一半。交易链路决定转化，这个对比是申请预算时最有说服力的依据。

交易链路抽取率系统性偏低，有结构上的原因：结账、支付、物流这几段通常做得最晚、改得最频繁，也最常由外部组件拼装。改动越频繁，开发者越容易直接写死文字，因为每次改动都得去资源文件加一条。于是这几段页面既改动多、又文字少，两个特征叠加，情况最糟。

第一批应该补哪些位置

排序原则只有一条：用户遇到它的概率乘以那一刻的重要程度。

第一批固定是三项：加购与结账链路上的所有按钮、结账环节的报错文案、订单与发货邮件。

第二批是列表页的筛选与排序控件，以及库存与配送状态词。

第三批是导航、面包屑、页脚和搜索框提示文字。

其余可以慢慢补，包括后台、帮助中心的界面框架、极少触发的系统页。

这个顺序和按数量排序正好相反，数量最多的通常是最边缘的那批。按数量排序的团队会先处理一大批没人看的文字，报表进度好看，转化却没有任何变化。

推动这件事还有一个比缺口本身更有力的论据：这笔投入是一次性的，并由后续所有语言分摊。补抽取与具体语言无关，做完一次，第二门、第三门语言上线时只需翻译，不用再补。所以立项时不要只按当前这门语言的收益算，要按未来三年计划上线的语言数量分摊，这样算下来单门语言的成本会低很多。

补完之后如何防止再次漏抽

一次性补完解决不了长期问题，因为下个月又会有新代码。

最有效的做法是把检查加进代码合并关卡，扫描新增代码里直接写入的可见文本。

各技术栈都有现成的检查工具，配置大约需要半天。

第二条是每季度重跑一次伪本地化，作为固定流程，不当作专项。

第三条是把抽取率写进本地化项目的验收标准，与翻译质量并列。

第三条最关键，也最难推动，因为这等于承认现有验收标准漏掉了一整个维度。但只要写进去，报价阶段的不可见问题就解决了：报价单上会多出一行，这一行正是本文一直在追的东西。

扫描规则也需要设计，扫得太宽会产生大量误报，最后没人看。实用的规则是只扫标签之间的可见文本，且只对包含两个以上字母、不含变量符号的片段告警，类名、属性值、注释全部跳过。这样配置的规则误报率很低，团队才愿意一直开着。

另外要提供正式的豁免写法，比如加一条特定注释就跳过该行。没有豁免机制的检查最后通常会被整体关闭，因为总有几处确实不需要翻译，比如商品编码前缀、货币代码、技术标识符。保留豁免机制，规则才能长期运行。

同时还要建一份禁止翻译的白名单，与抽取工作配套。品牌名、型号、货币代码、技术标识符、法定名称这几类应明确标出，既不进翻译文件，也不被自动翻译层处理。这份白名单和审校环节的禁改清单是同一份，区别是这里多了一个技术实现：在页面上给这些元素加不翻译标记，浏览器和翻译层都会跳过它们。

一份两天能跑完的自检清单

不想立项的团队，可以只做下面这份清单，两天能完成。

第一天上午：挑二十个页面截图，按页面类型分组。

第一天下午：圈出所有英文残留，按前面的五类归类，统计条数。

第二天上午：用资源文件条数除以估算的总条数，算出抽取率，按页面类型拆分。

第二天下午：挑出结算链路上的那几条，做成带截图的清单交给工程。

这份清单有说服力，是因为足够具体。只说站上有些地方没翻译，会被排到下个季度；写明结账页第二步的三个按钮和两条报错文案是英文、附上截图，通常当周就会修。

界面文案本地化中，前端工程与内容SEO如何分工？

交给前端与工程的部分

有几件事和本文属于同一条链路，但不该由做内容和做搜索的人负责。

资源文件怎么组织、按语言分包还是合并成一个文件、何时加载，属于前端架构问题。

构建流程中如何校验资源文件完整性，属于工程流程问题。

文字方向镜像、日期时间地区数据接入，都有成熟方案，按标准实施即可。

内容侧只需要做一件事：指出缺口，并说明它造成多少损失。

这个分工在实践中很重要，因为内容侧一旦开始讨论技术方案，话题就会转向技术选型，而选型可以争论三个月。把讨论限定在缺口和损失上，反而更容易推进。

交给搜索与内容团队的部分

反过来，也有几件事不该指望工程解决。

哪些词用本地说法、哪些词用户真正在搜、同一概念有几种写法，这是词表的工作。

补进来的界面词用哪种形式、是否和正文用词统一，这是内容的工作。

抽取后译得对不对、语气是否合适，这是审校的工作。

搜索引擎如何处理这类页面、各平台规则有何不同，本篇不再重复。

把边界划清还有一个好处：原本模糊的本地化没做好，会变成两张各有负责人的清单。多数跨部门问题卡住，原因通常不是没人愿意做，而是没人知道自己该做哪一部分。

排期上还有一条规律：第一门非英语语言总是成本最高的，因为全站的抽取缺口会在它上面一次性暴露。从第二门开始，成本大幅下降，只剩纯翻译。所以选第一门语言时，除了看市场规模，还要看团队能否承受一次基础设施改造。顺序选错，常见的代价不是这门语言做失败，而是团队从此认定多语言太贵。

常见问题解答

我们的站是用现成的电商系统搭的，也会有这个问题吗？

会，而且形态更隐蔽。现成系统自带的界面文案通常有官方语言包，覆盖率不错，问题出在两个地方：一是你自己或者外包做的主题模板，那里面的文字是你自己写的，官方语言包管不着；二是你装的插件，尤其是小众插件，很多只有英文。判断办法很简单：把官方语言包的语言切过去，页面上剩下的英文就是这两类贡献的。这批词往往正好落在你最重视的那几个位置上，因为主题模板改得最多的就是首页和商品页。

抽取率应该做到多少才算合格？

没有一个通用的数字，但可以按页面类型定分档目标。交易链路上的页面应该逼近百分之百，包括购物车、结账、订单、报错这几类，这里差一条都可能直接掉单。列表页与商品页可以定在九成五以上。后台、帮助中心的界面壳、极少触发的系统页可以放到八成。用一个全站平均数当目标是最没用的做法，因为平均数会被条数最多的那批边缘页面主导，而它们恰好最不重要。

能不能直接用浏览器的翻译功能兜住这批词？

不能，原因有三层。第一层，你控制不了译出来的用词，品牌名和型号经常被一起翻掉。第二层，那个版本只对开了翻译的那部分用户存在，搜索引擎抓到的仍然是你自己那份带英文的页面。第三层也是最要命的一层：机器读到的是你的原始页面，语言判定、关键词匹配全部基于那一份，翻译层完全不参与。这件事另有一整篇账要算，本篇只强调一点：它救不了检索这一侧。

我们没有工程资源，能不能只改内容侧？

能做的比想象中多。第一，图片上烧的字是内容侧完全能控制的，把横幅图和尺寸图上的文字改成本地语言，这一步不需要任何工程介入。第二，邮件和短信模板多数住在运营工具里，运营自己就能改。第三，站内搜索的提示语和空结果文案在不少系统里是可配置项。把这三样做完，通常能覆盖掉三成到四成的可见缺口，而且见效很快，也正好用来给后面那一半争取排期。

伪本地化跑出来的结果，非技术人员看得懂吗？

看得懂，这正是它最大的好处。它把一个需要语言能力才能发现的问题，转化成了一个视觉问题：页面上没变成怪样子的字就是没抽出来的字，变成方块的就是字体缺字符的，右边少了一个方括号的就是被截断的。三类现象用眼睛就能分清，不需要懂任何一门外语，也不需要读代码。保哥带团队做这件事时，通常让运营而不是工程来跑第一轮，因为运营更清楚哪几个页面重要。

这批词补上之后，多久能看到数据变化？

分两段看。转化侧的变化最快，结账链路上的英文一旦换掉，弃单率的变化通常在两周内就能看出来，因为它修的是一个硬阻塞。检索侧要慢得多，页面文本变了之后要等重新抓取和重新评估，加上你补进去的那批词本身量级不大，一个季度能看到趋势就算不错。所以立项时别把两段混在一起承诺，用转化侧的数字换排期，用检索侧的数字做长期跟踪。

多语言站的这个问题，跟单语言站的界面文案质量是一回事吗？

不是。单语言站的界面文案问题是写得好不好，是一个质量维度，改了会更好，不改也还能用。多语言站的这个问题是有没有，是一个存在与否的维度，不改就等于这一部分内容在这门语言下完全缺席。两者的严重程度差一个数量级，处理它们的优先级也应该完全不同。把这两件事混在同一张需求清单里，通常的结果是前者因为看起来更容易被先做掉。

权威参考资料