Localizing the Troubleshooting Pack

To specify that the package is localized, set the Localized attribute of GlobalDiagnosticPackage or LocalDiagnosticPackage to "true". If true, all UI string elements must be of the form "@resource.dll,-resourceID" (they cannot be literal strings). WTP will load the strings from the language-specific resource DLL. If the package is not localized, WTP reads the string directly from the manifest.

The troubleshooting pack's root folder must contain a language-neutral resource DLL and a language-specific subfolder for each locale that the pack supports. The name of the subfolder must be the language name string (for example, en-US for English (United States)). Each subfolder must contain the language-specific resource file (*.dll.mui). If the scripts in the pack use localized strings, the subfolders must also include the Windows PowerShell data file (*.psd1).

Each language-specific subfolder must contain a catalog file that includes all files in the folder. The language packs must be signed by the same publisher that signed the troubleshooting pack. WTP validates that all localized resources are trusted.

The name of the catalog file must use the same name as the subfolder that contains it (for example, if the subfolder is en-US, the catalog file must be named en-US.cat). The catalog header must contain a PackageId attribute that is set to the value of the manifest's ID node (see DiagnosticIdentification). The following is an example of a .cdf file for a language pack. If your scripts use localized string, the .cdf file must also include an entry for the .psd1 file.



Language packs can be distributed and installed separately from the troubleshooting pack.

Localized support for scripts

Windows PowerShell version 2 uses .psd1 files to support localization. For each locale that you support, create a .psd1 file that contains language-specific strings and place each file in its language-specific subfolder of the troubleshooting pack. To load localized strings from a .psd1 file to be used in your script, use the Import-LocalizedData cmdlet as shown in the following example.

Import-LocalizedData -bindingvariable localizationString -filename CL_LocalizationData

You would then use the localizationString variable to access the strings as shown in the following example. Set stringid to the name of a string identifier found in the CL_LocalizationData.psd1 file.

$obj | select-object -Property @{Name=$localizationString.stringid;Expression={$_.OldPropertyName}} | convertto-xml | update-diagreport