启动¶
在某些情况下，了解 Gecko 语言环境管理在启动期间的行为可能非常重要。
以下是 server 模式的描述，因为 client 模式以无数据状态启动，并且不执行任何操作，等待父进程填充基本的语言环境列表（requested 和 appLocales），然后以单向方式维护它们。
数据类型¶
在启动期间协商语言环境时涉及两种主要数据类型：requested 和 available。在整个启动过程中，这些列表的不同来源变得可用，因此这些列表的值会发生变化。
数据源¶
在引导过程中有三个主要来源变得可用。
存储在文件
update.locale和multilocale.txt中的打包语言环境列表。从配置文件中读取的用户偏好设置。
安装在用户配置文件或系统范围内的语言包。
引导¶
1) 打包数据¶
在 server 模式下，Gecko 首先不了解 available 或 requested 语言环境。
最初，所有字段都是延迟解析的，因此不会检索可用、请求、默认或解析语言环境的数据。
如果任何代码查询任何 API，则会触发初始数据获取和语言协商。
初始请求来自正在初始化第一个 JS 上下文的 XPCLocale，并且需要知道 JS 上下文应使用哪个语言环境作为默认语言环境。
此时，LocaleService 使用通过工具包包中的 multilocale.txt 文件检索的打包语言环境获取可用语言环境列表。这使 LocaleService 了解哪些语言环境最初可用。
请注意，这发生在任何语言包注册之前，因此在那个时候，Gecko 只知道打包的语言环境。
对于请求的语言环境，初始请求发生在读取用户配置文件偏好设置之前，因此数据是使用打包的偏好设置获取的。
在桌面 Firefox 的情况下，intl.locale.requested 偏好设置将不会设置，这意味着 Gecko 将使用从 update.locale 文件（也打包）中检索的默认语言环境。
这意味着语言协商的初始结果是在打包的语言环境作为可用语言环境和默认请求的语言环境之间进行的。
2) 读取配置文件偏好设置¶
接下来，将读取配置文件，如果用户设置了任何请求的语言环境，LocaleService 将更新其请求的语言环境列表并广播 intl:requested-locales-changed 事件。
如果请求的语言环境是打包的语言环境之一，这可能会导致语言重新协商。在这种情况下，将广播 intl:app-locales-changed。
3) 注册语言包¶
最后，AddonManager 注册所有语言包，它们将添加到 L10nRegistry 中，因此 LocaleService 的可用语言环境将更新。
这将触发语言协商，如果语言包中的语言在请求列表中使用，则将设置最终的语言环境列表。
所有这些都发生在构建任何 UI 之前，但不能保证此顺序会保留，因此务必了解，根据代码在启动期间的使用位置，它可能会接收不同的语言环境列表。
为了维护正确的语言环境设置，务必在 intl:app-locales-changed 上设置观察者，并在语言环境列表发生更改时更新代码。
这确保代码在启动期间始终使用最佳的语言环境选择，而且在运行时如果用户更改其请求的语言环境列表或语言包动态更新/删除时也是如此。