这些都不知道产品还怎么国际化

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