一、设计与开发的区别
当企业研发一个产品的时候，团队的结构或者智能一般是这样的:
从另外一个纬度看：如果把一个产品变成现实，大致分这么七个步骤:
• 设计有很多种类，例如架构设计、程序设计、交互设计、游戏中的策划等，常常由不同的角色负责。
• 我们讨论的范围包括将产品完成设计（想法、框图、交互设计）和开发（架构、编码实现）的整个过程。
我们遇到过国际化一些问题，程序设计出来后，发现做本地化很困难，要求修改源代码和设计。开发团队就很疑惑，“我们开发出来的东西，你们照着做，怎么还能反过来要求我们呢？”
• 总的来说，如果在某一个语言上碰到问题，那可能是本地化的问题。如果好几个语言上都有问题，那可能是国际化的问题了。
二、国际化设计和开发注意事项汇总
支持目标市场的语言文字是进入该市场的先决条件，虽然某些市场只需要发布一个英文版本就万事大吉，但这还远远不够。
主要问题有：
• 如何理解语言、文字、区域的概念？
• 如何设计选择语言的机制？
• 在语言前面加上国旗图标是最好的选择吗？
• 如何设计 RTL 语言（如阿拉伯语、希伯来语）的用户界面？
• 某些语言有不熟悉的文法体系，比如复数、阴阳性该如何处理？
• 标点符号不是国际通用的？
• 在某些文字体系中，难以对内容进行排序或首字母分组。
优秀的国际化产品，能够让产品在移植到其他区域时能够快速而健壮的使用，例如 Google 搜索、Facebook 并不需要到一个新地区就重新开发一个版本。
• 如果您投身于全球化的产品设计，主要需要从 5 个大方面进行思考：
• 语言文字
• 用户界面
• 文化差异
• 地区标准
• 开发技术
即便您正在设计一款不那么全球化的产品，思考这些问题仍能够使你的产品更健壮。
2.1、语言文字
语言、文字和区域是三种不同的概念，比如：
• “汉语”，采用简体汉字书写，用于中国大陆。
• “葡萄牙语”，采用拉丁字母书写，用于巴西。
• “英语”，采用拉丁字母书写，用于美国。
• “印地语”，采用天城文书写，用于印度。
了解语言、文字和区域这三种不同的概念有助于避免发生一些低级错误，以及理解语言方面的最佳实践——语言识别标签（也叫语言代码）：
• zh-Hans-CN
• zh-Hant-HK
• pt-BR
• en-US
• hi-IN
在设计产品时需要考虑两个部分的本地化展示：
• 界面文字
如「登录」「评论」「首页」等用于产品功能的文字，它们相对稳定。
• 内容文字
如「塞尔达传说旷野之息出官中了！买爆！」等由用户或媒体发布内容的文字，它们一般不受控制。本截图的界面文字为中文，内容文字为英文。
最主要的是界面文字，能够以该文字显示界面，一般就可以宣称支持对应的语言了。毫无疑问的，支持国际化的第一步是支持英文。
• 语言切换按钮
多语言版本界面上，要多一个语言切换按钮，按钮最好用本国的语言显示。
能“看到自己的语言”很重要，下图为iPhone手机语言设置界面 
请把英文作为产品无法匹配语言时的默认语言，也应当以英文版本为基本款进行设计。这有助于你在第一时间覆盖最广泛的区域，并且规避一些全球化的问题。
在用户切换语言的机制方面有两种选择：
•能够在应用内部自主选择界面语言。
•跟随系统设置是一个较为保险的方案。Facebook、Google等产品一般都选这个方案。
但一般产品难以覆盖足够广的语言，并且从用户的角度来看，一旦系统语言未匹配，还有自行更改为用户第二语言的可能，这样更为灵活。应用内自主更换语言更能满足设计和用户的需求。但是要避免一些惯性思维的问题：
下图为支付宝国际版界面截图（2017-09-22）（怎么切换界面语言，Language是什么意思？） 
注意⚠️：
不要采用旗帜图标指示语言。
葡萄牙人，只能选择巴西国旗的葡萄牙语？中国人用繁体字，就要选择台湾的“中华民国”的国旗？
存在有几个问题：
• 难以让旗帜和语言一对一映射；
• 用户可能被迫需要选择一个他国前缀的选项；
• 可能引起地缘政治的争议；
• 旗帜可能随着时间的发展而被替换，有更换成本。
虽然旗帜图标在选择效率上会略有提高，但仍然不建议使用。但也有例外，当选择区域时，例如 Apple 官网。
在国际化方面，产品的内容文字由用户自由决定，一般不受限制也没有必要限制。从运营角度，可以考虑按照地域进行内容划分隔离，以便更有效地传播内容。当然也可以像 Facebook、Twitter 或是 Google Play 一样提供内容辅助翻译。
点击「翻译自英文」后，系统会将内容翻译为本地语言提供。
2.1.2、书写顺序
RTL（Right to Left）语言指的是从右侧向左侧书写的语言。这些语言包括：
• 阿拉伯语
• 希伯来语
• 波斯语
• 乌尔都语
• 意第绪语
• 迪维西语
插图左为某希伯来语 APP、右为Android 波斯语设置界面
使用这些语言的人口数量相当大，特别是在波斯湾地区由于石油经济发展特别迅速。对于面对中东地区出海的产品，必须能正确处理RTL语言。
插图：阿拉伯语示例文本
1. RTL语言的普遍特征有：
• 句子从右到左阅读；
• 事件发展顺序从右到左进行；
• 左箭头 ← 表示向前运动，右箭头 → 代表向后运动。
2. 针对 RTL 语言的通用设计原则有：
• 在代码中声明 RTL;
• 整体UI界面，涉及方向的图标需调整：
••将整体界面左右顺序调整；
••滚动条出现在界面左侧；
••文本资源基本右对齐；
••左右箭头代表的前后含义相反，右箭头 ”→ ”代表“后退”。
3. 通常不调整的有：
• 不传达方向的图标，如 Email；
• 通常用右手拿着的物品的图标，如 电话；
• LTR 数字、不需翻译的外文；
• 图像、时钟、拟物、禁止符。
截图：某阿拉伯文的手机界面
2.1.3、语言层面
<1>、我们都知道英语的复数情况，例如：1 book 与 2 books 的单词形式不同。如果每一个涉及数量的单词都使用 if 来判断实在是过于繁琐，更何况还有更复杂的复数情况，如法语里的阴阳性、俄语里的六七格。
<2>、 由于中文中很少涉及到单复数和格数问题，而这两方面又是纯粹语言学的内容。在设计和代码开发时需要特别注意。
推荐本地化团队将对应的复数变化情况全部列出来，程序会根据接口获取到数字所对应的语言复数情况。
< item quantity="one">%d song found.< /item>< item quantity="other" >%d songs found.< /item>
截图：程序会根据接口获取到数字所对应的语言复数情况
<3>、匹配所有语言的文法几乎是一项不可能完成的任务， Language Plural Rules 里记录了绝大部分常用语言的复数、序数以及数字范围规则。好在系统平台已经提供了相当完善的接口，配合本地化团队可以满足文法需求。
优先调用系统级的本地化字符串处理函数进行处理。请联系你的开发人员查看以下本地化字符串文档：
• iOS: Localizing Your App – Handling Noun Plurals and Units of Measurement
• Android: 字符串资源 | Android Developers
<4>、如果一句话里出现多个变量，在本地化翻译的时候会遇到句子顺序颠倒和复数、格数问题。尽可能有结构化的内容表述有多个变量的句子。
“（张三）给了（李四）（30）元。”
这句里面“张三”、“李四”、“30”都是变量。建议设计成结构化的表述，如图: 结构化表述
2）、大小写
语言之间具有各种细微的差别，虽然看上去微不足道，但却可能对产品和功能设计产生巨大影响。例如，在俄语中，一周中的名称不能首字母大写，如果将「星期三 среда」首字母大写，含义就变为「环境 Cреда」，将「星期日 воскресенье」变为「复活 Воскресение」；或是英语中的「瓷器 china」与「中国 China」。
主要有以下情况：
• 1. 某些语言的大写字母与小写字母不是一一对应的。例如，德语 ß 的大写形式在印刷时代曾经是 SS（终于在 2017 年 6 月正式将单字符 ẞ 加入官方正字法中）或是希腊语中的 Σ 的小写形式根据位置有两种书写形式 σ 或 ς。
• 2. 有些字符根据语言不同，有不同的大小写映射关系。典型的是英语中 i 对应的大写是 I ，但在土耳其语中却各有其大小写： ı 与 I、i 与 İ，如果对 i 进行大写转换，那么一定要先判断语言类型，再进行转换。
• 3. 大多数非拉丁字母不适用小写和大写的概念。例如汉字、谚文、泰文、阿拉伯字母等，如果强制对这类文字进行大小写转换，可能导致意外的字符或乱码出现。
• 注意⚠️：不能仅用大小写来传达某种必要信息，例如，可供交互的按钮还需要其他样式标明。
截图：Material Design 中要求按钮将字母全部大写，并同时要求其他语言需要用色彩进行区别。
• 如果涉及到程序转换大小写的情况，务必需要先判断语言类型。
3）、标点符号
截图：思源宋体在各语言下的问号
即便是代表同一含义的标点，在不同语言中可能有不同的展示形式或排版要求。特别是在不同语言情况下，对于标点的排版要求可能大相径庭。
截图：逗号
某些标点使用方法不同，如西班牙文中的叹号和问号需前后使用：
• ¡Hola!
• ¿Qué edad tienes?
某些标点在不同语言中样式不同，如逗号：
• 简体中文 U + 3001（居左下）
• 繁体中文 U + 3001（居中）
• 英文 U + 002C
• 阿拉伯文 U + 060C
这些例子还有很多：
• 某些标点不能放置于行首或行尾，如中文里逗号不在行首，前引号不在行尾；
• 某些语言不使用空格作为词间间隔，如中文、日文、泰文；
• 某些语言基本不使用或是很少使用标点符号，如泰文、印地天城文、文言文等。
总的来说，本节主要考验的是本地化团队。但可以利用翻译工具自动解决大多数问题，比如用memoQ里的QA功能，自动检查标点符号错误 。
注意⚠️：注意将标点符号转换为本地方案，并特别注意换行时的标点位置。
4）、内容组织
由于语言大多使用不同的字符，将导致传统的分类和排序出现意外情况。
• 请注意右侧的快速预览，在不同语言版本下，会根据各自语言情况进行调用。换句话说，在涉及到字符排序或者首字母分组的情况下，不能仅考虑「A-Z」的规则。
截图：iOS 日语、俄语通讯录界面示例
注意⚠️：在排序和组织内容方面，请确保使用 Unicode 的规范化处理方式。
此外，还需注意以下影响因素：
• 多音字，如中文；
• 变音符号、标记等，如法文、阿拉伯文等；
• 多语言同时使用时，同一字符的不同代表含义。
2.2、用户界面
在具体的界面设计上，设计师需要面对极其复杂的兼容性问题，考虑如何健壮地应用文字、图片、视频、组件等。主要问题有：
• 本地化团队难以处理嵌入式图片、视频中的文字；
• 由于文字长度不同、语法语序调整，组件变化幅度较大；
• 不同语言的文字形式长度相差较大，导致版式错乱；
• 用户有可能缺失预设的字体；
• 复杂文字很难找到小字号的字体。
2.2.1、图片与文字分离
• 在后台，图片与其上的文字分别术语不同的内容区，降低图片再制作的周期和成本。
• 虽然我们可以为所有地区各自定制一个独立的版本，但国际化设计的本意就是使一个设计结构能够尽可能多的服务更广泛的地区。为了便于本地化团队进行本地化处理，设计和开发应当将UI节资源与逻辑代码相分隔，替换本地资源时必须不会影响逻辑代码。
• 截图：某产品的双语版本，本地化资源易替换
注意⚠️
• 不要将文字直接嵌入图片或视频媒体中，应当分别以较小个体进行存储，便于替换。
• 一般来说，图片上的文字建议采用分层展示，也就是可以在不替换图片的情况下，通过简单替换字符串即可满足需求。特别的，此处的文字可以为栅格后的图像（如上图中的 LUNA ），在这里更关心在最小的影响下替换资源。如果是特别为某个地区进行的本地化图片，那不妨嵌入，没有大碍。
• 不建议复用同一资源，某些本地化资源也许并不能一一对应。
• 简化的例子，“我”在英语中对应几种说法：I / me / myself，也许在中文界面可以使用同一字符串，但对应的英语情况可能需要进行分别考虑。
截图：图标虽小-也需要替换
• 同时需要注意，尽量不要在图标上直接应用文字，不但替换繁琐，还有长度等限制。
2.2.2、组件分离
通过变量字符拆解语句构成的用户表单，在不同语言的文法系统下可能无法应用。
注意⚠️
• 文字与组件必须分隔排版，不使用基于语言元素的拼接组件。
截图：左侧：组件与文字混排 右侧：组件与文字分离
截图：某游戏的本地化问题 
2.2.3、文字占位空间
在国际化过程中最常见的问题是翻译后的文字和预留空间之间的矛盾，俗称“爆框”。
截图：爆框
注意⚠️
为所有文字预留足够的空间，并且设置溢出情况下的处理方法。
需要处理的问题：
• 定宽组件上的文字过长；
• 变宽组件本身由于变化导致错位；
• 文字换行导致的错位。
• 直接缩写或采用省略号“…”的方案并不友好。
截图：某产品的英文版本（2018-04-03）
注意⚠️
• 尽量采用简洁的描述，并且提醒本地化团队节约使用空间或使用memoQ翻译软件在翻译时就设置字符长度限制。参考“多维翻译质量管理”
截图：以汉字为参考，建议预留的长度
• 保留足够的显示空间；
• 各种语言有不同的长度，适当保留合适的长度，同时要给出不同的格式要求；
• 以中文为参数基数，通常英文比中文长、德文普遍比英文长。
2.2.4、
要避免用户缺失产品预设的字体。
注意⚠️
界面文字尽量采用系统默认匹配的字体。如果有必要，可以将特殊字体的文字转换为图像进行展示。
截图：iOS 与 Android 常用字体
不是所有的字体都内含了粗体和斜体，虽然部分软件或系统提供了算法加粗或倾斜，但效果较差。设计师并不能确保本地化后的文字是否有足够品质的粗体和斜体，另外部分语言的强制粗体或斜体会导致可读性下降，如不应当使用中文的斜体。所以在设计原生版本时，也要少用粗体和斜体。
而下划线除了推荐应用于网页超链接中，本身就不太建议用于移动产品，更大的问题是不适合某些类型的文字，如内含下划线的印地天城文。
截图：含下划线的天城文
注意⚠️
少用、慎用粗体、斜体、下划线等样式。
对于拉丁语系设计师来说，需要注意东亚文字 CJKV 一般由于字形复杂而难以找到较小字号的字体，通常 12 号是最低尺寸。
字体不同
不同语言文字大小不同、字体不同；比如宋体的英文比较难看等。
2.3、文化差异
完全掌握理解各国家地区的文化既不现实也不经济，在这里列出一些通用的设计限制框架。主要问题有：
• 宗教、节日、文化、手势的含义差异较大；
• 涉及到仅母语者/当地人才能理解的内容；
• 容易忽略各地图标、图像、颜色、文化隐喻的不同；
• 某些含义可能无法在另一种文化中简单的表达出来；
• 涉及民族、地缘、宗教、政治的信息容易产生冲突；
• 注意色情、暴力、瘾品内容；
• 用户滥用平台功能发布禁忌内容；
• 当地法律法规或道德文化对隐私要求很高。
2.3.1、隐喻
有很多社会习俗、语言习惯是只有当地人理解的，能够理解并熟练表达这些内容是能融入当地文化的表现。如果是一个本地化的版本，强力推荐你的产品这样做；但在基础的国际化版本下，则不建议使用。
注意⚠️
• 避免使用冷幽默、双关、熟语、俚语等过于本地化的内容，低频术语、缩略语。
截图：John Doe 对于非母语使用者，一般不能 Get 到
•在图形、图像、色彩方面，设计师常用的隐喻也许并不能奏效，经常会有意外。使用异国文化、图形图像时注意收集本地化团队建议
截图：除了美国，世界上大部分邮箱不像这样
•尽量采用各大平台原生的标准图标，或基于标准图标进行重设计。
•尽量采用通用的图形图像，让本地化团队有一定权限针对当地版本去更改，这样的方案会更合适。有一个配色小技巧，对于完全陌生文化的国家地区，可以参考其旗帜的配色。
而在世界大量国家地区中，宗教都占据了重要社会位置，再者有宗教派别引起的冲突，例如印度与巴基斯坦等。
举例来说，「Merry Christmas！」有可能是一句冒犯的祝福，特别是对于犹太民族。在海外由于不确定他人的信仰是否和你相同，民众通常会说「Happy Holiday！」，仅仅在非常确信对方信仰的前提下使用前者。
•避免使用宗教、神话相关的内容、标志、符号等。
身体和手势从古就用于沟通信息，不幸的是和语言一样，在不同文化中代表的含义有所不同。即便是竖拇指、V字剪刀手这类在本文化中正面含义的手势，在其他文化中可能代表非常粗鲁或否定的含义。
OK 手势，在很多区域代表负面含义，近几年又被右翼赋予了“白人至上”的争议含义。
•避免使用身体、手势来表示含义。
2.3.2、禁忌
在世界各个文化中，一般都有禁忌的内容，总体来说主要是宗教、民族、文化、习俗、地缘政治相关的内容，例如，大多数穆斯林国家对于女性着装有要求，严格的教派禁止个人崇拜，所以在广告上都不能使用人像等等。
注意⚠️
•尽量避免涉及民族、地缘、宗教、政治的敏感信息，注意收集本地化团队的建议。
在大多数国家地区，成人内容都将受到不同程度的限制，而和欲望相关的内容在不同地区的开放程度不一。
•不要使用色情、暴力相关内容，需注意赌博、瘾品等内容。
关于阿拉伯地区，我们引用一段来自《中东游戏市场分析：中国厂商出海的第四大区域》里的章节6、“深耕本地化：语言&宗教“来举例：
传统大家的理解是重度用户听不懂英语，所以我们把英语翻译成阿拉伯语就行了。注意这个做法错误的，在中东地区你需要给他们一个背景，一个故事。世界上的阿拉伯地区只有三种语言。阿拉伯语、波斯语和希伯来语，这是从又往左划分的。阿拉伯语比较晦涩难懂，并且阅读习惯为从右至左，要做打电话不光需要做语言的翻译，同时还要在UI上进行调整，美术原画上也要调整。衣服穿的少的女性角色麻烦让她把衣服重新穿上——因为这里是宗教氛围浓重的国家。
同时在电商方面，在产品包装上，一定要精美，最好不要出现中文；如果包装上有女性形象，着装不能太暴露，并且不能出现十字形、六角星造型，要不要出现猪的图案；什叶派特别喜欢蓝色，逊尼派就喜欢绿色。而绿色颜色你最好直接按照沙特国旗的颜色去做，红色就看卡塔尔国旗的颜色就行了，其次受欢迎的颜色是白色、灰色、咖啡色；数字“5”会带来带来“吉祥“，“7”则受人崇敬。
对于内容生产的产品来说，需要采取措施对内容进行筛选过滤。
2.3.3、地缘政治问题
注意⚠️
• 第一个需要注意的是将所有的「国家 Country」改为「国家/地区 Country/Region」，同时不要使用旗帜作为图标。
• 第二个需要注意的是不要在地图中包含有争议的国界线。
2.3.3、隐私
重点指明日本、韩国、美国、欧盟国家对于数据隐私问题特别看重。
•日本：
早在 1996 年，日本开始电子化政府运动时就开始着重保护数据隐私，在几年间不断完善和维护，在 2005 年《个人信息保护法》开始全面实施。
以致在社会风气方面，一般民众也非常注重数据隐私保护，具有极强的意识。
•欧盟：
目前欧盟已经要求必须经用户许可才能使用 Cookie 进行跟踪。
经过 4 年的准备和讨论，欧盟议会于 2016 年 4 月 14日批准通过《一般数据保护条例》，在 2018 年 5 月 25 日正式实施，届时不满足数据隐私要求的公司将面临千万欧元级别的重罚。以目前情况来看，达到欧盟要求的产品屈指可数。
其他国家地区的隐私情况将在本地化部分提及，在此不赘述。
注意⚠️
•从底层架构开始考虑数据隐私保护，并遵照当地法律法规进行调整。
•尽量少的索取系统权限。
另外是关于移动产品索取用户系统权限的，用户对权限的认识逐渐加深，对于非必须的权限将予以抵制。
新装 APP 需要敏感权限，直接降低安装转化率。
升级 APP 需要新增权限，直接影响升级率。
2.4、地区标准
由于历史原因和现实原因，世界各地的标准并不是完全一致的，这为我们的产品设计也提出了复杂的挑战。
主要问题有：
•各区域相关标准习惯差异极大，而转换工具复杂容易出错；
•各区域历法、时间概念不同；
•各区域数值、度量衡、相关格式不同；
•各区域货币不同，支付结算方式复杂；
•各区域有独立的商标、知识产权、市场许可等要求。
2.4.1、ISO 与 CLDR
ISO（International Organization for Standardization），国际标准化组织 已经尽可能的将标准进行统一，如果不是极其特殊的情况，请务必遵守，这能将您的产品尽可能的兼容各大平台和其他产品的接口。例如，语言代码、区域代码、货币名等等。
注意⚠️
• 务必采用 ISO 系列标准。
CLDR（Unicode Common Locale Data Repository），通用语言环境数据储存库 用于格式化和解析区域的特定模式，已经包含了日期、数字、货币、语言、复数、性别、键盘布局等等内容，可以大大加快数据格式本地化的过程。
注意⚠️
• 务必优先使用 CLDR 整合的数据库进行本地化处理。
以上工作的一部分已经由 iOS 和 Android 的系统平台完成了，请确保优先使用。
2.4.2、日历、日期、时间、时区
好在世界上绝大部分地区都能理解现行公历，一般产品以公历为基础即可。
优秀的本地化产品会根据用户本地系统的设置进行优化展示，这需要具备完备的通用时间体系。主要有几点：
•采用通用的 API 进行时间处理；
•统一使用基于 UTC 的时钟进行后端运算，将结果转换为用户前台本地时间展示；
•注意时区、夏令时的影响。
截图：iOS 里的日语和阿拉伯语日历
注意⚠️
•在采用 UTC 统一时间基础上，使各地用户能够清晰理解所表达的时间。
• 除此之外，世界各地的每周休息日可能不同，每周的第一天也可能不同。
2.4.3、数值、度量衡
世界上并不仅仅使用 0-9 这套数字体系，还有非常多其他的数字体系正在使用中。
截图：其他的数字体系
世界上即便使用其他数字的地区，在今天也能理解「0-9」的数字概念。
截图：沙特阿拉伯车牌示例
截图：伊朗本土某电商界面示例
注意⚠️
•使用「0-9」的数字体系，在本地化版本中可以使用本地数字。
数值的常见本地格式还包括：
• 小数点；
• 千分位；
• 负数；
• 百分号；
• 缩写。
截图：世界小数点适用地图
注意⚠️
•请参考 CLDR 中各区域的格式，不要自行制定一套方案。
在计量单位方面，以「米-千克-秒制」为基础的国际单位制应用于绝大部分国家地区。美国，采用美式英制单位，如英里、英寸、加仑、盎司等；利比里亚和缅甸，采用英制单位；所有其他国家地区，采用国际单位制。
注意⚠️
•计量系统应采用国际单位制，仅在美国地区使用美式英制单位。
•度量衡格式。
处理不同的日期格式、货币格式单位。
2.4.4、货币
RMB 并不是国际通用的人民币缩写，而是由 ISO 4217 定义的 CNY。同样的，为了避免出现其他标准上或理解上的错误，建议统一使用 ISO 标准。
截图：某汇率产品界面
注意⚠️
•应使用 ISO 4217 货币代码，配合本地语言使用。
截图：某产品账单界面
不建议直接使用符号代表货币，如“￥”有可能是人民币，也有可能是日元。一般建议只使用本币，辅助货币直接换算，如人民币 5 角应计为 0.5 元，80 撒丹应计为 0.8 泰铢。
2.4.5、法律要求
商标、知识产权、市场许可是进入一个目标市场必须考虑的法律问题。
根据产品或服务的业务形态，还需要考虑细分场景的法律规章。
截图：因商标原因，Pokémon 中文译名定为精灵宝可梦
截图：2017 年 5 月 微信在俄罗斯被禁用
微信遭禁的原因，是其服务商没有在法律规定的期限内向相关机构提供信息转播服务组织者的有关数据信息。此外，微信也未在俄相关政府部门进行正式登记。在禁用约一周后解除封锁。
注意⚠️
•与市场部门验证所有商标声明，确定获取当地运营所需要的知识产权和市场许可。了解并遵循当地市场的法律要求，在出现问题时及时与政府沟通。
2.4.6、其他本地格式
在这里仅列出需要考虑的本地格式列表，详细内容不再描述。
• 日期、时间、时区、历法；
• 数字、货币；
• 姓名规则；
• 电话、邮政、地址格式；
• 键盘；
• 印刷、纸张。
2.5、代码开发
从开发的角度同样有很多细致复杂的工作，主要问题有：
•区域性编码转换复杂，支持东亚 CJKV 需要额外技术挑战；
• 产品迭代过程中与本地化团队协调复杂；
• 需翻译的文本难以对应上下文和位置；
• 用户界面隔离的具体实现繁琐。
2.5.1、字符编码
在字符集方面，不要去碰那些地区使用的字符集，如 Big 5、VISCII 之类的，从代码到数据都要使用 Unicode 统一编码 。
注意⚠️
•务必使用Unicode作为文件编码与文字编码。
Unicode编码，现在普遍来讲不是什么问题，但还是有很多研发不注意这个问题。
如果产品只在当地运行，用任何编码都不会出问题；如果要搬到国外去，就会出问题。
语言编码：
•单字节编码
•多字节编码
•右到左语言RTL
编码演进
•ANSI
•GB2312/Big5
•Unicode（16/32）
•UTF8：可变的编码
UTF8 mb4：开发程序一定要选这个。
2.5.2、与本地化翻译团队合作
本地化团队不仅仅是进行当地语言的翻译工作，而是一个完整的项目工程。初级的本地化工作就是将一份整理好的待翻译文档提交给翻译团队，翻译好再导入到程序内。一是合作复杂，难以快速迭代；二是翻译难度大，很多文本缺乏上下文难以精确翻译。如果可以的话，建议以英语为基础语料，甚至为部分文本提供相关的备注便于翻译。
注意⚠️
• 应该提供一套创建、翻译、打包的标准流程，在其中能够识别目前多语言文档的增删改情况，并能够查找文本对应用户界面的机制。
智能翻译管理解决方案
为中国企业“出海”量身定制多语言智能翻译管理解决方案。
从资源、流程和进度三个纬度集中管理多语言翻译项目。
持续提高多语言内容质量，提高整个项目周期效率。
为了避免产品的一点修改都需要对整个产品的全部流程全部地区进行调整，请务必将产品的多语言部分与程序主体隔离。
资源也叫UI或内容，在界面上能看到的内容。所有的可见信息，内容都抽取出来，单独形成资源文件，与核心代码文件分开。需要文字的时候用程序去引用资源文件。
基于 Key – Value 的多语言文档目前最为常见和实用。也可以参考 iOS 本地化（Localizing Your App） 和 Android 本地化（Localizing with Resources）相关内容。
资源文件的常用格式：xml、Properties、ResX、PO等等。
注意：必须将代码逻辑层与界面资源内容隔离。硬编码会有很大的修复成本。
截图：将本地文本与可执行代码隔离
截图：某游戏的本地化资源存储方案 
注意⚠️
<p>各国家地区拥有独立用户界面资源，包含语言文字，图标图像，样式文档等内容。
在本地化团队介入前解决大部分国际化问题，可以先通过伪语言包进行测试。毕竟本地化还是成本很高的。
2.5.4、其他注意事项
• 注意字符串中的变量问题
• 注意文字的可读性，必要时应加注释进行说明
• 应当建立术语表或者词汇表。这条很关键，但做产品的人一般不关注这个问题，参考术语动态管理。
实际上国际化开发是有规范的，我们按照参考规范做就好了。这个列了三个规范指南：
这是都是前人国际化经验的的总结，可以让我们避免很多坑。
毕竟每个坑要消耗很多钱。
以上内容主要参考国际化本地化学园和顾巍发布在知乎上文章。
本文目录
© Copyright 2023. 大辞科技 沪ICP备17050550号 
沪公网安备 31011402006110号
