浅析 AngularJS 全球化最优方案（四）

在前面三节我们分析了 AngularJS 的web application里面，3种常见获取浏览器用户语言信息的方法以及优缺点：

1. 前端 JS 直接获取浏览器的用户语言信息。

优点：真正意义上做到了前后端分离。

缺点：现有 API的定义，在每个浏览器上面的实现不一致或者有些浏览器暂不支持。

2.类 JSP 方案，定义locale 变量在引导页面，利用后台渲染模板上的 locale 变量。

优点：同步获取，保证在AngularJS 运行之前获取到准确的 locale 信息。

缺点：依赖传统方式，不符合AngularJS精神。

3.利用 AngularJS 自带的 $http 服务，通过restAPI 异步获取locale信息，将此逻辑封装成独立的service，在$routerProvider的resolve里面调用。

优点：符合AngularJS的精神。

缺点：如果在英文版本开发阶段没有考虑国际化需求，代码改动量较大，后期国际化bug比较多

在AngularJS的应用里面，大体来说如果想获取浏览器的用户语言，主要有以上几种方案。但是也如大家看到的每一种方案都会有自身的局限性。

我们之前谈的所有的方案都是基于浏览器的用户语言，除了浏览器做为来源外是不是还有其他的来源？预设？

答案是肯定的。比如根据 IP地址 或者用户系统语言，但是这些都不是常见的方案。这里再介绍一种常见的 Locale 定义和获取的方案，在Html 5和AngularJS的 web 应用里面很常见。

此方案解决了上面提及的几种方案的所有缺点，也用到了Html 5的新特性LocalStorage，保证了用户在固定机器上面的Locale存储，简化了获取 Locale的复杂度。

但是在企业级的应用里面，我们不单纯要考虑到本地化需求也需要考虑国际化，理论上一个支持全球化的软件，在国际化支持上面应该是取极大值，所谓极大值是指当前框架或者当前的开发语言支持国际化的所有 Locale，那么将这些 Locale全部配置在菜单里面，从用户体验的角度是不太友好的。常见处理方案是将国际化和本地化的Locale保持一致，这样解决了体验的问题，但是直接带来了国际化的Locale局限性。

讲到这里，关于Html5配合AngularJS的web应用里面，全球化Locale来源已经讲完。从个人的角度，如果软件的国际化点不多，类似时间日期，货币，小数等。那我们可以考虑使用语言下拉菜单,这种方案即符合AngularJS的风格也保证了Locale的动态更新。

如果是企业级的软件，国际化的点比较多，那么我建议使用后台模板渲染的方案，原因有两点：保证了Locale的同步获取，另外可以复用后台的Locale resolving 模块。当然作为极客或者AngularJS的忠粉是不太习惯的，而且与 Nodejs的结合测试不太方便。但是考虑总体的设计，这是一个比较简洁而清晰的解决方案。同时我们也期待AngularJS在$Locale服务上面的完善。

下个模块，我们会谈具体的Locale resolving和Locale fallback 机制，以及介绍第3方本地化和国际化库的使用方法和优缺点。