背景
国际化（internationalization）是设计和制造容易适应不同区域要求的产品的一种方式。它要求从产品中抽离所有地域语言，国家/地区和文化相关的元素。换言之，应用程序的功能和代码设计考虑在不同地区运行的需要，其代码简化了不同本地版本的生产。开发这样的程序的过程，就称为国际化。-----引自百度百科
前言
最近因为周会输出，整理了下iOS国际化这块，发现这块坑点还蛮多的，而且网上博客也比较杂，没有一份比较系统的文章，所以想唠叨两句。主要是结合自己之前做国际化的经验，分享下常见的一些坑点和解决方法。附带我们之前的国际化方案。（类似Localization怎么配置、xib/storyboard国际化。。。就不讲了，网上很容易就能找到）
流程
流程图
时间国际化
时间在很多app里都有体现，有些涉及业务，有些只是为了显示。但是在不同时区，时间应该是不一样的，所以我们应该多一些处理，来让应用根据不同的时区来显示时间。
时间国际化是我们在开发中很容易忽视的地方，虽然东西很小，但是影响却很大，因为时间在业务的体现更多是提醒的作用，重中之重。（令人难以置信的是我前后两个公司都有这个问题）
异常场景描述：系统需要对报名课程的用户进行开课提醒，但是因为没有做国际化，所以用户身处国外看到的却是东八区的时间，可想而知是有多坑，熬到了半夜，明明到了上课时间，但是直播课确没有。
what's the fuсk?
注意！
首先我们要和服务端同学规定，凡是系统中和时间相关的字段，都需要返回时间戳格式。时间戳！时间戳！时间戳！（有遇到服务端过于友好，特意转成直接可用的字符串给客户端，所以这个大家要小心，不管做没做国际化。）
如何避免？
其实系统已经帮我们做了这件事，我们要做的是受它支配，乖乖的～不要不反抗～
具体是这样的：众所周知，我们需要通过NSDateFormatter对象将时间戳转换成可用的字符串，NSDateFormatter对象里面有个TimeZone属性，默认是取系统当前时区，那么我们要做的是不去setTimeZone。这样获取到的时间就是当前系统对应的时间，随系统时区切换，时间也会跟着变化。
国际化分两种情况
开发之初就考虑国际化，这种情况做国际化是很容易的，只要在开发过程中对字符串进行简单的处理即可。
已经经历过多个版本的开发，并且一开始就没有做国际化的适配。此时面对项目中成千上万的字符串，内心就崩溃了。我们主要针对这种情况展开讨论。
字符串国际化
已开发多个版本，会面对如下问题
1. 大量字符串未加宏
2. Localizable.strings文件生成
3. storyboard/xib下的strings文件管理
1. 大量字符串未加宏
在已有工程上进行适配，首先要做的就是给需要进行国际化的字符串加上NSLocalizedString宏了。这种情况下一个个修改肯定不现实，工程里面可能有成千上万个字符串。
可以用Replace模式进行替换
Command+Shift+F，进入全局搜索引擎
切换为Replace模式，并把匹配模式改为Regular Expression
在搜索条件里输入正则 @"["]*[\u4E00-\u9FA5]+["\n]*?"，该正则的作用是：匹配到所有符合OC字符串格式的包含有中文的字符串
在下面替换内容里输入NSLocalizedString($1, nil)
然后进行查找，并Replace
步骤
但是过程并不一定那么顺利
很有可能产生语法错误，这种报错恶心的一匹，而且很难去排查。
iOS 国际化工具，让你的国际化更简单，包含了 iOS 中常用的一些脚本 。
2. Localizable.strings文件生成
跟NSLocalizedString配置一样，对于已有工程我们不可能把项目中的字符串一处处挑出来再写到Localizable.strings文件里的。
可以利用genstrings生成多语言文件
cd工程目录
mkdir en.lproj
//.m
find ./ -name “*.m" -print0 | xargs -0 genstrings -o en.lproj
//.h 和.m
find . \( -name '*.m' -o -name '*.h' \) -print0 | xargs -0 genstrings -o en.lproj
(去遍历所有的.m子目录文件，去生成Localizable.strings,其中包含key和value)
en.lproj会生成Localizable.strings文件
然后我们修改每个key所对应的value值就行（这其实是翻译的事）
成功
或者也可以用github上的开源框架ReadChinese
使用起来非常方便，读取某个目录中的所有中文，并且将这些中文按照多语言(.string)格式写入文件中，可以直接拿来实现国际化。
操作示例图
3. storyboard/xib的国际化处理
storyboard的国际化非常简单
将storyboard的inspector栏目的localization项勾上后，project的file navigator那里会多出几个文件
示意图
不足之处
storyboard/xib多语言文件中的配置并不会随着控件的增减而变化，需要手动添加。
storyboard/xib需要多维护很多语言文件，增加不必要的成本
storyboard/xib少用/不用（在项目之初），如果考虑到国际化
也可以这样做
通过python脚本来实现。
原理：假设原来我们就有翻译文件A，添加控件后，我们再执行一次国际化指令，生成文件B，我们拿A和B对比，把B中多出来的键值对插入A文件的尾部，将A中有而B中没有的键值对删掉（即控件被删除），这样我们就算是更新了storyboard的翻译文件了。然后每次installing的时候会运行脚本，去重新生成storyboard/xib中的多语言文件。
参考文章：https://www.cnblogs.com/levilinxi/p/4296712.html
参考git：https://github.com/linyu92/MyGitHub
网络请求国际化
采用方案：（可参考）
在RequestHead中加个lang（en或cn）字段做语言区分
服务端获取到lang，返回对应的数据，一般差异会体现在文案、图片、requestErrorMessage
应用内语言切换
采用方案：（可参考）
默认跟随系统语言：中文(中文简|繁体)英文(非中文简|繁体）
除了默认语言外，用户可以切换语言，切换成功后就跟随用户设定的语言
设置语言方法[[NSUserDefaults standardUserDefaults] setObject:@"zh-Hans" forKey:currentLanguageKey]
应用内动态更新语言
常用的更新语言方式：
1. reloadRootViewController
2. 通知
3. 预留更新文字的方法
1. reloadRootViewController（成本低）
这个方法应该是编码成本最低的方法了，只需要把原有的rootViewController移除并清空，然后重新设置一遍rootViewController就行了。但是这种实现方式会重新加载已经原来已经加载好的所有界面。
微信用的其实也是这种，在微信内切换语言的时候很明显会感觉到有一个重新载入的过程。可能在项目之初也没有考虑到国际化。
然后因为我们国际化是在之后提出的，所以考虑到成本风险，最后也选用了这种方式，虽然会重新加载，但是毕竟编码成本最低，也不容易出错。建议老项目，时间预留不多的可以用这个。（其实效果也不会那么差）
2. 通知
在用户切换语言的时候，发送一个通知，然后在各个界面接收通知，更新所有需要更新的文本即可。这种方法适合新建的项目，在代码编写之初就预留好更新文本的方法，收到通知后调用此方法就行。如果已经是一个已上线项目，则改动成本比较高，需要改动的地方比较多。
3. 预留更新文字的方法（切换顺畅）
在用户切换语言的时候，遍历所有已经加载的界面，调用更新文字的方法。这种实现也是比较适合新建的项目，在代码编写之初就预留好更新文本的方法。如果项目已上线，则改动成本较高。
支付宝切换过程就比较完美，实现了无缝切换，有可能是前期就预留了更新文本的方法，后期直接调用就可以。建议新项目试试，体验会很好。
出处：https://www.jianshu.com/p/1550f2835f4f
