Consider the following use case:

 - installer localization is not required
 - one of the application files has a name with non-ASCII symbols, that can be represented in windows-125x encoding, but not in windows-1252 (for example, windows-1251 Bulgarian Cyrillic)

Currently jpackage will fail bundling on light.exe step with the following error:

error LGHT0311 : A string was provided with characters that are not available in the specified database code page '1252'.


It appeared, that with jpackage WiX setup the codepage (1252 in light.exe error message) is actually determined by the "Codepage" attribute in a localization file (see linked comment from WiX author).

It is possible to work around the error using the following custom l10n file:

<?xml version="1.0" encoding="utf-8"?>
<WixLocalization Culture="bg-bg" xmlns="http://schemas.microsoft.com/wix/2006/localization" Codepage="1251">
</WixLocalization>


But with such custom file, the Culture attribute can not be the same as in the primary (jpackage internal) l10n file (otherwise Codepage value is taken from the primary file). So, if "en-us" primary l10n file is used, custom l10n file cannot be "en-us", and actual installer UI language is controlled by this Culture value from custom l10n file (will be in Bulgarian with the l10n file above).

In case, when English installer UI is required, custom l10n file can use "en-gb" or "en" Culture, but this is not exactly the same as use the "en-us".

Attributes in WiX files can be templated with $(var.MyCodepage) variable, this works for main.wxs, but does NOT work for l10n (.wxl) files files, where Codepage must be hardcoded.

It is proposed to introduce support for "--win-codepage" argument, and substitute the Codepage attribute with "--win-codepage" specified value in primary l10n file when it is being copied to the config dir. in this case custom l10n file won't be required.