微信遭禁的原因，是其服务商没有在法律规定的期限内向相关机构提供信息转播服务组织者的有关数据信息。此外，微信也未在俄相关政府部门进行正式登记。在禁用约一周后解除封锁。

　　最佳实践 4.6.1

　　与市场部门验证所有商标声明，确定获取当地运营所需要的知识产权和市场许可。

　　了解并遵循当地市场的法律要求，在出现问题时及时与政府沟通。

　　五.开发技术

　　从开发的角度同样有很多细致复杂的工作，本篇更着重于设计，所以主要是作为产品方需要在开发合作时需注意的方面。

　　主要问题有：

　　区域性编码转换复杂，支持东亚 CJKV 需要额外技术挑战

　　产品迭代过程中与本地化团队协调复杂

　　需翻译的文本难以对应上下文和位置

　　用户界面隔离的具体实现繁琐

　　1. 字符编码

　　在字符集方面，不要去碰那些地区使用的字符集，如 Big 5、VISCII 之类的，从代码到数据都要使用 Unicode 统一编码。

　　Unicode Consortium

　　最佳实践 5.1.1

　　务必采用 Unicode 编码。

　　△ 「三国志曹操传 → 瓣B变巨肚」Big5 码转 GB 码导致

　　△ 字符编码不匹配

　　2. 本地化团队合作

　　本地化团队不仅仅是进行当地语言的翻译工作，而是一个完整的项目工程。

　　Fly 应该翻译成什么?

　　初级的本地化工作就是将一份整理好的待翻译文档提交给翻译团队，翻译好再导入到程序内。一是合作复杂，难以快速迭代;二是翻译难度大，很多文本缺乏上下文难以精确翻译。

　　如果可以的话，建议以英语为基础语料，甚至为部分文本提供相关的备注便于翻译。

　　最佳实践 5.2.1

　　应该提供一套创建、翻译、打包的标准流程，在其中能够识别目前多语言文档的增删改情况，并能够查找文本对应用户界面的机制。

　　△ 某产品的本地化工具

　　建议你与同一个本地化团队保持长期合作。

　　3. 用户界面隔离

　　为了避免产品的一点修改都需要对整个产品的全部流程全部地区进行调整，请务必将产品的多语言部分与程序主体隔离。

　　最佳实践 5.3.1

　　必须将代码逻辑层与内容表现层隔离。

　　△ 将本地文本与可执行代码隔离

　　△ 某游戏的本地化资源存储方案

　　基于 Key – Value 的多语言文档目前最为常见和实用。

　　也可以参考 iOS 本地化(Localizing Your App) 和 Android 本地化(Localizing with Resources)相关内容。

　　最佳实践 5.3.2

　　各国家地区拥有独立用户界面资源，包含语言文字，图标图像，样式文档等内容。

　　在本地化团队介入前解决大部分国际化问题，可以先通过伪语言包进行测试。毕竟本地化还是成本很高的。

　　附录

　　最佳实践清单

　　1.1.1 请把英文作为产品无法匹配语言时的默认语言，也应当以英文版本为基本款进行设计。

　　1.1.2 应用内自主更换语言更能满足设计和用户的需求。

　　1.1.3 不要采用旗帜图标指示语言。

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

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

　　1.3.2 勉强也可接受复数无关的界面排版模式。

　　1.3.3 不能仅用大小写来传达某种必要信息。

　　1.3.4 如果涉及到程序转换大小写的情况，务必需要先判断语言类型。

　　1.4.1 注意将标点符号转换为本地方案，并特别注意换行时的标点位置。

　　1.5.1 在排序和组织内容方面，请确保使用 Unicode 的规范化处理方式。

　　2.1.1 不要将文字直接嵌入图片或视频媒体中，应当分别以较小个体进行存储，便于替换。

　　2.1.2 不建议复用同一资源，某些本地化资源也许并不能一一对应。

　　2.2.1 文字与组件必须分隔排版，不使用基于语言元素的拼接组件。

　　2.3.1 为所有文字预留足够的空间，并且设置溢出情况下的处理方法。

　　2.3.2 尽量采用简洁的描述，并且提醒本地化团队节约使用空间或设置限制。

　　2.4.1 界面文字尽量采用系统默认匹配的字体。

　　2.4.2 少用、慎用粗体、斜体、下划线等样式。

　　3.1.1 避免使用冷幽默、双关、熟语、俚语等过于本地化的内容，少用术语、缩略语。

　　3.1.2 尽量采用各大平台原生的标准图标，或基于标准图标进行重设计。

　　3.1.3 避免使用宗教、神话相关的内容、标志、符号等。

　　3.1.4 避免使用身体、手势来表示含义。

　　3.2.1 尽量避免涉及民族、地缘、宗教、政治的敏感信息，注意收集本地化团队的建议。

　　3.2.2 不要使用*情、暴力相关内容，需注意赌博、瘾品等内容。

　　3.3.1 从底层架构开始考虑数据隐私保护，并遵照当地法律法规进行调整。

　　3.3.2 尽量少的索取系统权限。

　　4.1.1 务必采用 ISO 系列标准。

　　4.1.2 务必优先使用 CLDR 整合的数据仓库进行本地化处理。

　　4.2.1 在采用 UTC 统一时间基础上，使各地用户能够清晰理解所表达的时间。

　　4.3.1 建议使用「0-9」的数字体系，在本地化版本中可以使用本地数字。

　　4.3.2 请参考 CLDR 中各区域的格式，不能强行一套方案。

　　4.3.3 计量系统应采用国际单位制，仅在美国地区使用美式英制单位。

　　4.4.1 应使用 ISO 4217 货币代码，配合本地语言使用。

　　4.6.1 与市场部门验证所有商标声明，确定获取当地运营所需要的知识产权和市场许可。

　　5.1.1 务必采用 Unicode 编码。

　　5.2.1 应该提供一套创建、翻译、打包的标准流程，在其中能够识别目前多语言文档的增删改情况，并能够查找文本对应用户界面的机制。

　　5.3.1 必须将代码逻辑层与内容表现层隔离。

　　5.3.2 各国家地区拥有独立用户界面资源，包含语言文字，图标图像，样式文档等内容。

　　以上是全球化设计中的国际化问题，还不能说是尽善尽美，加之随着时间推移还会有新的挑战或是更优雅的解决方案，会努力进行动态更新。