产品如何国际化?

如何让你的产品走向世界?我来教你几招!

如题。这些都不知道,还谈啥国际化?

1.翻译

产品要国际化,首当其冲就面临一个问题——语言问题。所以必须要翻译。

翻译就翻译呗,有啥要注意的?

总结起来,有这么两点:

  • 从项目进度来看,越早开始越好。因为翻译完成,你才能进入设计、开发;
  • 尽量节省一些翻译费用。

翻译费用其实挺贵的。有多贵呢?来,开开眼:

举个例子:

  • 假如要中译英,翻译一万字(不多吧),费用约200*10 = 2000元。
  • 假如要中译西班牙语,翻译一万字,费用约400*10 = 4000元。

而一个产品往往长期运营,几十万字很正常吧,你看这费用,反正比咱搬砖的工资高。。。

image

如何节省费用?

说起来也简单:尽量缩减语句,尽量去除标点符号。

为什么?因为翻译社告诉我们:

根据中华人民共和国国家标准GB/T 19363.1-2003 对翻译行业服务规范的要求,中文字数统计是以不计空格字符数为计算单位的。可能我们平时不是很注重标点符号,其实在文字表达中,标点符号的重要不亚于单字单词,一个标点符号可以改变全句话的意思,而我们的工作也是做到了这一点,保证每个标点符号的准确,保证译文表达的意思和原文一样。

看到没?一个标点符号也算一个字。

说到这,还有一个小插曲:翻译社给的依据是国家标准GB/T 19363.1-2003,我去工标网查了下,发现这份标准早已作废,现行的标准是GB/T 19363.1-2008。

image

不过,计字方法倒没变,国标这么说:

image

怕翻译社计算错的话,就用office看看字数统计,如下图:

image

2.切换语言的方式

切换语言看起来很简单,不就是点击、切换?并没有这么简单。

目前主流的切换语言方式有3种:

  • 直接显示语言选择
  • 直接显示国家
  • 显示国家 + 语言选择

所谓「存在即合理」,为何存在这三种?我们的产品应该选择哪一种?这就取决于我们的用户需求与产品目标。说白了,就是需求。

1)直接显示语言选择

例如BURSA MALAYSIA:http://www.bursamalaysia.com/market/

image

这种方式的适用场景是:

  • 场景1:仅针对1个国家,但这个国家有几种语言。比如马来西亚国内的网站,需要3种语言,就可以做成这种形式。
  • 场景2:针对多个国家,但每个国家只有1种语言。比如美国用英语、中国用中文,语言选择上分别显示英语、中文,点击英语,则切换至针对美国用户的界面;点击中文,则切换至针对中国用户的界面。
  • 场景3:针对多个国家,但提供给每个国家的内容都完全相同。比如马来西亚有英语,美国也有英语,这时马来西亚的用户、美国的用户看到的界面完全相同。
2)直接显示国家

例如苹果:https://www.apple.com/choose-your-country/

image

这种方式的适用场景为:每个国家仅有一种语言。

PS:苹果官网该页面底部也提供了部分国家的多种语言,比如加拿大的法语、英语。

3)显示国家 + 语言选择

比如:https://www.malaysiaairlines.com/my/ms.html

image

这种方式的使用场景为:不同国家用户的需求不同,而且提供给不同国家用户的产品也不同,而且同一语言还对应多个国家。这时就要已国家为准。

比如马来西亚,主要语种有3种:马来语、英语、汉语。但你会发现,英语和汉语在多个国家都会使用。假如提供给马来西亚的英文内容与提供给美国的英文内容不同,就不能直接通过语言来切换,而应以国家为切换标准。

3.URL

别看URL很简单,也有一些注意点。

PS:这些注意点主要针对SEO。

对于不同语种,主流的URL使用方式有3种:

1)不同语种网站完全独立,放在不同国家域名上

例如:ITDoer.comITDoer.cnITDoer.com.co.jp。谷歌采用的就是这种方式。

采用这种方式,优点在于用户和搜索引擎都能很好地识别地理位置,但网站完全独立,推广上需要独立推广,耗时费力。

2)不同语种网站放在主域名的子域名上

例如:en.ITDoer.comzh.ITDoer.com。维基百科采用的就是这种方式。

采用这种方式,优点在于可以继承一些主域名的权重,但网站完全独立,推广上需要独立推广,耗时费力。

3)不同语种网站放在主域名的二级目录下

例如:ITDoer.com/en/、ITDoer.com/cn/。苹果采用的就是这种方式。

采用这种方式,优点在于二级目录完全继承主域名的权重。

但有人也说用户和搜索引擎都可能对网站语种产生一定程度的混淆,有的还说不同二级目录很难放在不同国家的主机上,技术上实现比较困难。不过这种方式其实很常见,个人认为可以采用。

4.两类数据

产品国际化,必然会面临如下两类数据。这两类数据直接决定了表结构设计。如果这点没考虑到,就会被开发哥哥怼死。。。

  • 独立数据
  • 公共数据
1)独立数据

独立数据即在前后端代码中,不同语言对应的数据完全独立。

例如对于微信的「朋友圈」这个按钮,不同语言对应的数据就是独立的。你在中文界面看到的是「朋友圈」三个字,而在英文界面则看到的是「Moments」。

对于独立的数据,处理起来很简单:

  • 前端——翻译所有字段名,写死即可。
  • 后台——输入对应字段对应语言的数据即可。

当然,「朋友圈」按钮并不对应后台数据。不过我们可以假设「朋友圈」按钮的值取自后台一个字段X,那中文的后台就会输入「朋友圈」,而英文的后台则会输入「Moments」。

2)公共数据

还有一部分数据处理起来比较麻烦,这就公共数据。

公共数据就是在前后端代码中,不同语言对应的数据是公共的。

比如微信用户名。不论你把微信的语言改成什么,你的用户名都不会变。

但公共数据还得进一步细分:

a.不变的公共数据

比如用户头像、用户名、用户个性签名、手机号码、邮箱等。这类数据如果随语言变化,就失去了原本的意义。

b.可变的公共数据

比如性别、温度单位、地区名。

对于性别,用户将中文字段 [性别] 设置为"男",那么英文就会将字段 [性别] 显示为字段 [gender],而且其值为显示为"male"。

这类数据其实可以不变,但改变语言之后,显然体验更好。

不变呢?其实用户也能看懂——因为用户肯定会选择他熟悉的语言,更何况有些可变的公共数据还是用户自己设置的信息,他若不熟悉,如何设置?

另外,开发哥哥还告诉我:前后端字段对应,才能做成一张表,才能做在后台的同一个模块。

也就是说:不同语种的网站字段如果不同,就不能共用一个后台模块,就必然导致数据的独立。

1条评论 添加新讨论

登录后参与讨论
Ctrl+Enter 发表