I have an application in which the installer must be in Spanish and English (the client is a Mexican company), and in which a value selected from a combobox widget (along with other values typed into text and entry widgets) ends up being embedded in an XML file. Currently, this is implemented with the "Read File Into Virtual Text" action (to populate the virtual text variable that provides values for the combobox), followed by the "Replace Text In File" action (to write the selected value into the XML file).
We've standardized on UTF-8 encoding for all of our text resources, and the original XML file contains characters for which the UTF-8 encoding results in byte values which are invalid in ISO-8859-1 (which would otherwise be a reasonable default encoding). However, when the values written to the file include non-ASCII characters, they are written out as as Windows-1252 (i.e. single-byte ANSI encoding - like ISO-8859-1 - but including the values between 0x80 and 0x9F as characters). When a conformant XML parser reads the file and encounters these characters (which generally result in byte sequences that are not valid in UTF-8), the disagreement between the actual encoding and the declared encoding (found in the XML text declaration at the start of the file) will cause a fatal parsing error.
This behavior of the "Replace Text In File" action is seen whether the replacement values are entered directly (e.g. typed in the Values property of a combobox widget) or are read with the "Read File Into Virtual Text" action, using the UTF-8 encoding. The attached .zip archive includes an InstallJammer v1.2.9 project (the same behavior is seen in v1.2.8), along with a file containing values used to populate a combobox, and a UTF-8-encoded XML file.
As a default behavior for the "Replace Text In File" action, this is not surprising, since the original XML file doesn't include the optional quasi-byte-order-mark (0xEF 0xBB 0xBF) which is sometimes (but usually not) included in UTF-8 files. However, the ability to set the encoding explicitly is clearly (in my opinion) a missing feature - especially since we can control the encoding used by the "Read File Into Virtual Text" action.
I suggest that the Encoding property be added to the "Replace Text In File" and "Write Text To File" actions.
