阿拉伯语网站搬进手机之后，桌面时代验过的那份RTL清单有一半不作数

摘要：从右往左这件事在宽屏上基本被解决过一轮，换到窄屏之后又冒出一批新的。区别在于坏掉的东西变了：桌面时代出问题的是版面与模板，窄屏上出问题的是折行、截断、手势与键盘。价格串会在折行时被拆成两截，标题的省略号落在左端，手机键盘决定用户打的是哪一套数字。这篇把这批只在窄屏上成立的坑逐条拆开。

移动优先之后重新出问题的不是版面，是交互

桌面时代那份清单为什么不能直接搬过来

大部分团队手上都有一份从右往左的检查清单，是做桌面站时攒下来的。

那份清单的核心是模板层：方向属性有没有写对，栅格有没有镜像，表格列序对不对。

这些条目今天依然有效，但它们只覆盖了窄屏问题里的一小半。

原因很直接：桌面上有足够的宽度，很多冲突被空间吃掉了，根本没机会显形。

屏幕一窄，被空间掩盖的那些冲突就一次性全都跑出来了。

所以这不是原来的结论错了，是原来的测试条件太宽松。

更麻烦的是这批新问题很难在评审里被发现。模板层的错误看一眼截图就知道，而折行、截断、手势这三类只有在真机上用真实内容滑一遍才会暴露，评审用的示意图往往用的是英文假数据，方向一翻转就把问题藏住了。做桌面时代那套阿拉伯语布局检查时积累的经验在这里只能当起点。

有个判断哪些条目要重验的土办法：把清单里每一条问一句它在多宽的屏幕上会失效，答案是任何宽度的留着，答案是屏幕窄到某个值以下的挑出来单独放一组，这一组就是这轮要重做的全部。

出问题的位置从版面移到了交互

窄屏上用户的动作变多了：滑、拖、展开、收起、切换键盘。

每一个动作都隐含一个方向假设，而这些假设写代码的人通常没意识到自己做过。

轮播往左滑是下一张还是上一张，抽屉从哪一侧推出来，返回手势从哪条边起。

这些在从左往右的世界里是默认值，没人会写进需求文档。

换到从右往左之后，默认值有的该翻转、有的绝对不能翻转。

判断哪个该翻哪个不该翻，恰恰是这门语言带来的额外功课。

还有一层更隐蔽：交互的方向错了不会报错，也不会让页面看起来坏掉，它只是让用户多花两三秒才明白该往哪边划。这种损耗在数据里表现为跳出率略高、页面停留略短，很难被归因到方向上，团队通常会先去怀疑文案和图片。

把交互层的方向假设显式写进需求文档，是唯一能长期生效的办法。文档里给每个可滑动可展开的元素标一个方向属性，值只有三种：跟随文字、跟随设备、不适用。三种一标完，实现和验收都有了依据。

把两个年代的坑摆在一张表里

下面这张表把桌面时代和窄屏时代的问题分开，避免混着查。

左列是宽屏就能发现的，右列是只有窄屏才会显形的。

这张表最实用的地方是它能省掉重复劳动。

左列那些如果当年验过并且模板没大改，这一轮可以直接跳过。

右列这些则一条都不能跳，因为它们在桌面测试里根本没有对应的动作。

用这张表还能顺手解决排期争议。右列六条里有四条属于前端改动、两条属于内容与词表改动，责任方不同，可以并行开工；如果不做这个拆分，整件事很容易被打包成一个模糊的适配任务扔给前端，而词表那半边永远排不上。

窄屏折行为什么会把价格拆成两截？

断点落在数字与符号之间

阿拉伯语正文里嵌一段西文数字，是电商页面的常态。

价格、型号、容量、滤芯规格，这些几乎全是西文数字或者字母数字混排。

混排段落的显示顺序由双向算法决定，它按逻辑顺序存储、按视觉顺序呈现。

宽屏上一行放得下，看不出问题。

窄屏上这一段要折行，折行点是按可用宽度算的，跟逻辑顺序没有关系。

结果就是一个完整的数值被切在两行里，上一行的末尾和下一行的开头各留一半。

这类错误的典型形态是这样的：一台净水器的型号写成八位字母数字，折行之后前四位留在上一行的左端、后四位跑到下一行的右端，两截之间隔着整整一行的空白，用户根本拼不回来。双向算法把重排规则写得很清楚，但它管的是顺序，不管折行。

这里还藏着一个反直觉的点：折行位置由换行算法按字符类别决定，而顺序由双向算法决定，两套规则各管各的、互不通气，所以顺序正确的字符串照样会被折在最不该折的地方。

三类混排串的实际表现不一样

价格串通常带货币符号，符号在哪一端由本地习惯决定。

型号串是纯粹的字母数字，方向上完全中性，最容易被算法归到相邻文字的方向里。

尺码与规格串常带斜杠和乘号，这些符号本身也是中性字符。

中性字符的方向取决于两边邻居，两边方向不同时按段落方向兜底。

所以同一串数字放在不同上下文里，呈现出来的顺序可能不一样。

测试时如果只造一条数据，很可能刚好躲开出问题的那种组合。

造测试数据有个偷懒办法：把型号写成一半数字一半字母、价格写成带小数点和货币符号、规格写成带斜杠的三段式，这三条覆盖了中性字符的大部分情形，比造二十条随机数据管用。滤芯规格这类字段最容易出事，因为它同时带数字、字母、斜杠和汉字以外的单位缩写。

顺带记一条经验值：如果一个字段的内容里同时出现方向强字符、方向弱字符和中性字符三类，它出问题的概率接近百分之百，商品标题和规格描述通常都属于这一类，可以直接列入必查名单不用再逐个判断。

把混排段钉住的两个办法

第一个办法是不让它折：给整串加上不折行的包裹。

代价是宽度不够时会撑破容器，需要配合缩小或者换行策略。

第二个办法是给这段加方向隔离，明确告诉渲染引擎它是一个独立的方向单元。

隔离之后这一段不再受邻居影响，顺序稳定，折行也只在它自己内部发生。

两个办法可以叠加，先隔离再禁止折行，稳定性最好。

模板层面把这两条固化到价格与型号的输出函数里，比逐个页面改省事得多。

还有一个常被忽略的位置是结构化数据与元描述。这两处的字符串不参与页面渲染，团队默认它们没有方向问题，可实际上搜索结果里的摘要一样会折行、一样会重排，价格在摘要里被拆开的观感比页面里更糟，因为用户还没进站就先看到一串对不上的数字。

处理时要区分方向隔离和方向覆盖两件事，行内双向标记的规范说明里讲得很细：隔离是让这一段自成一体不影响邻居，覆盖是强行指定顺序，后者用错会把本来正确的显示改坏。

同一段文字在三个位置会有三种折断

页面正文里折行按容器宽度算。

页面标题在窄屏上按可显示的行数截断，多出来的直接不显示。

按钮和标签里的文字通常单行，超出部分被省略号吃掉。

三个位置的规则不同，同一串内容会呈现出三种断法。

验收时要三个位置分别看，不能拿正文的结果推断按钮里的表现。

这也是为什么截图评审容易漏：截图往往只截了正文那一屏。

更细一层是筛选标签。这类标签既短又多，容器宽度是按内容自适应的，一旦某个标签里带了西文数字，它的实际宽度会跟设计稿差出一截，一行放三个变成放两个，整个筛选区的高度跟着变，把下面的商品列表推出首屏。

把这三处的可用宽度写进设计规范，比每次改版都重新试一遍省事。规范里要写的是渲染宽度不是字符数，因为这门语言里不同字母的宽度差别很大，同样十个字符占的像素可能差出四成。

手机上的手势方向要不要跟着文字方向翻转？

轮播、抽屉与返回各有各的判断

轮播要翻。内容序列跟阅读顺序绑定，第一张在右边，往左滑看下一张。

抽屉要翻。它的位置对应导航区的位置，导航在右边抽屉就从右边推出。

返回手势要看系统。系统级的边缘返回由操作系统定义，页面不该去改它。

页面内部的返回按钮箭头要翻，指向的是阅读的来路。

这三条合起来就是一个判据：它表达的是文字顺序还是设备约定。

文字顺序的翻，设备约定的不动。

这个判据能解决绝大部分争议，剩下的少数情形靠一条补充规则：如果这个动作在用户心里对应的是物理世界的运动方向，比如下拉刷新、上滑加载，那它跟文字方向无关，一律不翻。判断时问一句这个动作横着还是竖着，竖着的基本都不用管。

这条判据还能反过来用：如果团队为某个交互该不该翻转吵起来了，说明它同时带着文字属性和设备属性，这种情形下最稳妥的处理是跟随系统的本地化行为，而不是自己拍一个方向，因为用户的预期本来就是分裂的。

系统习惯与用户习惯不重合的那一部分

装了阿拉伯语系统界面的用户，系统的方向假设已经翻转过了。

但相当一部分用户的系统界面是英文的，页面却是阿拉伯语的。

这批用户的手上同时存在两套方向习惯。

他们对系统级手势用英文习惯，对页面内容用阿拉伯语习惯。

所以页面内的方向要跟内容走，不要去猜系统语言。

拿系统语言当判断依据，会让这批用户遇到两套互相打架的方向。

这个分裂在中东市场比想象中普遍，尤其在高端机型和年轻用户里，系统界面是英文的比例相当高。产品讨论里如果有人主张按系统语言自动决定页面方向，把这条摆出来通常就能结束争论：真正稳定的信号是页面内容的语言，不是设备设置。

还有一批用户的设备是二手或者水货，系统语言是出厂地的语言，跟他自己和内容都不一致。这批人的比例不高但在部分市场确实存在，是又一条不该依赖系统设置的理由，页面自己把方向说清楚才是稳的。

进度条、步骤条与滑块的方向

结算流程的步骤条要翻，第一步在右边。

已完成的部分从右侧开始填充，这跟阅读顺序一致。

价格区间滑块要翻，最小值在右端。

视频播放进度条不翻，时间轴是设备约定不是文字顺序。

音量条也不翻，理由相同。

这几个例子放在一起，前面那条判据就变得很好记了。

实操里最容易出错的是步骤条上的数字。步骤序号本身是西文数字，在从右往左的容器里它们的排列顺序会被双向算法重排，如果序号是逐个渲染的独立元素就没事，如果是拼成一个字符串再渲染的就会乱序，这个细节在设计稿上完全看不出来。

星级评分是个容易被忽略的例子。评分本身表达的是数量不是文字顺序，按理不必翻转，但它左侧的说明文字和右侧的数值会跟着翻，星星如果不动就会跟标签错位，实际做法是整组一起翻、星星本身的填充方向保持不变。

翻错了会怎样

方向翻错不会让页面崩，只会让用户慢半拍。

慢半拍的代价在漏斗深处会累加成实实在在的流失。

轮播方向反了，用户以为到头了就不再滑，后面的商品等于没上架。

步骤条反了，用户会误判自己还剩几步。

滑块反了，筛出来的价格区间跟预期相反，看到的商品全不对。

这些都不会有人来投诉，只会安静地掉转化。

有个成本极低的自查办法：让一个完全不懂阿拉伯语的同事拿真机走一遍结算流程，只看图形和数字不看文字。如果他在某一步犹豫了，那一步的方向多半有问题，因为图形和数字本身应该已经把方向讲明白了。

要把这类损耗量出来，可以在轮播上加一个滑动次数的埋点，对比两个方向版本的平均滑动次数。方向错的那一版通常会明显偏低，因为用户滑一下发现不对就停了，这个数字比任何主观判断都直接。

标题在窄屏被截断时，被砍掉的是哪一端？

省略号落在左端会吃掉什么

阅读方向从右往左，句子的开头在右边、结尾在左边。

截断从结尾开始，所以省略号出现在左端。

这一点跟从左往右完全对称，本身不难理解。

麻烦在于团队看惯了省略号在右边，第一次看到在左边会以为是渲染错了。

更实际的麻烦是：被砍掉的永远是句子后半段的信息。

如果把品牌名、型号、卖点放在句尾，窄屏上它们就是最先消失的那批。

这条规则对面包屑尤其不友好。面包屑的最后一级通常是当前页面的名称，也就是信息量最大的那一节，在窄屏上恰好落在最左端最先被吃掉，用户看到的是一串上级分类加一个省略号，等于什么也没告诉他。

还有一个连带影响是链接的可点区域。截断之后按钮和链接的实际宽度变了，如果热区是按文字宽度算的，热区会跟着缩到只剩一半，用户点在看得见的文字上却没有反应，这类问题在方向翻转之后出现的频率明显更高。

关键词前置在这门语言里等于放在右边

关键词靠前这条通用建议在这里要重新翻译一次。

靠前指的是逻辑顺序上的开头，视觉上落在右端。

写标题的人如果按视觉直觉把重点放在左边，其实是放在了句尾。

这个错误在中文团队里出现的频率不低，因为大家默认左边就是开头。

检查办法很简单：把标题里的文字按朗读顺序念一遍，第一个念到的词就是最靠前的。

不要用眼睛在屏幕上从左往右扫，那个顺序是反的。

顺带说一句，这条也适用于标题的长度控制。标题与页面主标题之间的分工不变，但阿拉伯字形的平均宽度跟拉丁字母不同，同样字符数占的像素宽度差别很大，按字符数控制长度会失准，得按渲染宽度量。

写作时有个笨办法能彻底避开这个错误：先把标题写成纯文字草稿在文本编辑器里排一遍，编辑器会按逻辑顺序显示，看到的第一个词就是真正靠前的那个，等确认无误再放进设计稿里看视觉效果。

搜索结果里的截断点跟页面里不是一套

页面里的截断按容器宽度算，容器宽度由样式决定。

搜索结果里的截断按结果页自己的宽度算，跟你的样式无关。

两者的可用宽度不同，截断点自然不同。

所以页面里显示完整的标题，在结果页里可能已经被砍了一截。

反过来也成立，结果页显示得下的，在你的移动模板里可能反而放不下。

两边都要量，不能只量一边。

量的时候有个取巧的做法：把候选标题渲染成图片按像素量宽度，比在浏览器里逐个试快得多。移动结果页的可用宽度是个经验值，会随时间调整，所以真正稳妥的是把最关键的那几个词压进前面一小段，而不是去卡某个具体的字符数。

还有第三个位置常被忘掉：社交平台分享出去的卡片。卡片的标题宽度又是另一套，而且多数平台不支持方向属性，长标题在那里的表现基本不可控，稳妥的做法是给分享卡片单独写一条更短的标题。

移动键盘把哪一套数字打进了搜索框？

两套数字形态造成的查询分叉

这门语言的书写传统里存在两套数字形态。

一套是通行世界的那组符号，另一套是阿拉伯语区自己的那组。

两套在编码上完全不同，是两批各自独立的字符。

用户打哪一套，取决于他手上键盘的布局。

同一个人在手机上和电脑上可能打出不同的形态。

于是同一个查询在数据里裂成两条，量都不高，合起来才是真实需求。

这件事在选词工具里几乎不可见，因为多数工具的输入框会做一次静默转换，把两套形态归成一套再去查询，返回的数字看起来干干净净，实际上已经把分叉抹掉了。要看真实分布只能查自己的站内搜索日志。

还有一层影响在广告和分析工具的报表里：两套形态被当成两个不同的关键词分别计费和统计，预算分配会因此失真，出价高的那一套拿走了大部分曝光，另一套明明有需求却因为量小被判为不值得投。

规范化要放在哪一层

站内搜索必须做数字形态的归一，这是底线。

归一放在查询解析层，把两套形态映射到同一个内部表示。

筛选器的数值输入同样要归一，不然筛不出结果。

页面上展示用哪一套是另一个问题，可以按市场习惯决定。

输入端归一、展示端本地化，两件事分开做。

混在一起处理的结果通常是两头都不对。

归一的时候还要顺手处理小数点和千分位。阿拉伯语区常用的小数分隔符与千分位符号跟通行写法不是同一个字符，用户从别处复制粘贴过来的数字里带着这些符号，直接送进数值解析会报错或者被截断，这类报错在日志里通常表现为一堆没有结果的搜索。

归一的具体位置建议放在最靠近入口的那一层，也就是请求进来之后第一时间处理，而不是等到数据库查询前才做。放得越靠后，中间经过的每一个模块都要各自处理一遍，漏掉任何一个都会让整条链路前功尽弃。

三个字段的实际后果

电话号码字段如果只接受一套形态，另一套的用户直接注册不了。

订单号查询同理，用户从短信里复制过来的形态可能跟你库里的不一样。

验证码输入框最要命，六位数字打进去提示错误，用户根本猜不到原因。

这三个场景的共同点是失败了没有任何提示能帮到用户。

解决办法是在输入端做静默归一，不要弹错误提示。

用户不需要知道这背后有两套字符，他只需要它能用。

这类问题在客服记录里的表述通常是我输入没反应，非常难定位。有个快速验证法：拿一台把键盘切成本地布局的真机，在每个数字输入框里各打一遍，五分钟能扫完整个站的表单，比读代码找漏网的字段快得多。

短信和邮件模板同样要检查一遍。系统发出去的验证码如果用了一套形态，而用户的键盘只能打另一套，他就得手工换算，很多人到这一步直接放弃了，而这个流失在站内数据里完全看不见。

移动可用性判定里，哪几条会被这类页面系统性踩中？

点击目标在镜像栅格里的塌陷

很多组件库的间距是靠单侧外边距实现的。

方向翻转之后，单侧外边距如果没跟着翻，相邻元素的间隙就消失了。

间隙消失的直接后果是两个可点区域挨在一起。

可用性检测会把这一条报成点击目标过于接近。

这类问题在从左往右的版本里完全不存在，所以初版测试全绿。

排查时优先看所有硬编码了左右的间距值。

成体系的解法是把间距写成跟随方向的形式，让它自己在两个方向下取正确的一侧。这轮改动的收益不止于间距，图标与文字的相对位置、卡片里的角标位置也会一并修好，因为它们踩的是同一个坑。

这类问题有个特征能帮着快速定位：它总是成对出现，一侧间隙消失的同时另一侧间隙翻倍。看到某处元素挤在一起，往它的反方向看一眼，多出来的那段空白就是原本该在这一侧的间距，两处一起改才对。

横向溢出最常见的四个来源

第一是固定宽度的元素，翻转后超出可视区。

第二是负外边距，方向翻转让它往错的一侧顶。

第三是绝对定位里写死的坐标值。

第四是嵌入的第三方内容，它自己不认方向。

四类里前三类改代码能解决，第四类只能用容器包起来限制。

横向溢出的表现是页面能左右晃动，用户体感很差且很容易发现。

诊断有个笨但有效的办法：给所有元素临时加一圈描边，页面滑到最右侧看哪个框超出去了。比起逐个查样式，这个办法一次能找出全部四类来源，代价是要在测试环境里跑一次。

表格是第五个来源，只是它太常见反而容易被当成理所当然。窄屏上的宽表格无论方向如何都会溢出，区别在于从右往左时用户要往哪一边滑才能看到剩下的列，而滚动条的初始位置默认在左端，正好是反的。

字号与行高要另设一档

阿拉伯字形有相当一部分带有基线以下的延伸笔画。

同样的字号，实际占据的垂直空间比拉丁字母大。

行高按拉丁字母的比例设置，字形之间会显得拥挤甚至相碰。

再加上连写的特性，笔画之间的辨识依赖足够的字号。

实践中通常要把正文字号提一档、行高提高一到两成。

这不是审美偏好，是可读性的下限要求。

提字号会带回一个副作用：同样的容器里能放的字数变少，标题和按钮更容易被截断。所以字号、行高、截断这三件事要一起调，单独调其中一个多半会把另一个搞坏，这也是为什么方向适配的排期不能按单点估算。

低配机上这个问题会被放大。字体渲染的质量在低端设备上明显更差，笔画连写处容易糊成一团，同样的字号在旗舰机上清晰可读、在低配机上勉强能认，所以字号的下限要按低配机定，不能按测试用的那台好机器定。

固定条与弹层的遮挡方向

底部固定条本身没有方向问题，里面的按钮排列有。

主要动作按钮在从右往左时应该落在右侧。

侧边弹出的购物车面板要从右侧滑出。

浮动的返回顶部按钮位置要跟着翻，不然会挡住内容的起始端。

吸顶的筛选条里，标签的排列顺序也要翻。

这些都属于翻转清单里的常规项，容易被漏在于它们通常写在不同的文件里。

最后还有一层是动画方向。面板滑入滑出的位移方向如果没翻，会出现面板从右侧出现却往左侧收起的怪异感，用户说不出哪里不对但会觉得别扭，这类细节在验收清单里基本不会被单列，只能靠真机滑一遍发现。

一套模板同时服务两个方向，代码该怎么组织？

两份样式表还是一份加方向选择器

两份样式表的做法是维护一份主样式，再用工具生成镜像版本。

优点是运行时零成本，缺点是每次改动都要重新生成、两份容易漂移。

一份样式加方向选择器的做法是在同一份文件里写两套规则。

优点是改动只有一处，缺点是文件变大、选择器嵌套变深。

站点规模不大时用后者，方向相关的规则通常不超过全部规则的一成。

站点规模很大或者主题多时，生成两份更好管理。

还有第三条路是把方向敏感的属性统一抽成变量，方向切换时只换变量值。这条路的代价是要先梳理出完整的方向敏感属性清单，前期投入大，但一旦建成，后面新增页面几乎不用再考虑方向问题，长期看是最省的一种。

无论选哪条路，都要把方向相关的规则集中在可以被单独检索的位置，别散落在各个组件文件里。这件事的价值在下一次换主题或者升级组件库时才会显现，能不能在半小时内说清楚全站有哪些方向敏感规则，差别就在这里。

图标与图片里哪些该镜像

指示方向的箭头要镜像。

表示前进后退、上一页下一页的图标要镜像。

带文字的图片要重做，不能靠翻转。

产品实拍图绝对不能翻转，翻了商品本身就错了。

时钟、播放、音量这类图标不镜像。

logo不镜像，除非品牌方另有一套本地版本。

手写体或者书法风格的装饰图形要单独判断。这类图形常常本身就带方向感，翻转后会变得很奇怪，但不翻转又跟整体版式冲突，通常的解法是给这个市场单独出一版，成本不高而且是一次性的。

还有一类要单独处理的是带箭头的流程图和示意图。这类图既有方向语义又常常内嵌文字，翻转会让文字倒过来，不翻转又跟阅读顺序冲突，正确做法是把图重新画一版，顺手把图里的文字也换成本地语言。

第三方组件的方向支持怎么验

不要看文档说支持就信，要拿真实内容跑一遍。

测试串固定成一段纯本地语言文字加一串西文数字。

看三件事：顺序对不对、折行对不对、输入光标从哪一端起。

三件事里有一件不对，这个组件就要么改要么换。

评论、日期选择器、富文本编辑器是出问题最多的三类。

地图与图表组件通常问题较少，因为它们本来就不依赖文字方向。

验组件时顺手记下版本号和验的日期，写进一份内部清单。组件升级后方向支持退化的情况并不罕见，有清单在，下次升级时能定向复验，不用整套重来。这份清单的维护成本极低，但能省掉的返工次数很可观。

有一类组件要格外小心：把文字画进画布或者转成图形的那些，比如某些图表库的坐标轴标签。它们绕过了浏览器的文字排版，方向和折行全靠自己实现，多数库在这一块做得很粗糙，遇到就直接换掉比修划算。

移动端的查询，跟桌面上是同一批词吗？

输入成本让查询变短变口语

在手机上打这门语言，比打拉丁字母慢。

字母形态随位置变化，输入法的候选逻辑也更复杂。

输入成本一高，用户就倾向于打更短的词。

短词更接近口语，而口语跟书面语在这门语言里差得不小。

结果是移动端的查询整体更口语化、更短、更依赖上下文。

按桌面数据做的词表，覆盖不住这半边。

这个偏移的幅度可以自己量：把站内搜索日志按设备切开，比较两边查询的平均长度和词数。如果移动端明显更短，说明这个偏移在你的市场是成立的，值得单独给移动端补一批短词落地页；差别不大就不用折腾。

这个成本差异还解释了另一个现象：移动端用户更依赖搜索建议和历史记录，因为选比打省力。这意味着建议列表里出现什么词，会实实在在地反向塑造用户的查询习惯，站内搜索的建议逻辑值得单独调一轮。

语音输入把方言送进了搜索框

手机上按住说话比打字快得多，使用率明显更高。

说出来的是日常口语，也就是方言，不是书面标准语。

识别结果会被转写成文字送进搜索框。

于是方言词以书面形式出现在查询日志里。

这批词在传统选词工具里基本查不到。

它们只在自己站的搜索日志和实际落地词里露面。

方言与标准语的分工在这门语言的选词方法里已经讲过，这里要补的是移动端把这条分界线往方言那边推了一截。同一个品类的落地页，标题用标准语、正文里带上两三个高频方言说法，是成本最低的兼顾办法。

语音识别本身也会引入固定的偏差：识别引擎的训练数据以标准语为主，遇到方言时会把某些音归到最接近的标准语词上，于是日志里会出现一批看着像错别字实际是识别产物的词，这类词不必做覆盖但要能识别出来排除掉。

移动端的字母省略率更高

有几个字母存在带记号与不带记号的两种写法。

词首那个带上加符号的字母，很多人直接打成不带的。

词尾那个圆形字母，常被打成另一个形近的字母。

还有一个字母的带点与不带点两种形态，在不同地区习惯不同。

这三类省略在手机上比在电脑上更常见，因为切换键盘层级要多按一次。

词表里如果只收规范写法，这部分流量接不住。

处理办法不是给每种写法都做页面，而是在站内搜索和内部匹配层做等价折叠，同时在正文里自然地把两种写法都写到。这跟另一门从右往左的语言里省略元音标记造成的匹配问题是同一类，只是省略的对象不同。

要摸清自己市场的省略程度，可以拿站内搜索日志做一次统计：把同一个词的规范写法和各种省略写法都数一遍，算出省略写法的占比。这个比例在不同国家差别很大，别拿别人的经验值套自己的数据。

上线顺序错了，两类改动会互相盖掉对方的效果

先钉字符串，再动布局

字符串层的改动指的是隔离、不折行、数字归一这些。

布局层的改动指的是镜像、间距、字号行高这些。

先做字符串层，因为它的效果最容易被单独观测。

布局改动一上，页面的观感整体变了，字符串层的收益就混进去说不清了。

顺序反过来做，两批改动的效果会互相掩盖。

两批之间留两到三周的观察窗口。

这个顺序还有个现实理由：字符串层的改动风险低、回滚容易、不需要设计参与，可以在等设计稿的间隙先做掉，等于把排期利用起来了。布局层的改动通常要等设计确认，中间的空档正好够跑完第一批的观察。

灰度的分面要按方向切

常规的灰度按流量比例切，这里不够用。

因为从右往左的页面只占全站的一小部分，随机切样本量太小。

正确做法是先按语言分面，再在这个面内做灰度。

这样才能在合理时间内拿到有统计意义的结果。

不这么切的话，方向相关的改动会被主流量的波动淹没。

指标也要分面看，不能只看全站汇总。

分面之后还要注意一件事：这个市场的流量周期跟欧美不同，周末的起止日不一样，按自然周对比会错位。做同比时先确认这个市场的一周从哪天开始，否则得出的结论会系统性偏移一天。

还要留意样本里的设备构成。这个市场的低配安卓占比通常高于欧美，如果灰度桶随机分配时设备构成失衡，观测到的差异可能来自设备而不是改动本身，分桶时把设备档次也纳入平衡条件会稳得多。

三级验收

第一级是模拟器，快，用来筛明显错误。

第二级是真机，必须有真机，手势和键盘只有真机上是真的。

第三级是本地用户实测，找几个真正用这门语言的人走一遍。

三级各能发现不同层次的问题，缺一层就会漏一类。

真机要覆盖高低两档配置，低配机上字体渲染差别很大。

本地用户实测的价值在于他们会说出你根本想不到的别扭之处。

做真机测试时把系统语言分成两种情况各测一遍：系统是本地语言的，和系统是英文的。前面说过这两批用户的方向习惯不同，只测其中一种会漏掉另一批人遇到的问题，而这两批人在这个市场里都不是小数。

哪些问题不归语言层，要一句话交出去

移动友好本身是算法与技术议题

页面在窄屏上能不能用，是一个跟语言无关的通用问题。

它的判定标准、权重变化、检测工具都属于技术层。

这一篇只讲这门语言额外带来的那部分。

通用的那半边有专门的讨论，不在这里重复。

把两者混在一起讲，结果是两边都讲不透。

分开之后，语言层的清单反而变得很短很具体。

通用那一半可以直接看移动友好更新的来龙去脉，以及首屏内容的版面机制；本篇的判据是把语种换成英语还成不成立，不成立的才留在这里。

多语言站的架构与地区定向

一个站要不要为这个市场单开目录、用哪种域名结构、地区定向怎么设，都是架构问题。

架构问题跟具体是哪门语言无关，换成任何语言都一样要面对。

这部分有成体系的做法，按多语言站的架构与语言地区标注那套走就行。

本篇涉及架构的地方只有一处：方向属性要写在页面根元素上。

这条属于标记层，跟目录结构无关。

其余架构决策都交出去。

顺带提醒一句常见的混淆：语言标注和方向标注是两件事，前者说这是什么语言，后者说文字从哪边开始。有的模板只写了语言没写方向，浏览器会按默认值处理，一整页的方向就错了，而这个错误在语言标注的检查里查不出来。

引擎差异与本地平台

这个市场里用户从哪个入口开始搜，属于引擎层的问题。

不同引擎对方向、对本地字符的处理确实有差别。

但那属于各引擎自己的排序与呈现规则，不是这门语言的属性。

需要了解某个引擎的具体打法时，看第二大搜索引擎的完整打法那类专门讨论。

本篇只保证一件事：无论从哪个入口进来，页面本身在窄屏上不出方向错误。

入口的选择和分配是另一个层面的决策。

把边界划清楚有个额外好处：跨部门讨论时不容易扯皮。方向问题归前端和内容，入口问题归渠道，架构问题归技术，三方各自有清单，比开一个大会把所有问题堆在一起有效率得多。

常见问题解答

桌面站已经做过从右往左适配，移动端还需要重新做一遍吗？

模板层不用重做，交互层必须重做。桌面时代验过的方向属性、栅格镜像、表格列序这些结论继续有效，只要模板没有大改就可以直接跳过。真正要重新验的是四类只在窄屏上成立的问题：混排字符串的折行、标题与标签的截断、手势方向、移动键盘带来的数字形态分叉。这四类在桌面测试里没有对应的动作，所以再完整的桌面清单也覆盖不到。实操上建议把两份清单物理分开，一份标注为宽屏结论、一份标注为窄屏专属，每次改版时前者抽查后者全验，这样既不会重复劳动，也不会漏掉新增的窄屏问题。判断某一条属于哪一份的办法也很简单：问它在宽屏上会不会发生，不会的就属于窄屏那份。一个常见的判断失误是以为改版幅度小就不用重验，实际上只要容器宽度或者字号变过，折行与截断的结果就全变了，这两项跟改动大小无关只跟宽度有关。

价格在手机上被折成两行，最快的修法是什么？

最快的修法是在输出价格的模板函数里给整串加上方向隔离并禁止折行，两条一起加，改一处全站生效。方向隔离让这一段成为独立的方向单元，不再受左右邻居影响；禁止折行保证它不会被切开。加完之后要检查容器宽度是否足够，宽度不够时价格会撑破容器，需要配合缩小字号或者把价格单独占一行的布局。同样的处理要覆盖型号、规格、尺码这些混排字段，它们踩的是同一个坑。别忘了结构化数据和元描述里的价格串也走同一套处理，那两处不参与页面渲染，但会出现在搜索结果的摘要里，同样会折行、同样会被拆开，而且用户是在进站之前就看到的。改完记得回头看一眼列表页的卡片，卡片里的价格容器通常比详情页窄得多，详情页上验通过的宽度设置搬到卡片里往往还是会撑破。

页面方向该按用户的系统语言判断还是按页面内容判断？

按页面内容判断，不要看系统语言。这个市场里有相当比例的用户把系统界面设成英文，页面内容却是本地语言，他们手上同时存在两套方向习惯：对系统级手势用英文习惯，对页面内容用本地习惯。如果页面方向跟着系统语言走，这批用户会遇到两套互相打架的方向，体验比统一按内容走差得多。正确做法是在页面根元素上明确写死方向属性，跟着内容语言走，同时不去改系统级的边缘返回手势，那属于操作系统的地盘。还有一个常被混淆的点：语言标注和方向标注是两个独立的属性，只写了语言没写方向的模板会走浏览器默认值，整页方向就错了，而这个错误在语言标注的检查里完全查不出来。如果站点同时提供多个语言版本，方向属性要跟着当前页面的语言走而不是跟着用户的偏好设置走，否则切换语言时会出现方向没跟着变的半截状态。

两套数字形态要不要都做关键词覆盖？

查询端要都接住，展示端选一套就够。用户打哪一套取决于他手上的键盘布局，同一个人在手机和电脑上可能打出不同形态，这会让同一个需求在数据里裂成两条，单看每一条量都不高。处理办法是在站内搜索的查询解析层做归一，把两套形态映射到同一个内部表示，筛选器的数值输入同样处理；页面上展示用哪一套则按当地习惯决定，两件事分开做。特别要检查电话号码、订单号、验证码这三个输入框，只接受一套形态会让另一套的用户直接卡住而且看不到任何有用的提示。顺手把小数分隔符和千分位符号也纳入归一范围，用户粘贴过来的数字里常带着这两个本地符号，直接送进数值解析会静默失败。排序也要一并处理，两套形态在按字节比较时的次序跟数值大小完全对不上，价格排序、评分排序这类功能如果直接按字符串排会给出乱七八糟的结果。

轮播和进度条的方向，到底哪个该翻哪个不该翻？

判据是这个元素表达的是文字顺序还是设备约定。表达文字顺序的要翻：轮播、结算步骤条、价格区间滑块、导航抽屉、页面内的返回箭头。属于设备约定的不翻：视频播放进度条、音量条、系统级边缘返回手势、时钟与播放类图标。还有一条补充规则处理竖向动作：下拉刷新、上滑加载这类跟物理运动方向绑定的交互一律不翻，判断时先问这个动作是横着还是竖着，竖着的基本都不用管。实操中最容易漏的是步骤条上的序号，如果序号是拼成一个字符串再渲染的，会被双向算法重排成乱序，改成逐个渲染的独立元素就好了，这个细节在设计稿上完全看不出来。拿不准的时候还有个兜底判断：看这个元素在纸质媒介上会不会跟着排版方向变，会变的就翻，不会变的就不翻，这个类比对绝大多数争议都成立。

方向适配的改动应该按什么顺序上线？

先做字符串层，再做布局层，中间留两到三周观察窗口。字符串层指的是方向隔离、禁止折行、数字归一这些，它们风险低、回滚容易、不需要设计参与，可以在等设计稿的间隙先做掉。布局层指的是镜像、间距、字号行高这些，一旦上线页面观感整体改变，之前那批改动的收益就混进去说不清了。灰度也要调整：常规的按流量比例切在这里样本量不够，因为这类页面只占全站一小部分，正确做法是先按语言分面再在面内灰度，指标也分面看。做同比时先确认这个市场的一周从哪天开始，按欧美的自然周对比会系统性错位一天。两批改动之间的观察窗口里不要同时上线内容或者词表的调整，否则三件事的效果搅在一起，前面费劲做的分面灰度就白做了。

没有懂这门语言的同事，怎么自己先验一轮？

可以验掉大部分问题，因为窄屏上的方向问题多数是图形和数字层面的，不依赖读懂文字。具体做法是拿一台真机，把系统键盘装上本地布局，然后走三条路径：商品列表滑到底、走完整个结算流程、在每个数字输入框里各打一遍。过程中只看图形、数字和排版，不看文字。轮播往哪边滑能到下一张、步骤条从哪端开始填、价格串有没有被折断、省略号出现在哪一端、输入框接不接受打进去的数字，这五件事全是不懂语言也能判断的。剩下真正需要语言能力的只有文案本身和词表，那部分再找本地用户过一遍，两小时足够。这套自查最好在提测之前做，能挡掉大半返工。自查时把整个过程录屏，发给本地用户看比让他们自己重新走一遍效率高得多，他们能在录屏里直接指出哪一步不对劲，省掉来回沟通的时间。

权威参考资料