cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Tim_Mayert
Level 9

Small text or strange characters in Progress Box

Okay here is a strange issue.

We converted a bunch of our projects from IS 2009 to IS 2010 that contained support for multiple languages.

During the build we would have multiple build errors and found out that we had to set the UTF-8 database check box for the release media builds. Once this was done the builds were successful.

Now we have an issue where the progress bar text is extremely small, if the machine has all the language code pages installed, but if they do not then the text shows up as strange box characters:

What is causing this issue and what can I do to fix it as we can not ship this way.

Thanks for all help.
Labels (1)
0 Kudos
(10) Replies
MichaelU
Level 12 Flexeran
Level 12 Flexeran

The small text is a behavior problem with Windows Installer itself. I'm unaware of any workarounds that still use the UTF-8 Codepage. Chances are what you really want to do is fix the strings that were causing build errors without the UTF-8 setting.

Simultaneous to introducing the UTF-8 setting, we introduced wider Unicode text support in our IDE, allowing you to enter text from multiple codepages for a single language's strings. Since this doesn't cooperate directly with the MSI codepage option, we also introduced validation to catch when strings cannot be represented on the default codepage for a given language. What this really means is any string that it complains about has had bad data for a long time, but now we're telling you. However, most of the cases I've seen internally involved invisible character data rather than characters that would show up as something weird.
0 Kudos
Tim_Mayert
Level 9

Okay I'll turn the UTF-8 flag back off and re-check the strings that it thinks are bad.

Thanks,
0 Kudos
Tim_Mayert
Level 9

Okay I am looking at the strings that give the errors and they are mainly for Czech and most of them are correct - no errors in the translations.

What can I do about these ones that are correct, but build still complains with a -7185 error - characters that are not aviable on code page 1250????

If I can not fix for these strings then the only way to build the project is to convert these strings back to English or turn on the UTF-8 flag, in which case we get the small text on the progress bar or strange boxes for text.

Again your help would be appreciated.

Thanks,
0 Kudos
MichaelU
Level 12 Flexeran
Level 12 Flexeran

If you haven't done custom translations, you might try reimporting the strings we provide. I don't see anything relevant in this history on our Czech translations, but I believe some of our strings in other languages had invalid whitespace on the ends of the strings before IS 2010.

If these are custom translated strings, and you can export them, limit it to the strings in question, and post them here, I can see if I can identify the problem.
0 Kudos
Tim_Mayert
Level 9

Attached are the Romanian strings that the install keeps complaining about. We have tried many times to get it to accept these strings but the install will not compile with them in the install.

If you do see anything wrong with the strings let me know.

Thanks,
0 Kudos
MichaelU
Level 12 Flexeran
Level 12 Flexeran

It looks like all of these strings have characters which are unavailable on the code page. The way I find them is with a python script which encodes and decodes on "Windows-1250", and replaces the characters that it can't handle.

This points me to these three characters as the troublemakers. I'm not actually familiar enough with them to know if they're "supposed" to be available on this codepage or why they wouldn't be. But it may be well worth checking out your previous builds of Romanian to see if these characters worked there.

  • þ of Activaþi, dezinstalaþi, opþional, Puteþi, ...
  • º of ºi (GALLERY_*), fiºier, ...
  • ã of Englezã, Matematicã, culturã, dupã, ...
0 Kudos
Tim_Mayert
Level 9

I Just checked my project that was built with IS 2009 and it looks like these particular strings characters were converted to "?". But when the project was upgraded to IS 2010 these characters caused the build to fail.

I have sent you information on to our Translation manager to see what they can do, but if they are the correct translations then how can we get around the build issues? Is it an code page issue or IS issue?

Thanks,
0 Kudos
MichaelU
Level 12 Flexeran
Level 12 Flexeran

My perspective is that the underlying issue is a code page issue, and that there had been a long standing limitation in InstallShield: until recently we couldn't verify that the strings you provide were valid for the target language's code page. In IS2010 we do validate these and let you know where the problems are. I do understand how this seems like a new problem in InstallShield, but really it's finally telling you about something that's been wrong all along. So even if they are "correct" translations, they are not usable unless you use UTF-8; from the code page perspective they are definitely incorrect.

It all comes down to how code pages work, and how MSI uses them. Any character that doesn't have a representation on a code page cannot be shown in a string described on that code page. Windows Installer databases store strings in code pages, so with the exception of the UTF-8 code page (which can represent any character), some characters must be excluded. Unfortunately using the UTF-8 code page has the side effect you noted at the beginning of this thread.
0 Kudos
Tim_Mayert
Level 9

Okay so since we do not want to switch the UTF-8 flag and these characters cause a build issue we have to somehow replace them with something that will allow the build to complete, but also make it so the user of that language can at least read the strings...

Do you have any suggestions on this?

Thanks for you help.
0 Kudos
MichaelU
Level 12 Flexeran
Level 12 Flexeran

I'm no expert in any language other than English (and that only on a good day), so I don't really have any suggestions. I noticed that our Romanian translations do not use any of those characters, so I have hope that it's possible for a good translation to avoid them. Let's see what your translation manager (or the translators themselves) have to say.
0 Kudos