This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: HTML Display Text doesn't display properly for non-english strings
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 06, 2007
01:34 PM
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?
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?
(3) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 06, 2007
06:45 PM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 07, 2007
11:41 AM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 16, 2007
03:32 PM
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 😞
- 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 😞