国际化思考

支持国际化需要解决哪些问题呢？

• 语言包
• 时区
• 货币

围绕这些问题看看如何解决呢？

语言包

网络上很多关于解决国际化语言包的通用办法，最简单的就是通过读取项目内的语言包配置。

|— locale_zh-CN.ini
|— locale_en-US.ini

JAVA, Go，PHP 都有支持读取配置的方法。

对于少量的有限的语言包这么支持完全OK，但是如果一个公司面向国际化不仅仅是支持网站的语言切换，还可能面向各个业务。这个时候就迫切的需要一个集中管理国际化语言包的部门。

于是我们现在的语言包流程是这样的：
产品需求 》文案审核 》文案推送 》获取文案

产品需求整理出项目中用到的所有文案KEY，然后通过L10N提交所有文案KEY。翻译中心（一批语言专家）将对应的文案翻译成对应的语言。然后L10N会把所有的语言压缩打包放到不同的服务器下。

公司统一管理的服务器，读取的语言包路径也都是统一的。然后通过提供好的SDK去获取文案即可。

这么做有什么好处呢？

• 解藕PRD和RD：RD无需关心文案是否翻译完成，只需要有文案KEY即可继续开发。提高RD开发效率。
• 减少沟通成本：PRD只需要往文案中心增加文案KEY，RD只需要从文案中心获取KEY。中间不需要任何沟通成本。
• 扩展性强：新增国家语言时，不会对原来的项目产生任何影响。

不好的地方：

• 成本变高：运营成本，翻译成本。

这里面涉及到的技术细节有哪些呢？

• 如何保证文案推送服务成功且高效？
• 文案替换后如何保证线上一致性和时效性？

时区

基本知识

更好的了解国际时间传送门

默认的时间戳是从1970-01-01 00:00:00到现在的秒数。不同的国家对应的时区不同。

时区：为了不同地区的人能够按行为习惯表述自己所在的时间，又能够国际化通用。于是提出了时区概念。

GMT：确定时区规则后，会议还规定英国（格林尼治天文台旧址）为零时区。这就诞生了第一个世界时（Universal Time，缩写为UT）：格林尼治标准时间（Greenwich Mean Time，缩写为GMT，又称格林尼治平时）。

GMT 12:00就是指格林尼治天文台当地的中午12:00，而GMT+8 12:00，则是指的东八区的北京当地时间的12:00。

GMT称之为UT0，由于GMT的计算方式存在秒差，后来制定新的标准UT1，UT2。

UTC：协调世界时（Universal Time Coordinated，缩写为UTC。UTC是当前的世界标准时间。

CST (中国标准时间) 是UTC+8时区的知名名称之一，比UTC（协调世界时)提前8个小时与UTC的时间偏差可写为+08:00.

CST可以代表如下四个不同的时区：

• Central Standard Time (USA) UT-6:00：美国标准时间
• Central Standard Time (Australia) UT+9:30：澳大利亚标准时间
• China Standard Time UT+8:00：中国标准时间
• Cuba Standard Time UT-4:00：古巴标准时间

时区代码

当地时区参考

// 北京时间
ti := time.Now()
fmt.Println(ti)
fmt.Println(ti.Unix())
// 纽约时间
locale, _ := time.LoadLocation("America/New_York")
ti = time.Now().In(locale)
fmt.Println(ti)
fmt.Println(ti.Unix())

// 格式化成中国习惯性格式
// fmt.Println(ti.Format("2006-01-02 15:04:05"))

输出：

2022-03-14 15:09:17.607935 +0800 CST m=+0.010896917
1647241757
2022-03-14 03:09:17.614962 -0400 EDT
1647241757

这么做的麻烦之处在于我们需要知道时区才能够转换为当地时间。但是一般业务方只会提供国家或者城市ID。不同的国家展示时间格式也不同，对于一个公司来说为了避免每个开发人员都去了解这些，而且这个过程中出错的概率极大。因此会统一提供SDK调用。如此每个调用方只要下载这个SDK并且通过国家或者城市ID调用其中的方法即可。

公司的做法是：将不同的国家下的城市，通过配置平台以key:value的形式配置好。然后在获取的时候通过拼好的key去获取value。然后结合Go的工具包去处理。

key：国家，城市，版本
value：时区，偏移，省会，名称

不同情况具体分析。

本作品采用《CC 协议》，转载必须注明作者和本文链接