共用方式為

建立當地語系化的 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 。 如果您 支援多個架構，那麼在 lib 之下，每個變體會有一個資料夾。

有了這些資料夾，您就可以參考以下 .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必須使用[1.0.0]表示法宣告對ContosoUtilities.1.0.0.nupkg的相依性。 當然，附屬套件的版本號碼可以與主要套件不同。

然後，衛星套件的結構必須將資源元件和 XML IntelliSense 檔案包含在與套件檔名相符的子資料夾 {language} 中：

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