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: Czech localization problem
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
βJul 11, 2012
04:21 PM
Czech localization problem
I have a Czech version of an installer and when I try to run the installation in Czech some of the characters are not properly rendered. In particular one character is consistently rendered as a block graphic, the accented z in words like: SluΕΎba
(11) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
βJul 11, 2012
06:57 PM
Can I change the code page used by IS for a particular language? I suspect it is using 1252 and would work better with 1250.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
βJul 12, 2012
09:09 AM
I just built a single-language installer using Czech, and it uses code page 1250. I see no problems displaying the character ΕΎ on a Windows 7 system. What scenario do you see this in - is it a multiple language installer, or are you using a different OS?
(I should probably mention I tried with InstallShield 2012 Spring, but I don't think we've made any changes that are relevant to this behavior.)
(I should probably mention I tried with InstallShield 2012 Spring, but I don't think we've made any changes that are relevant to this behavior.)
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
βJul 12, 2012
10:35 AM
It looks like we are using IS 2011. Is it different thatn 2012 and can I change the code page because I think it is using 1252?
Windows 7 and multi-language installation.
Windows 7 and multi-language installation.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
βJul 13, 2012
09:09 AM
I think all our relevant changes went in place in IS2010 for MSI and IS2011 for InstallScript. And even the ones I'm thinking of are unlikely to have changed this.
I just tried including both English and Czech, and it still displays correctly on my system. While the underlying .msi uses code pages, the display logic is actually a Unicode program which only uses the code page to translate the stored strings back to Unicode. Have you changed the fonts from the defaults? You can check this, for example, by testing if a new sample project works correctly. If it doesn't, we can cross-check if it works correctly on my or another system.
I just tried including both English and Czech, and it still displays correctly on my system. While the underlying .msi uses code pages, the display logic is actually a Unicode program which only uses the code page to translate the stored strings back to Unicode. Have you changed the fonts from the defaults? You can check this, for example, by testing if a new sample project works correctly. If it doesn't, we can cross-check if it works correctly on my or another system.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
βJul 16, 2012
07:57 AM
Ahah, using InstallScript was the key. I'd been trying Basic MSI projects (as my last comment indicated). On first blush it looks like a font issue, as if I include the ΕΎ character in my product name, it appears fine in the title bar but not in the text in the wizard.
I confirmed this is the font by adding the following code to the DLG_INIT in an override of SdWelcome, which fixes the symptom on the controls specified, but is an incomplete solution.
I confirmed this is the font by adding the following code to the DLG_INIT in an override of SdWelcome, which fixes the symptom on the controls specified, but is an incomplete solution.
hFont = GetFont("Tahoma", 8, STYLE_NORMAL); // note: declared HWND hFont above
CtrlSetFont(szDlg, hFont, SD_STA_MSG);
CtrlSetFont(szDlg, hFont, NEXT);
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
βJul 19, 2012
11:12 AM
What would be a complete solution?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
βJul 25, 2012
08:27 AM
You could apply this call for all controls on all of the dialog boxes you show; I personally think that would be too painful to be realistic. Alternately, you can edit the resources to specify the alternative font.
However it may be worth verifying whether the behavior exists on a system that is likely to select Czech by default; it's possible that it would use a different font by default that does not have this problem.
However it may be worth verifying whether the behavior exists on a system that is likely to select Czech by default; it's possible that it would use a different font by default that does not have this problem.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
βJul 25, 2012
11:38 AM
Thanks for your help but it looks like I failed to mention that I was unable to repro on Windows 7 - our customer reports it was happening on Window 8. Do you know if it is possible that code page 1252 is not present on early releases of Windows 8? Our app specifies that code page in the Win32 resource. I have not been able to get my hands on a Czech Win 8 yet to try it out.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
βJul 27, 2012
10:06 AM
I'm not aware of any such change in Windows 8, and it would strongly surprise me. For what it's worth, the control panel > Region Settings includes Czech (Czech Republic) in the list of options for the current system locale on the release preview. I think this indicates the code page is present.