Is it possible to define a language transform for LoadStringFromStringTable?

[IlkkaV]

I'm having a problem with localizing custom question dialogs and possible custom error messages during uninstallation. If I install my package in a language other than English, everything works fine until I get to uninstallation. The default dialogs are shown in the non-English language like they're supposed to, but by the time my deferred InstallScript custom action tries to fetch a translation for the message I need to show, the result is in English. I've tried both string constant operator @ and LoadStringFromStringTable function, and while the rest of the uninstallation seems to know what language transform to use, this doesn't seem to apply to InstallScript functions.

Previously I've worked around this by having another custom action write the localized strings to a property that's then passed as CustomActionData to my deferred custom action, but for some reason trying to read those strings from the property in my deferred function fails in Windows 8.1. Could this be because there are variable placeholders and escape sequences (@, \n) included in those strings?

How could I get my uninstallation to be localized properly and work on Windows 8.1 as well?

[IlkkaV]

It appears that the old workaround has been broken by InstallShield 2013. An older package built with InstallShield 2012 Spring works fine on Windows 8.1.

[DemonPiggies]

Can you not use a #Define for the language string and #if...#ifelse...#endif for selecting the language. Might be easier than using the string table or a custom action. Could just include a translator application or code in the script so that it switches to the correct language strings via Switch case or some such thing.

It makes sense that your workaround is broken since Flexera sells a version of InstallShield that is for different languages. I know our version supports only 1 string table and the next license up supports multiple.

[IlkkaV]

DemonPiggies wrote:
Can you not use a #Define for the language string and #if...#ifelse...#endif for selecting the language. Might be easier than using the string table or a custom action. Could just include a translator application or code in the script so that it switches to the correct language strings via Switch case or some such thing.

No, not really. With over 15 languages to support, an ifdef mess becomes unmaintainable before it's even fully implemented, not to mention issues with different character sets etc.

DemonPiggies wrote:
It makes sense that your workaround is broken since Flexera sells a version of InstallShield that is for different languages. I know our version supports only 1 string table and the next license up supports multiple.

Well we're already using the top tier version as we need the localization support. The workaround has been working fine from late 2010 up to now, so to me it looks like InstallShield 2013 has introduced a regression in that area.

[DemonPiggies]

IlkkaV wrote:
No, not really. With over 15 languages to support, an ifdef mess becomes unmaintainable before it's even fully implemented, not to mention issues with different character sets etc.

Understandable. We use some automation for maintaining our translations within our application which uses #Defines, so I was hoping it could help but totally understandable.

IlkkaV wrote:
Well we're already using the top tier version as we need the localization support. The workaround has been working fine from late 2010 up to now, so to me it looks like InstallShield 2013 has introduced a regression in that area.

Have you opened a ticket with Flexera? Sounds like they need to issue a fix then.

[IlkkaV]

DemonPiggies wrote:
Have you opened a ticket with Flexera? Sounds like they need to issue a fix then.

Not yet, but I think I will do so tomorrow. Just hoping that this is a known issue and someone from Flexera chimes in and reveals that a hotfix exists 🙂