Localized Extensions

You can create your own localized extensions like WixUIExtension using lit.exe. Localized extensions can even contain multiple languages. Products using these extensions can pass the -cultures switch to light.exe along with the -ext switch to reference the extension.

Authoring Libraries

WiX extensions contain libraries comprised of fragments. These fragments may contain properties, search properties, dialogs, and more. Just like when localizing products, replace any localizable fields with variables in the format !(loc.variableName). Product would be authored to reference elements in this library, and when compiled would themselves contain the localization variables.

Authoring Localization Files

The WiX localization files, or .wxl files, are a collection of strings. For libraries, extension developers can choose whether or not those strings can be overwritten by .wxl files specified during linkage of the product. For example, part of the WixUIExtension's en-US resources are copied below.

<?xml version="1.0" encoding="utf-8"?>
<WixLocalization Culture="en-us" xmlns="http://schemas.microsoft.com/wix/2006/localization">
    <String Id="WixUIBack" Overridable="yes">&amp;Back</String>
    <String Id="WixUINext" Overridable="yes">&amp;Next</String>
    <String Id="WixUICancel" Overridable="yes">Cancel</String>
    <String Id="WixUIFinish" Overridable="yes">&amp;Finish</String>
    <String Id="WixUIRetry" Overridable="yes">&amp;Retry</String>
    <String Id="WixUIIgnore" Overridable="yes">&amp;Ignore</String>
    <String Id="WixUIYes" Overridable="yes">&amp;Yes</String>
    <String Id="WixUINo" Overridable="yes">&amp;No</String>
    <String Id="WixUIOK" Overridable="yes">OK</String>
</WixLocalization>

These String elements are attributed as @Overridable="yes" to allow for product developers to override these strings with their own values if they so choose. For example, a product developer may wish to use "Previous" instead of "Back", so they can define the same String/@Id in their own .wxl while still linking to the extension where that string is used. This offers product developers the benefits of the library while allowing for customizations. Extension developers can also choose to disallow overriding certain strings if it makes sense to do so.

Building Libraries

When all the fragment authoring and localization files are complete, they can be compiled and linked together using candle.exe and lit.exe.

First compile all the .wxs sources.

candle.exe example1.wxs -out example1.wixobj
candle.exe example2.wxs -out example2.wixobj

Now link together all the .wixobj files an .wxl files for each culture you want available in the extension library.

lit.exe example1.wixobj example2.wixobj -loc en-us.wxl -loc de-de.wxl -out example.wixlib

To be useful, the .wixlib should be embedded into a managed assembly and returned by WixExtension.GetLibrary().

Using the Libraries

Product developers reference elements within your .wixlib, as shown in the WixUIExtension example. When compiling and linking, the extension is specified on the command line using the -ext switch. If any additional localization variables are used in the product authoring or would override localization variables in the library, those .wxl files are passed to the -loc switch as shown in the example below.

candle.exe example.wxs -ext WixUIExtension -out example.wixobj
light.exe example.wixobj -ext WixUIExtension -cultures:en-us -loc en-us.wxl -out example.msi