3 replies to this topic

[sebica79]

Hi there,

I’m using InstallShield X. I intend to create a huge project with English as default language. In the end I have to provide also a patch / language pack that will update a number of resource files for several languages. I would like to create a separate module for the localization of the binaries files.
I am currently comparing two possibilities to accomplish this localization issue, but I’m not sure what the best way is.
First of all, I was thinking if it is a good idea to create separate patches for each language, which can be applied to the main English product. The patches would contain the resources files which get installed after the main product (English version) was installed on the target machine.
The second idea would be to create merge modules which may contain also the resource files for all available localizations. Those *.msm files will be added in the main English project under some features. Then, the features will be conditioned depending on the language which was selected at the beginning of the installation.

Please, take a few minutes, comment on my ideas and also, let me know what you think and maybe let me know other ideas that may work in this case, I’m looking forward for yours replies.


Thanks,
Sebastian.

[reddy611]

Hi ,

I feel the 1st option is the best if you are using InstallShield Premier edition, setup itself will identify which OS you are going to install like is it English, Japanese, Dutch...etc. so once main application is installed, create a custom action to identify your patch or updates and call that custom action in the sequences at after Installfinalize.

Regards,
Reddy611(Prathap)

[sebica79]

Hi,

Thanks for the reply. I don’t get it all of your idea. What do you mean through “create a custom action to identify your patch or updates and call that custom action in the sequences at after InstallFinalize”? The first option would be to install only the English product, no matter the OS language is, and then, depending on the customer’s option, a patch with the resources files (corresponding to customer option) will be installed over the main product. The updates or the “patches”, will be created as separated projects, not as a truly patch because the user would may want to install another language after the first localized language was applied. If I’ll create the localization packages as patches, a base image (an *.msi file) is needed for that – in our case the msi for the main product. This will get changed after the first localization is applied so the second will no longer be available for installing.

The main weakness if I’ll create a separate project for the resources binary files, would be the way how the programs must be uninstalled – first the localized package must be uninstalled and then the main product, because there is no relations between them.

Another weakness would be if I’ll try to apply a patch later, on the main product which has already applied the localized package, I don’t think so that would be possible.

Anyway, here we can get in the second option, if we are creating separated projects, but as merge modules which can be included in the main product.

Thanks again, and I’m still open to your suggestions,
Sebastian

Edited by sebica79, 21 June 2006 - 07:51.

[Stefan Krueger]

If you need to add the locatization later a patch might be a solution, but it's not really the purpose of a patch.
You don't need to use merge modules, you can conditionalize features on OS language or on the language in which your setup runs (your setup would be multi-lingual).
Using Release Flags you could even build multiple language specific versions of your setup from one project.