尺码那一栏的数字不归译者管,可整条流水线上没有一个人负责做那道算术
本文目录
- 尺码那一栏错了,为什么译审、母语审校和上线检查三道关全都放行?
- 一家做宠物出行装备的站,德国那边的退货率高出一截
- 母语审校把那一页从头看到尾,一个字都没改
- 出错的是一个没有主人的动作
- 这一类值跟关键词表里其他所有词的分界线
- 为什么这类错误永远在售后才暴露
- 这一类值到底有几种,怎么从词表里把它们挑出来?
- 先按品类清点一遍,数量比想象中多
- 第一条判据:概念不变,值随市场变
- 第二条判据:错了能用尺子量出来
- 怎么把这些字段从站里捞出来
- 宠物出行这条线上具体有哪几格
- 两把尺子的刻度差1.8毫米,那张换算表还对得上吗?
- 先把两把尺子的定义摆出来
- 把220到300毫米的脚长逐档算一遍
- 取整误差有多大:最大偏差1.87毫米
- 两套刻度要走多远才重合一次
- 所以不同来源的对照表互相打架是正常的
- 标准数据库里到底替你规定了什么,又漏掉了什么?
- 先看那份被所有系统读取的单位偏好数据
- 身高这一格不是两派,是三派
- 华氏温度只剩六个地区,而其中一个不是美国
- 瑞典人有一个属于自己的长度单位
- 同一个盎司,两个说英语的市场差4.08%
- 这份数据里没有的那一格,恰好是最贵的一格
- 商品字段只认十一种码制,剩下那些市场的码填哪儿?
- 先数一遍平台到底给了几个取值
- 同一页官方文档上,同一个概念摆着两套代码
- 字段填错之后,损失落在哪一侧
- 没有对应取值的市场,实际该怎么填
- 用结构化数据把三列都写出来
- 用户在搜换算的时候,打出来的到底是什么?
- 这类查询的形状跟普通关键词完全不同
- 各语言的问法不是同一个结构
- 数字的写法本身就是一个变量
- 用站内搜索日志反推真实问法
- 把答案前置,因为这类查询要的是一个数
- 这些数值该摆在页面的哪几个位置,才既被人看见也被机器读到?
- 尺码表不能只做成一张图
- 正文里要有一句人话版的换算
- 筛选器里不要放换算,要放分档
- 常见问题区放一条换算问答,位置很关键
- 详情图、包装图和视频里的数值要单独立一份清单
- 一套两天能跑完的数值清点流程
- 第一天上午:把带单位的字段全捞出来
- 第一天下午:给每一行标出源单位和目标单位
- 第二天上午:算一遍,并且留下算式
- 第二天下午:把三处出口一次性对齐
- 把这套流程接进新品上线的固定动作
- 三种看起来很合理、实际在帮倒忙的做法
- 只给本地码不给厘米
- 用脚本在浏览器里动态换算
- 全站统一成一套码制
- 顺带说一句四舍五入的方向
- 这套东西该由谁维护
- 哪些相邻的问题不归这一层管
- 汇率和价格不是同一类账
- 版式和字号是另一条腿
- 物流限重和关税门槛属于合规侧
- 用户测量方式的差异也不在这一层
- 这一层跟词表那一层的分工
- 常见问题解答
- 尺码换算这件事,交给母语审校去把关行不行?
- 页面上只给本地码,不给厘米,是不是更本地化?
- 欧码和英码的对照表,网上好几个版本对不上,该信哪个?
- 商品数据里的尺码制式字段,遇到没有对应取值的市场怎么办?
- 换算类的长尾词工具里查不到量,还值得做吗?
- 做一个单位切换的小工具,是不是比写死两套数值更好?
- 温度、容量这些单位,有没有现成的标准可以直接抄?
- 权威参考资料
摘要:关键词表里有一类值不是翻出来的,是算出来的。保哥把欧码和英码的刻度实算了一遍:一档差1.8毫米,两把尺子要走127档才重合一次,所以任何一张对照表每一行都四舍五入过,最大偏差接近半个码。而整条本地化流水线上,没有一个岗位负责做这道算术。
尺码那一栏错了,为什么译审、母语审校和上线检查三道关全都放行?
一家做宠物出行装备的站,德国那边的退货率高出一截
有个客户做宠物出行,主力是航空箱、背包式宠物包、车载安全座和牵引装备。
荷兰站跑了一年多,数据稳,团队顺势把内容铺到德国和波兰。
翻译走的是正规流程,母语译者加母语审校,交付前还过了一遍术语表。
上线四个月,德国站的自然流量涨得不难看,转化率也说得过去,唯独退货率比荷兰站高出将近一半。
客服那边的退货理由写得很整齐:尺寸不合适。
团队第一反应是选品问题,讨论了两周要不要砍掉几个SKU。真正的原因躺在商品页上一张表里,那张表所有的字都翻译得毫无破绽,只有里面的数字是错的。
母语审校把那一页从头看到尾,一个字都没改
保哥后来看那份审校记录,审校确实是认真做的。
他改了品类词,改了两处语序,把一句被动式改成主动式,还在术语表上补了一条备注。
那张尺寸表他也看了,表头改得很地道,行标签也对。
问题是审校的职责范围写得清清楚楚:语言准确、表达自然、术语一致。
数字不在这三条里的任何一条。
更麻烦的是,数字看上去也没有任何异常。一个宠物包写着长45、宽28、高25,单位是厘米,德语里这几个词写得完全正确,唯一的毛病是这组数字是从英寸那一版四舍五入回来的,每一维都短了一点点。
出错的是一个没有主人的动作
把这条链路拆开看,会发现一个很尴尬的空隙。
产品团队给的是英制原始数据,因为供应商在美国。
翻译团队拿到的是已经成型的页面文案,他们的工作是把词换成德语,数字原样保留。
前端把文案填进模板,模板不做单位判断,它只负责渲染。
本地化项目经理验收的是交付文件的完整性和交期,不验算数。
于是从供应商那张英制规格表,到德国用户面前那张厘米表,中间需要一次换算,而这次换算不在任何一个人的工作说明里。它最后是被某个赶工的运营用计算器手动敲了一遍,敲的时候把17.7英寸记成了17.5。
这一类值跟关键词表里其他所有词的分界线
本站写过很多种词的麻烦。
有的词是范畴对不齐,比如颜色在不同语言里的切分位置不一样。
有的词是取值由别人定死,比如那个每月几万次搜索却印在别人商标证上的品类词。
有的词是社群还在投票,比如新借词的语法性别。
这几类的共同点是,它们都还是词,都能用查、问、验这三个动作解决,都能在词典、法条或语料里找到依据。
尺码这一类不一样。它的正确答案不在任何一本词典里,因为它根本不是一个词的问题,是一道算术题。你把德语词翻得再地道,那个数字该错还是错。
为什么这类错误永远在售后才暴露
语言层的大部分错误会在流量侧留下痕迹。
词选错了,排名上不去;写法不地道,跳出率高;页面语言标错了,收录出问题。
这些都有报表能看。
数值错了不影响任何一条流量曲线。
页面照样收录,关键词照样匹配,用户照样点进来,甚至照样下单,因为下单的时候他相信那张表。
错误在包裹拆开的那一刻才生效,而那个时刻距离页面上线通常隔着两三个月,隔着客服、仓库和财务三个部门。等它绕回到做内容的人手里,已经变成了一句退货率偏高,谁也想不到要去查一张尺寸表。
这一类值到底有几种,怎么从词表里把它们挑出来?
先按品类清点一遍,数量比想象中多
服装尺码是最显眼的一个,但它只是其中一格。
鞋码是第二个,而且它的刻度体系跟服装完全无关,是另一套独立的账。
戒指圈号是第三个,三大市场用的是三个不同的自变量:日本用号,欧洲直接用内周长毫米,美国用一套自己的编号。
床上用品是第四个,因为床的尺寸本身按市场分档。
纸张、画框、相框是第五个,A4和Letter差着3.28%的面积,装裱和打印类的商品全部受影响。
再往下还有温度、容量、重量分档、功率、承重、绳长、口径。保哥的经验是,一个中等规模的独立站清点下来,这类字段通常有二十到四十个,散在属性表、规格段、筛选器和详情图里。
第一条判据:概念不变,值随市场变
判断一个字段属不属于这一类,第一条问句很简单。
换一个市场,这个字段说的还是同一件事吗?
如果是,而它的取值必须跟着变,那它就属于这一类。
宠物包的长度在德国和美国说的是同一段距离,但一个写45一个写17.7。
颜色不属于这一类,因为换个市场之后,蓝这个概念本身的边界就变了,那是范畴问题不是换算问题。
品类词也不属于这一类,因为它换的是名字不是数。这条判据能把八成的字段一次分完,剩下的两成才需要人来想。
第二条判据:错了能用尺子量出来
第二条判据保哥更喜欢,因为它是可操作的。
把这个字段的值填错,用户能不能拿一把物理的尺子、秤或者温度计证明你错了?
能,它就是这一类。
这条判据的价值在于它同时划出了后果的性质。
别的语言层错误的后果是概率性的,是排名低几位、转化差几个点、母语者觉得别扭。
这一类的后果是确定性的:东西寄到了,不能用,退回来。它不参与概率,它只参与算术。
怎么把这些字段从站里捞出来
最快的入口是筛选器。
凡是筛选器里能按数值区间筛的,背后一定有一个这类字段。
第二个入口是商品数据源,也就是喂给购物平台的那份文件。
那份文件里带单位的字段都是候选,尺寸、重量、容量、材质克重全在里面。
第三个入口是详情图,这一处最容易漏,因为图里的数值不参与任何自动检查。
第四个入口是客服的退货理由分类表。这一处的好处是它按后果排序,哪个字段错得最贵,一目了然。
宠物出行这条线上具体有哪几格
回到那个客户。
清点下来他们有四组值需要换算,而不是团队原先以为的一组。
第一组是箱包的三维尺寸,供应商给英寸,欧洲市场要厘米。
第二组是承重和宠物体重分档,供应商给磅,欧洲要公斤,日本还要按不同的分档习惯重新切。
第三组是航空箱能不能带上飞机,这一格最要命,因为各家航司的限制是按厘米还是按英寸写的都不一样,而用户搜的正是这件事。
第四组是牵引绳的长度,这一格看着最简单,却是全站唯一一个用户会拿卷尺当场验的字段。
两把尺子的刻度差1.8毫米,那张换算表还对得上吗?
先把两把尺子的定义摆出来
欧陆鞋码用的单位叫巴黎点,一码等于三分之二厘米。
算出来是6.6667毫米。
英国鞋码用的单位是大麦粒,一码等于三分之一英寸。
算出来是8.4667毫米。
两者的比值正好是1.27,也就是25.4除以20,这不是巧合,是因为一个来自公制一个来自英制。
日本码、中国新鞋号和韩国码用的是第三套,叫蒙多点,它直接标脚长毫米,一档5毫米。这三套里只有第三套的数值本身有物理意义,前两套标的都是楦长,而楦长比脚长多出一段放余,各家还不一样。
把220到300毫米的脚长逐档算一遍
保哥用业界常用的15毫米放余,把脚长从220毫米到300毫米每5毫米一档算了一遍。
脚长250毫米时,欧码的精确值是39.75,英码是6.30,美码男是7.30,日本码是25.0。
脚长265毫米时,欧码正好落在42.00,英码是8.07。
脚长285毫米时,欧码正好落在45.00,英码是10.43。
注意欧码这一列:它只在少数几个脚长上落到整数,其余全是带小数的。
这说明一件事,你在鞋盒上看到的那个整数码,本身就已经是取整的结果,而不同品牌取整的方向还不一致。
取整误差有多大:最大偏差1.87毫米
反过来算更能说明问题。
把欧码从35到48每一档回算成楦长,再换成英码,看四舍五入到半码之后差了多少。
欧码40的精确英码是6.50,正好落在半码上,误差只有0.03毫米。
欧码41的精确英码是7.28,取整到7.5,脚长上多出1.83毫米。
欧码46的精确英码是11.22,取整到11.0,脚长上少了1.87毫米。
整个范围内最大偏差是1.87毫米,而一个英码半档本身才4.23毫米。也就是说对照表里最坏的那几行,误差已经吃掉了将近半个档位,这不是哪张表做得糙,是两把尺子的刻度决定的。
两套刻度要走多远才重合一次
还有一个更彻底的算法。
欧码一档6.6667毫米,英码一档8.4667毫米,两个数什么时候能同时落在整档上?
保哥让脚本从1档往上跑,一直跑到127。
欧码走127档,累计846.67毫米,正好等于英码走100档,残差是0.000毫米。
127档是什么概念?欧码一档6.67毫米,127档是84.7厘米,比一整条腿还长。
换句话说,在人类脚长这个区间里,这两把尺子一次都对不齐。任何一张欧码换英码的表,每一行都必然是近似值,区别只在于是谁替你做的四舍五入。
所以不同来源的对照表互相打架是正常的
这条结论有个很实用的推论。
你去搜同一组码的对照关系,品牌官网、鞋类媒体、维基条目给出的表经常对不上,差半档很常见。
过去团队遇到这种情况的处理办法通常是找一个看起来最权威的抄下来。
这个办法在这里不成立,因为不存在一张正确的表。
正确的做法是把厘米补上去,让用户绕过所有码制直接量脚。
蒙多点体系之所以在专业运动鞋和军靴上通行,就是因为它是唯一自洽的那一套。页面上给出厘米,等于给用户一把不需要翻译也不需要换算的尺子,而这句话正好也是这一整篇的解法。
标准数据库里到底替你规定了什么,又漏掉了什么?
先看那份被所有系统读取的单位偏好数据
做本地化的技术栈底下有一份公共数据,叫CLDR,各家操作系统、浏览器和开发框架的区域格式都从这里取。
它里面有一块专门规定各地区该用哪套单位,叫单位偏好数据。
保哥把这份文件拉下来数了一遍,46175字节,41个区块,覆盖15个量纲。
长度、面积、速度、体积、质量、温度、压强、功率、能量、浓度这些都在。
每个量纲下面还按用途细分,比如长度就分成默认、身高、道路、降雨、降雪、车辆、焦距这七种用途。
这份数据的存在意味着一件事:你以为需要自己判断的很多单位问题,标准里已经写好了答案,只是没人告诉你去哪儿看。
身高这一格不是两派,是三派
最能说明问题的是身高那一格。
直觉里这件事只有两种答案:公制的用厘米,英制的用英尺英寸。
数据里写的是三种。
用英尺加英寸的是加拿大、英国、印度、美国。
用米加厘米的是奥地利、比利时、阿尔及利亚、埃及、西班牙、法国、香港、印尼、以色列、约旦、马来西亚、沙特、瑞典、土耳其、越南。
剩下所有地区走世界默认值,用纯厘米。也就是说同样是公制市场,一个人的身高在法国要写成1米78,在德国要写成178厘米,这两种写法在各自市场里都是唯一自然的那一种,而任何一个把公制当成一格的模板都会在其中一边写出怪话。
华氏温度只剩六个地区,而其中一个不是美国
天气温度那一格更干脆。
用华氏的地区一共六个:巴哈马、伯利兹、开曼群岛、波多黎各、帕劳、美国。
其余全世界走摄氏。
这个清单值得贴在墙上,因为它把一个模糊印象变成了一份名单。
做产品页的时候,涉及温度的字段该按什么条件切换,看这六个代码就够了,不需要再讨论。
顺带一提,人体体温和天气温度在这份数据里是分开的两个用途,同一个地区在两件事上可以用不同单位,这一层细分连很多做本地化的工程师都没注意到。
瑞典人有一个属于自己的长度单位
道路距离那一格藏着一个彩蛋。
世界默认是公里和米,美国是英里和英尺,英国是英里和码。
瑞典单独一行,用的是公里、米,外加一个叫斯堪的纳维亚里的单位。
这个单位等于10公里,是瑞典人日常说距离时真会用的那个词。
标准数据库肯把一个只有一国在用的单位收进去,说明它确实高频到不能忽略。
本站写瑞典挪威丹麦三国资产共用边界那一篇的时候,把商品图和尺寸表列成了少数能整块共用的资产,这个彩蛋正好是那条结论的边界:数值参数确实能共用,前提是三国都在公制圈里,一旦有一国的日常表达自带一套刻度,共用就到头了。
同一个盎司,两个说英语的市场差4.08%
容量那一格是最容易吃亏的。
数据里美国和英国是分开写的,美国用杯、液体盎司、加仑、品脱、夸脱,英国用的是英制液体盎司和英制加仑。
标准之所以把它们写成两个不同的单位,是因为它们真的不是一个数。
美制液体盎司是29.5735毫升,英制是28.4131毫升,相差1.16毫升,也就是4.08%。这两个数不是民间总结,英国的法定计量规定里对哪些场合必须用公制写得很细。
16盎司的差距是18.6毫升,32盎司差37.1毫升。
更狠的是品脱:美制一品脱16盎司等于473.2毫升,英制一品脱20盎司等于568.3毫升,两者差20.1%。宠物饮水器、洗护补充装、旅行分装瓶这几类商品,标错一个字母就是五分之一的容量差,而两边页面上写的都是英语。
这份数据里没有的那一格,恰好是最贵的一格
说完有什么,说没有什么。
15个量纲里没有服装尺码,没有鞋码,没有戒指圈号。
原因也不难理解:这几样不是物理量纲,是编号体系,它们背后虽然挂着长度,但取值是人为约定的档位而不是连续的数。
后果是,你的技术栈在长度、重量、温度上都能自动适配,唯独在尺码上什么也帮不了你。
这就解释了一个很多人纳闷的现象:为什么框架能自动把公里换成英里,却不能把欧码换成美码。
不是它不想,是标准里根本没有这一格。这也是为什么这件事必须由做内容的人来管,因为技术栈默认它不存在。
商品字段只认十一种码制,剩下那些市场的码填哪儿?
先数一遍平台到底给了几个取值
喂给购物平台的商品数据里有一个字段专门标尺码制式。
保哥把官方文档翻出来数了一遍,支持的取值是11个:澳大利亚、巴西、中国、德国、欧盟、法国、意大利、日本、墨西哥、英国、美国。
这11个值决定了全世界的尺码只能落进这几个桶。
韩国不在里面,俄罗斯不在里面,印度不在里面,土耳其不在里面,波兰不在里面。
这些市场当然有自己的码制,韩国用毫米,俄罗斯的鞋码历史上就是自成一套。
它们在这个字段里没有对应的取值,于是只能被塞进欧盟或者美国那一格。这一步塞进去的偏差,后面所有的筛选、比价和推荐都会照单继承。
同一页官方文档上,同一个概念摆着两套代码
更有意思的是同一页文档的下半部分。
那一页除了给出数据源用的取值,还顺带说明了结构化数据里对应的属性该怎么填。
结构化数据那边的取值有12个,跟上面那11个只是看着像。
数据源里写欧盟用的是EU,结构化数据里对应的名字是Europe,另外还多一个Continental。
数据源里的墨西哥写作MEX,结构化数据里写作MX。
这两套代码印在同一页官方文档上,中间隔着不到一屏。你要是在两处填了同一个字符串,其中一处必错,而这件事没有任何工具会提醒你,因为两边各自都是合法的。
字段填错之后,损失落在哪一侧
这类偏差不会让商品下架,所以很容易被当成小事。
它的代价在别处。
第一处是购物结果里的尺码筛选,用户按本地码筛,你的商品按别的码入库,直接被筛掉。
第二处是同类商品的横向对比,平台会把同尺码的商品摆在一起,制式标错等于被摆到了错误的邻居中间。
第三处是本地码制的搜索词,用户搜的那个数字你页面上根本没有。
这三处的共同点还是老样子:全都不在任何一条曲线上,损失是缺席型的,缺席型损失的特点是没人会为它开会。
没有对应取值的市场,实际该怎么填
保哥给客户的处理办法是三段式。
制式字段填一个离本地最近的合法值,通常是欧盟或者美国,这一步是为了让数据能跑起来。
尺码字段本身写本地用户认得的那个写法,能带单位就带单位。
正文和结构化数据里补一张完整的对照,把本地码、欧码和厘米三列都写成可抓取的文本。
这三步的分工很清楚:第一步喂机器,第二步喂用户,第三步喂检索。
本站讲商品数据源里的语言字段那一篇提过一个组织上的怪象,数据的操作权在投放那一侧而成本落在自然这一侧。尺码制式这一格是同一个坑的孪生条,区别只在于它错了连投放那一侧都察觉不到,因为广告照样能跑。
用结构化数据把三列都写出来
结构化数据里有一个专门描述尺码的类型,可以同时容纳制式、尺码组和具体尺码,还能挂上对应的身体测量值。
用它把三列信息一次性写全,是这件事上性价比最高的一个动作。
写全之后的好处不只是给引擎看。
它逼着团队回答一个平时糊弄过去的问题:你这件商品的42码,究竟对应多少厘米。
保哥见过不止一个客户,是在填这个字段的时候才发现自己压根不知道答案,因为供应商给的规格表里只有码,没有量。
问回去往往还要等两周,而这两周暴露的正是问题的真身:整条链路上没有一处存过那个物理长度。
用户在搜换算的时候,打出来的到底是什么?
这类查询的形状跟普通关键词完全不同
普通关键词是名词或者名词短语。
换算类查询是一个算式,里面必然有数字。
典型形状是数字加单位加疑问词,比如42码是多少厘米。
这个形状带来两个后果。
第一,它的组合数量极大,一个品类几十个码值乘以几套制式,长尾一下子铺开好几百条。
第二,关键词工具几乎不返回它们的量,因为工具会把带数字的查询打散或者归并,最后每一条的量都低到显示为零。本站讲关键词工具返回零那一篇说过,那个零是数据缺口不是需求缺口,这一类词是那句话最典型的样本。
各语言的问法不是同一个结构
英语里这类问句短得像公式。
德语用户的问法通常把单位写在前面,还会把两个单位用一个介词连起来,整句是一个完整的从句。
波兰语的问法常以疑问词开头,后面接一个变了格的单位词,而那个格的形态跟词典里的原形对不上,这一点跟本站写过的一个名词接出十八种格那几篇是同一条老账。
日语的问法把单位放在句尾,前面用助词连接,用户经常连品类词都不打,直接搜数字加单位。
这几种结构差异意味着,你不能把英语那条模板直译成八门语言就当覆盖完了。
正确的做法是找本地人写五条,然后从站内搜索日志和自动补全里补齐剩下的形状。
数字的写法本身就是一个变量
还有一层容易漏。
同一个数在不同市场的写法不一样,小数点可能是逗号,千位分隔可能是空格或者点。
用户搜27,5和搜27.5是两个字符串。
如果你的站内搜索按字符串精确匹配,其中一种写法会直接返回空结果。
页面文本也一样,你写27.5而当地人写27,5,匹配就少一次。
稳妥的做法是页面正文用本地写法,同时在结构化数据里用国际格式,本站讲结构化数据那一篇正好把这条规则完整写过:正文越本地越好,标记里反着写回国际格式。
用站内搜索日志反推真实问法
这一类词的量在外部工具里查不到,但在你自己的日志里躺得整整齐齐。
做法是把站内搜索关键词导出来,筛出含数字的那一批。
然后按单位词分组,看用户最常用哪几个单位问。
保哥给那个宠物出行客户跑过一遍,德国站含数字的站内搜索里,超过一半带的是厘米,剩下的大头是公斤。
而他们商品页上最显眼的那组数字当时给的是英寸。
这一步不需要任何工具,导出、筛选、分组,一个下午做完,得到的却是这门语言里用户真正在用的那把尺子。
把答案前置,因为这类查询要的是一个数
换算类查询的意图非常单纯:要一个数。
用户不想读方法论,不想看品牌故事,他要的是一个能马上抄走的数字。
所以这类内容的写法跟品类页正相反:第一句就给答案,第二句给对照表,第三句才解释误差。
这也是这类页面在生成式检索里容易被引用的原因,答案短、结构清楚、能验证。
反过来,那些把答案埋在第五段的换算文章,在这一轮几乎没有存在感。
顺便说一句,这类页面最忌讳的就是把换算做成需要点击的小工具而正文里一个数都不写,那等于把自己的答案藏进了一个抓取不到的抽屉。
这些数值该摆在页面的哪几个位置,才既被人看见也被机器读到?
尺码表不能只做成一张图
这是最常见也最贵的一个错。
设计师做一张漂亮的尺码图,前端当作商品图挂上去,收工。
图里的数值对检索来说等于不存在。
本站算过图上烧进去那行字的账,那一篇讲的是复用面被砍掉多少,这里的损失换了一种形态:不是复用不了,是根本查不到。
更麻烦的是这类图往往还带着从总部继承来的英制数值,改一次要重新出图,于是它成了全站更新最不及时的一块内容。
正确做法是表格用文本渲染,图只做示意。真要留图,图里的每个数在下方的表格里必须原样再出现一次。
正文里要有一句人话版的换算
表格是给要查数的人看的。
正文里那一句是给刚好在读段落的人看的,也是给抽取段落的机器看的。
写法很简单:这款宠物包的长边是45厘米,约合17.7英寸。
一句话里同时出现两个单位和两个数值,抽取的时候不需要任何上下文就能成立。
本站讲句子边界与段落抽取那一篇说过,检索的最小单位已经降到一句话,这一句正好是为那个粒度写的。
顺带的好处是,这一句在翻译成八门语言之后依然自洽,因为两个数都在句子里,译者删不掉也改不错。
筛选器里不要放换算,要放分档
有团队喜欢在筛选器里做单位切换,觉得体验好。
实际效果通常相反。
筛选器的取值要进URL、进面包屑、进内链锚文本,一旦带上可切换的单位,同一个商品集合会分裂出两套地址。
更稳的做法是筛选器固定用本地主流单位分档,把切换留给商品页上的对照表。
道理很简单:筛选器承担的是集合划分,不承担信息呈现,这两件事一旦混在一起,受害的一定是地址结构。
如果确实要给两套单位,让它作为页面上的一个视图状态,别让它进地址。
常见问题区放一条换算问答,位置很关键
换算类查询的答案很短,正好适合放进常见问题区。
放的时候有两个讲究。
第一,问句要按本地用户的实际问法写,别用英文模板直译。
第二,答案的第一句必须是那个数,解释放在第二句以后。
这一条同时服务两类读者:一类是拉到底部找答案的用户,一类是抽取问答对的机器。
本站讲小语种问答长尾那一篇算过一笔账,这类问题搜的人不多,但整个语种里认真写完整答案的更少,所以它的性价比不看绝对量,看的是竞争密度。
详情图、包装图和视频里的数值要单独立一份清单
页面上还有几处数值是内容团队管不到的。
供应商给的详情图里通常印着一套数值。
包装实物上印着另一套。
视频里口播的可能是第三套。
这三处的共同点是改起来贵、更新慢、没人巡检。
保哥的处理办法是给它们单列一份清单,标明每一处的数值来源和最后更新时间,上线前对一遍。这三处里包装最特殊:页面能改、视频能重录,盒子印出来就跟着商品进了用户家里,上面那个数字是用户唯一能拿在手上反复看的版本。
一套两天能跑完的数值清点流程
第一天上午:把带单位的字段全捞出来
从商品数据源开始,因为那份文件字段最整齐。
把所有带单位的字段列成一张表,记下单位和取值范围。
再去筛选器抄一遍,补上数据源里没有的。
然后打开三个不同品类的商品页,人工数一遍页面上出现的所有数字。
人工这一步不能省,因为详情图和正文里的数值不在任何结构化的地方。
半天时间通常能得到二十到四十行,这张表就是后面所有工作的底稿。
第一天下午:给每一行标出源单位和目标单位
每一行填三列。
第一列是这个值最初是谁给的,供应商、工厂还是测量得来。
第二列是原始单位。
第三列是每个目标市场该用的单位,这一列直接抄标准数据库里的规定,不要现场讨论。
填完之后会自动浮出两类问题行:一类是原始单位是英制而所有目标市场都是公制,这类必须换算;另一类是原始值本身就没有单位,只有一个码,这类要回头问供应商要物理测量值。
第二类通常比第一类更多,也更难办。
第二天上午:算一遍,并且留下算式
换算这一步本身不难,难的是留痕。
保哥要求客户把换算写成表格里的公式而不是手敲的数字。
原因很实际:手敲的数字没人能复核,公式能。
四舍五入的位数要统一约定,尺寸留一位小数,重量留两位,容量取整。
约定完写进文档,因为下一批商品还要用。
这一步做完,那个把17.7敲成17.5的事故就再也发生不了了,不是因为人变仔细了,是因为人不再负责敲数字。
第二天下午:把三处出口一次性对齐
数值算完之后有三个出口。
页面正文和表格是一个,结构化数据是第二个,商品数据源是第三个。
这三处必须由同一个字段派生,不能各填各的。
做不到自动派生的,至少要在上线检查表里加一行,要求三处逐个比对。
这一条听起来像常识,实际上保哥见过的站里能做到三处一致的不到一半。
最常见的走样是数据源更新了而页面没更新,因为改数据源的人和改页面的人不是同一批。
把这套流程接进新品上线的固定动作
清点一次的价值是有限的,它只解决存量。
真正省事的是把它接进新品流程。
做法是在商品资料模板里加两列:物理测量值和原始单位。
这两列填不满,商品不许进入翻译环节。
这个卡点看着强硬,实际推行阻力很小,因为供应商本来就有这些数据,只是从来没人问他要。
本站讲写死在代码里的界面文案那一篇说过一句话,凡是靠一次性改造达成的状态都需要一道回归动作来维持,数值这件事同样如此,区别是它的回归动作可以做成一个必填项,成本几乎为零。
三种看起来很合理、实际在帮倒忙的做法
只给本地码不给厘米
第一种是本地化做得太彻底。
团队认为既然是德国站就应该只出现德国用户熟悉的码,于是把厘米那一列删掉了。
问题是德国用户在网上买鞋的时候,恰恰最需要那一列,因为不同品牌的同一个码差得离谱。
删掉之后,用户唯一的验证手段没了,退货率必然上去。
本地化的目标是让用户不用翻译就能读懂,不是让他失去参照物。
厘米那一列在任何市场都不算冗余,它是这一整套体系里唯一不需要信任任何人的那一列。
用脚本在浏览器里动态换算
第二种是技术上的过度优化。
做一个单位切换开关,用户点一下所有数值就变成另一套。
体验确实好,代价是那些数值全部由脚本在客户端生成。
抓取的时候页面上可能只有一套值,另一套完全不存在。
用户搜的偏偏是不存在的那一套。
稳妥的做法是两套值都写进初始的页面文本,切换只控制显示与否,别控制存在与否。这是老生常谈了,但它在这类页面上重犯的频率高得惊人,因为换算天然让人想到用脚本算。
全站统一成一套码制
第三种是管理上的图省事。
为了避免混乱,团队决定全站只用欧码,所有市场一视同仁。
这个决定在后台确实清爽,在前台是灾难。
日本用户搜的是厘米数,英国用户搜的是英码数字,你的页面上一个都没有。
更微妙的是,统一之后所有市场的数据看起来都正常,因为没有对照就没有落差。
本站讲一个模板生成十种语言那一篇讲过同一个结构:字符层看不出问题,信息层已经塌了一半。码制统一属于同一类症状,它统一掉的不是格式,是用户的搜索入口。
顺带说一句四舍五入的方向
还有一个小到没人讨论、但值得定死的细节。
换算之后的取整方向要按语义定,不能一律四舍五入。
容器容量往小了取,因为标大了会溢。
承重往小了取,因为标大了会断。
箱包内部空间往小了取,外部尺寸往大了取,因为用户量的是能不能塞进后备箱。
这几条写进换算约定,一共不到五行,能挡掉一整类售后纠纷。
单位符号的写法也有讲究,这一层直接抄国际单位制手册就行。符号和数字之间要不要空格、缩写用不用点、复数形式怎么处理,这些都有明确规定,没必要在内部会上争。真正需要团队自己拍板的只有取整方向那几条,因为它取决于你卖的是什么,标准替不了你判断。
还有一个更小的细节:同一页上不要混用两种写法。有的行写45厘米,有的行写45cm,看着无所谓,实际会让站内搜索匹配不到其中一半,也会让批量校验脚本失效。统一写法这件事花不了十分钟,却是这一整套约定里唯一一条能被机器强制执行的。
这套东西该由谁维护
最后一个常见误判是把这件事交给翻译供应商。
交出去的结果通常是他们原样保留数字,因为他们的合同里写的是语言服务。
比较务实的归属是商品数据团队,他们本来就掌握原始规格。
内容团队负责的是页面上那三处出口的一致性,以及换算约定这份文档。
本地化团队负责的是单位写法和数字格式,这一层确实归他们。
三方各管一段,中间那道算术必须有人签字,签字的人是谁不重要,重要的是它不能再是空的。
哪些相邻的问题不归这一层管
汇率和价格不是同一类账
价格也是数字,也随市场变,看起来像是同一类。
它不是。
汇率每天在变,尺码几十年不变。
价格错了用户当场就知道,尺码错了要等包裹拆开。
价格有系统自动同步,尺码没有。
把两者放进同一个流程去管,通常的结果是尺码被价格那套高频机制带跑,反而更少被人认真核对一次。
版式和字号是另一条腿
数值多了会撑长表格,尤其是同时给三套单位的时候。
这确实是个真问题,但它属于排版层。
本站算过小语种站的字形集与首屏成本,那一篇讲的是字形和加载,跟这里的算术不是一笔账。
处理顺序上,先把数值弄对,再去解决表格放不下。
反过来做的团队保哥也见过,为了让表格好看先砍掉一列,砍掉的正好是厘米那一列。
物流限重和关税门槛属于合规侧
航空箱能不能带上飞机、包裹超没超重、申报价值有没有过免税额,这几件事也全是数字。
它们不归内容层管,归合规和物流。
但有一个交界处要留意:这些规则的官方文本本身有单位,而它们在不同市场的官方语言版本里单位可能不同。
你引用的时候要么原样引,要么换算之后注明来源,别自己悄悄改成另一套。
本站讲取值不由你决定的那类词时的逻辑在这里同样成立:凡是取值由外部权威定死的,你的自由度是零,唯一能做的是把它准确地搬过来。
用户测量方式的差异也不在这一层
还有一层更细的,是同一个部位不同市场量法不同。
比如胸围是量最丰满处还是量下沿,宠物的颈围是量松还是量紧。
这一层是内容问题不是换算问题,解法是配一张量法示意图加一句文字说明。
它和换算的关系是串联的:量法不统一,换算再精确也没用。
所以这两件事要一起交付,但不要混在同一张表里,一张表只解决一个问题,是保哥这些年最不后悔的一条经验。
这一层跟词表那一层的分工
最后收个尾。
词表那一层管的是这个东西在这门语言里叫什么。
这一层管的是它有多大、多重、多热。
两层的检查动作完全不同:前者靠查、问、验,后者靠算、量、对。
把它们混在一个验收表里,结果通常是后者被前者吃掉,因为语言问题看得见,算术问题看不见。
分开列,各签各的字,是这一整套东西里最省力也最有效的一步。
常见问题解答
尺码换算这件事,交给母语审校去把关行不行?
不行,而且这不是审校水平的问题,是职责边界的问题。母语审校的验收项是语言准确、表达自然、术语一致,数字不在其中任何一条里。更关键的是,一个正确换算过的数字和一个算错的数字,在母语者眼里长得一模一样,他没有任何线索能察觉。这一格必须由掌握原始规格的人来签字,通常是商品数据团队。
页面上只给本地码,不给厘米,是不是更本地化?
正好相反。同一个码在不同品牌之间差得很大,本地用户在线购买时最依赖的就是厘米那一列,因为那是唯一不需要信任任何人的参照。删掉它,用户就失去了自我验证的手段,退货率会替你回答这个问题。本地化的目标是让人不用翻译就读懂,不是让他失去尺子。
欧码和英码的对照表,网上好几个版本对不上,该信哪个?
哪个都不用全信。欧码一档是6.6667毫米,英码一档是8.4667毫米,两把尺子的刻度本来就不整除,实算下来要走127档才重合一次,而人的脚长根本用不了那么多档。所以任何一张对照表都是近似值,最大偏差接近1.9毫米。正确的处理是把厘米补上去,让用户绕过码制直接比长度。
商品数据里的尺码制式字段,遇到没有对应取值的市场怎么办?
平台目前支持的取值只有11个,韩国、俄罗斯、印度、土耳其、波兰都不在里面。可行的办法是三段式:制式字段填一个最接近的合法值让数据能跑,尺码字段写本地用户认得的写法,正文和结构化数据里补一张本地码、欧码和厘米三列齐全的对照。三步分别喂机器、喂用户、喂检索。
换算类的长尾词工具里查不到量,还值得做吗?
值得,判断依据不是绝对搜索量而是竞争密度。这类查询带数字,工具会把它们打散或归并,最后每条都显示为零,那个零是数据缺口不是需求缺口。真实需求可以从站内搜索日志里筛含数字的查询反推出来,通常一个下午就能看清用户到底在用哪把尺子问。
做一个单位切换的小工具,是不是比写死两套数值更好?
体验上更好,检索上更差。如果两套数值里有一套是脚本在客户端生成的,抓取时它可能完全不存在,而用户搜的偏偏是那一套。稳妥的做法是两套值都写进初始页面文本,开关只控制显示与否,不控制存在与否。切换是呈现问题,不该变成存在问题。
温度、容量这些单位,有没有现成的标准可以直接抄?
有,而且比大多数人以为的完整。公共区域数据里有一份单位偏好数据,按地区规定了各量纲该用哪套单位,覆盖15个量纲。天气温度用华氏的只有6个地区,身高的写法分成3派而不是2派。要注意的是这份数据里没有服装尺码和鞋码,因为那不是物理量纲而是编号体系,所以这一格永远得自己管。
权威参考资料
本文标题:《尺码那一栏的数字不归译者管,可整条流水线上没有一个人负责做那道算术》
本文链接:https://zhangwenbao.com/minor-language-size-unit-conversion-keyword.html
版权声明:本文原创,转载与引用请注明作者与原文链接。许可协议: CC BY 4.0