通过

创建本地化的 NuGet 包

可通过两种方法创建库的本地化版本：

  1. 将所有本地化资源程序集包含在单个包中。
  2. 按照一组严格的约定创建单独的本地化卫星包。

这两种方法都有其优点和缺点，如以下部分所述。

单个包中的本地化资源程序集

在单个包中包含本地化资源程序集通常是最简单的方法。 为此，请在 lib 中为软件包默认语言（假定为 en-us）以外的受支持语言创建文件夹。 在这些文件夹中，可以放置资源程序集和本地化的 IntelliSense XML 文件。

例如，以下文件夹结构支持德语（de）、意大利语（it）、日语（ja）、俄语（ru）、中文（简体中文）（zh-Hans）和中文（繁体中文）（zh-Hant）：

lib
└───net40
    │   Contoso.Utilities.dll
    │   Contoso.Utilities.xml
    │
    ├───de
    │       Contoso.Utilities.resources.dll
    │       Contoso.Utilities.xml
    │
    ├───it
    │       Contoso.Utilities.resources.dll
    │       Contoso.Utilities.xml
    │
    ├───ja
    │       Contoso.Utilities.resources.dll
    │       Contoso.Utilities.xml
    │
    ├───ru
    │       Contoso.Utilities.resources.dll
    │       Contoso.Utilities.xml
    │
    ├───zh-Hans
    │       Contoso.Utilities.resources.dll
    │       Contoso.Utilities.xml
    │
    └───zh-Hant
            Contoso.Utilities.resources.dll
            Contoso.Utilities.xml

可以看到，语言都列在目标框架文件夹下 net40 。 如果您 支持多个框架，那么在每个变体下都有一个文件夹。

在设置好这些文件夹后，引用 .nuspec 中的所有文件。

<?xml version="1.0"?>
<package>
    <metadata>...
    </metadata>
    <files>
    <file src="lib\**" target="lib" />
    </files>
</package>

使用此方法的一个示例包是 Microsoft.Data.OData 5.4.0。

优点和缺点（本地化的资源程序集）

将单个包中的所有语言捆绑在一起有几个缺点：

  1. 共享元数据：由于 NuGet 包只能包含单个 .nuspec 文件，因此只能为单个语言提供元数据。 也就是说，NuGet 不支持本地化元数据。
  2. 包大小：根据支持的语言数量，库可能会变得很大，这会减缓包的安装和还原速度。
  3. 同时发布：将本地化文件捆绑到单个包中需要同时释放该包中的所有资产，而不是能够单独发布每个本地化。 此外，任何本地化更新都需要整个包的新版本。

但是，它也有一些好处：

  1. 简单性：包使用者在单个安装中获取所有支持的语言，而无需单独安装每种语言。 单个包在 nuget.org 上也更容易找到。
  2. 耦合版本：由于所有资源程序集都与主程序集位于同一个包中，因此它们都共享相同的版本号，并且没有错误分离的风险。

本地化卫星包

与 .NET Framework 如何支持附属程序集类似，此方法将本地化资源和 IntelliSense XML 文件分成附属包。

为此，主包使用命名约定 {identifier}.{version}.nupkg ，并包含默认语言的程序集（如 en-US）。 例如， ContosoUtilities.1.0.0.nupkg 将包含以下结构：

lib
└───net40
        ContosoUtilities.dll
        ContosoUtilities.xml

卫星程序集随后使用命名约定 {identifier}.{language}.{version}.nupkg，例如 ContosoUtilities.de.1.0.0.nupkg。 标识符 必须与 主包的标识符完全匹配。

由于这是一个单独的包，因此它 .nuspec 有自己的文件，其中包含本地化的元数据。 请注意，该.nuspec语言必须与文件名中使用的语言匹配。

附属程序集 还必须 使用 [] 版本表示法将主包的确切版本声明为依赖项（请参阅 包版本控制）。 例如，ContosoUtilities.de.1.0.0.nupkg 必须声明对ContosoUtilities.1.0.0.nupkg的依赖，使用[1.0.0]符号。 附属包的版本号当然可以与主包不同。

然后，卫星包的结构必须在与包文件名中的 {language} 相匹配的子文件夹中包括资源程序集和 XML IntelliSense 文件。

lib
└───net40
    └───de
            ContosoUtilities.resources.dll
            ContosoUtilities.xml

注意：除非需要特定的语言变体 ja-JP，请始终使用高级语言标识符，例如 ja。

在卫星程序集里，NuGet 将仅识别文件夹中的那些文件，该文件夹的名称与{language}文件名匹配。 将忽略所有其他项。

满足所有这些约定后，NuGet 会将包识别为附属包，并将本地化文件安装到主包的文件夹 lib 中，就好像它们最初捆绑在一起一样。 卸载卫星包会从同一文件夹中删除其文件。

对于每种受支持的语言，您可以以相同的方式创建附加的卫星程序集。 例如，检查 ASP.NET MVC 包集：

所需约定摘要

  • 主包必须命名 {identifier}.{version}.nupkg
  • 卫星包必须命名 {identifier}.{language}.{version}.nupkg
  • 附属包 .nuspec 必须指定其语言以匹配文件名。
  • 卫星包必须在其 .nuspec 文件中使用 [] 符号声明对主程序包的确切版本的依赖。 不支持该范围。
  • 卫星包必须将文件放在与文件名完全匹配的 lib\[{framework}\]{language} 文件夹中 {language}。

优点和缺点（卫星套餐）

使用卫星包具有以下优势：

  1. 包大小：将主要包的总体占用空间降到最低，使用者只会产生要使用的每种语言的成本。
  2. 单独的元数据：每个卫星包都有自己的 .nuspec 文件，因此拥有自己的本地化元数据。 这可以让某些用户使用本地化术语搜索 nuget.org 更容易找到软件包。
  3. 分离版本：卫星程序集可以随着时间的推移而发布，而不是一次性发布，从而让你能够分散本地化工作。

不过，卫星包有它自己的一些缺点：

  1. 混乱：与单个包相反，多个包可能导致 nuget.org 上搜索结果的混乱，并在 Visual Studio 项目中产生很长的引用列表。
  2. 严格的约定。 卫星包必须严格遵循约定，否则本地化版本将无法被正确识别。
  3. 版本控制：每个附属包必须对主包具有确切的版本依赖关系。 这意味着，即使资源未更改，更新主包也可能需要更新所有附属包。
  • Last updated on