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

在上节我们分析了从前端，无论是AngularJS本身 $locale 还是通过现有的 JS navigator对象的相关的language属性，都无法得到准确的用户语言信息。

由此可见从前端获取Browser 的用户语言，在现阶段是有缺陷的。那么要获取当前用户端接受的语言除了从浏览器直接获取外，其实通常情况下是分析Http 请求里面的报头，（Accept - Language）请求报头域类似于Accept，但是它是用于指定一种自然语言。eg：Accept-Language:zh-cn.如果请求消息中没有设置这个报头域，服务器假定客户端对各种语言都可以接受。

Accept-Language: zh-cn,zh;q=0.5

　　意思：浏览器支持的语言分别是中文和简体中文，优先支持简体中文。

　　详解：

　　Accept-Language表示浏览器所支持的语言类型；

　　zh-cn表示简体中文；zh 表示中文；

　　q是权重系数，范围 0 =< q <= 1，q 值越大，请求越倾向于获得其“;”之前的类型表示的内容，若没有指定 q 值，则默认为1，若被赋值为0，则用于提醒服务器哪些是浏览器不接受的内容类型。

获取到Http请求里面的报头信息后，后端可以进行逻辑处理。

Accept-Language 里面可以放多个值，对应不同的权重，在后端做处理时，我们需要根据产品支持的语言和区域去定制是否需要遍历整个list做fallback。还是简单的取首选项，如果首选语言后台不提供，直接做后台的语言fallback，而不考虑用户在浏览器设置的fallback机制。

后面章节里面我们会讲到什么是language-chain的fallback，上文提及的是获取浏览器用户语言以及是否在浏览器层面进行语言的fallback。

后台获取language信息后，有两种方式向前端传值，常用的方式是模板的渲染，这个是同步是获取，简单明了。但是此方式不是AngularJS的style，AngularJS试图成为WEB应用提供一种端对端的解决方案。这意味着它不只是WEB应用中的一个小部分，还是一个完整的端对端的解决方案。这会让AngularJS在构建一个CRUD（增加Create、查询Retrieve、更新Update、删除Delete）的应用时显得很“固执”（原文为 opinionated,意指没有太多的其他方式）。但是，尽管它很“固执”，它仍然能确保它的“固执”只是构建应用的起点，并且仍能灵活变动。很显然模板渲染和变量替换不是AngularJS追求的，可能大家会问了什么是AngularJS的数据传送理念？

$Http service 一个基于Ajax的轻量级底层服务，上层还有$q 服务，它提供了一种承诺/延后（promise/deferred），可以保证我们的调用代码一定能够拿到数据。但是仔细读过API的源码的读者应该知道，Http service里面是hardcode的异步请求，所以说用AngularJS你就forget 同步。只不过这个服务提供了表面上是同步访问的API，当数据获取成功之后，自动将数据提供给调用的代码。

问题来了，如果是异步怎么确认在页面加载之前能获取到正确的语言信息，实现同步效果。方法是：在$routeProvider  的resolve里面是写异步的language service，直到异步返回结果，模板才会被渲染。但是这样做并不是一个简洁的方案，我们还要考虑到timeout等问题。总结下来，AngularJS在设计初就没有考虑咱们国际化的需求，只能这样理解了。

模板渲染是一个稳定而简单的方案，但不符合AngularJS 精神。restAPI 结合$q 异步获取略显麻烦，对英文版本的影响比较大，后期国际化测试引入问题较多。当然还有一个方案就是用原生的AJAX或者jquery做同步请求，但是这样不好，不纯粹。

在此，希望大家针对项目的特点，综合以上的优缺点灵活的选择技术方案。