HTML Display Text doesn't display properly for non-english strings

This happens for the welcome screen (for example) when displaying even simpler things like Russian:

Instead of getting cyrillic characters, I get "?" characters. This is with the out-of-box InstallShield strings, not only my home-made strings.

Note that it seems to work fine on non-HTML display widgets, so the buttons and title bar are fine, but not the Welcome Page.

Any suggestions? Do I have to change the encoding for the HTML-displayed widgets to be HTML escaped characters?
Labels (1)
0 Kudos
3 Replies

Re: HTML Display Text doesn't display properly for non-english strings

Follow Up Info:

This only happens for MyStrings.

Strings that are from com.installshield.* don't have this issue.

BUT, to confuse things:

If I copy WelcomePanel.message from com.installshield...ProductResources_ru.properties

and put it into MyStrings.properties
and change the dialog to load from MyStrings instead of com.installshield.*

then it still fails: it displays ? characters instead of cyrillic.
load it up and compare and the property file entry is byte-for-byte identical. It just doesn't work.
0 Kudos

Re: HTML Display Text doesn't display properly for non-english strings

Additional follow up (minimal steps to reproduce)

1 - make new project
2 - copy the i18n/com/... product resources properties to a new directory, renaming to MyStrings_ru.properties (I only did english and russian, to make the test quicker)
3 - import files from #2

so now you have a "MyStrings" which is 100% identical to the out-of-the-box content, as it's a direct copy of the files.

4 - build the installer with russian support
5 - run the installer in russian

the welcome screen shows question marks rather than cyrillic characters.
0 Kudos

Re: HTML Display Text doesn't display properly for non-english strings

So I found the problem (in case anyone's interested and doing a search) and came up with a solution.

- the "original" strings are stored in escaped-unicode ascii text (content looks like "\u1384\u2383" etc.)

- On import, InstallShield converts the strings to Unicode and stores them in unicode internally. When it's run, it uses this internal unicode format.

- when running, it HAS to be in the escaped-unicode ascii text format, NOT UNICODE, or it won't work.

So, InstallShield isn't doing the right thing: it should definitely be exporting its internal structure to escaped-unicode at build time, but it's not doing so.

So, we need to do this ourselves!

solution (if you're not familiar with native2ascii, you're going to need to research that before you'll be able to do this. I did it all with maven and it's working smoothly, though I had to work around some InstallShield peculiarities to make it work)

1 - Do all your string work using MyStrings (or whatever you call your string category in the string table.) Once you're happy with the layout, export the strings to a directory (this saves your strings in .properties files)

2 - Rename all the relevant .properties files (languages with non-ascii characters) to .utf8. For example, I have MyStrings_ja.utf8 in my Japanese Language Pack directory.

3 - Before your build runs, use native2ascii (sun java tool, or the ant task that calls it 🙂 to convert the .utf8 format files into escaped-unicode files, named .properties (this is a normal thing for native2ascii to do)

4 - InstallShield Peculiarity: .properties files are resource bundles. InstallShield will only use resource bundles from the ${IS_HOME}/i18n directory. So you need to copy the results of #3 above into this directory structure. I'd highly recommend using a java-style com. hierarchy when doing this if you build more than one installer (lest you get the strings from the wrong installer!)

For example: C:\IS11.5\i18n\com\company\product\MyStrings.*

5 - In InstallShield, in the Releases configuration area, under the Languages Section, you need to add your custom resource bundle from #4 above.

For example: com.company.product.MyStrings

6 - When you refer to your strings in the product, you need to change things slightly. Instead of "$L(MyStrings,StringName)" you'll need to put "$L(com.company.product.MyStrings,StringName)" instead.

7 - build and run your installer, that's it!

Note that the standalone builder uses the same directory structure. For my project, the maven build calls the standalone build, whereas my working environment is in the normal InstallShield IDE. So I generally end up copying the content from C:\IS11.5-SAB\i18n\com\company to C:\IS11.5\i18n\com\company after I run the maven build (which does the native2ascii for me)

It's very simple and direct, but it's very very very annoying that InstallShield didn't do this already 😞
0 Kudos