Localization, Language Packs, etc. ??

[Superfreak3]

Hi all,

We are going to be upgrading to the Premier edition (2012, I guess) as the need has arisen for us to have a localized product & installation.

I do have a few questions around this, of course.

How do most deal with installations in different languages. One of our products is delivered in an .msi and the other is wrapped in a Setup.exe. For the .msi I would think this would have to be separate packages for the different languages. Or, if I choose 1033 and #### (for French) in the .ism will that work. I would think you would have to choose the preferred language somehow, but there would be no front end UI to do so.

Also, for the most part, our .msi delivery is run silently so I don't know how I'm going to deal with product placement based on language. I guess that depends on what development has in store for my come deployment time. I know I will find out at the last minute.

Enough rambling. I guess I just need to know if you guys/gals develop separate packages per language or somehow combine. Again I guess this may depend on what has to be placed for the product to support localization.

I hope someone can make sense of this and can provide some info, starting points, etc.

Thanks and sorry for the lack of clarity!! 😉

[MichaelU]

When we deliver InstallShield in both English and Japanese, we build separate binaries and separate installations. If your product is structured to run in any of its supported languages without changing its binaries, you can build a single installation that supports all of those installation languages.

If it's a .msi project, this approach will use transforms to change between the versions. So you can either pass TRANSFORMS=... to select the language, or pass it to setup.exe's /l parameter even if running silently. InstallScript setups support /l similarly but aren't built on transforms. If you run with setup.exe UI, it has a language selection dialog you can choose to enable; without this, we will try to select the best fit languge for the settings of the target machine.

With suite installations in InstallShield 2012, there's another potential layer of complexity here, but it doesn't sound like you're looking at that yet.

[Superfreak3]

Thanks for the response. I believe the binaries will be the same for all language versions.

So, for .msi's I need to use transforms, correct? If so, what property, etc do I flip in the package to show difference for transform generation (its been a while since I created transforms with InstallShield so I'll have to revisit that)? Would it be create the package in English, change maybe the Setup Language and/or Default Language attributes in the General Information view (General section), then create the new transform for the second language.

Oh and also, I will be looking into the Suite concept soon so any info on that with regard to localization would be appreciated.

Again, thanks so much for the information so far.

[MichaelU]

So it sounds like you will likely prefer a single installation that can handle multiple languages. To do this, use the settings in General Information (to enable various languages) and in the Releases view (to include them in a build) will together do all the heavy lifting to generate the transforms at build. Note that you will need to provide any necessary translations for strings you have created (for names of your features, etc.). See Creating Multilingual Installations in the help for more details.

[Superfreak3]

So, it won't matter which method we use for package deployment, .msi or setup.exe, with regard to multiple language support in a single installation?

Also, when you say I would need to provide translations, do the language packs included with the Premier edition only include translations for strings out of the box? In other words, if I add a dialog and new labels, I would have to provide the translations for these new controls?

Thanks for all of this information. It's getting clearer!! 😄

[MichaelU]

It almost doesn't matter; but if you want the user to be able to select the language, it has to happen before the .msi is launched. As I alluded to earlier, the setup.exe bootstrap handles this either with a dialog or the /l command-line parameter; the .msi would require a command line to specify the proper language transform (.mst file).

As for translations of labels and other controls you add to a new dialog, you're absolutely correct. Things like the next button are already translated, so long as you select the existing string table entry in use on the built-in dialogs. But anything new you add will need a translation, as we haven't quite ironed the kinks out of our clairvoyance feature (or any automatic translation for that matter).

[Superfreak3]

It's funny you mention clairvoyance because I was going to ask if that feature was yet implemented in the overall InstallShield product line. Where I work, I am supposed to install bug fixes before they are coded and supplied to me. I affectionately refer to this concept as Clairvoyant Installation Technology. Can InstallShield help with that? 😄

Seriously, thank you for the replies! They have been more than helpful!!

Have a greate Holiday Weekend!!!

[Superfreak3]

Without looking at the link you mentioned earlier, theoretically, if I can localize specialized strings, couldn't I localize the whole thing myself without having to purchase the Premier edition?

[MichaelU]

That depends largely on how you build and launch it. Only the Premier edition is willing to create the language transforms for you, and only when it builds it is setup.exe likely to know they exist.

[Superfreak3]

OK, I guess I'll look at the documentation to better understand as well.

Thanks for your replies on this!!!

😄

[Superfreak3]

Soon I'll be moving to localize our .msi installer project. I'm currently working on translating any specialized dialogs/controls I have added for our installs that are wrapped in Setup.exe's.

For the .msi, and I guess I'll see this eventually, when I add a language, are the transforms embedded in the .msi...

Embedded Transforms.

The only thing that concerns me is that they are not cached on the target system so I don't know what effect this may have on repair installs. We currently have user specific items that cause repairs for non-installing users on launch, but we're looking to move away from that. I just wouldn't want any problems until we get to that point.

[MichaelU]

Transforms applied during the initial installation (the only time you can apply them) are cached on the target machine just like the .msi package. Associated files in transform-added cabs (not so relevant for the translation case you're talking about) are not cached so might not be available during maintenance.

[Superfreak3]

I take it I'll be working with external .mst's then.

Again, I guess I'll see when I get to them, but are they built at build time for me of is there some intermediary steps I need to take to create them as they pertain to languages.

I remember when I worked with InstallShield a bit years ago, I compiled an installation then made changes to the template to generate the .mst. Again, this had nothing to do with languages back then.