本地化构建¶

本地化重新打包¶

为了节省构建时间，构建系统和自动化协同工作，允许下载打包的 en-US 版 Firefox，执行一些特定于区域设置的后处理，并重新打包特定于区域设置的 Firefox。此类工件称为“单一区域设置语言重新打包”。还有一种“多区域设置语言构建”的概念，它更像是常规构建，而不是重新打包的后处理步骤。

注意

这些构建依赖于对工件构建不起作用的 make 目标。

开发人员的单一区域设置重新打包说明¶

假设 $AB_CD 是您要重新打包的区域设置；您可以从 firefox-l10n 中找到可用的本地化。

您必须拥有一个已构建和打包的对象目录，或一个预构建的 en-US 包。
```
./mach build
./mach package
```
使用特定于区域设置的更改重新打包。
```
./mach build installers-$AB_CD
```

您应该在 OBJDIR/dist/ 中找到重新打包的构建，并在 OBJDIR/dist/l10n-stage/ 中找到可运行的二进制文件。 installers 目标为您运行了许多操作，包括从 https://github.com/mozilla-l10n/firefox-l10n 获取本地化（如果已存在则更新它）。它会将它们克隆到 ~/.mozbuild/l10n-central 中。如果您希望磁盘上的其他位置存储 l10n 存储库，则可以通过以下方式指向该目录：

ac_add_options --with-l10n-base=/make/this/a/absolute/path

此构建还会打包语言包。

语言包说明¶

语言包是仅包含本地化资源的扩展。构建它们不需要实际构建，但它们仅与构建它们的 mozilla-central 源代码兼容。

./mach build langpack-$AB_CD

此目标共享上面 installers-$AB_CD 目标的大部分逻辑，并执行本地化存储库的检出等操作。不过，它不需要包或构建。生成的语言包位于 OBJDIR/dist/$(MOZ_PKG_PLATFORM)/xpi/ 中。

注意

尽管构建目录中的位置依赖于平台，但语言包与平台无关，并且进入它们的内容需要以与平台无关的方式构建。

多区域设置构建说明¶

如果您想创建一个包含多个区域设置的单个构建，您将执行以下操作：

创建构建并打包
```
./mach build
./mach package
```

创建多区域设置包

./mach package-multi-locale --locales de it zh-TW

在 Android 上，这会生成一个多区域设置 GeckoView AAR 和多区域设置 APK，包括 GeckoViewExample。您可以通过更改 Android 操作系统的区域设置并重新启动 GeckoViewExample 来测试不同的区域设置。您需要使用设置的 MOZ_CHROME_MULTILOCALE 变量进行安装，例如：

env MOZ_CHROME_MULTILOCALE=en-US,de,it,zh-TW ./mach android install-geckoview_example

无需编译的多区域设置构建¶

由于一些深层次的技术原因，工件构建不支持多区域设置构建。但是，稍微做一些工作，我们就可以达到相同的效果。

安排一个没有编译环境但支持 RecursiveMake 构建后端的 mozconfig，例如：

ac_add_options --disable-compile-environment
export BUILD_BACKENDS=FasterMake,RecursiveMake
... other options ...

配置。
```
./mach configure
```
手动提供已编译的工件。
```
./mach artifact install [-v]
```
构建。
```
./mach build
```

生成多区域设置包。

./mach package-multi-locale --locales de it zh-TW

此构建配置很脆弱，通常不适用于主动开发（为此，请使用完整/编译构建），但它确实可以加快多区域设置打包的测试速度。

重新打包的总体流程¶

区域设置重新打包的总体流程由 $MOZ_BUILD_APP/locales/Makefile.in 和 toolkit/locales/l10n.mk 以及打包构建系统控制。上面三个主要入口点都会触发相关的构建流程。

获取本地化存储库（如果需要）
使用先前清除的合并目录运行 l10n-merge
将 l10n 文件复制到 dist， l10n-% 和 chrome-% 之间存在细微差别
重新打包和打包

l10n-merge 的详细信息在下面它自己的部分中进行了描述。文件的复制主要由 jar.mn 控制，在包含可本地化文件的少数源目录中。 l10n-% 用于重新打包， chrome-% 用于多区域设置包。重新打包是 toolkit/mozapps/installer/l10n-repack.py 中的专用 Python 代码，使用现有的包。它会剥离现有的 chrome l10n 资源，并添加本地化和元数据。

语言包不需要重新打包。Windows 安装程序是通过简单地将现有的重新打包的 zip 打包到安装程序中生成的。

公开字符串¶

本地化流程处理源代码树中知名位置的几种文件格式。

除了通过将目录包含在 $MOZ_BUILD_APP/locales/Makefile.in 中以及 jar.mn 中的相应条目来构建外，我们还拥有针对本地化工具和基础设施量身定制的配置文件。它们还控制 l10n-merge 处理哪些文件以及如何处理。

这些配置是 TOML 文件。它们是 Mozilla 中更大的本地化生态系统的一部分，并且有关文件格式的文档解释了如何设置它们以及各个条目的含义。简而言之，您会发现：

[paths]
reference = browser/locales/en-US/**
l10n = {l}browser/**

以添加所有本地化的目录。对这些文件的更改最好由 :Pike 或 :flod 提交以供审查。

这些配置文件是未来，现在，我们仍然支持以前配置 l10n 的方式，如下所述。

这些位置通常位于以下目录中：

browser/locales/en-US/subdir/file.ext

首先要注意的是，只有 locales/en-US 下面的文件会被公开给本地化人员。其次要注意的是，只有少数目录会被公开。哪些目录会被公开是在名为 l10n.ini 的文件中定义的，这些文件位于源代码中的几个位置。

一个示例如下所示：

[general]
depth = ../..

[compare]
dirs = browser
    browser/branding/official

[includes]
toolkit = toolkit/locales/l10n.ini

这告诉 l10n 基础设施三件事：

解析相对于向上两级的目录的路径
包含 browser/locales/en-US 和 browser/branding/official/locales/en-US 中的文件
从 toolkit/locales/l10n.ini 加载更多数据

对于 comm-central 中的 Thunderbird 和 SeaMonkey 等项目，在包含来自不同存储库的 l10n.ini 时，需要提供其他数据：

[include_toolkit]
type = hg
mozilla = mozilla-central
repo = https://hg.mozilla.org/
l10n.ini = toolkit/locales/l10n.ini

这告诉 l10n 基础设施在哪里可以找到存储库，以及在该存储库内部 l10n.ini 文件在哪里。这是必要的，因为对于本地构建， mail/locales/l10n.ini 会引用 mozilla/toolkit/locales/l10n.ini，而这就是 comm-central 构建设置预期 toolkit 所在的位置。

现在已经知道了公开给 l10n 的目录，我们可以讨论支持的文件格式了。

文件格式¶

以下文件格式为 l10n 工具链所知：

Fluent: 用于 Firefox UI，既有声明式也有编程方式。
属性: 从 JavaScript 和 C++ 中使用。当从 js 中使用时，也带有复数支持（如果可能，请避免）。
ini: 由错误报告程序和更新程序使用，如果可能，请避免。

添加新格式涉及更改各种不同的工具，并且强烈不建议这样做。

例外¶

通常，en-US 中存在的任何内容都需要在所有本地化中进行一对一映射。在一些情况下，这并不需要，特别是在区域设置配置和依赖于区域设置的元数据方面。

对于可选字符串和文件，如果本地化没有该内容，则 l10n-merge 不会添加 en-US 内容。

对于 TOML 文件， [[filters]] 文档是一个很好的参考。简而言之，过滤器匹配本地化的源代码，可选地一个 key 和一个操作。例如：

[filters]
path = "{l}calendar/chrome/calendar/calendar-event-dialog.properties"
key = "re:.*Nounclass[1-9].*"
action = "ignore"

表示 calendar-event-dialog.properties 中匹配的消息是可选的。

对于旧版 ini 配置文件，在主 l10n.ini 旁边有一个 Python 模块 filter.py，实现 test()，具有以下签名：

def test(mod, path, entity = None):
    if does_not_matter:
        return "ignore"
    if show_but_do_not_merge:
        return "report"
    # default behavior, localizer or build need to do something
    return "error"

对于任何缺少的文件，此函数都会被调用，其中 mod 是模块， path 是 locales/en-US 内部的相对路径。该模块是 l10n.ini 中引用的顶级目录。

对于缺少的字符串， entity 参数是 en-US 文件中字符串的键。

l10n-merge¶

Gecko 中的 Chrome 注册表不支持在运行时从本地化回退到en-US。因此，构建需要确保内置于软件包中的本地化包含所有必需的字符串，并且这些字符串不包含错误。为了确保这一点，我们在构建时将本地化和en-US进行合并，称为 l10n-merge。

对于 Fluent，我们还删除了错误的消息。对于 Fluent 中的许多错误，这只是外观上的问题，但当本地化在消息上具有不同的值或属性时，这实际上很重要，以便 Fluent 的 DOM 绑定可以应用翻译，而无需加载en-US源进行比较。

可以通过以下方式手动触发此过程：

$> ./mach build merge-$AB_CD

它在 object dir 中创建另一个目录，browser/locales/merge-dir/$AB_CD，其中存储了清理后的文件。实际的重新打包过程仅查看合并目录，因此 l10n-merge 的准备步骤需要确保生成或复制所有文件。

如果 l10n-merge 支持特定的文件类型，并且存在未过滤掉的缺失字符串，或者现有字符串显示错误，则它会修改该文件。有关详细信息，请参阅下面的“检查”部分。如果文件未修改，则 l10n-merge 会将其复制到合并目录中的相应位置。

检查¶

作为构建和其他本地化工具链的一部分，我们运行各种基于源代码的检查。可以将它们视为代码风格检查器。

检查套件通常由文件类型决定，即，Fluent 文件有一套检查，属性文件有一套检查，等等。

本地化¶

现在我们深入讨论了如何向本地化人员公开内容，那么本地化文件在哪里呢？

我们将所有语言环境托管在一个 Git 单仓库中。我们所有的本地化文件都可以在https://github.com/mozilla-l10n/firefox-l10n上找到。

您可以在Transvision上搜索我们本地化文件中的内容。