用户点同意之前你的翻译脚本一行都不许跑，首屏那段字只能是原文

摘要：合规弹窗是多语言站上唯一一段这样的文字：它盖在首屏最上面，是访客第一眼读到的内容，却不从你的内容库出来，也没进过翻译交付清单。它由同意管理工具输出，语言按浏览器偏好或地理位置挑，跟页面按地址语言段挑是两个坐标系，于是波兰语页面配英语横幅没有一处会报错。更要命的是它还是一道闸门：用户点同意之前，靠第三方脚本注入的翻译根本不许运行，而抓取程序永远不会去点那个按钮。本文拆开这段字归谁管、按什么挑语言、法律那侧硬在哪、怎么排一张能验完的矩阵。

波兰语页面配着英语同意横幅，这件事为什么一直没人报错？

一家美妆个护站的波兰市场，转化在第一屏就掉了一截

有个客户做美妆个护，精华、面膜、洁面仪、护发油这几条线。

德国、法国、波兰三个市场，页面全做了本地语言，商品数也差不多。

德法两个市场的数据一直平稳，波兰这一边有个怪现象：进站的人不少，读完第一屏就走的比例高得离谱。

团队查过加载速度、查过图片、查过价格显示，都正常。

保哥让他们换一台没登录过的电脑，把浏览器语言改成波兰语，再从搜索结果点进去。

屏幕下半截压着一条横幅，上面写着We use cookies to improve your experience，两个按钮一个Accept All一个Manage Preferences。整页波兰语，唯独这条盖在最前面的东西是英语，而且它必须先被处理掉，用户才能继续往下读。

波兰这个市场的用户对英语的接受度并不低，问题不在于看不懂那两个单词，而在于一进门就有一段外语要求你做一个跟隐私有关的决定，这件事本身在传递一个信号：这个站不是给你做的。

把横幅换成波兰语之后，第一屏的流失确实回落了，但没有立刻追上德法两个市场。

这一点值得记住：第一屏赶走的人不会回来参与你的第二次测量，所以这类修复的收益永远只能看往后的数据，看不到追回来的那一批。

页面翻得很干净，遮住页面的那一层没翻

这个客户的本地化做得不算差。

商品标题、属性、面包屑、退换货说明，全是波兰语，还请了母语审校过一轮。

问题出在层次上：他们翻的是页面，而横幅不在页面上，它盖在页面上面。

从技术角度说，这段文字是另一段脚本在页面加载之后插进去的。

从流程角度说，它是另一个后台里的一条配置，跟内容库没有任何关系。

所以无论翻译交付清单列得多细，只要那份清单是照着页面模板列的，这段字就永远不会出现在上面。它不是被遗漏了，是它压根不在被清点的那个集合里。

竖屏手机上这件事更严重，一条两行高的横幅加上两个按钮，能吃掉首屏三分之一到一半的面积。

换句话说，移动端用户在读到你翻译过的第一句话之前，先读完了一整段没翻译的文字。

三个环节都检查过，三个环节都不认为这段字归自己

做本地化验收的人打开页面，看到的是自己翻过的那些内容，横幅在他眼里是个技术组件。

装同意工具的人负责的是合规能不能过、脚本会不会拖慢页面，文案长什么样不在他的验收项里。

法务那一侧要的是有没有装、分类对不对、能不能留痕，语言这一栏在他的清单上通常写的是有。

三拨人都尽职了，中间那段字仍然没人认领。

这种归属真空在多语言项目里特别常见，因为它同时跨了内容、技术、法务三个职能，而三边的验收清单都是按各自的专业维度写的，没有一份是按屏幕上的位置写的。

还有一个经常缺席的第四方：外部投放代理。很多站的追踪脚本是代理装的，他们只在自己的后台里看数据，从来不打开这个站的前台。

它不报错，是因为没有任何一处程序认为这是错误

页面语言声明写着波兰语，这一项检查通过。

同意工具后台显示已启用、已分类、已留痕，这几项也通过。

结构化数据校验、移动端友好度、抓取诊断，全都不看这段文字用了什么语言。

唯一能发现它的是人，而且必须是把浏览器语言调成波兰语之后的人。

这一条几乎是本文所有麻烦的总源头：整条链上没有一个自动检查项会去质疑首屏那段字的语言，于是它可以在线上安静地待好几年，期间每一份体检报告都是绿的。

市面上的合规体检工具查的是有没有装、分类对不对、拒绝之后脚本停没停，没有一项会去读那段文字是什么语言。

自动化测试也帮不上忙，多语言站的用例通常写在页面模板上，覆盖层不在任何一个模板里。

这段文字到底是谁输出的，为什么不在你的翻译队列里？

页面文字走内容库，横幅文字走另一个后台

先把出处分清楚，后面的判断才不会打架。

页面上的文字有两个来源：内容库里的条目，以及主题模板里的固定文案。

这两处都在你的翻译工作流里，导出、翻译、回填，路径是通的。

横幅上的文字是第三个来源：同意管理工具自己的后台。

它的存储位置不在你的数据库里，通常在服务商那边；改它要登录另一套系统，用另一套权限，导出格式也跟你的翻译交付文件对不上。

这就是为什么翻译团队从来没见过这段字。他们拿到的文件里根本没有这几行，而没人会去翻译一份自己没收到的文件。

导出格式也对不上。翻译交付走的是标准的双语文件，同意工具后台导出的是它自己那套结构，字段名跟你的内容库没有一处能对上。

所以就算有人想起来要翻它，回填也只能一格一格手工粘，而手工粘的东西下次改版又会丢。

这跟本站讲翻译报价单上写着四万字，页面上真正被人读的那几十个词一个都不在里面那一篇里的界面字符串是同一族问题：它们都住在内容库之外，于是都不在按字数计价的那份报价单上。

翻译交付清单是按页面模板列的，弹层不在模板里

本地化排期通常这么做：先列页面类型，首页、列表页、商品页、结算页、政策页。

再按类型列字段，标题、描述、按钮、提示语。

这个方法本身没问题，覆盖率也高，唯一漏掉的是那些不属于任何页面类型的东西。

同意横幅、订阅浮层、年龄确认、地区确认，这几样都是全站级的覆盖层。

它们的共同特征是：不隶属于任何一个页面，却出现在每一个页面上。按页面类型清点的方法天生看不见它们，因为清点的单位选错了。

正确的清点单位不是页面类型，是屏幕上的位置。按位置清点，才能把这些不属于任何页面的东西捞出来。

全站级覆盖层通常有五类：同意横幅、订阅浮层、年龄确认、地区与货币确认、退出挽留弹窗。它们的共同点是每一个页面上都会出现，却不属于任何一个页面。

这五类里只有同意横幅是法律要求必须存在的，别的四类都可以撤掉，这一点决定了它们的优先级排序。

装它的人是技术或法务，验收的人是市场

这条组织上的错位值得单独说。

同意工具的采购动机是合规，推动者通常是法务或者管数据的人。

实施的人是技术，他关心的是加载顺序、脚本拦截规则、跟统计工具的对接。

最后看到成品的是做市场的人，可他没有那个后台的账号。

于是出现了一种很尴尬的分工：唯一能看出文案有问题的人，恰好是唯一改不了它的人。而能改的那两位，各自的验收标准里都不含语言这一项。

有个成本很低的解法是把语言支持写进采购需求：语言来源可配、自定义描述支持多语言、给本地化团队一个只读账号。

这三条写在合同阶段是一句话的事，等上线之后再补，就变成跨部门要权限的事了。

一句话判据：这段字改起来要登录哪个系统

想快速判断一段文字归不归你的翻译流程管，问一个问题就够。

改这句话，要打开哪个后台？

如果答案是内容库或者主题文件，它在流程里，正常排期就行。

如果答案是某个服务商的控制台，它在流程外，需要单独立一条。

把这个问题拿去问一遍站上所有可见文字，通常能揪出五到八处流程外的文本：同意横幅、客服窗口、评价插件、支付按钮、地图控件、退出挽留弹窗。它们加起来往往就是新市场用户读到的第一批字。

实际跑一遍，多数站能揪出五到八处流程外的文本：同意横幅、客服窗口、评价插件、支付按钮上的文案、地图控件、退出挽留弹窗、物流查询嵌入框。

把它们的第一屏可见部分加起来，往往就是一位新市场访客读到的头几十个词。

横幅挑语言的依据，跟你的页面挑语言的依据是一套吗？

页面按地址里的那一段语言信息走

多语言站的页面语言基本都由地址决定。

子目录形式的看第一段路径，子域名形式的看前缀，独立域名的看域名本身。

这套做法的好处是确定：同一个地址，谁打开都是同一门语言。

它也可被引用、可被收藏、可被分享，别人点开看到的跟你看到的一样。

这是搜索引擎能把各语言版本分别收录的前提，也是本站讲小语种页面正文越本地化越好、结构化数据却要反着写回国际格式那一篇里反复强调的地基。

地址决定语言还有两个附带好处：这个地址可以被分享，别人点开看到的和你一样；它也可以被缓存，不需要按人区分。

全站真正不带语言信息的地址通常只有两个，根域名首页和那个面向未匹配用户的兜底版本。

横幅多半按浏览器偏好或者按地理位置走

同意工具的默认逻辑跟这个不一样。

最常见的是读浏览器发来的语言偏好，也就是那串按顺序排的语言标签。

其次是按访问者的网络位置判断国家，再映射到一门语言。

还有一种是读页面标签上的语言声明，但这一种反而不是默认项，需要在后台单独开。

三种取法各有各的道理，问题在于它们跟地址那一套是彻底独立的两个坐标系，谁都不知道对方拿到了什么答案。

浏览器发来的偏好其实是一串带权重的列表，可多数工具只取排在最前面的那一个。

而这个设置极少有人主动改过，它基本等于用户当初装系统时选的那门语言，跟他此刻想读什么没有必然关系。

两个坐标系撞车，会撞出四种组合

把地址语言和横幅语言排成一张两乘二的表，四格里只有一格是对的。

第一格，地址波兰语、横幅波兰语，正常。

第二格，地址波兰语、横幅英语，就是前面那个客户的情况，最常见。

第三格，地址英语、横幅波兰语，出现在波兰用户点开你的英语国际站时，页面是英语反而横幅是波兰语。

第四格更微妙：地址波兰语、横幅德语。这发生在一位住在德国的波兰用户身上，他的浏览器首选德语，而他特意点开了你的波兰语站。四格里只有第一格是团队测试时会遇到的那一格，因为测试的人通常在本地开着中文浏览器。

第四格在移民人口多的市场里并不罕见，德国的波兰裔、法国的葡萄牙裔、英国的印地语人群都属于这一类。

这批人恰恰是你的波兰语站最想要的访客：他们主动找了本地语言版本，结果被一段第三门语言的横幅拦在门口。

判据：地址里带语言信息时，一切以地址为准

这个冲突有一条很简单的处理原则。

地址里已经带了语言信息，说明访客做过一次明确的选择，或者搜索引擎把他送到了这一版。

这时候浏览器偏好只是背景资料，不该覆盖已经明示的选择。

只有地址完全不含语言信息时，才轮到浏览器偏好出场。

落到操作上，就是去同意工具后台把语言来源改成读页面上的语言声明，而不是读浏览器偏好。这个开关多数工具都有，只是默认不在那一档，而默认值一旦没人动过就会一直在那儿。

改完这个开关要重新测第四格，因为它是唯一一个改对了才会显现差别的组合。

只有根域名首页和兜底版本该继续读浏览器偏好，因为那两处确实没有别的依据可用。

平台自带三四十种语言，为什么用户看到的还是半洋不土？

按钮那几个词是厂商给的，用途说明是你自己写的

同意横幅上的文字其实分两批，来源完全不同。

第一批是界面词：接受全部、拒绝全部、管理偏好、保存设置。

这一批由服务商的语言包提供，主流工具能给到三四十种语言。

第二批是内容词：你收集哪些数据、每一类用来做什么、放多久、给了谁。

这一批必须由你自己填，服务商不可能替你写，因为他不知道你装了哪些追踪工具。而你填的时候，多半是照着合规文档抄了一版英语。

界面词还包括二级面板里的分类名称：严格必要、偏好、统计、营销。这四个词也在语言包里，所以它们通常是对的。

于是显示效果更奇怪：分类名是本地语言，分类下面那段解释是英语，用户读到一个看得懂的标题和一段看不懂的正文。

顺带说一句，这四个分类名在各语言里的译法相当固定，反而是最不需要你操心的部分。

自定义那一部分通常只有一份，而且多半是英语

后台的字段结构大致是这样：界面词按语言各一套，自定义描述往往只有一个输入框。

要做多语言，得在每一门语言下面重新填一遍那几段描述。

这件事没有技术难度，只有工作量，于是它成了最容易被跳过的一步。

跳过之后的显示效果很分裂：按钮是波兰语的，展开分类之后的说明是英语的。

用户能读懂按钮，读不懂他到底同意了什么，而这恰好是整个机制里唯一有法律意义的那部分。

还有一种更隐蔽的退化：工具升级语言包、新增了字段，新字段在你没填过的语言下会显示成英语。

同样地，新增一门语言时，自定义描述不会从别的语言复制过去，那几格是空的，而空格的显示结果就是回落到默认语言。

双语用户的判断标准还跟单语用户不一样。本站讲两种语言都看得懂的用户，而你的站只能有一套URL那一篇里说过，两门语言都读得懂的人不会因为看不懂而离开，他会因为你没做而降低对你的评价，这是一种更难察觉的流失。

越是合规要求写清楚的部分，越是没被翻译的部分

这里有个挺讽刺的对应关系。

法律要求说明白的是目的、范围、保存期限、第三方名单。

而这几项全部落在自定义描述里，也就是最可能没被翻译的那一批。

反过来，那两个按钮的措辞在法律上要求最低，却翻得最全。

结果就是横幅上翻得最好的部分是最不需要翻的部分。这不是谁失职，是因为翻译工作量跟文本重要性在这一页上正好成反比，而没有人拿着法律清单去逐段核对过。

第三方名单那一栏最典型。里面列的是一串英文公司名加英文用途，即便按钮翻成了本地语言，这一栏对用户仍然等于没写。

而这一栏恰恰是监管口径里最要紧的一项，因为它回答的是数据到底给了谁。

清点办法：把横幅上的每一段字标出来源

这个动作十五分钟能做完。

把横幅完整展开，包括点了管理偏好之后的二级面板。

截图打印，然后逐段标注：这段来自服务商语言包，那段是自己填的。

标完之后，自己填的那些就是要单独排一次翻译的清单。

顺手记下每段字在后台的字段名，交给翻译时把字段名一起给，回填才不会对错位置。这份对照表以后每次换工具、每次加语言都能复用，做一次能省很多轮。

标注的时候把每段字在后台的字段名一起记下来，交给翻译时字段名跟着走，回填才不会串位置。

这份对照表以后换工具、加语言、改分类都能复用，做一次能省掉后面每一轮的重新摸索。

法律那一侧对语言的要求，硬在什么地方？

同意必须是知情的，而知情的前提是读得懂

欧盟这套规则里，同意要成立有几个条件，其中一条是知情。

知情不是形式上给了文本就算，是这个人确实能明白他答应了什么。

一段他读不懂的文字，无法让他知情。

所以语言在这里不是体验问题，它直接决定这次同意在法律上成不成立。

这是本文最值得记住的一条：站上大部分文案翻错了只是难看，这一段翻错了或者没翻，等于你收集到的那批同意可能从一开始就不作数。

同一条逻辑也适用于拒绝那一侧：如果用户读不懂怎么拒绝，他就没有真正的选择，而自由选择是同意成立的另一个条件。

所以只翻接受按钮、把拒绝路径留在英语里，是比全英语更糟的一种做法。

条例原文要求用清晰平实的语言

相关条款写得很直白。

请求同意的表述必须能被清楚区分，用可理解、易获取的形式，语言要清晰平实。

另一条关于透明度的要求也重复了同样的措辞。

条文里没有一句写着必须用当地语言，因为它写的是必须能被这个人理解。

这个写法比列一张语言清单更强：它把判断标准放在了接收方身上，你面对的是波兰用户，那么可理解就意味着波兰语，没有讨价还价的余地。

条文里没有一句写着必须使用当地语言，它写的是必须能被这个人理解，判断标准落在接收方身上。

这个写法反而更严，因为它堵死了通用语言这条辩解：你面对的是波兰用户，可理解就意味着波兰语。

后果不是罚款那么简单，是这次同意不成立

很多人把合规风险直接翻译成罚款金额，这里不是。

如果同意不成立，那么建立在这次同意之上的所有数据处理就失去了依据。

统计脚本收集的行为数据、广告平台拿到的转化信号、重定向名单，全部悬空。

严重的情况下要删数据、要重新收集，还要解释这段时间的报表怎么算。

对做增长的人来说，这比罚款更疼：你不只是被罚了一笔钱，你是发现过去两年积累的受众数据可能不能用，而这批数据正是投放效率的地基。

重新收集也有代价。横幅要重新弹一遍，而重新弹一次意味着一部分本来已经同意的人这次会点拒绝。

换句话说，这个问题拖得越久，修复时要付出的不是补一次翻译，是把好不容易攒起来的同意率再交一次学费。

检查的时候，语言是一眼就能看出来的那一项

数据保护机构的检查动作大多需要技术核验：脚本什么时候加载、默认值是什么、拒绝之后有没有真的停。

唯独语言这一项，打开页面就能看见。

它是整份检查清单里成本最低、最先被注意到的一项。

一个用英语横幅面对本地用户的站，很容易在第一眼就被判定为没认真对待这件事。

投诉链条也短：一个看不懂横幅的用户去投诉，附一张截图就够了，不需要懂任何技术。这跟别的合规问题很不一样，别的问题至少还要有人会看开发者工具。

投诉的门槛也低得出奇：一位读不懂横幅的用户截一张图就能投诉，不需要懂任何技术。

别的合规问题至少还要有人会看开发者工具，这一条不需要，它是站在门口就能看见的那种问题。

还有一种触发路径：竞争对手举报。本地竞品比谁都清楚你这一页是英语的。

用户点同意之前，你的翻译脚本被允许运行吗？

同意工具的工作方式是先拦住所有非必要脚本

这套机制的核心动作只有一个：在拿到同意之前，不让非必要的第三方脚本跑起来。

实现方式通常是把脚本标签改成一种浏览器不会立刻执行的类型，等同意到手再放行。

有的工具更彻底，直接在网络层拦住对特定域名的请求。

被拦的名单是按类别配的：统计、广告、功能、个性化。

这里的关键在于分类是人配的，而配的人看到一个陌生域名时，很自然会先扔进非必要那一档，毕竟宁可多拦不可少拦，这在合规上永远是安全的选择。

分类的默认档位天然保守。工具自动扫描给出的建议也一样，它认不出的域名一律往非必要里放。

从合规角度这没错，宁可多拦不可少拦；问题只在于没人回头看看被多拦的那几个是干什么的。

本站讲在非洲选语种别先看人口，先看有没有人拿这门语言写价格和退货政策那一篇里提过，第三方脚本在弱网市场能占到首屏体积的一半，而同意工具通常是其中加载最早的那一个。

靠第三方注入的翻译方案，正好落在被拦的那一类里

现在把两件事对上。

一部分多语言站的译文不是服务端渲染的，而是靠一段第三方脚本在浏览器里替换文字。

这段脚本来自服务商的域名，加载时机在页面之后。

它在同意工具眼里就是一个外部域名发起的请求，跟统计脚本长得没什么两样。

于是它有相当大的概率被归进功能类甚至个性化类，然后在用户点同意之前被拦住。这不是谁写错了代码，是两套系统各自按自己的正确逻辑工作，撞在了一起。

判断有没有被拦有个很快的办法：看页面源码里那段脚本的类型属性有没有被改写成不会立刻执行的值。

被改写了就是被拦了，没改写但请求失败，那就是在网络层被挡住的那一种。

结果是首屏原文，点完同意才变成本地语言

这个连锁的表现很有辨识度。

页面刚打开时是源语言，通常是英语。

横幅盖在上面，也是英语。

用户点了接受，页面上的文字才刷成本地语言。

换句话说，你花钱做的整套本地化，被一道合规闸门挡在了第一屏之外，而第一屏恰恰是决定这个人留不留下来的那一屏。用户看到的顺序是：先被一段外语要求做决定，同意之后才发现原来这个站是有波兰语的。

用户实际经历的顺序是这样的：先被一段外语要求做一个跟隐私有关的决定，同意之后才发现原来这个站是有波兰语的。

而在这个顺序里，有一批人在做决定之前就已经离开了，他们从头到尾没见过你的本地化。

这条连锁只在多语言站上成立，单语言站永远看不到

值得强调一下这件事的稀有度。

单语言站装同意工具，被拦的是统计和广告，用户体验上几乎没有差别。

多语言站装同意工具，如果译文靠客户端脚本，被拦掉的是内容本身。

同一个工具、同一份配置，在两种站上的后果完全不是一个量级。

所以这个坑在通用的合规文章里读不到，那些文章的默认读者是单语言站。它只在两件事同时成立时出现：译文靠第三方脚本，同意工具默认拦截未分类域名。

所以这个坑在通用的合规文章里读不到，那些文章默认读者只有一门语言。

它只在两件事同时成立时出现：译文靠客户端脚本注入，同意工具默认拦截未分类域名。任何一条不成立，它都不会显形。

三种排查动作，十分钟能确认

第一种最简单：关掉同意，看页面还剩哪些字是源语言。

第二种是看拦截名单，找找翻译服务商的域名在不在里面，在哪一档。

第三种是把浏览器的脚本执行关掉再打开页面，看看返回的文档里译文在不在。

三种动作各自回答一个问题：拦没拦、归在哪一类、译文到底在服务端还是客户端。

如果确认是被拦了，处理办法通常是把翻译服务商的域名归到严格必要那一类，或者干脆把翻译改成服务端完成。前者是权宜，后者才是根治，因为服务端渲染的译文同时解决了抓取那一侧的问题。

还有第四种动作，而且它是最容易被忘的一种：用无痕窗口测。

因为点过一次同意之后横幅就不再出现，你在自己常用的浏览器里怎么刷新都看不到问题，而每一位新访客看到的都是第一次那一版。

实操上建议把这一步写成固定动作：每次改完横幅配置，开一个新的无痕窗口，把语言偏好改到目标语言再测。

这个动作只要一分钟，却是唯一能复现新访客视角的方法。

抓取程序永远不点同意，它看到的是哪一版页面？

抓取程序不会点任何按钮

这是一条太基础反而常被忘掉的事实。

抓取程序会执行脚本，但不会点击。

它不会点接受，也不会点拒绝，更不会去二级面板里逐项打开。

所以它永远停在未同意那个状态里。

如果你的页面在未同意状态下少了一半内容或者语言不对，那么它拿到的就是那一版，而它不会告诉你它看到的跟你看到的不一样。

它也不会滚动、不会关闭浮层、不会展开二级面板。

凡是需要一次交互才能显示的内容，对它来说都不存在。

它拿到的第一段可见文字，很可能是横幅

横幅的位置决定了它在文档结构里的地位。

很多同意工具把横幅插在文档最前面，或者用很高的层级盖在最上层。

抓取程序不看层级，它读的是文档顺序。

于是横幅那几句话有机会成为文档里靠前的文本块。

一个波兰语页面，最前面那段文字是英语的隐私说明，这在语言判定这件事上不是好消息。本站讲站上字最少的那几类页面最容易被机器认成另一门语言那一篇里说过，判错语言的代价往往不显示在语言这一栏，而是显示在收录量和展示位置上。

位置差别很大。有的工具把横幅节点插在文档最前面，有的插在文档末尾再用层级盖上去。

前一种对文本顺序的影响明显更大，而你没法从视觉上分辨这两种，只能去看源码。

短文本参与语言判定，代价在别处结算

页面语言不是只看标签上写的那个值。

标签是声明，正文是证据，两者矛盾时以证据为准的情况并不少见。

当一个页面的正文很短，比如分类页、筛选页、图片页，横幅那几十个词的占比会突然变得可观。

本来就短的页面，加一段外语，判定就更容易偏。

这解释了一个常见的困惑：同一个站里，商品详情页的语言从来没判错过，列表页和筛选页却时不时被归到别的语言去。差别不在模板，在正文与横幅的字数比例。

判断风险有个很快的指标：拿横幅文本的字数除以这个页面的正文字数。

商品详情页这个比值很小，可以忽略；分类页和筛选页的正文本来就只有几百个字符，比值一下子就上去了。

模板化的页面本来就彼此相似，本站讲一个模板生成十种语言，字符层看不出重复、信息层十份一模一样那一篇算过这笔账，再叠上一段各语言完全相同的英语横幅，相似度只会更高。

自查：用不执行脚本的方式取一次页面

最省事的验证方法是取一次原始文档。

用命令行工具直接请求页面地址，看返回的内容里有什么。

如果译文在返回的文档里，说明翻译在服务端完成，抓取那一侧安全。

如果返回的是源语言，说明译文靠客户端脚本，那就要再确认脚本有没有被同意工具拦住。

顺手看看返回内容里横幅文本的位置在哪一段，越靠前越要留意。这个动作两条命令就能做完，却能一次性回答本文里最要紧的两个问题。

顺手也看一眼响应头里的语言声明，跟页面标签上写的是不是同一个。

更彻底的做法是把执行脚本和不执行脚本的两版文本各存一份做比对，差异那一部分就是抓取程序看不到的内容。

语言回落发生的时候，页面会以什么形式出错？

找不到该语言就回落，而且不报错

同意工具的语言逻辑里都有一层兜底。

请求的语言在语言包里没有，就退回到默认语言。

默认语言通常是英语，也可能是你配置时的那门语言。

这个退回过程是静默的，后台不会亮红灯，控制台也不会打印警告。

这一点跟本站讲用户撞上404的那一刻请求已经不在你的应用里那一篇里的软性错误是同一类：系统认为自己成功了，因为它确实按规则返回了一个东西，只是返回的那个东西对这位用户没用。

留痕记录里通常也不记语言。也就是说事后你无法核对当时那位用户看到的是哪一版文字。

如果有一天要证明某一批同意是有效的，这一栏的缺失会让举证变得很困难，而这一栏在多数工具里是可以自定义加上的。

顺手把语言这一栏加进留痕字段的成本很低，多数工具支持自定义字段，填的就是当时展示给用户的那门语言。

回落到英语和回落到主语言，是两种不同的错

这两种情况值得分开看。

回落到英语，用户至少可能读懂，属于体验下降。

回落到你的主语言，比如一家德国公司的站回落到德语，波兰用户看到的是一段完全陌生的语言。

后一种更糟，而它恰恰更容易发生，因为配置的人常把自己熟悉的语言设成默认。

选默认语言时有个不太直觉的判据：它不该是你最熟的语言，而该是你的目标市场里第二外语普及率最高的那一门，在欧洲多数市场这仍然是英语。

选默认语言时有个不太直觉的判据：它不该是你最熟的语言，而该是你的目标市场里第二外语普及率最高的那一门。

在欧洲多数市场这仍然是英语，但在拉美是西班牙语、在中亚可能是俄语，照抄英语并不总对。

半屏本地语言半屏英语，用户读到的是不信任

混语言的横幅比全英语的横幅更伤。

全英语至少像个统一的国际站。

半屏波兰语半屏英语，传递的信号是这一页没人管。

而这一页恰好是要用户做一个跟个人数据有关的决定的地方。

本站讲落地页上最像装饰的那几个信任元素在小语种市场是搜索量最高的购买词那一篇里算过一笔账：一个新市场的访客在下单之前会用一切细节判断你是不是认真在做这个市场，而语言不一致是他不需要任何专业知识就能看出来的那一类细节。

混语言还会反过来削弱页面语言判定的证据面，因为它让这一页同时出现了两门语言的特征词。

一个本来就短的页面，加上一段外语，判定偏掉的概率会明显上升。

监控这件事只能靠自己造一张矩阵

没有现成工具会告诉你横幅语言不对。

能做的是把组合列出来，定期人工过一遍。

横轴是你的语言版本地址，纵轴是浏览器的语言偏好。

每一格记录横幅显示了什么语言、二级面板显示了什么语言。

一个五语言的站，矩阵是五乘五加上一行没有语言偏好的情况，三十格，一个人半小时能过完，一个季度做一次就够。抓取程序那一行要单独记，因为它的语言偏好通常是空的。

抓取程序那一行要单独记，它的语言偏好通常是空的，走的永远是回落分支。

顺手把二级面板也记进去，因为一级横幅和二级面板的语言来源不一样，很多站是一级对了二级还是英语。

这一页该由谁负责，验收怎么排？

三方各出一部分，缺谁都验不完

这段文字的特殊之处在于它没有单一归属，所以只能明确分工。

法务出内容：哪些类别、每类的用途表述、保存期限。

本地化出译文：把上面那批表述按语言各出一版，跟站上其他文案的用词保持一致。

技术出配置：语言来源改成读页面声明、拦截名单里翻译域名归类、加载顺序。

最后需要一个人做集成验收，而这个人必须有那个后台的只读权限。多数团队卡在最后这一步，不是不愿意验，是没有账号。

卡住多数团队的其实是最后这一步，而且卡的不是意愿是权限：能看出问题的人没有那个后台的账号。

解法很土，申请一个只读账号，成本是一封邮件。

还有一个务实的替代方案：让技术那一侧每季度导出一次横幅的全部文案给本地化过目，绕开账号问题。

一张浏览器语言乘以地址语言的矩阵

验收清单的主体就是上一节那张矩阵，这里给出每格要看的四项。

横幅主体的语言对不对。

展开二级面板之后，分类名称和用途说明的语言对不对。

拒绝之后再次打开页面，横幅语言有没有变。

点完接受之后，页面正文有没有从源语言刷成本地语言，如果有，说明译文在客户端且被拦过。

还有第五项：在页面上把语言切到另一门，看横幅会不会跟着变。

多数情况下不会变，因为同意已经存下来了，横幅根本不再出现，这也是为什么这一项必须在无痕窗口里测。

上线前的五项检查

第一项，把自定义描述在每一门语言下都填了没有。

第二项，语言来源开关是不是读页面声明。

第三项，默认回落语言选的是哪一门，理由是什么。

第四项，翻译服务商的域名在拦截名单的哪一档。

第五项，用不执行脚本的方式取一次页面，确认译文和横幅文本各自的位置。这五项加起来不超过一小时，但它们覆盖了本文提到的全部失效路径。

这五项加起来不超过一小时，却覆盖了本文提到的全部失效路径。

把它们写成一页纸贴进上线清单，比记住本文任何一条结论都管用。

什么时候要重新验一遍

有四个触发条件值得写进日历。

新增一门语言的时候，因为自定义描述默认不会跟着新增。

换同意工具的时候，因为语言来源开关的默认值可能不一样。

换翻译方案的时候，尤其是从服务端换成客户端注入。

加装任何新的第三方脚本的时候，因为它会被扔进某个分类，而分类会影响加载顺序。这四件事平时都不会被当成本地化变更，所以必须显式写进流程，否则不会有人想起来去看一眼那条横幅。

第五个触发条件是工具自己升级语言包，这件事你不会收到通知，只能在季度检查时顺手看一眼。

前四件平时都不会被当成本地化变更，所以必须显式写进流程，否则没人会想起来去看那条横幅。

哪些做法看着省事，实际上把问题埋得更深？

全站只留一版英语横幅

这是最常见的省事做法，理由通常是英语通用。

它省下的是几段文案的翻译工作量。

它埋下的是同意有效性的问题，而这个问题不会在流量报表上显形。

更麻烦的是它有欺骗性：因为一切正常运转，团队会以为这件事已经做完了。

要判断这个选择划不划算，只需要问一句：你愿意用两段文案的翻译成本，去换整个市场同意数据的有效性吗？这么一问，答案就很清楚了。

它最大的欺骗性在于一切都在正常运转：横幅弹得出来、同意收得到、报表照样出。

所有信号都在告诉你这件事已经做完了，只有那位波兰用户知道没有。

用机器翻译批量灌进后台

比不翻好，但这一页有它自己的门槛。

合规文本的用词是有惯例的，各语言里都有一批固定说法。

机器翻译在这类文本上容易把法律含义翻软，比如把必要的翻成需要的。

更常见的问题是术语在同一页里不统一，同一个概念前后两种译法。

可行的折中是机器翻译打底、法务或本地顾问过一遍关键的几段，工作量不大，因为这一页的字数本来就很少，通常两三百字。

好在这一页的字数很少，通常两三百字。机器翻译打底、请本地顾问过一遍关键几段，成本几乎可以忽略。

真正要盯的是术语一致：同一个概念在同一页里不能出现两种译法，这是机器翻译在这类文本上最常见的失手。

把横幅做成全屏遮罩

这个做法在语言之外还有别的代价，本站讲GDPR与CCPA同意横幅怎么不毁掉SEO数据那一篇写过。

这里只补语言层的一条。

全屏遮罩意味着抓取程序拿到的首屏文本几乎全是横幅。

如果横幅还是英语，那么这个页面对外呈现的第一批文字就是一段跟内容无关的外语。

体积小的页面受影响最大，而列表页和筛选页正好是体积小的那一批，它们又是站内链接结构里承上启下的一层。

体积小的页面受影响最大，而列表页和筛选页正好是体积小的那一批。

它们又是站内链接结构里承上启下的一层，判错语言的连带损失比单个商品页大得多。

本站讲阿拉伯语网站搬进手机之后，桌面时代验过的那份RTL清单有一半不作数那一篇里讲过固定条与弹层的遮挡方向，在从右往左的语言里，遮罩上那个关闭按钮的位置也要跟着翻，否则用户会下意识去点错的一侧。

把同意状态写进整页缓存

最后一条是技术上的坑，后果落在语言上。

把同意状态混进整页缓存，缓存键就多了一个维度。

再叠上语言维度，缓存命中率会明显下降。

更糟的情况是缓存串了：一位波兰用户拿到了缓存里那份德语横幅的页面。

正确做法是同意状态只放在客户端，页面缓存不带这个维度。这条跟按语言协商内容时要正确声明缓存差异是同一类问题，判断依据都是同一句话：这个维度到底该不该进缓存键。

正确做法是同意状态只留在客户端，页面缓存不带这个维度。

判断依据可以浓缩成一句话：这个维度会不会改变返回给用户的内容？会改变的才该进缓存键，而同意状态改变的是脚本行为，不是页面内容。

顺带提醒一句，边缘缓存那一层也要看，很多站的整页缓存其实发生在离用户更近的地方，而不是自己的服务器上。

常见问题解答

同意横幅用英语，在欧盟到底算不算违规？

不能一概说违规，但风险很实在。规则要求同意必须是知情的，且请求同意的表述要用清晰平实、能被理解的语言。判断标准落在接收方身上：面对波兰用户，可理解通常就意味着波兰语。真正的后果不是罚款那么简单，而是这次同意可能不成立，建立在它之上的统计与广告数据会一并失去依据。所以这不是体验问题，是数据资产的有效性问题。

补一句实操上的判断：如果你的市场里有本地语言的竞争对手，那么英语横幅在监管眼里几乎没有辩解空间，因为它证明了用当地语言做这件事是可行的。

同意工具后台已经开了多语言，为什么用户看到的还是一半英语？

因为横幅上的文字有两个来源。按钮和界面词由服务商的语言包提供，开了多语言就都有；你自己填的分类说明、用途描述、保存期限只有一份，需要在每门语言下重新填一遍。合规要求写清楚的恰好是后一批，于是最重要的那部分最容易留在英语。清点办法是把横幅完全展开截图，逐段标注来源，自己填的那些单独排一次翻译。

还有一个更隐蔽的版本：工具升级语言包新增了字段，新字段在你没填过的语言下会退回英语，于是本来全对的横幅过一阵子又混进了几行英文。

为什么页面是波兰语，横幅却按德语显示？

因为两者挑语言的依据不是一套。页面按地址里的语言段走，同意工具默认按浏览器语言偏好或者地理位置走。一位住在德国的波兰用户点开你的波兰语站，就会出现页面波兰语、横幅德语的组合。处理原则是地址里带语言信息时以地址为准，去后台把语言来源改成读页面上的语言声明，这个开关多数工具都有，只是默认不在那一档。

改完开关要重新用无痕窗口测一遍，因为点过同意之后横幅不再出现，你在常用浏览器里看不到任何变化。

抓取程序看到的横幅是什么语言，会影响收录吗？

抓取程序不会点任何按钮，永远停在未同意状态，它的语言偏好通常也是空的，所以它拿到的多半是回落语言那一版。影响主要有两处：一是横幅文本在文档里位置靠前，会参与页面语言判定，正文越短影响越大，列表页和筛选页首当其冲；二是如果译文靠客户端脚本注入而脚本被拦，它拿到的整页都是源语言。用命令行取一次原始文档就能确认。

顺手记一下横幅节点在文档里的位置，插在最前面的那种影响明显更大，而这一点无法从视觉上分辨。

翻译服务商的域名要不要放进严格必要那一类？

如果译文靠这段脚本在浏览器里替换文字，那就必须放，否则用户在点同意之前看到的是源语言，抓取程序看到的也是源语言。放进严格必要这一类需要有理由，而这个理由是站得住的：没有它页面无法以用户能理解的语言呈现。更彻底的做法是把翻译改到服务端完成，这样既绕开了拦截，也让抓取那一侧拿到完整译文。

把它归进严格必要之前，最好留一份书面理由，写清楚没有它页面无法以用户能理解的语言呈现，这样将来接受检查时这个分类是站得住的。

只面向一个市场的单语言站，需要在意这一节吗？

需要在意的部分不多。单语言站装同意工具，被拦的通常是统计和广告脚本，内容本身不受影响，语言也不会撞车。真正要留意的只有一条：如果这个市场的用户不使用你的界面语言，比如一家用英语后台的公司做日本市场，那么这一页仍然要单独确认。判断依据很简单，看横幅显示的语言跟你的目标用户日常使用的语言是不是同一门。

还有一种情况要留意：站是单语言的，但用户群不是。这时判断依据仍然是横幅语言与目标用户日常语言是不是同一门，跟站有几个语言版本无关。

权威参考资料