【转】浅析 AngularJS 全球化最优方案（五）
在前几节了我们总结了获取Locale的几种方式，各有优缺点。接下来我们聊聊如何做 Locale 的 mapping 和 fallback。从浏览器获取到用户的语言偏好，或者下拉框选择预定义语言，只是Locale的一个入口，在获取到raw Locale以后，我们需要进行映射和fallback处理。首先我们先回顾下国际化分层，分层的概念。在本系列开始的时候，我给大家讲过一个概念，国际化的分层，一般来说国际化分3层，第一层是软件在多语言操作系统的安装以及 Non-ASCII 字符串的输入输出。第二层是区域敏感数据处理，时间日期格式，货币，数字，等等。第三层是本地化支持。Locale 在后面两个层面都是关键入口，对于i18n支持来说，当前开发语言或者框架支持多少种语言，我们的应用就应该支持多少种语言，而不是同步本地化支持的语言。所以在获取到原始的locale，我们从逻辑上面做分离，一个locale服务于i18n的，一个服务于本地化。这样区分的原因是往往一个应用的本地化支持的语言范围是远小于国际化的。这样分离后，我们下一个要考虑的问题是locale fallback和locale mapping。i18n的locale fallback mechanism一般是由开发语言库定义的或者是当前的框架，如果当前框架支持国际化，那么它们包含的语言一般是够用的，很多框架或者语言都引入了 cldr。什么是 locale mapping，最常见的例子是中文：如果你细心看这个图片，你会发现简体中文有4种表示，在不同的浏览器上面语言代码是不一致的：zhzh-cnzh-Hanszh-Hans-CN除 zh 外，其实简体中文代码有3种表示，理论上这3种是有区别的：但是在实际的项目中，往往这3种语言代码对应的资源文件是一致的。而不同浏览器的标准不一致导致多样性的语言代码，给国际化开发带来了一定的麻烦。在 .NET 开发里面，我们从IE的accept-head里面获取简中的代码是zh-Hans-CN, 而CultureInfo 不支持 zh-Hans-CN 写法，如果你使用了，会收到这样一个异常。zh-Hans-CN 是无效的区域性标识符。你可以使用 zh,zh-cn, zh-Hans, 但是，不能使用 zh-Hans-CN 来构建 CultureInfo 对象。基于上面Locale 代码的多样性，在本地化使用之前。我们需要做一个mapping去满足我们的业务需求，例如：zh-Hans-CN->zh_CN在语言和区域以及脚本之间的下划线和连接符，也需要按照BCP47或者Java规范进行统一。在做完mapping后，我们开始正式使用locale做本地化。Locale fallback 是另一个关键点在本地化开发中，Locale的 fallback 会影响到资源文件的fall back 和Key fallback。而不同的语言和框架本身是维护一套locale fallback的mechanism。后面会用一个单独的章节，讲locale的组成和locale fallback mechanism 及算法。如果语言和框架没有健全的locale fallback mechanism，我们可以实现一个简单的fallback mechanism，fallback 到default language，这里写default，为什么没有写en?在我们详细讲解locale fallback之前，大家可以看看GWT里面lcoale fallback chain，在中文上面的行为： zh -> zh_CN -> 以上的逻辑顺序决定了GWT i18n资源文件的fallback和key的fallback。这个机制很像Java i18n的fallback mechanism，后面会集中讨论。说到这里，本节已经结束。总结下，在获取到原始locale后我们需要做两点：[*]Locale 的mapping。
[*]考虑Locale的fallback mechanism，可以使用开发语言或者框架自带的。如果没有现成可用，我们可以自定义。可以很简陋，甚至直接fallback到英文，但是这个步骤不能省掉。
在本节完后，最后我们将在下节对比目前流行的第三方框架支持AngularJS的本地化，分析优缺点。这些框架实现了资源文件的定义、加载以及相应的工具，但是同时也有一些问题是需要预处理或者按照业务逻辑自定义。
页:
[1]
