站上加一门语言是加一套模板，喂给平台的那份数据要多一整份文件

摘要：站上加一门语言，是加一套模板和一批译文；喂给购物平台的那份商品数据加一门语言，是多一整份文件、一条独立的审核队列和一次全量复制。原因在于语言在页面上是每条记录的一个属性，在数据源里却是整份文件的一个设置，一份只能声明一门语言加一个国家，份数是乘出来的不是加出来的。更麻烦的是这两套声明互不知情，没有任何一处会做交叉校验，而拒登理由永远只写落地页与数据不符。本文拆开份数怎么算、属性取值怎么对齐、平台自动翻译那一版算谁写的。

你的站有语言这个维度，为什么喂给平台的那份数据没有？

一家小家电站的荷兰语市场，投放没问题自然购物结果一条都没有

有个客户做小家电，空气炸锅、破壁机、除螨仪、加湿器这几条线。

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

投放这一侧一直是外部代理在跑，数据交上去、广告能出、没人抱怨。

问题出在自然那一侧：德国和波兰在免费的购物结果里都有露出，荷兰一条都没有。

保哥把三个市场的商品数据后台点开对着看，看到第三屏就明白了：三个市场共用同一份数据文件，而这份文件的语言设置写的是德语。

德国那边当然对，波兰那边靠代理另建了一份，只有荷兰这一份从来没人动过，于是平台一直在拿一份声明为德语的数据去匹配荷兰用户的荷兰语查询。页面翻得再好都没用，因为参与匹配的根本不是页面。

还有一处细节值得记：这份数据的诊断报告一直是绿的。因为格式没错、必填字段齐全、抓取成功率也高，所有会被自动检查的项目都通过了，只有那个下拉框里的取值没有任何程序会去质疑。

页面上语言是每条记录的属性，数据源里语言是整份文件的设置

这个差别是本文所有结论的根。

在你的站上，语言是挂在每一条内容上的：这个页面是荷兰语，那个页面是德语，同一个模板能渲染出两种语言。

在商品数据源里不是这样。语言不在数据行上，它在这份数据的设置里，是一个整份文件级别的取值。

换句话说，一份数据源只能是一门语言，里面的每一行都必须是这门语言。

平台官方的支持的语言与货币那份说明里把这条讲得很清楚：语言和目标国家都是数据源属性，一份数据源对应一个组合。这不是限制，这是它的数据模型。

这个模型差异还有一个不太直观的推论：数据源里没有办法表达这一行是荷兰语、那一行是德语。你想混着放，唯一的结果是整份数据被按声明的那门语言处理，另一门语言的那些行成了噪声。

于是加一门语言，两边付的代价完全不同

把这个差别翻译成成本，落差就很直观了。

站上加一门语言，加的是一套语言资源文件，页面数量不变，地址结构不变。

数据源这边加一门语言，加的是一整份新文件：它要单独生成、单独上传、单独排进审核、单独出诊断报告。

更要命的是它有自己的失败模式，跟页面那一侧完全不重叠。页面上线了不代表数据通过了，数据通过了不代表页面对得上。

所以团队里那句加一门语言的工作量已经评估过了，多半只评估了页面那一半。本站在产品feed到底该谁管那篇里讲过这份数据在组织里的归属问题，语言这一列正是归属不清最容易掉下去的地方。

还有一层代价在时间上。页面上线是你说了算的，数据要等平台抓取和审核，快则几小时慢则几天。所以新语言上线的那几天里，页面已经在了而数据还没进来，这段窗口期的表现不能用来判断做得对不对。

这件事为什么在英语站上永远不会成为一个话题

这条规律本站已经遇到过很多次，这里又一次成立。

一个只做英语的站，数据源份数等于国家数，语言这个维度根本不参与计算。

做英美澳三个市场，三份数据源，语言全是英语，你甚至不会注意到设置里有语言这一项。

于是所有关于这份数据的教程、清单和最佳实践，都是在语言维度恒等于1的前提下写出来的。

它们讲标题怎么写、图片怎么选、价格怎么对，就是不讲语言，因为在作者的场景里那不是一个变量。同一种英语卖到美英澳那篇拆过这种情形的另一半，两边合起来才是完整的图。

顺带说一个判断技巧：读任何一份关于这类数据的指南时，先看它有没有提到语言这个设置。一个字都没提的，说明作者的场景里语言恒等于一，那份指南的份数计算和排期建议都不能直接照搬。

数据源的语言到底声明在哪儿，跟页面上那套语言声明是什么关系？

声明的位置不在数据里，在后台的数据源设置里

很多人第一反应是去数据文件里找语言字段，找不到。

它确实不在文件里，它在后台创建这份数据源时选的那两个下拉框上。

一个下拉选语言，一个下拉选目标国家，选完就定死了。

这个位置的隐蔽性是它最大的问题：文件是每天自动生成上传的，谁都能看到；那两个下拉框是三年前某个人点的，从此没人再点开过。

本站在界面文案那批从没进过翻译文件的字里记过完全一样的结构：一个当时不需要评审的决定，此后没有任何流程会重新审视它。

还有一处同样隐蔽的设置在旁边：目标国家。两个下拉挨着，错一个的后果差不多，但目标国家错了往往会因为货币或者税率对不上而被诊断出来，语言错了不会。所以真正没有防线的是语言那一个。

页面这一侧的语言声明有三处，数据源那一侧只有一处

把两边的声明并排列出来会更清楚。

页面这一侧至少有三处：标签上的语言属性、响应头里的语言字段、以及各语言版本之间互相指认的那组标记。

数据源这一侧只有一处，就是后台那个下拉。

三处对一处，本身就说明两套体系的精细度不在一个量级。

更关键的是数量少的那一侧是决定性的：匹配用的是数据源那一份，页面上写得再全也改不了它。结构化数据里的语言与地区声明那篇讲的是页面这三处怎么写，本文补的是第四处。

把这四处列成一张表贴在流程文档里是划算的。新市场上线时逐处打勾，四个勾打完再上线。这张表的价值在于它把一个分散在两个系统里的检查项收成了一次动作。

两套声明互不知情，也没有任何一处会做交叉校验

这是本文最想让人记住的一句。

页面的语言声明和数据源的语言设置之间，没有任何自动校验。

你可以把一份声明为德语的数据源指向一批荷兰语落地页，系统全程不会提示你。

抓取会成功，商品会入库，诊断报告可能一片绿，广告甚至照常投放。

不一致的后果不是报错，是匹配质量悄悄变差：查询用荷兰语进来，数据说这批商品是德语的，于是它在这个国家的自然购物结果里排不上。整条链上没有一个环节的职责是发现这件事。

自己补这个校验并不难：把数据源的语言设置导出来，跟落地页地址里的语言前缀做一次字符串比对，对不上的报警。这个脚本几十行，跑一次几秒钟，可它填的是整条链上唯一没人负责的那个缺口。

数据源里没有各语言版本互相指认的那套机制

还有一件事值得单独点出来。

页面这一侧有一套成熟的机制，让同一个内容的各语言版本互相指认，告诉引擎这几页是一回事的不同语言版。

数据源这一侧没有等价物。同一款空气炸锅的德语版和荷兰语版，在数据层面就是两条毫无关系的记录。

唯一能把它们联系起来的是落地页地址，而地址关系由页面那一侧的标记维护。

这意味着页面那一侧的标记如果做错了，数据这一侧不会有任何补救余地。hreflang标签怎么落地那篇讲的是页面那一侧怎么做对，这里补一条依赖关系：那一侧做对了，数据这一侧才有可能被正确归拢。

这条依赖关系还有一个实用推论：先把页面那一侧的语言关系做干净，再去铺数据源。顺序反过来的话，数据侧会先积累一批归拢错误的记录，而这批记录的纠正周期比页面长得多。

一门语言一份文件，数据源的份数是怎么被乘出来的？

语言乘国家，而不是语言加国家

算份数的时候最常见的错误是用加法。

做三门语言、四个国家，很多人下意识觉得是三份或者四份。

实际上一份数据源锁定的是一个语言与国家的组合，所以要按组合数算。

不是所有组合都存在，但存在的那些每一个都要一份。

德语卖去德国、奥地利、瑞士，是三份；再加荷兰语卖去荷兰和比利时，又是两份。五份，而不是两门语言加两三个国家那种直觉上的三四份。

算之前建议先画一张表：行是语言，列是国家，在实际有销售的格子里打钩。打完钩数一下有几个钩，这个数就是份数。这个动作五分钟，却能把后面几个月的排期算清楚。

还有一个上限要提前知道：平台对一个账户下的数据源数量通常有限制，多数场景够用，但如果你既按语言拆又按商品线拆，两个维度乘起来很快就会撞上限。所以拆的维度只能有一个是语言，另一个别再拆。

同一门语言卖去三个国家，为什么还是三份

这一条最反直觉，值得单独说。

同一门语言的三个国家，商品文案可以完全一样，一个字都不用改。

但价格不一样、税率不一样、配送政策不一样、可售商品范围也未必一样。

这些差异都写在数据行里，所以文件本身就是三份不同的文件。

语言在这里帮不上忙：语言相同只省掉了翻译成本，没省掉文件数。这也是为什么这件事的成本曲线跟页面那一侧长得完全不一样，页面可以靠同一套内容覆盖三个国家，数据不行。

这里有一个真正能省的地方：文案可以完全复用。三份文件里的标题和描述可以是同一批字符串，只有价格、货币、可售状态这几列不同。所以生成这三份的脚本可以共用一套文案逻辑，差异用参数控制。

份数一多，增长点不在文件上而在审核队列上

五份文件听起来还好，真正的成本在后面。

每一份都有独立的抓取排期、独立的诊断报告、独立的拒登记录。

一个商品在五份里被拒登，就是五条要处理的记录，而它们的拒登理由可能各不相同。

更耗人的是这五份的问题不会同时出现，它们错峰发生，于是这件事永远有人在处理，永远没做完。

见过的失败模式基本都是这一种：份数从两份长到八份的过程中没人重新分工，还是原来那一个人在看，看着看着就只看主力市场那两份了。

有一个能提前止损的动作：给每一份配一个明确的接收人，而不是发到共享邮箱。共享邮箱的通知在份数超过四份之后基本就没人看了，因为它变成了一条永远有新消息的流。

什么时候可以合并，什么时候绝对不能

给两条判据。

可以合并的情形只有一种：同一门语言、同一个国家、只是商品来源不同，这时候用补充数据源覆盖字段就够，不必建新的主数据源。

绝对不能合并的是跨语言。哪怕两门语言的用户群高度重叠，比如同一个国家的两种官方语言，也必须分开，因为语言是文件级设置。

还有一种半合并的做法值得知道：主数据源保持一份，用补充数据源按语言覆盖标题和描述这两列。这条路在部分平台上可行，在部分平台上不行，接入前要先确认。

判断顺序永远是先看语言是不是同一门，语言不同就别想着省这份文件。

补充数据源这条路还有一个附带好处：它不需要重新生成主数据，只覆盖指定的几列。对于只想按语言换标题的场景，这是改动量最小的做法，也最容易回滚。

落地页与数据不符这条拒登理由，差的到底是什么？

这条理由的字面意思和实际成因

这是所有商品数据里最高频的一类拒登，字面意思是数据里写的和落地页上显示的对不上。

大多数人第一反应是查价格，其次查库存状态。

这两项确实占了多数，但它们通常几小时内就能定位。

真正拖成慢性病的是另外几类，其中语言不一致是最不被想到的一种。

官方的购物广告政策里对这一类的要求写得比多数人以为的宽泛：数据必须准确反映落地页，而落地页的语言当然也在反映的范围里。

还有一类容易被归错的：抓取的时候拿到的页面跟用户看到的不一样。常见成因是按地区做了跳转，或者页面靠脚本渲染而抓取时没执行。这一类看起来像语言问题，实际上是可访问性问题，要分开处理。

语言不一致是最常见也最不被想到的一种

语言不一致有三种发生方式。

第一种是数据源设置错了，就像开头那家小家电站，整份数据的语言从一开始就填错。

第二种是数据对但落地页跳错了：地址指向的是默认语言版本，用户和抓取程序拿到的都是另一门语言的页面。

第三种最细：数据里绝大多数字段是目标语言，但有几列没翻，比如尺寸类型、材质、适用场景这类枚举值。

第三种触发拒登的概率不高，但它会持续拉低匹配质量，而且没有任何报表会告诉你有几列没翻。

第三种的排查有个笨但有效的办法：把数据文件按列抽样，每列取十个不同的取值，交给母语者扫一眼。他能在两分钟内指出哪几列不是本地语言，而这件事没有任何自动检查能替他做。

属性取值的一致性要求比标题更严

这里有个容易被忽略的不对称。

标题和描述允许你写得跟落地页不完全一样，只要意思准确。

而颜色、尺寸这类属性，平台要求提交的取值和落地页上显示的取值保持一致。

也就是说，页面上写荷兰语的颜色名，数据里就得是荷兰语的颜色名，不能图省事全填英语。

官方的颜色属性说明还额外要求用标准的颜色名而不是自造的营销名，两条要求叠在一起，就把这一列变成了必须逐语言维护的一列。

这条不对称的实际含义是：属性列的本地化优先级应该排在描述之前。多数团队的顺序正好相反，先花力气翻描述，属性列留到最后，而属性列才是那个会触发拒登和影响筛选归类的部分。

排查顺序：先看语言，再看价格和库存

给一条能直接用的排查顺序，跟多数人的习惯正好相反。

拿到一批拒登，先按国家分组，看是不是集中在某一个市场。

集中在某一个市场的，先去看那份数据源的语言设置，两分钟就能确认。

确认没问题再往下查价格、库存、图片这些逐条差异。

这个顺序的道理很简单：语言设置错了是整份文件的系统性问题，一次能解释掉成千上万条；价格和库存是逐条问题，查一条解决一条。先查能一次解释掉全部的那类。

还有一个能顺手做的分组：按拒登理由的文本聚合。同一句理由下面挂着上千条商品，多半是系统性问题；一句理由下面只有三五条，才是逐条问题。先处理前者，投入产出差一个数量级。

属性值那一列，为什么翻了页面不翻属性值等于白翻？

属性值是给机器筛选用的，可它同样要按目标语言提交

属性列跟标题描述不一样，它的读者主要是机器。

机器拿它做筛选面、做比价、做同款归并。

正因为读者是机器，很多团队默认它可以用英语，反正机器认识。

这个默认是错的：平台按语言维护自己的属性取值表，你提交的值要落进目标语言那张表里才会被正确归类。

提交英语值到一份荷兰语数据源里，最好的结果是被当成自定义值放行，最坏的结果是这条商品在筛选面里彻底消失。

有个快速自检：去平台的筛选面上看看自己的商品出现在哪些筛选项下。如果某个颜色或者尺寸筛选项里找不到你的商品，而商品本身有这个属性，那多半就是取值没落进标准表。

还有一类自定义属性值得单独说：平台允许你上传自己定义的属性，用来做广告分组和报表切分。这一类不参与前台展示，理论上填什么都行，但强烈建议全站统一用英语标识，否则按语言分的报表会碎成一片。

换句话说，标准属性按目标语言填，自定义属性按内部标识填。两类混着填是这一块最常见的乱源，而它的代价要等到做跨市场报表的时候才显出来。

颜色和尺寸这两列的坑最深

属性列里最容易出事的是颜色和尺寸。

颜色的麻烦在于范畴边界，各语言把连续的色谱切在不同位置，同一个色号在两门语言里可能落进不同的基本色。

本站在你的色卡上蓝和绿是两格那篇里专门拆过这一层，这里只补数据源侧的一条：平台要的是标准色名，而标准色名的清单是按语言给的，直接把英文清单翻一遍会翻出一批当地人不用的说法。

尺寸的麻烦在于制式，同一个数字在不同国家指的不是一码事，而尺寸类型这一列的取值本身也要按语言写。

这两列建议单独建对照表，一次建好长期复用，因为它们的取值集合是有限的，不像标题那样每条商品都不同。

尺寸这一列还有一个跟语言直接相关的坑：尺寸类型的取值本身是词，比如常规、加大、加长这一类，它们要用目标语言写。很多团队翻了尺寸数字所在的说明文字，却把这一列的枚举值留成了英语。

提交值和落地页显示值经常由两拨人维护

一致性要求本身不难满足，难的是组织。

页面上显示的颜色名由内容或者本地化团队定，数据里提交的颜色名由做数据管道的人定。

两边各有各的来源，中间没有一条线把它们绑在一起。

于是页面改了词，数据没跟着改；或者数据换了标准值，页面还是老说法。

解法是把这批取值收进一个字段，页面和数据都从这个字段取，而不是各写各的。本站在品牌名算公的还是母的那篇里用过同一招：结论存进数据字段，字段一旦存在就有了负责人和变更记录，而不是变成一场每年重来一次的口头争论。

还有一个更省事的判断：如果你说不出这批取值现在存在哪儿，那它一定存在好几个地方。存在好几个地方就意味着它们迟早会不一致，而不一致的那一天不会有任何提示。

建一张属性取值对照表，一次建好长期复用

具体做法很朴素。

把用到的属性列出来，通常不超过八列：颜色、尺寸、尺寸类型、材质、图案、年龄段、性别、状态。

每一列列出你实际用到的取值，多数列在二十个以内。

再按语言横向展开，每门语言一列，请本地写手一次填完。

这张表的规模通常在一两百格，一个人半天能填完，而它此后覆盖所有新品。属性枚举值那件事给过一条判据可以直接借用：取值本身是不是落在一条连续谱上，是的话就必须逐语言确认，不是的话可以放心复用。

表建好之后要定一条维护规则：新增取值必须先进表再上线，不允许先在数据里写一个新值再回头补表。这条规则听起来死板，但它是这张表能活过一年的唯一前提。

平台替你翻译的那一版数据，跟你自己翻的差在哪？

它不是翻译层，它直接落成那个站点上的正式内容

多数平台都提供某种形式的自动翻译，帮你把商品信息铺到更多国家。

这件事跟搜索引擎在结果页替用户翻译一个页面不是一个量级。

那种翻译不改变你的原始页面，用户看到的是一层临时的转换。

平台的自动翻译不一样，它产出的文本会作为正式商品信息落在那个站点上，署的是你的名字，出问题也是你的客服在解释。

本站在平台搜索词字段那笔字节账里已经点过这一条，数据源这一侧的机制完全一样：账单还是寄给你。

还有一个容易被忽略的后果：这一版内容会成为那个市场用户对你品牌的第一印象，也会成为别人引用你的时候抄走的那一版。它不只影响这一次成交，它进入了公开语料。

自动翻译最容易在哪几类字段上出事

把出事概率按字段排一遍，顺序很稳定。

最容易出事的是品类词本身，因为它是整条数据里语义最集中、上下文最少的一处。

其次是规格里带单位的短语，机器经常把数字和单位之间的关系搞错。

第三是那些看着像英语其实是本地造词的说法，这一类翻过去会变成一个更普通的词，读起来还更顺。

最不容易出事的反而是长描述，因为上下文足够多。这个排序有点反直觉：字越少的字段越危险，而商品数据里最重要的那几个字段恰好都是短字段。

本站在讲品牌名进入非拉丁市场时记过一条同构的规律：你不定，市场会替你定。自动翻译是这条规律在数据层的版本，区别只是这次替你定的不是当地媒体，而是一个不解释理由的程序。

有一个可以量化的自查：把自动翻译产出的品类词导出来，跟你自己词表里的品类词做一次比对，看重合率。重合率低于一半，说明这个市场的商品在用一批你从没审过的词招揽用户。

关掉它要付什么代价

知道了风险，下一个问题是要不要关。

关掉的代价是覆盖面：那些你暂时不打算认真做的国家，会从有一份粗糙的信息变成什么都没有。

对处在试水阶段的市场，粗糙的信息确实好过没有。

所以这件事不该一刀切，该按市场分档。

主力市场自己翻，用自己的词表和审校；试水市场让它开着，但要把品类词那一列用自定义值锁住，别让它翻。锁住品类词这一个动作，就能挡掉这一类问题里的大半。

锁住品类词的具体做法多数平台都支持，通常是把该字段标为不翻译，或者提供一份术语表让它按表走。接入时问一句有没有这个功能，比事后逐条改要省事得多。

判据：什么时候该让它开着

给三条判据。

这个市场的月订单还没到两位数，让它开着。

这个市场已经有本地化页面和本地客服，就该自己翻，因为此时数据是全链路里唯一还没本地化的一环，留着它反而突兀。

介于两者之间的，折中做法是只自己翻标题和品类，其余交给自动翻译。机器翻译直接发上线那篇给过一条质量线，数据源这一侧可以整体沿用，只是要把判断单位从页面换成字段。

还有一个时点值得记：准备正式进入某个市场的前一个季度，就该把自动翻译关掉换成人工。因为搜索侧对内容变化的反应有滞后，等页面都做好了再换，前面那几个月的积累是按机翻那一版算的。

数据源里的标题在不同语言里，为什么装不下一样多的信息？

长度上限按字符算，而各语言的信息密度不一样

数据源的标题有长度上限，这个上限对所有语言是同一个数字。

但同样的信息在不同语言里占的字符数差得很远。

德语靠复合词把几个概念压进一个长词，字符数不省，词数省。

荷兰语和波兰语的修饰结构更长，同一句话经常多出两三成。

这条跟平台那个按字节计的搜索词字段是两回事，那边算的是字节，这边算的是字符，但结论方向一致：同一个额度在不同语言里兑换出的容量不一样。

有一个反直觉的地方：复合词语言的字符数未必更多，但它的可切分点更少。同样一百个字符，英语能装七八个可独立成词的成分，德语可能只有四五个，而检索侧认的是成分不是字符。

描述字段的上限宽松得多，所以有人会把塞不进标题的信息挪到描述里。这个做法在英语上有效，在形态丰富的语言上收益会打折，因为描述里的词形跟用户查询对不上的概率更高。

前几十个字符是唯一确定会被看到的部分

标题的显示长度和可填长度不是一回事。

购物结果卡片上显示的字数远少于上限，移动端更短。

同样的显示宽度下，各语言能显示的字符数还不一样。

所以标题的前几十个字符要能独立成立：品牌加品类放最前，这一条在所有语言下都成立。

复合词语言在这里额外吃亏，因为它可能在一个词的中间被切断，切出来的半截在那门语言里不是词。德语复合词那件事讲过这类词该怎么切，数据源标题是它最直接的应用场景之一。

把这条落成规则很简单：品牌加品类必须出现在前二十个字符内，属性和修饰词往后放。这条规则不分语言都成立，也不需要为每门语言单独讨论，是这一节里最容易执行的一条。

模板拼出来的标题在有些语言里不合语法

数据源标题多数是模板拼的，结构通常是品牌加品类加属性。

这个结构在英语和中文里读着自然，在别的语言里未必。

屈折语里名词和形容词要配合，直接把属性值原样拼进去会得到语法上不搭的组合。

有些语言的属性习惯放在名词后面，模板一律前置就会读着像机器写的。

处理办法不是给每门语言写一套复杂的形态逻辑，而是把模板的槽位顺序做成按语言可配的，再把属性值本身按主格形态准备好。这跟站上屈折语站的锚文本用的是同一条思路：能靠版面和字段解决的，别靠语法逻辑解决。

还有一种更省事的处理：在属性和名词之间加一个分隔符号，把拼接变成并列而不是修饰。这样语法上就不要求配合了，读起来像一张标签而不是一句话，在数据源标题这个位置是完全可以接受的。

一条能当天做完的截断实测

验证办法很土。

在目标国家的购物结果里搜自己的核心词，把自己商品的标题截屏。

看它在什么位置被截掉，截掉的位置前面有没有品牌和品类。

每门语言取五条商品，二十分钟能跑完一门语言。

顺手记下截断位置对应的字符数，这个数字比任何文档里的建议值都贴合你自己的品类。

实测的时候别只在电脑上看。购物结果在手机上的显示长度明显更短，而多数卖家写标题、看效果都在电脑上完成，于是所有人都在一个比真实情况宽松得多的环境里做判断。

谁在维护这份数据，语言这一列该挂在谁名下？

这份数据的所有权问题在语言这一列上最尖锐

商品数据的归属本来就模糊，语言这一列把模糊放大了一倍。

做数据管道的人管字段格式和上传，他不判断某个词在荷兰语里对不对。

本地化团队管译文质量，但他们多数不知道有这么一份文件存在。

投放团队管这份数据能不能跑起来，语言对不对不在他的验收项里。

三方都不觉得这是自己的事，而这件事恰好只需要一个人花两分钟去点开那个下拉框确认一次。

这件事还有一个组织上的怪象：它的成本落在自然那一侧，而这份数据的日常操作权在投放那一侧。成本和操作权不在同一个部门，是它长期无人认领的根本原因。

还有一个组织信号值得留意：如果这份数据是外部代理在维护，那么语言设置这一项几乎注定没人验过。代理的验收标准来自广告效果，而语言错了广告照样能跑，它不在任何一份对赌条款里。

语言这一列在投放部门那里不是一个字段

这句话值得展开。

投放部门看这份数据的视角是它能不能出广告、成本高不高、哪些商品被拒了。

在这个视角里，语言不是一个可调的变量，它是环境的一部分。

所以当自然那一侧出问题时，投放部门给出的诊断永远是数据没问题，因为按他的验收项确实没问题。

这跟本站讲过的另一类错位是同构的：一件事的收益和成本不结算在同一个部门，于是没有人有动机去改它。

所以问投放部门数据有没有问题，得到的答案永远是没问题，而这个回答是诚实的。要问出东西来，问题得换成：这份数据的语言设置是什么，是谁在什么时候选的。这个问法指向一个具体取值，答不上来本身就是答案。

三种归属方式各自的失败模式

见过三种分工，各有各的翻车方式。

全给投放的，失败模式是自然那一侧长期没人看，问题往往等到季度复盘才浮出来。

全给技术的，失败模式是格式永远合规、语言永远没人验，因为技术侧没有判断语言对错的能力。

全给本地化的，失败模式是他们改不动数据管道，提了需求排不上期。

比较可行的是拆：技术负责生成和上传，本地化负责属性取值表和标题模板的语言部分，投放负责诊断报告的日常处理，检索这一侧负责定规则和验收。四方各管一段，交接点写清楚。

四方分工里最容易漏的交接点是本地化到技术那一段。本地化产出的是一张表，技术要把这张表接进模板，这一步如果没有明确的接口约定，最后多半变成技术把表里的值手工抄一遍，抄完就再也不同步了。

最小可行的分工写法

如果只能写三句话，就写这三句。

每一份数据源的语言设置由谁在什么时候确认过，记在一张表里，新建数据源时必须填。

属性取值对照表由本地化团队维护，技术侧的模板从这张表取值，不允许写死。

诊断报告里出现的拒登，先按国家分组看是不是系统性问题，再往下逐条查。

三句话写进流程文档，比任何培训都管用，因为它们都是可执行的动作，不是原则。

这三句话建议直接写进新市场上线的检查清单，而不是单独放一份流程文档。单独的流程文档没人翻，上线清单每次都会被走一遍，规则挂在会被执行的地方才有意义。

那家小家电站后来改了四处

第一处：把三份数据源拆成六份

最先改的是份数。

原来三份对应三个国家，语言设置一份德语两份混着。

重新按语言与国家的组合数了一遍，实际需要六份。

拆的过程本身不复杂，麻烦的是要给每一份重新配一次抓取排期和通知人。

拆完当天就看到了变化：荷兰那一份第一次跑出了完整的诊断报告，之前它的问题一直被合并在德语那份里，看起来像是德语市场的零星错误。

拆的时候还顺手发现了一件事：原来那份混着的数据里，波兰市场的商品一直在跟德国市场的商品竞争同一批展示位。拆开之后两个市场的数据第一次能分开看，这是拆份数除了修语言之外的另一半价值。

第二处：属性取值对照表

第二件事是把颜色、尺寸类型、材质三列做成对照表。

三列加起来实际用到的取值是四十几个，三门语言横向展开一百多格。

本地写手一个下午填完，填的过程中顺手挑出了两个词：一个是原来页面上用的颜色说法在荷兰语里偏文学，另一个是材质词用的是英语原词而当地有通行译法。

这两处在页面上也一并改了，因为它们本来就该一致。

这张表现在挂在商品数据字段里，页面模板和数据管道都从它取值。

填表过程中还确认了一件本来有争议的事：材质那一列到底该用当地通行译法还是保留英语原词。做法是把两种写法各拿去搜一次，看当地电商站的商品标题用的是哪一种，用当地卖家的写法作准。

第三处：标题模板按语言重排前二十个字符

第三件事是标题。

原来三个市场共用一套模板，结构是品类加属性加品牌。

在购物结果卡片上实测，荷兰语和波兰语的标题在品牌出现之前就被截断了。

改成品牌加品类前置，属性往后放，一次改完三个市场。

这一处的改动量最小，效果却最直接，因为它改的是唯一确定会被用户看到的那一段。

改完之后团队顺手加了一条上线检查：新品上架后在目标国家的购物结果里搜一次，截图存档。这一条花不了两分钟，却把这类问题的发现周期从几个月压到了当天。

结果里那个没预料到的收益

三个月后回看，荷兰市场在自然购物结果里从零开始有了稳定露出。

预料之外的是德国市场也涨了一截，而德国那份数据源本来就是对的。

原因是属性取值对照表顺带修掉了德语那一列里几个不规范的颜色说法，那几个说法之前一直被当成自定义值处理，没进标准筛选面。

换句话说，为了修一个市场的系统性问题而建的那张表，顺手修掉了另外两个市场的零散问题。

这类收益不太好提前预估，但它出现的频率不低：把一件本来靠人各写各的事收进一个共享字段，通常会顺手暴露一批没人报过的老问题。

还有一个次要收益也值得记：拆分之后每个市场有了独立的诊断报告，团队第一次能说清哪个市场的数据健康度更差。之前所有市场的问题混在一份报告里，看起来永远是一个笼统的百分比。

把语言变成数据源流程里的一个字段

第一天上午：盘清现在有几份，各是什么语言

第一步是打开后台，把所有数据源列出来。

每一份记三样：语言设置、目标国家、落地页地址的语言前缀。

三样对不上的立刻标红，这一步通常十分钟就能出结果。

再按语言与国家的组合算一遍应该有几份，跟实际份数对比。

差额就是待建的份数，也是这次工作量的主要来源。

顺手记第四样：这份数据源是谁在什么时候创建的。这一列多半查得到，而它能直接告诉你有多少份是当年匆忙上线时建的、此后再没人碰过。那几份就是重点怀疑对象。

第一天下午：把属性取值对照表建起来

第二步是属性列。

先导出实际用到的取值，按列去重，通常每列不超过二十个。

再按语言横向展开，交给本地写手一次填完。

填完之后同步进商品数据字段，并且把模板改成从字段取值。

最后拿三个商品做端到端验证：页面上显示的取值和数据里提交的取值逐字对一遍。

端到端验证的时候要注意选样本：挑那些属性最多的商品，而不是随手挑三个。属性少的商品验不出问题，因为它根本没用到那几列有争议的取值。

第二天：标题模板、抓取排期与通知人

第二天做剩下的工程动作。

按语言实测标题截断位置，把品牌和品类挪到前面。

给每一份新建的数据源配抓取排期，排期时间错开，别让它们挤在同一个小时。

给每一份配一个明确的通知接收人，而不是发到一个没人看的共享邮箱。

最后把新建数据源的检查清单写进流程文档，重点是那个语言下拉框必须有人确认并签字。

抓取排期错开还有一个实际理由：多份数据同时抓取会在同一时刻给你的服务器带来一个尖峰，而这个尖峰恰好可能触发限流，导致其中几份抓取失败。错开半小时就能避掉。

上线前的五项检查与两条反信号

发布前照着五条走：每一份数据源的语言设置与落地页语言一致、属性取值在页面和数据里逐字相同、标题在移动端购物卡片上截断前包含品牌和品类、自动翻译在主力市场已关闭而在试水市场已锁住品类词、每一份都有独立的诊断报告接收人。

两条反信号也要说清楚。

如果你只做一个国家一门语言，整件事不成立，不必建对照表也不必拆份数。

如果你的商品数量在两位数，且全部靠人工维护，那么把这套流程建起来的成本会高于收益，直接人工逐条核对更快。

判断顺序是先数一遍语言与国家的组合数，组合数超过三，这件事才值得按流程做。

还有一条值得在检查表之外单记：把这次盘出来的份数和语言对应关系存成一份文档，下次新增市场时先看它。这类知识流失得特别快，因为它既不算技术文档也不算内容规范，没有天然的归属地。

投入也可以分三档。最低一档只做份数拆分和语言设置校正，半天能完；中间一档加上属性取值对照表和标题模板重排，两天；最高一档把校验脚本挂进每日流水线并按语言出独立报表，一周。多数站做到中间一档就够。

常见问题解答

做多语言站，购物数据源到底要建几份？

按语言与目标国家的组合数算，不是按语言数加国家数。一份数据源锁定一个组合，语言是整份文件级的设置，不是数据行上的字段。德语卖去德国、奥地利、瑞士是三份，再加荷兰语卖去荷兰和比利时是两份，一共五份。同一门语言卖去三个国家仍然是三份，因为价格、税率和可售范围写在数据行里，文件本身就不一样。

页面已经做了各语言版本互相指认的标记，数据源那边还要管语言吗？

要，而且这两套声明互不知情。页面那一侧至少有三处语言声明，数据源那一侧只有后台那个下拉框，参与商品匹配的是后者。你可以把一份声明为德语的数据指向一批荷兰语落地页，系统全程不提示，抓取会成功、商品会入库、诊断报告可能一片绿，只是匹配质量悄悄变差。整条链上没有任何一个环节负责发现这件事。

属性值可不可以统一填英语，反正是给机器看的？

不可以。平台按语言维护自己的属性取值表，提交的值要落进目标语言那张表里才会被正确归类。填英语值到一份非英语数据源里，最好的结果是被当成自定义值放行，最坏的结果是这条商品在筛选面里消失。颜色这一列还额外要求用标准色名而不是自造的营销名，两条要求叠起来，这一列必须逐语言维护。

拒登理由写着落地页与数据不符，该从哪儿查起？

先按国家分组，看是不是集中在某一个市场。集中的话先去看那份数据源的语言设置，两分钟能确认。确认没问题再往下查价格、库存、图片这些逐条差异。这个顺序跟多数人的习惯相反，道理是语言设置错了属于整份文件的系统性问题，一次能解释掉成千上万条，而价格库存是逐条问题。先查能一次解释掉全部的那类。

平台的自动翻译要不要关掉？

按市场分档，别一刀切。月订单还没到两位数的试水市场让它开着，粗糙的信息好过没有，但要把品类词那一列用自定义值锁住不让它翻。已经有本地化页面和本地客服的市场就该自己翻，此时数据是全链路里唯一还没本地化的一环。介于两者之间的，只自己翻标题和品类，其余交给它。

数据源的标题长度上限对所有语言一样，怎么公平？

它不公平，但这一条改不了，只能在结构上补。同样的信息在德语里靠复合词压缩，在荷兰语和波兰语里往往多出两三成。真正要保的是前几十个字符，因为购物卡片上显示的字数远少于上限，移动端更短。把品牌和品类放最前，属性往后，然后在目标国家的购物结果里实测截断位置，每门语言取五条商品，二十分钟能跑完。

这件事该归投放、技术还是本地化？

拆开归。技术负责生成和上传，本地化负责属性取值对照表和标题模板的语言部分，投放负责诊断报告的日常处理，检索这一侧负责定规则和验收。全给投放的失败模式是自然那一侧长期没人看；全给技术的失败模式是格式永远合规、语言永远没人验；全给本地化的失败模式是他们改不动数据管道。关键是新建数据源时那个语言下拉框必须有人确认并留痕。

权威参考资料