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: Problem importing stings of a different locale
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
Sep 07, 2009
11:53 AM
Problem importing stings of a different locale
We are having problems importing in strings of a different locale from a Unicode text file into our ism on our build machine. This import works fine on all our development machines and another build machine – but the machine we want to use is not importing in the strings properly.
The build machines both just have IS 2009 standalone builder, and are Windows XP.
Each install is initially created in English and then transformed to the other language. Part of this transform imports the language strings for that locale using the Automation Interface and the script that was supplied by InstallShield.
On the machines that work, the strings import fine in UTF-8. Here is an example string to be imported and how it’s displayed in the String table
ID_STRING27 Español
ID_STRING271033Spanish0-1164218227
ID_STRING271034Español0-1004712334
However, on the machine that doesn’t work this appears to have been imported as base64 encoding – it’s clearly different to the UTF-8 encoding above
ID_STRING27103410!S`'``80#Q`&\`;```71016968304
When this is then built the text is not converted back correctly and the text appears as squares in the IDE.
This is strange as it is the exact same script that imports these text strings, the version of the Standalone Automation Interface is the same and the files are the text files are the same binary UNICODE text files – the same file imports fine on the other machines when copied over.
Does anyone know of any environmental factor or anything else that may cause this issue? This is causing us great delays and a lot of time has been spent trying to figure this out.
Thanks in advance,
Adrian
The build machines both just have IS 2009 standalone builder, and are Windows XP.
Each install is initially created in English and then transformed to the other language. Part of this transform imports the language strings for that locale using the Automation Interface and the script that was supplied by InstallShield.
On the machines that work, the strings import fine in UTF-8. Here is an example string to be imported and how it’s displayed in the String table
ID_STRING27 Español
However, on the machine that doesn’t work this appears to have been imported as base64 encoding – it’s clearly different to the UTF-8 encoding above
When this is then built the text is not converted back correctly and the text appears as squares in the IDE.
This is strange as it is the exact same script that imports these text strings, the version of the Standalone Automation Interface is the same and the files are the text files are the same binary UNICODE text files – the same file imports fine on the other machines when copied over.
Does anyone know of any environmental factor or anything else that may cause this issue? This is causing us great delays and a lot of time has been spent trying to figure this out.
Thanks in advance,
Adrian
(1) Reply
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Jan 26, 2010
12:23 PM
InstallShield exports the string table file in USC-2 Little Endian encoding (UTF-16). It expects the import file to be in the same encoding.
Use a text editor that supports encoding conversions (notepad will do) to ensure your import file is in USC-2.
Use a text editor that supports encoding conversions (notepad will do) to ensure your import file is in USC-2.