Non-English Strings in English Installation

[bdwilliams]

I have recently run into a serious issue that is plaguing a current project and I have run out of options at this point. I am beginning to question the integrity of Macrovision's localization.

The project is as follows:
English only user interface
40 components that have conditions based on UserLanguageID
Each component creates shortcuts in the respective language.

You would think this would be simple. Except that the fact you're using an English string table seems to screw everything up.

I created my 40 IDs in my string table. Exported the table. Modified the UNICODE version using Notepad, saved it. Imported it.

The IDE does not properly display any of the unicode characters. Some of the extended ascii but none of the Chinese, Japanese, Hebrew, Hindi, etc.

If I load that same string table into the Chinese langauge it displays the Chinese, Japenese, etc, but the Hebrew and Hindi don't appear.

Now why would the language the string table is designed for change how the IDE interprets the unicode? I would assume all string tables are in the same format.

Now. If I export the English string table with the unicode in it, the exported string table appears properly in Notepad and any other unicode compliant text editor. Which means IS is storing the data properly, but is not parsing it properly.

Attempting to build the installation and run it causes the transform to fail when applying the language that a string contains invalid characters for a path. Because it's reading in question marks (?).

Is there an issue with the encoding on my text file? I am using the file straight exported from InstallShield.

I cannot determine why there are inconsistencies between the different language string tables and I cannot determine why the exported string table contents are accurate but they cannot be imported into the installation properly.

If my installation user interface is in English, I should still be able to use strings that are not, the English should simply be stored as unicode. Somewhere along the lines it's messing everything up. I don't care if the IDE doesn't display it properly, but it has to function in the end product, and currently I am receiving neither from IS 2008 Premier.

This is a big investment in a solution that should be fully localizable, yet I cannot determine why this is posing such a problem.

Any insight anyone could give me as to clearing up this issue would be greatly appreciated. Perhaps I have to do some funky encoding on the text file before importing it other than unicode. I am willing to accept any tricks or hints anyone may have in getting my installation to use an English string table that supports unicode text.

Specific languages that are posing problems: Arabic, Bulgarian, Chinese (Simplified and Traditional), Greek, Hebrew, Hindi, Japanese, Korean, Macedonian, Russian, Thai

Note that some of these languages work properly in other String tables. But if I am using an English user interface and installation I cannot use another string table without importing all of the English strings into a Chinese or other string table, which just seems ridiculous.

-Brett

[Mike_Marino]

Do you have the code pages for those languages installed on your machine?

Our String Table Editor is a based on the Microsoft Flex Grid Control, which is ANSI based. It can show other Locals, however I believe that the code pages for those languages need to be installed on the machine for it to work.

[bdwilliams]

Thanks for the reply.

Yes I do have the code pages installed. The text appears fine in an external editor, like Notepad and other places on the machine.

I have the MAC, OEM, ANSI/OEM, Arabic, ISCII, UTF8, ISO-2022, ISO 8859-8, plus others like JIS X, Simplified Chinese GB2312. The only ones I don't really have installed are some of the IBM EBCDIC ones, which shouldn't be necessary.

If it has the proper code pages to view the text in other Microsoft applications I would assume the Flex Grid control would use the same.

This is a build machine used for regular installation builds, however this is the first time working with unicode and double byte. The consistency across the different string tables is what confuses me. For example with the English string table the chinese displays as ???'s, but if I import the same file into the Chinese string table it appears as Chinese. So it does not appear to be the Flex grid.

Thanks though, it did make me double check to verify I had them installed.

[Mike_Marino]

The problem with the Flex Grid control is that it can only display one code page at a time, it is not a Unicode control. So Japanese, or Chinese characters in the English String table will not show up correctly. We switch the code page of the Grid Control to match that of the language you are viewing.

So Chinese characters should look OK in the Chinese String Table, but not in the in English.

There is a Unicode Flex Grid control, however that is not the one we are using (at this time).

[bdwilliams]

I appreciate the responses. This clears things up for me knowing that the control itself is not Unicode and it has to code page swap per language selected. That makes a lot more sense now why some appear and others do not.

I was able to get the issue cleared up through trial and error of different editors to make sure I was retaining the proper encoding that IS exported.

Though it took some trial and error which I believe could be a bit smoother process, it is functioning at this time which is what matters most.

-Brett