翻译报价单上写着四万字，页面上真正被人读的那几十个词一个都不在里面

摘要：页面上的字分两类：进过翻译文件的，和写死在代码里的。前一类按字数计价、有交付物、有验收；后一类从没被交出去过，所以它在荷兰语页面上永远还是英文。这批字只有几十到几百个，位置却极好——按钮、筛选器、面包屑、空结果提示、发货邮件，正是页面上文本最少也最被人读的地方。更麻烦的是缺口在报价那一刻就不可见：字数统计只数得到已抽出来的那部分。本文讲清抽取这道工序在做什么、哪五类位置最容易漏、怎么用伪本地化在一句译文都没有时先测一遍，以及上线三年的老站按什么顺序补。

同一个页面上，为什么有的字翻了、有的字没翻？

一家母婴站的荷兰语页面，八个词出卖了整个站

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

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

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

保哥拿手机打开那个站，第一屏还没滑完就停住了。

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

整整八个词，全站每一页都有，全是英文。团队里没有一个人觉得这是问题，因为这些词在他们的内容管理后台里根本不存在——后台的文章列表里躺着三百多篇荷兰语稿子，一个字都不缺。这八个词住在另一个地方，一个内容团队从来不会打开的地方。

差别不在译员，在这些字根本没被交出去

追下去只用了二十分钟。

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

而前端模板里真正写着的英文短语，数一数是一百九十多条。

中间那五十多条从来没出现在任何一份交付清单上，因为它们从来没被抽出来过。

它们直接写在模板文件里，跟结构标签混在一行，形态大概是一个标签中间夹着一个单词。

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

页面上的字其实分两类，只有一类进过流程

这件事的根子在于一个多数人没意识到的分界。

页面上呈现给用户的每一个字，来源只有两种。

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

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

用户看不出这两类字有什么区别，它们在同一个页面上、同一种字体、同一个颜色。

可这两类字走的是两条完全不相交的管道，两条管道有各自的负责人、各自的工具、各自的排期。内容那条管道成熟得不像话，从选题到发布每一步都有人盯；界面文案那条管道在多数团队里压根没有本地化这个环节，它的默认终点就是英语。这条分界线才是本文真正要讲的东西，后面所有的现象都是它的推论。

这件事跟翻译质量无关，它发生在翻译之前

为什么这个问题在讨论多语言内容的场合几乎从来没被提起。

因为绝大多数关于多语言的讨论，前提是已经有一份要翻的东西了。

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

而这批词的问题发生在更早一步：它压根没进入被讨论的那个集合。

你可以把翻译质量做到满分，这批词还是英文。

顺着这条线还能推出一条更不舒服的结论：本地化的完成度并不是由译者的水平决定的，而是由三年前那个写模板的前端决定的——他当时随手把一个词写在了标签里还是写成了一个变量，就已经决定了这个词今天能不能出现在荷兰语页面上。这个决定当时不需要任何评审，也没有任何人会知道。

一句话从代码里被抽出来，中间要过几道关？

抽取这道工序到底在做什么

先把这道工序说清楚，因为多数内容岗的人没见过它。

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

抽取的意思是：把这句话从代码里拿走，换成一个引用。

代码里留下的是一个键名，真正的文字挪到一个专门的资源文件里。

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

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

抽出来之后它变成了什么形态

抽出来的文字会落在一个文件里，格式取决于技术栈。

用得最久的一种是每条一个原文一个译文，原文那行叫msgid，译文那行叫msgstr。

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

移动端有各自的形态，一边是扩展名strings的文件，一边是strings.xml。

行业里做交换用的是另一套标准格式，翻译公司的工具基本都认。

不管哪种形态，共同点是这批文字终于变成了一份可以被清点、被计价、被发出去的资产。这一步之前它是代码的一部分，之后它才是内容。整个问题的分水岭就在这里：抽出来的东西会被当成内容对待，没抽出来的会被当成代码对待，而代码是不需要翻译的。

谁决定哪句话要被抽出来

决定权在写这行代码的那个人手上，而且是当场决定的。

他写一个按钮的时候，可以顺手把文字写进去，也可以调一次翻译函数。

前者快，一秒钟的事；后者慢，要起键名、要去资源文件里加一条。

在一个只做英文站的阶段，两种写法看起来完全一样，页面上长得一模一样。

于是绝大多数团队在早期都选了快的那种，而且选得毫无心理负担。

等到两年后要出海了，这个决定的代价才开始结算，而且结算方式很别扭：它不是一笔大账，而是散落在几百个文件里的几百个小坑。谷歌的gettext手册专门有一节叫准备字符串，讲的就是写代码那一刻该怎么写才不留坑，可惜看这份手册的人和写商品页模板的人通常不是同一批。

抽漏了不会报错，这是问题的根源

软件工程里绝大多数错误都有一个共同的好处：它会报错。

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

唯独这一类不会。一句写死在代码里的英文，在任何语言下都能正常显示。

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

它唯一的表现形式，是一个荷兰人打开你的站，看见一个英文按钮。

这条性质决定了它必须靠主动去查，而不能等它自己冒出来。跟前端为了让德语长词不撑破手机屏幕塞进标题的那个看不见的字符属于同一族：都是在正常渲染下完全无害、只在某一门语言的某一条链路上才致命的东西。区别是那个字符至少还能用工具扫出来，这批词连扫都不知道该扫什么。

还有一种更隐蔽的情形，它连抽取这一关都过了。资源文件里某一条在英语那份有、在荷兰语那份缺，运行时框架不会报错，而是静默回退到默认语言。页面上照样显示，显示的是英文。这条回退机制是所有主流框架的默认行为，它的设计初衷是宁可显示点什么也别显示空白，代价是缺译这件事从此没有任何可见信号。

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

哪些位置最容易漏，能不能列成一张固定清单？

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

这一类最常见，也最容易被外人一眼看穿。

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

状态词是同一族：有货、缺货、售罄、预售、新品、促销中。

它们的共同特征是短，一到三个词，写在代码里几乎没有心理负担。

也正因为短，它们在页面上的密度极高，一个商品列表页能出现几十次。

这一类词有个附加的坏处：它们往往同时是用户会搜的词。缺货、现货、包邮这类词在很多小语种市场里是带搜索量的修饰词，页面上写成英文等于把这一层长尾整个让出去。落地页上那几个最像装饰的信任元素其实是搜索量最高的购买词讲过同一个道理的另一半。

第二类：只在出错时才出现的句子

这一类的漏检率最高，原因很朴素：日常测试根本走不到。

包括表单填错的提示、搜索没有结果的提示、支付失败的提示。

还有找不到页面时的那一页、系统维护时的那一页、权限不足时的那一页。

它们的出现频率低，可出现的那一刻恰好是用户最焦虑、最容易放弃的一刻。

一个荷兰用户在结账时看到一句英文报错，他的第一反应不是读懂它，是关掉。

这一类还有一个结构性的尴尬：出错这件事本身是最不能本地化的时刻，因为报错文案通常离业务逻辑最近、离内容团队最远，写它的人考虑的是把状态说清楚而不是把话说得让人能读。于是同一批文案在两个维度上同时欠着账：信息量不够，语言这一关也没过。两笔账里，语言这一笔更容易还，也更该先还。

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

检查办法很直接：把结账流程走到失败一次，把每一个第三方组件的提示都截下来。这一步值得单独排一个小时，因为它是整条链路上唯一一处出问题时页面还得替别人的系统说话的地方，而这几句话恰好出现在用户已经掏出银行卡的那一刻。

第三类：拼在一起的半句话

这一类隐蔽得多，因为它看上去已经被抽出来了。

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

可代码里它是三段拼的：一个前半句，一个数字变量，一个后半句。

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

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

后果在下一节细讲，这里只强调一点：这一类在字数统计里是合规的，在交付清单里是齐全的，在验收时也挑不出毛病——每一条都翻了。坏掉的是拼起来那一刻，而拼起来这件事没有任何一份交付物记录过。

第四类：不是文字但要读的东西

这一类严格说不算字符串，可用户读到的效果一样。

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

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

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

这些东西写死在代码里的概率极高，因为它们看起来根本不像文字。

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

图片上烧字这件事有一条很实用的判据：这张图要在几门语言下复用，就别把任何一个会随语言变的信息烧上去。价格、促销文案、尺码标签、功能说明全归这一类。真要放，把文字层单独留出来用页面元素叠上去，这样换语言只换文本不换图。这一条决定的不只是本地化成本，还有这张图能不能被搜到——烧在像素里的字，检索这一侧读不到一个。

第五类：走另一条管道出去的字

最后一类干脆不在页面上，可它同样是你发给用户的内容。

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

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

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

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

换句话说，一个用户可能全程没读完你精心本地化的商品页，却一定会逐字读完那封发货邮件。把这批模板漏在英文里，等于在整条链路上唯一一次用户必读的位置露了怯。这批模板还有一个特点：它们通常由运营而不是工程维护，所以连前面那份抽取率的账都算不到它们头上。

这一类还有一个附带的伤：即使运营认真把邮件模板译了，用的词也未必跟站上一致。站上的按钮叫一个词，发货邮件里叫另一个词，退款政策页上叫第三个词。用户不会觉得这是三套系统，只会觉得这家店说话前后不一致。把邮件模板里的品类词、状态词跟站内词表对一遍，通常一个下午就能捋顺，收益是整条售后沟通的用词统一。

报价单上的字数，为什么天生看不见这批词？

字数统计只数得到已经被抽出来的字

本地化项目的报价方式几乎是行业统一的：按源语言字数或者词数计价。

字数从哪儿来？从你交出去的那批文件里统计出来。

翻译工具打开一份资源文件，逐条数，给出一个总数。

没被抽出来的那批词不在文件里，工具当然数不到。

于是报价单上写着四万字，而页面上真正露出来的那几十个词一个都不在里面。

这条性质值得单独记一下，因为它比其它任何一条都更能解释这个问题为什么能存活这么久：缺口在报价那一刻就已经是不可见的，而报价是整个项目里第一次有人认真清点内容的时刻。第一次清点就漏了，后面每一次核对都是拿这份漏了的清单当基准。

报价那一刻缺口就已经不可见

再往下一层，这个机制还有个自我强化的部分。

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

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

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

因为这个问题的答案需要另一份数据，而那份数据谁都没有。

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

验收也查不出来，因为验收对着的是同一份清单

验收环节按理说是最后一道闸。

可验收的做法是：拿交付文件对着原文件，逐条核。

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

清单本身的完整性从来没有人验，因为清单就是这件事的定义。

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

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

那几十个词在检索这一侧值多少钱？

它们恰好落在页面文本最少的地方

如果这批词散落在长篇文章里，问题会小很多。

可它们的分布正好相反：越是文字少的页面，它们的占比越高。

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

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

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

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

它们会把这一页的语言证据拉偏

接着上面那条往下推一步。

机器判断一个页面是哪门语言，靠的是页面上的实际文本。

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

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

不稳定的后果不是判成英语，而是判定结果在同类页面之间来回摇摆。

摇摆比判错更难查，因为你抽查十个页面可能有七个是对的。真正的信号藏在那三个上，而它们跟另外七个在模板上是同一份。这类问题在报表上的表现是某一批页面的表现莫名其妙低于同批的其它页面，而根因在字符层面，不在内容层面。

有个不用任何工具就能验的办法：把一个筛选结果页的可见文本全选复制，粘进纯文本编辑器，把明显是本地语言的词删掉，看剩下多少。剩下的比例超过三成，这一页的语言证据就已经不干净了。这个动作三分钟能做完一个页面模板，而同一个模板通常覆盖几千个页面，性价比高得离谱。

用户搜的是本地词，页面上写的是英文词

第三笔账落在关键词覆盖上。

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

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

它们写在按钮上、写在角标上、写在筛选项里，全是界面文案的地盘。

页面上留着英文，等于这几组长尾在这门语言下一个字都接不住。

这里跟关键词表里唯一一批全英文的词从翻译到审校没有一个人动过那篇是两条平行线：那篇讲的是词表里留了英文，这篇讲的是页面上留了英文。两者的成因不一样，一个是人主动决定不译，一个是流程压根没碰到；后果却完全一致。

结构化数据与可见文本不一致时会怎样

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

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

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

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

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

小语种页面的正文越本地化越好，结构化数据里却要反着写回国际格式讲的就是这两层该怎么分。这里要补的是一种特殊情形：当界面文案没被抽出来时，你并不是做对了标记那一层，而是两层都停在了默认值上——看起来符合规范，实际上是没做。

不懂那门语言，怎么在一句译文都没有的时候先测一遍？

伪本地化是什么，它替代了什么

这一节是本文最值钱的一个动作，做法却简单得有点滑稽。

伪本地化的意思是：造一份假的译文，用它去跑一遍整个站。

假译文不是随便乱写，它按固定规则从英文原文变换出来。

变换后的文字仍然认得出原意，但每个字符都被改过样子。

然后把这份假译文当成一门真语言接进站里，人肉走一遍。

它替代的是一件在真实项目里永远做不到的事：在译文交付之前就验证本地化是不是可行。微软把这套方法写进了官方的伪本地化方法论文档里，安卓也内置了两套伪地区可以直接开。这不是什么冷门技巧，只是它长期停留在工程侧，没人告诉做内容和做搜索的人这里有一把钥匙。

那串怪字符每一部分在测什么

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

每一部分都在测一件具体的事，不是为了好看。

首尾的方括号测截断：如果页面上看不见右边那个方括号，说明这句话被切掉了。

字母上的重音测编码：如果变成问号或者方块，说明这条链路上有一环丢字符。

末尾那几个波浪线测膨胀：欧洲语言普遍比英语长，加长之后布局撑不撑得住。

而最关键的那一条是：凡是页面上没有变成怪样子的字，就是没被抽出来的字。这一条不需要懂任何语言，也不需要任何工具，一眼就能看见。整套办法的精髓就在这里——它把一个原本要靠语言能力才能发现的问题，变成了一个靠眼睛就能发现的问题。

末尾要拖多少个波浪线不是随手定的，业界有一套按源文本长度分档的膨胀比例：十个字符以内的短词要预留三倍以上的空间，十到二十个字符预留一倍，长句子预留三成左右。越短的词膨胀比例越高，而按钮上的词恰好全是最短的那一档。这解释了一个常见现象：出问题的永远是按钮，不是段落。

按语言看，德语和芬兰语的膨胀最凶，俄语和法语中等，日语和中文反而会缩短。所以伪本地化那份假译文如果只按一个固定比例加长，测出来的结果对德语偏乐观、对中文偏悲观。稳妥的做法是按你实际要上的语言里膨胀最厉害的那一门定比例，测出来的布局才是安全的。

怎么在自己的站上跑一遍

落地路径分三档，按团队的技术条件挑。

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

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

第三档最土：不改任何东西，把线上某个语言版本的页面挨个截图，人工圈英文。

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

保哥的建议是从第三档开始，先用两天时间圈出三十个关键页面的英文残留，拿这份带截图的清单去推第一档。空口说站上有英文没人当回事，三十张圈了红圈的截图摆在会上，排期通常当场就有了。

判读结果：三类问题要分开记

跑完一遍会拿到一堆现象，要分成三类分别派活。

第一类是没变样的字，这是抽取缺口，归工程，动作是补抽取。

第二类是变成方块或问号的字，这是编码或字体缺口，归前端，动作是补字体子集。

第三类是被切掉或者撑破的地方，这是布局缺口，归设计，动作是改宽度或者改折行规则。

三类问题的表面症状看着都是页面变丑了，可它们各自要找不同的人。

字体那一类还有一笔单独的账，网页字体在英文站只占几十KB，到了小语种站就变成拖慢首屏的最大一块算过这笔钱该怎么省。分开记的价值在于：三类里只有第一类是本文说的这个问题，另外两类是顺手捡到的，捡到也别混在一张单子上报，否则三个团队会互相等。

抽出来之后，译者拿到的是一个词还是一句话？

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

抽取解决了一个问题，同时制造了一个新问题。

文字从代码里被拿走之后，也就离开了它原来所在的那个位置。

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

他不知道这一条会显示在按钮上还是标题上，不知道旁边有什么，不知道它有多宽。

更要命的是他不知道这个词在这个场景里到底是什么意思。

这个副作用在英文站时代完全不存在，因为写代码的人当场就知道自己在写什么。抽取把文字和它的语境分成了两份，只有前者被交了出去。所以抽取率高不等于本地化质量高，它只是把问题从缺失变成了歧义。

一个单词能有几种意思

举几个真实踩过的例子，都很短。

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

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

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

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

而译员手上只有一个孤零零的单词，他只能猜，而且多半会猜最常见的那个意思。这就解释了一个常见的怪现象：明明找了母语者，界面上还是有几个词读起来怪怪的。不是他水平不行，是你给他的信息不够他做判断。

键名与注释该写成什么样

解法不复杂，成本也低，只是需要在写代码那一刻多花十秒。

键名别起成btn1、text2这种，起成能读出位置和用途的形式。

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

更进一步是在每条旁边写一行注释，说明它出现在哪儿、旁边是什么、最大能多宽。

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

这件事的投入产出比高得不像话：一条注释十秒钟，省掉的是一次返工加一次上线。可它极难推动，因为写注释的人和承受返工的人不是同一个人，中间隔着两个部门和三个月。

屏幕截图为什么是最便宜的上下文

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

做法是让译员直接在页面上看到自己翻的这句话长什么样。

成熟的工具能做到实时预览，改一个词页面上立刻变。

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

截图的成本几乎为零，效果却抵得上半页说明文档。

这一步在小语种项目上的收益比在大语种上更高，因为小语种译员通常拿不到产品培训，也很少有机会真的用一遍你的站。你给他的每一张截图，都是在替他补一次产品理解。这一条跟前面那条注释的建议不冲突，同时做效果最好。

拼在一起的那半句话，为什么在别的语言里必然坏掉？

拼接的三种形态

前面提过这一类，这里展开。

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

第二种是把一个词单独抽出来，跟不同的前缀组合复用。

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

三种在英文里都能拼出通顺的句子，所以写代码的人不觉得有问题。

问题在于英文的语法特点恰好让拼接的代价最小：词序固定、名词几乎不变形、形容词不跟着变。换一门语言，这三条前提一条都不成立。国际化组织专门写过一篇处理组合消息，把这件事的各种坏法列了一遍。

词序不同的语言会把变量甩到另一头

最直观的坏法是位置。

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

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

德语的从句会把动词甩到句子最末尾，前半句和后半句根本不能独立成立。

土耳其语和芬兰语更狠，变量本身要跟着句子里的角色改词尾。

结果是译员拿到两个半句，无论怎么翻都拼不出一句正常的话，他能做的只有选一个最不难看的错法。芬兰语的十五个格只是开胃菜，真正难住关键词工具的是词干自己也会变那篇讲过格的规模，套到拼接上就是：每一个插进去的变量，都可能要求前后两半跟着改形态。

正解是整句带占位符，而不是把句子切碎

解法在工程侧是成熟的，只是没被当成本地化问题看待。

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

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

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

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

这里要跟另一件事划清界限：波兰语站的商品标题自动模板为什么必然拼错讲的是商品数据按语法规则拼标题，那是内容侧的模板；这里讲的是界面句子被切碎发给译员，是工程侧的资源。两者的正解方向也相反：那边要减少拼接、改成人工确认的形态，这边要把碎片合回整句。

已经上线三年的站，按什么顺序补？

先量：抽取率这个数怎么算

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

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

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

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

算出来的比值就是抽取率，多数第一次做这件事的站落在六成到八成之间。

这个数最有用的地方不是绝对值，而是它能按页面类型拆开看。拆开之后你会发现抽取率的分布极不均匀：内容型页面通常九成以上，交易链路上的页面往往只有一半。而后者才是决定转化的那一段，这个对比是拿预算最有力的一张牌。

交易链路上的抽取率之所以系统性偏低，有个结构性的原因：结账、支付、物流这几段通常是最晚做的、改动最频繁的、也最常由外部组件拼起来的。改动越频繁，写死一个词的诱惑越大，因为每改一次都要去资源文件里加一条。于是这几段页面同时具备了改动多和字少两个特征，而这两个特征相乘正好是最坏的组合。

第一批该补哪些位置

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

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

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

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

剩下的可以慢慢来，包括后台、帮助中心的界面壳、极少触发的系统页。

这个顺序跟按数量排正好相反：数量最多的通常是最边缘的那批。按数量排的团队会先啃掉一大片没人看的字，报表上进度很好看，转化上一点动静都没有。

推动这件事还有一个论据比缺口本身更有力：这笔投入是一次性的，而且被后面所有语言分摊。补抽取这件事跟具体哪门语言无关，做完一次，第二门、第三门语言上线时只需要翻译，不需要再补一遍。所以立项时不该按当前这一门语言的收益算账，要按未来三年计划上的语言数量算，一除下来单门语言的成本立刻变得很好看。

补进去之后怎么防止再漏

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

最有效的一条是把检查放进代码合并的关卡里，扫描新增代码中直接写着的可见文本。

这类检查工具在各个技术栈里都有现成的，配置成本大概半天。

第二条是每个季度重跑一次伪本地化，把它做成固定动作而不是专项。

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

第三条最关键也最难推，因为它等于承认现有验收标准漏了一整个维度。可只要它写进去了，报价那一刻的不可见就被打破了——报价单上从此会多一行，那一行才是本文从头到尾在追的东西。

扫描规则本身也有讲究，扫得太宽会误报到没人愿意看。实用的一条是只扫标签之间的可见文本，且只对包含两个以上字母、不含变量符号的片段报警，类名、属性值、注释一律跳过。这样配出来的规则误报率能压到很低，团队才愿意让它一直开着。

另外要给出一个正式的豁免写法，比如加一条特定注释就跳过这一行。没有豁免通道的检查最后一定会被整个关掉，因为总有那么几处确实不需要翻译，比如商品编码前缀、货币代码、技术标识符。留一条明路，规则才活得下去。

还要同时建一份不许翻的白名单，跟抽取这件事配套。品牌名、型号、货币代码、技术标识符、法定名称这几类应该明确标出来，既不进翻译文件，也不被自动翻译层碰。这份白名单跟审校环节用的不许动清单是同一份，只是这里多了一个技术落点：在页面上给这些元素加上不翻译的标记，浏览器和翻译层都会绕过它们。

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

不想搞项目的团队可以只做下面这一份，两天能完。

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

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

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

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

这份清单的说服力来自它的具体：不是站上有些地方没翻译，而是结账页第二步的三个按钮和两条报错文案是英文，这里有截图。前者会被排到下个季度，后者通常这周就修。

哪些事不归语言层，要交给谁

交给前端与工程的那一半

有几件事跟本文讲的是同一条链路，但不该由做内容和做搜索的人扛。

资源文件怎么组织、按语言分包还是打进一个文件、加载时机怎么定，这些是前端架构问题。

构建流程里怎么校验资源文件的完整性，这是工程流程问题。

文字方向的镜像、日期时间的地区数据接入，这些有成熟方案，照着标准做就行。

内容这一侧要做的只有一件：把缺口指出来，并且说清楚它值多少钱。

这个分工在实践中特别重要，因为一旦内容侧的人开始讨论技术方案，讨论就会滑向技术选型，而选型是一个可以吵三个月的话题。把话题钉在缺口与损失上，反而推得动。

交给检索与内容那一侧的那一半

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

哪些词该用本地说法、哪些词用户真的在搜、同一个概念有几种写法，这是词表的活儿。

补进去的那批界面词该用哪一个形态、要不要跟正文里的用词统一，这是内容的活儿。

抽出来之后译得对不对、语气合不合，这是审校的活儿。

引擎那一侧怎么处理这类页面、平台的规则有什么不同，本篇不重复讲。

把这条边界画清楚有个附带好处：它让这件事从一个模糊的本地化没做好，变成两张各自有主人的清单。多数跨部门问题卡住的原因不是没人愿意做，是没人知道自己该做哪一部分。

还有一条排期上的规律值得记住：第一门非英语语言永远是最贵的那一门，因为整个站的抽取缺口会在它上面一次性暴露。第二门开始成本断崖式下降，只剩纯翻译。所以选第一门语言时，除了看市场大小，还该看这个团队有没有耐心承受一次基础设施改造，选错顺序的代价往往不是这门语言做砸了，是团队从此认定多语言太贵。

常见问题解答

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

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

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

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

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

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

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

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

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

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

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

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

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

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

权威参考资料