阿拉伯语预订网站不只是翻译

广州一家旅行社打开阿拉伯语开关,看了一眼首页,认为活干完了。两周后,一位客户在 WhatsApp 上把一条运价链接转给妹妹,到对方手里却是一堵百分号组成的墙。另一位打来电话,因为总价出现在她认为不对的那一侧。第三位把广州–迪拜订错了日期,因为日历把一周从周一开始排。这三件事没有一件是翻译错误。阿拉伯语预订网站首先是一套版式、一套数字系统和一套网址规则,然后才是一堆文案——而文案总是最先做的,因为那是截图里能看见的部分。
下面是真正会变的东西,大致按旅行社踩坑的顺序排列。
RTL 是版式决定,不是文字方向
设置 dir="rtl" 会把页面镜像过来:导航移到右边,筛选栏移到左边,段落右对齐。这部分几乎是免费的。真正花钱的是那些不能镜像的东西。
航班时间不镜像:07:45 还是 07:45。一段写作 CAN–DXB 的航程,即使放在从右往左流动的段落里,也必须仍然按这个顺序读成一条航线,因为无论句子朝哪个方向走,出发机场都还是出发机场。航司代码、PNR 和电子客票号是嵌在阿拉伯语句子里的拉丁字符串;如果不做隔离,浏览器的双向算法会重排它们周围的标点,一个后面跟着句号的 record locator,句号可能显示在错误的一端。在客户眼里,那就是自己订座编号里的一个错字。你的标志不镜像。播放的三角形不镜像。返回箭头要镜像。
再往后是那些没人会列出来、直到客户提起才发现的东西:货币符号和数字的先后、预订漏斗里的步骤条、座位图、轮播前进的方向、航司标志落在结果行的哪一侧,以及一张很宽的运价表从哪一边开始滚动。每一项都是一个决定。没有一项是打开一个开关就好。
数字、日期,以及客户手里真正在用的那本历
阿拉伯语有两套数字,都在日常使用,而旅游业到处是数字:票价、时刻、飞行时长、行李额、银行卡字段、OTP 验证码。你的市场读哪一套,是一个只需要用自己的客户回答一次的问题,回答之后就不再有例外。看得见的失败不是选了较少用的那一套,而是把两套混着用——同一张结果卡上价格用一套、起飞时间用另一套——那看起来就像一个做了一半的网站。
日期比数字承载了更多假设。一周从周一开始,对于一周从周日开始的客户就是错的;而一张从错误的那天开始排的日历,只会造成一种错误:订到旁边那一格。准备做副朝的客户是按伊斯兰历的月份在安排行程,不是公历;在日期选择器和行程单上把伊斯兰历日期放在公历旁边,成本是零,却能省掉一通电话。但在一趟去法兰克福的商务出行里到处显示它,就是噪音。
阿拉伯语预订网站必须做对的几件事
翻译过的网站和真正本地化的网站,差距是一屏一屏拉开的,不是一个全局开关。这份清单值得你和开发争一争:
| 界面 | 只是翻译 | 真正本地化 |
|---|---|---|
| 乘客姓名 | 字段标签是阿拉伯语 | 用拉丁字母采集,并标注"与护照一致",因为航司在 PNR 里存的就是那个名字 |
| 日期 | 月份名是阿拉伯语 | 读者的一周起始日、读者的数字,行程需要时把伊斯兰历放在公历旁边 |
| 金额 | 币种名称翻译过来 | 该市场的默认币种,以及你真正在卖的那份币种清单 |
| 手机与 OTP | 标签是阿拉伯语 | 预选该市场的区号,输入框里用拉丁数字,验证码一眼能读出来 |
| 机场与城市 | 名称是阿拉伯语 | 阿拉伯语名称旁边仍保留拉丁 IATA 代码,因为下级代理输入 DXB,旅客读阿拉伯语 |
| 网址 | 把标题翻译一遍 | 每种语言一套 slug 规则,只定一次 |
| 字体 | 系统默认的阿拉伯语回退字体 | 按数字形态和小字号表现挑选的阿拉伯字体,而不是一套拉丁字体后面借用阿拉伯字形 |
| 联系方式 | 一个翻译过的联系页 | 该市场客户真的拨得通的号码,而且在他醒着的时间段 |
姓名那一行是真正要花钱的一行,也是最常做错的一行。旅客用阿拉伯语填了自己的名字,因为表单就是这么请他填的;机票按那串字符出票,而它和航司核验的护照对不上。后面所有的事——改签重出、争执、退款——都落在你身上,而不是承运人身上。
字体那一行比看上去便宜。在这个平台上,主题连同字体、配色和标志都可以从管理后台直接更换,不需要重新部署,所以拿另一套阿拉伯字体在自己的运价表上试一遍,是一个下午的事,而不是一个版本的事。币种那一行自成一题,我们在多币种定价与利润从哪里漏掉里讲过。
slug,以及什么能熬过一次 WhatsApp 粘贴
阿拉伯语 slug 在地址栏里很好看,而且由人们真的会输入搜索框的词组成。可一旦被复制进纯文本字段,它就会做百分号编码并膨胀好几倍,客户转发出去的东西看起来像机器吐出来的。拉丁转写粘贴得很干净,却对谁都不可读——它既不对应阿拉伯语读者搜的任何词,也不对应中文读者搜的任何词。
按网址的用途来拆这个决定。内容页靠搜索活着,那就给它阿拉伯文的 slug;编码形态只在有人复制时才出现,而落地页无论如何都是对的。预订深链——一条搜索结果、一个锁定的运价、给下级代理的一份报价——本来就不可能好看,因为它的查询串里本就带着日期和人数。那种链接给一个短链,并且让它保持短。
两者底下的同一条规则:每个页面每种语言只有一个规范网址。把同一篇文章同时发在阿拉伯文 slug 和转写 slug 上,会把这个页面挣到的一切拆给两个地址,还留下两份要维护。
hreflang,否则你的阿拉伯语页面会和自己的英文页面打架
同一个页面的两种语言版本不是两个页面。如果爬虫看不出这一点,最常见的结果不是处罚——而是其中一个版本被选中,另一个被当作近似重复悄悄丢掉。
把它们分开靠四件事。每种语言需要自己的网址,这就排除了用一个地址加 JavaScript 切换的做法。每个版本都要列出所有语言,包括它自己,因为一组不指回自身的标注会被整体作废。每个页面的 canonical 指向自己,而不是指向英文原文——把阿拉伯语页面 canonical 到英文,是让阿拉伯语页面一个都进不了索引的最快办法。而 x-default 指向你希望没有匹配语言的读者落到的地方。
除非那些页面真的不同——不同币种、不同电话、不同库存——否则别急着拆成 ar-AE 和 ar-SA。同一份文案的两个地区版本,就是两个页面在抢同一个查询词,而且两个都挂着你的名字。
做错了要付多少代价
流失不发生在首页。它发生在填乘客信息那一步,也就是漏斗里丢人最贵的地方:对方已经搜过、选过、看过价格并接受了,而你已经为把他带到这一步的那次搜索付过钱了。
其余的代价更安静。每一通因为看不懂而打来的电话,都是你当初上线就是为了省下的那一分钟人力。每一次姓名不符,都是一次重出票,外加一个把账算在你头上而不是航司头上的客户。而一个永远不会被收录的阿拉伯语页面,是一篇你付了钱、却没人找得到的文章——这是唯一一种完全不会引来投诉的失败,所以它能悄悄持续一整年。
从哪里开始
如果阿拉伯语是你的第二个市场,这是一次改造,上面那张表就是你的整改清单。如果它是你的第一个市场,顺序要反过来:在定配色之前先定数字体系和阿拉伯字体,照着一本真护照来搭乘客表单,并且把中文当成译文。
无论哪种情况,最便宜的验证都是把一个真实门店放到一位真实客户面前。创建旅游网站的向导会直接从表单里在平台子域上开出一个带你品牌的站点,而且不要求绑卡;门店以 40 种语言上线,其中包括阿拉伯语、波斯语、希伯来语和乌尔都语,自有域名可以之后再接。如果你还在犹豫要不要自己造引擎,那笔账我们在这里算过——但在决定之前先用阿拉伯语跑一遍,因为 RTL 这部分工作,正是内部估算最容易漏掉的。