什么是国际化？
国际化（Internationalization的缩写是i18n——i,中间18个字符,n）是将软件处理的能让来自各种地方使用各种语言的用户更简单使用的一个过程。假定某个用户来自某个地方说某种语言，他可能不经意间就得到一些错误提示。尤其是你甚至都没有做这种假设。
function formatDate(d) { // Everyone uses month/date/year...right? var month = d.getMonth() + 1; var date = d.getDate(); var year = d.getFullYear(); return month + "https://www.jb51.net/" + date + "https://www.jb51.net/" + year; } function formatMoney(amount) { // All money is dollars with two fractional digits...right? return "$" + amount.toFixed(2); } function sortNames(names) { function sortAlphabetically(a, b) { var left = a.toLowerCase(), right = b.toLowerCase(); if (left > right) return 1; if (left === right) return 0; return -1; } // Names always sort alphabetically...right? names.sort(sortAlphabetically); }
JavaScript过去的i18n支持太糟糕
传统JS的i18n程序使用toLocaleString()方法进行格式化。结果字符串包含实现自身提供的所有细节：没有办法自己选择(你确实需要那种date格式的weekday吗？year是无关紧要的吗？)。即使包含对应的细节，格式也可能是错的，比如本期望是百分比但得到的是数字。而且你还不能选择一个区域设置(locale)。
对于排序，JS提供了基本没用的基于区域设置(locale-sensitive)的文本比较函数。localeCompare()确实存在，但是其接口根本不适合sort。而且还不允许选择区域设置，或者排序方式。
这些限制太糟了(当我认识到时，我非常吃惊！)，因为需要i18n支持(通常是金融站点用于显示货币)的严谨web应用会把数据打包，发给服务器，服务器进行操作，然后发回客户端。数据往返服务器仅仅为了处理货币的数量。Yeesh。
新的JS国际化API
新的ECMAScript国际化API大大提升了JS的i18n能力。 它提供了大家所能想到的格式化date、数字，文本排序的方式。区域设置是可选的，如果请求的区域设置不支持可以回退。格式化请求可以指定具体要包含的组件。支持自定义的百分比、有效数字、货币格式。开放了大量排序选项用于文本排序。如果你关心性能，首要的操作是选择一个区域设置，然后处理选项参数，现在这个操作只会处理一次，而不是之前每次区域设置相关的操作执行时都会被执行一遍。
这不是说，这个API是万能药，而仅仅是"尽最大努力"。精确的输出几乎总是故意不指定的。一份实现可以仅支持 oj 区域设置(合法的)，也可以忽略(几乎全部)提供的格式化选项。大多数实现都包含高质量的多区域支持，但并不保证有(尤其是资源限定的系统，如手机)。
在底层，Firefox的实现依赖于Unicode 的国际化组件库(ICU) ，这个库又依赖 Unicode Common 区域数据仓库(CLDR)的区域数据集。我们的实现是自托管的：ICU之上的大部分实现用JS写的。在这个过程中，我们遇到了一些问题(我们从未如此大规模的自托管过)，但基本上都不大。
Intl 接口(不是数字1，是字母l)
i18n 存在于 Intl 对象之上。Intl 包含3个构造函数：Intl.Collator, Intl.DateTimeFormat, 和Intl.NumberFormat。每个构造函数创建一个对象，这个对象提供相关操作、高效地为这些操作缓存区域设置和选项。按以下方式创建对象：
var ctor = "Collator"; // 或其他 var instance = new Intl[ctor](locales, options);
locales 是个字符串，指定单个语言标签，或者包含多个语言标签的类数组对象。语言标签如下面的字符串：en(普通英语)，de-AT(奥地利德语)，zh-Hant-TW(台湾使用的繁体中文)。语言标签可以包含一个“Unicode扩展”，形式为-u-key1-value1-key2-value2..., 其中每个key是“扩展key”。不同的构造函数对此进行具体解释。
opions 是个对象，其属性(如果不存在，就赋值为undefined)决定格式化器(formatter)和整理器(collator)的行为。精确的解释由构造函数决定。
给定区域信息和选项，实现会尝试生成近似理想行为的最接近行为。Firefox 支持用于整理(collation)的400+区域，用于date/time和数字格式化的600+区域，所以很可能(但不保证)你想要的区域是被支持的。
Intl 通常不保证某些特定行为。如果请求的区域不被支持，Intl 允诺“尽最大努力”的行为。即使区域是被支持的，行为也不是严格指定的。永远不要假设特定的选项集适用于某个特定格式。(围绕请求的组件)总体格式的用语可能因浏览器甚至浏览器的版本而不同。单个组件的格式是未指定的：weekday的短格式可以为“S”, “Sa”, 或“Sat”。Intl API并不用于公开精确的特定行为。
选项
date/time格式化的主要选项属性如下：
weekday, era
"narrow", "short", or "long". (era通常指历法系统中长于一年的分段，如现行日皇统治, 或者其他纪年法)
month
"2-digit", "numeric", "narrow", "short", or "long"
year
day
hour, minute, second
"2-digit" or "numeric"
timeZoneName
"short" or "long"
timeZone
区分大小写的"UTC"通过对应的toUTC进行格式化。有些值如"CEST"和"America/New_York"不是必须被支持的，它们确实在当前Firefox下没有效果。