基本思路
阿里飞冰采用的是React基本框架，因而国际化方案采用yahoo的React-Intl包，其提供了IntlProvider的类，用于包裹组件。因而基本思路就是通过localStorage存储一个lang值，用于提供给IntlProvider的属性locale进行语言的识别，在locales模块目录下维护各个不同的语言配置即可，通过按钮的选择改变lang值，即可对全局环境进行语言切换。
目录结构
- 语言配置文件:
src/locales - 设置lang工具函数:
src/utils/locale.js - 配置转换函数:
src/utils/localeConfig.js - 全局语言包裹组件:
src/components/LocaleProvider - 语言选择框组件:
src/components/LocaleSelect
踩坑案例
飞冰ice的Dialog组件导致的上下文丢失
[bug描述] 在PageHead中按钮点击，是通过jsx传输的包裹格式，在飞冰Dialog点击后会出现导致包裹在全局最外层的<LocaleProvider></LocaleProvider>丢失，错误为Uncaught Error:[React Intl] Could not find required 'intl' object <IntlProvider> heads to exit in the component ancestry.
[bug分析] jsx和js中的ast转换中造成场景性质的bug，原因在于项目书写过程中的js和jsx混合使用，对于前期未考虑到国际化场景
[解决方案] 在工具函数库localeConfig中实现confirmLocale函数，用于在js中的字符串转换
总结
相较于Vue的国际化Vue-i18n来说，React的国际化较为复杂，其依赖包也有很多，如'React i18n'、'Intl'等，本次国际化过程较为繁复，其本身难度倒不大，关键在于前期未考虑到要做国际化的需求，导致js和jsx混合使用，有的需要在config.js转换，而有的则需要在jsx中做转换，在某些场景中还会出现bug，因而后续过程中的项目如果考虑到国际化场景，需要提前留出预备量，任何的框架设计与实现需要做好度的把控，过渡设计和缺少设计都不能很好的达到业务效果，后期的反复工作就会增加，做好系统设计是每一个工程师都应该提升的能力。
