在国际化方面，产品的内容文字由用户自由决定，一般不受限制也没有必要限制。从运营角度，可以考虑按照地域进行内容划分隔离，以便更有效地传播内容。

　　当然也可以像 Facebook、Twitter 或是 Google Play 一样提供内容辅助翻译。

　　点击「翻译自英文」后，系统会将内容翻译为本地语言提供。

　　或者由用户自行选择内容来源。

　　△ Twitter 可自行更改内容源

　　3. 书写顺序

　　最佳实践 1.2.1

　　全球化的产品应当能正确处理 RTL 语言。

　　△ 阿拉伯语示例文本

　　RTL(Right to Left，从右到左)语言指的是从右侧向左侧书写的语言。

　　这些语言包括：

　　阿拉伯语

　　希伯来语

　　波斯语

　　乌尔都语

　　意第绪语

　　迪维西语

　　语言的普遍特征有：

　　句子从右到左阅读

　　事件发展顺序从右到左进行

　　左箭头 ← 表示向前运动，右箭头 → 代表向后运动

　　使用这些语言的人口数量相当大，特别是在波斯湾地区由于石油经济发展特别迅速。对于面对中东地区出海的产品，是不能回避的问题。

　　针对 RTL 语言的通用设计原则有：

　　在代码中声明 RTL

　　将整体界面左右镜像

　　左右箭头代表的前后含义相反

　　涉及方向的图标需要镜像

　　文本资源基本右对齐

　　不进行镜像的有，不传达方向的图标，如 Email;LTR 数字、不需翻译的外文;图像、时钟、拟物、禁止符

　　至于某种特定的语言情况，会在对应的本地化部分提及。

　　4. 文法

　　复数与阴阳性

　　相信你已经了解了英语的复数情况，1 book 与 2 books 的单词形式不同。如果每一个涉及数量的单词都使用 if 来判断实在是过于繁琐，更何况还有更复杂的复数情况：

　　△ 俄语名词变格表

　　完美匹配世界上所有语言的文法几乎是一项不可能完成的任务，不信来看 Language Plural Rules ，这里记录了绝大部分常用语言的复数、序数以及数字范围规则。

　　好在系统平台已经提供了相当完善的接口，配合本地化团队可以满足文法需求。

　　最佳实践 1.3.1

　　优先调用系统级的本地化字符串处理函数进行处理。

　　请联系你的开发人员查看以下本地化字符串文档：

　　iOS：Localizing Your App – Handling Noun Plurals and Units of Measurement

　　Android：字符串资源 | Android Developers

　　概括来说，需要本地化团队将对应的复数变化情况全部列出来，程序会根据接口获取到数字所对应的语言复数情况。

　　%d song found.

　　%d songs found.

　　如果你的产品实在是不愿意在这方面投入资源，也有一些取巧的方法：

　　最佳实践 1.3.2

　　勉强也可接受复数无关的界面排版模式，如 Message (10) 或者 10 book(s) 等。

　　不推荐。但如果完全不处理复数和阴阳性问题，将缺失语言本地化的重要一环。

　　大小写

　　语言之间具有各种细微的差别，虽然看上去微不足道，但却可能对产品和功能设计产生巨大影响。例如，在俄语中，一周中的名称不能首字母大写，如果将「星期三 среда」首字母大写，含义就变为「环境 Cреда」，将「星期日 воскресенье」变为「复活 Воскресение」;或是英语中的「瓷器 china」与「中国 China」。

　　主要有以下情况：