|
经过 4 年的准备和讨论，欧盟议会于 2016 年 4 月 14日批准通过《一般数据保护条例》，在 2018 年 5 月 25 日正式实施，届时不满足数据隐私要求的公司将面临千万欧元级别的重罚。以目前情况来看，达到欧盟要求的产品屈指可数。
△ General Data Protection Regulation，一般数据保护条例，欧盟 其他国家地区的隐私情况将在本地化部分提及，在此不赘述。 最佳实践 3.3.1 从底层架构开始考虑数据隐私保护，并遵照当地法律法规进行调整。 另外是关于移动产品索取用户系统权限的，用户对权限的认识逐渐加深，对于非必须的权限将予以抵制。 新装 APP 需要敏感权限，直接降低安装转化率。 升级 APP 需要新增权限，直接影响升级率。 最佳实践 3.3.2 尽量少的索取系统权限。 四. 地区标准 由于历史原因和现实原因，世界各地的标准并不是完全一致的，这为我们的产品设计也提出了复杂的挑战。 主要问题有： 各区域相关标准习惯差异极大，而转换工具复杂容易出错 各区域历法、时间概念不同 各区域数值、度量衡、相关格式不同 各区域货币不同，支付结算方式复杂 各区域有独立的商标、知识产权、市场许可等要求 1. iSO 与 CLDR iSO，国际标准化组织已经尽可能的将标准进行统一，如果不是极其特殊的情况，请务必遵守，这能将你的产品尽可能的兼容各大平台和其他产品的接口。例如，语言代码、区域代码、货币名等等。 International Organization for Standardization
△ iSO 国际标准化组织 最佳实践 4.1.1 务必采用 ISO 系列标准。 CLDR，通用语言环境数据仓库用于格式化和解析区域的特定模式，已经包含了日期、数字、货币、语言、复数、性别、键盘布局等等内容，可以大大加快数据格式本地化的过程。 CLDR – Unicode Common Locale Data Repository 最佳实践 4.1.2 务必优先使用 CLDR 整合的数据仓库进行本地化处理。 以上工作的一部分已经由 iOS 和 Android 的系统平台完成了，请确保优先使用。 2. 日历、日期、时间、时区 好在世界上绝大部分地区都能理解现行公历，一般产品以公历为基础即可。 优秀的本地化产品会根据用户本地系统的设置进行优化展示，这需要具备完备的通用时间体系。主要有几点： 采用通用的 API 进行时间处理 统一使用基于 UTC 的时钟进行后端运算，将结果转换为用户前台本地时间展示 注意时区、夏令时的影响
△ UTC 时区
△ iOS 日语、阿拉伯语日历 最佳实践 4.2.1 在采用 UTC 统一时间基础上，使各地用户能够清晰理解所表达的时间。 除此之外，世界各地的每周休息日可能不同，每周的第一天也可能不同。 3. 数值、度量衡 遗憾的是世界上并不仅仅使用 0-9 这套数字体系，还有非常多其他的数字体系正在使用中。
世界上即便使用其他数字的地区，在今天也能理解「0-9」的数字概念。
△ 沙特阿拉伯 车牌示例
△ 伊朗 本土某电商界面示例 最佳实践 4.3.1 建议使用「0-9」的数字体系，在本地化版本中可以使用本地数字。 数值的常见本地格式还包括： 小数点 千分位 负数 百分号 缩写
△ 小数点格式分布
△ 某土耳其语 APP 页面 最佳实践 4.3.2 请参考 CLDR 中各区域的格式，不能强行一套方案。 在计量单位方面，以「米-千克-秒制」为基础的国际单位制应用于绝大部分国家地区。 美国，采用美式英制单位，如英里、英寸、加仑、盎司等 利比里亚和缅甸，采用英制单位 所有其他国家地区，采用国际单位制
△ 注意计量单位 最佳实践 4.3.3 计量系统应采用国际单位制，仅在美国地区使用美式英制单位。 4. 货币 RMB 并不是国际上通用的人民币缩写，而是由iSO 4217 定义的 CNY。同样的，为了避免出现其他标准上或理解上的错误，建议统一使用 iSO 标准。
△ 某汇率产品界面 最佳实践 4.4.1 应使用 iSO 4217 货币代码，配合本地语言使用。
△ 某产品账单界面 不建议直接使用符号代表货币，如「￥」有可能是人民币，也有可能是日元。 一般建议只使用本币，辅助货币直接换算，如人民币 5 角应计为 0.5 元，80 撒丹应计为 0.8 泰铢。 5. 其他本地格式 在这里仅列出需要考虑的本地格式列表，详细内容不再描述。 日期、时间、时区、历法、 数字、货币 姓名规则 电话、邮政、地址格式 键盘 印刷、纸张 6. 法律要求 商标、知识产权、市场许可是进入一个目标市场必须考虑的法律问题。 根据产品或服务的业务形态，还需要考虑细分场景的法律规章。
△ 因商标原因，Pokémon 中文译名定为精灵宝可梦
△ 2017 年 5 月 微信在俄罗斯被禁用 (责任编辑：admin) |
