淘宝前端国际化方案探索
作者: 发布于:

全球化、农村、云计算大数据是我们目前集团非常明确的未来战略。全球化会让我们服务更多的人,服务全球范围内的人。落实到我们前端这块就需要有一套国际化的方案,能为海外用户提供非常好的体验,推进集团全球化进展。

这段时间有幸交接了淘宝海外的业务,淘宝海外就是专门面向国外用户提供服务的,因此在国际化这边有一些尝试,但是还远远不够,之前主要面向的用户是海外华人和留学生等,所以国际化只是做了一些繁简体转换等。后面多语言还会面临更多更大的挑战。在这里我思考整理汇总一下国际化方案,希望与大家讨论完善,后续可以针对一些重要的点进行突破和落地,最终产出一整套国际化方案。

国际化的目的

简单的说一个国外网站被你打开却以为是国内公司开的,那么这个网站的国际化就做的非常成功。

所以国际化的目的就是:让各个地区的人都能感受到这个网站像本地的网站一样,亲切、易用。

然而这个目标很难实现,在做调研的时候,亚马逊属于国际化比较好的网站,开设分站并在主要几个国家都有专门的运营团队等,然而让普通人打开这个中国亚马逊,还是能感受到与淘宝、京东的不同。

即便是无法完全实现目标,我们仍然可以用技术以较低成本来尽可能改善体验,因此还是有一定的价值来探索这个。

国际化的流程和步骤

一个其他地区的人访问我们的网页,然后最终得到一个国际化友好的网页,这个过程发生了什么?这个过程有哪些问题和解决方案?下面就来整条链路的梳理一下。

针对来源判断用户所属区域

当这个用户访问的时候,我们要获取该用户所属地区,然后拿到相关语言和习惯然后才能进行下一步处理。因此可以有两种方法:

  • 入口 URL 附带相关参数。
  • 通过 IP 地址进行判断。

第一种方法适用于引导页进行跳转,使用范围比较小。初次访问的判断方法最好是 IP 判断的方式进行。我们已经有一套 IP 库:http://ip.taobao.com/ ,后端也有相关接口,初次访问的人可以用这种方式进行粗略的定位,因为 IP 肯定会有误差。

记录 Cookie 并提供用户切换地区、语言的功能

访问之后,我们可以粗略拿到该用户所在的地区,因此可以回写一个 Cookie 来保存当前用户的一些信息,通常比较重要的信息有:

  • 地区
  • 语言
  • 货币

这几个信息组合就可以像 sku 那样,共同确定唯一的一个信息,所以我起了个名字叫『唯一地区语言定位串』。但是目前缺乏一套一致的数据规范,因此会产生一些问题:

  • 地区是按国家维度区分还是按区域?香港是表示为 HK 还是 CN?
  • 语言按照什么维度区分?用什么表示?繁体和简体都属于中文,只用中文区分?chinese 和 zh-cn 用哪种表示?

这些信息如果没有一套规范和列表,很难进行统一和推广,如果没有在一开始就全集团统一确定下来,后期就会像 GBK、UTF-8 这样的编码问题一样,后患无穷。

当确定了记录信息和 Cookie 键名之后,只要在集团域名下,大家都可以共享这些信息然后进行后续的国际化处理。

此外,由于 IP 的不准确性以及人口的流动,所以还需要提供用户自定义选择的功能,例如之前国际 UED 团队(之前维护淘宝海外)定制的吊顶:

上面这两步对于基于 Midway 开发的应用,可以以中间件的形式过滤处理直接变成『唯一地区语言定位串』,如果全集团铺开,甚至可以考虑在接入层做这个处理。

针对特定区域进行国际化处理

获取信息只是第一步,下面轮到我们进行国际化处理了。

国际化的处理主要分为两部分:

  • 页面内容改变
  • 页面交互样式改变

按照当地的习惯设计视觉、展示当地的语言的内容等,基本就是国际化处理的核心。这块也是最复杂最有挑战性的部分。

文本内容改变

内容主要有固定文案和动态数据,比如购物车这里:

固定文案的处理比较简单,最常见的方法就是创建一个映射表,用一个标记来表示该文案,然后不同区域下读取不同的文案内容即可。

现在市场上也有非常多类似的工具可以帮你简化这些操作,比如 i18next 等。

比较麻烦的是动态数据这块,在淘宝这个场景下,就是各种商品数据,比如标题、sku 等信息。这些信息怎么进行本地化语言转换就是一个需要突破的问题。即便是看似最简单的繁简体转换,也没有那么简单。有些香港、台湾的惯用语等,并不是单个汉字转成繁体就可以的。更具体的细节可以点击这里

由于目前在考虑做英文站,需要大量英文数据,后端也有考虑批量翻译商品数据直接存入数据库的方式来处理。但这种翻译不够完善,最大的缺陷在于无法对图片的内容翻译。一个淘宝商品详情承载最大信息量的不是商品标题等,而是商品的图片。卖家往往通过在商品图片上打字来介绍这个商品,所以这种批量转换只能在搜索和 SEO 方面能有所价值。对于真实成交和本地化的体验可能没有非常大的效果。

既然商品信息都是卖家提交的,那国际化的内容,能否让卖家自行提交、编辑?这或许是一个最好的突破口,提供给卖家多语言的编辑入口,赋能想要发展国外业务的卖家,在搜索排名上也会更倾向于这些本地化做的好的商家。这样既解决了本地化内容的问题,又促进了卖家的成交,还带给了买家愉快的购物体验。

更进一步,让淘宝真的只是作为一个交易平台,在当地推广,让本地人开店把商品卖给本地人,建立本地商品库,那是更好的一种方案了。

除了商品数据之外,还有一个非常重要不可忽视的就是价格信息。包括货币表示符号、货币单位、价格映射,也是一块比较大的挑战。而稍有差池则会引起强烈的不满。比如类似人民币的这种货币符号,跟日元等比较像,如果没有表述清楚可能会产生一些误解。

图片内容改变

商品图片内容改变的挑战已经在在上面列出来了,所以不再赘述。本节所说的图片是由视觉做的,然后由我们进行控制的图片,比如首焦图:

这种图片的多语言、国际化我们应该怎么处理呢?马上就可以想到:让视觉在做的时候,把相关文案、视觉换一下,做成多张图片就好了,然后由技术进行定向切换图片地址实现。

但跟淘海外支持视觉讨论了下,并没有这么简单。如果要做好一个国际化的突破,是需要非常细致的做,并不是简单的文案转换即可,视觉都要有变化。对于十分重要的场景(双十一等)这样的投入也是值得的。而日常的一些需求,如果这样做就会十分的浪费资源,投入跟产出比比较低。

他介绍了一种更方便实现的思路,希望可以通过技术手段来解决掉这个问题。顺着他描述的需求的原型,我补充了一些更细节的技术实现思路,在这里简单介绍下。

首先活动图片其实是有一些共性的,比如下图:

基本元素就几个:宣传文案、利益点、辅助图片等。其实很容易形成规范固定下来,比如设计时就放这几个元素,然后基于这几个元素设计一张底图,约定好几个文案元素的位置、大小、字体等,然后由运营填写文案。我们的技术工具可以自动把文案翻译并合并到图片上生成多张多语言的图片。然后当请求这个图片时,会自动根据地区进行返回。实在不行也可以手动填写进去,进行定向投放。

再到后面,甚至都不需要视觉资源。运营想要一个活动,利用现有的模板,从高质量图片库中取出辅助图片,放上去定下位置,填下文案就可以了。

这样就可以减少人力资源的投入,也可以很好的实现图片的国际化处理,极大的提高了效率。

交互样式改变

国际化中这也是非常大一部分,正如中国亚马逊,商品内容是中文的,但是视觉和交互没有做好本地化,仍然给人感觉跟淘宝、京东不是一类网站。

对于样式、交互的国际化,马上想到的应该是通过给 body 加『唯一地区语言定位串』相关联的 class 来实现定制。这样也有问题,就是与浏览器强绑定,无法实现跨端复用。当你的内容用在 Native 或者没有 body 标签的地方,就没法用了。

如果用这样一套方案,有两个点需要着重考虑:

  • 根据语系和习惯来定制 class,而不是语言。比如英文和德语都是字母,他们的样式个性化就有共通性,而不需要定义多个 class 重复编写规则,产生冗余代码。
  • 样式是用来适配内容而不是约束内容。中文内容翻译成英文,长度势必会增长,从而产生错位。这就需要在视觉时就要思考到溢出要怎么处理。可以像响应式布局那样流动起来,样式用来适配内容,而不是固定死约束内容展示。

后端的处理在这里会有比较大的优势,就 Midway 而言,可以根据上面解析出来的『唯一地区语言定位串』直接映射到某个区域的 xtpl 模板,实现非常灵活的改变。

国际化的部署服务器

终于到了最后一步,服务器部署国际化。国内的网络都变幻莫测,更别提国外连到国内服务器的网速了。所以我们的服务器也要进行国际化部署。这样就依靠阿里云多造(租)点机房了。

但并不是所有应用都能迁移到国外,有些核心数据还是要在国内机房。那么这么远距离的链接、数据沟通、应用部署又带来非常多的、不可预知的挑战。

最后

整个过程中,除了上面描述的那些问题和挑战,目前我能想到的还有两个:

  • 文件编码
  • 内容不准确性的修正和个性化需要投入的人力成本

目前淘宝由于历史原因还有一些应用是 GBK 编码,GBK 编码显然不能用于国际化、全球化,特殊语言的国家访问看下来全是『口口口口口口口口口口口口口口口口』。或许这也是一个契机,就像升级 HTTPS 那样,推动整个集团去 GBK。

内容和个性化始终需要人力,我们如何能利用技术进一步提高效率解决人力问题?这也是一个挑战。

欢迎你提出一些问题和见解,一起来继续完善下!

附:国际化方案探索脑图