如题。这些都不知道，还谈啥国际化？
1.翻译
产品要国际化，首当其冲就面临一个问题——语言问题。所以必须要翻译。
翻译就翻译呗，有啥要注意的？
总结起来，有这么两点：
从项目进度来看，越早开始越好。因为翻译完成，你才能进入设计、开发；
尽量节省一些翻译费用。
翻译费用其实挺贵的。有多贵呢？来，开开眼：
举个例子：
假如要中译英，翻译一万字（不多吧），费用约200*10 = 2000元。
假如要中译西班牙语，翻译一万字，费用约400*10 = 4000元。
而一个产品往往长期运营，几十万字很正常吧，你看这费用，反正比咱搬砖的工资高。。。
如何节省费用？
说起来也简单：尽量缩减语句，尽量去除标点符号。
为什么？因为翻译社告诉我们：
根据中华人民共和国国家标准GB/T 19363.1-2003 对翻译行业服务规范的要求，中文字数统计是以不计空格字符数为计算单位的。可能我们平时不是很注重标点符号，其实在文字表达中，标点符号的重要不亚于单字单词，一个标点符号可以改变全句话的意思，而我们的工作也是做到了这一点，保证每个标点符号的准确，保证译文表达的意思和原文一样。
看到没？一个标点符号也算一个字。
说到这，还有一个小插曲：翻译社给的依据是国家标准GB/T 19363.1-2003，我去工标网查了下，发现这份标准早已作废，现行的标准是GB/T 19363.1-2008。
不过，计字方法倒没变，国标这么说：
怕翻译社计算错的话，就用office看看字数统计，如下图：
2.切换语言的方式
切换语言看起来很简单，不就是点击、切换？并没有这么简单。
目前主流的切换语言方式有3种：
直接显示语言选择
直接显示国家
显示国家 + 语言选择
所谓「存在即合理」，为何存在这三种？我们的产品应该选择哪一种？这就取决于我们的用户需求与产品目标。说白了，就是需求。
1）直接显示语言选择
例如BURSA MALAYSIA：http://www.bursamalaysia.com/market/
这种方式的适用场景是：
场景1：仅针对1个国家，但这个国家有几种语言。比如马来西亚国内的网站，需要3种语言，就可以做成这种形式。
场景2：针对多个国家，但每个国家只有1种语言。比如美国用英语、中国用中文，语言选择上分别显示英语、中文，点击英语，则切换至针对美国用户的界面；点击中文，则切换至针对中国用户的界面。
场景3：针对多个国家，但提供给每个国家的内容都完全相同。比如马来西亚有英语，美国也有英语，这时马来西亚的用户、美国的用户看到的界面完全相同。
2）直接显示国家
例如苹果：https://www.apple.com/choose-your-country/
这种方式的适用场景为：每个国家仅有一种语言。
PS：苹果官网该页面底部也提供了部分国家的多种语言，比如加拿大的法语、英语。
3）显示国家 + 语言选择
比如：https://www.malaysiaairlines.com/my/ms.html
这种方式的使用场景为：不同国家用户的需求不同，而且提供给不同国家用户的产品也不同，而且同一语言还对应多个国家。这时就要已国家为准。
比如马来西亚，主要语种有3种：马来语、英语、汉语。但你会发现，英语和汉语在多个国家都会使用。假如提供给马来西亚的英文内容与提供给美国的英文内容不同，就不能直接通过语言来切换，而应以国家为切换标准。
3.URL
别看URL很简单，也有一些注意点。
PS：这些注意点主要针对SEO。
对于不同语种，主流的URL使用方式有3种：
1）不同语种网站完全独立，放在不同国家域名上
例如：ITDoer.com、ITDoer.cn、ITDoer.com.co.jp。谷歌采用的就是这种方式。
采用这种方式，优点在于用户和搜索引擎都能很好地识别地理位置，但网站完全独立，推广上需要独立推广，耗时费力。
2）不同语种网站放在主域名的子域名上
例如：en.ITDoer.com、zh.ITDoer.com。维基百科采用的就是这种方式。
采用这种方式，优点在于可以继承一些主域名的权重，但网站完全独立，推广上需要独立推广，耗时费力。
3）不同语种网站放在主域名的二级目录下
例如：ITDoer.com/en/、ITDoer.com/cn/。苹果采用的就是这种方式。
采用这种方式，优点在于二级目录完全继承主域名的权重。
但有人也说用户和搜索引擎都可能对网站语种产生一定程度的混淆，有的还说不同二级目录很难放在不同国家的主机上，技术上实现比较困难。不过这种方式其实很常见，个人认为可以采用。
4.两类数据
产品国际化，必然会面临如下两类数据。这两类数据直接决定了表结构设计。如果这点没考虑到，就会被开发哥哥怼死……
独立数据
公共数据
1）独立数据
例如对于微信的「朋友圈」这个按钮，不同语言对应的数据就是独立的。你在中文界面看到的是「朋友圈」三个字，而在英文界面则看到的是「Moments」。
对于独立的数据，处理起来很简单：
前端——翻译所有字段名，写死即可。
当然，「朋友圈」按钮并不对应后台数据。不过我们可以假设「朋友圈」按钮的值取自后台一个字段X，那中文的后台就会输入「朋友圈」，而英文的后台则会输入「Moments」。
2）公共数据
比如微信用户名。不论你把微信的语言改成什么，你的用户名都不会变。
但公共数据还得进一步细分：
a.不变的公共数据
比如用户头像、用户名、用户个性签名、手机号码、邮箱等。这类数据如果随语言变化，就失去了原本的意义。
b.可变的公共数据
比如性别、温度单位、地区名。
对于性别，用户将中文字段 [性别] 设置为”男”，那么英文就会将字段 [性别] 显示为字段 [gender]，而且其值为显示为”male”。
不变呢？其实用户也能看懂——因为用户肯定会选择他熟悉的语言，更何况有些可变的公共数据还是用户自己设置的信息，他若不熟悉，如何设置？
另外，开发哥哥还告诉我：前后端字段对应，才能做成一张表，才能做在后台的同一个模块。
也就是说：不同语种的网站字段如果不同，就不能共用一个后台模块，就必然导致数据的独立。
