site_archiver@lists.apple.com Delivered-To: installer-dev@lists.apple.com Am 23.05.2008 um 21:05 schrieb Jim Dodd <bcbuilderboy@yahoo.com>: HTH Mike -- Mike Fischer Softwareentwicklung, EDV-Beratung Schulung, Vertrieb Note: I read this list in digest mode! Send me a private copy for faster responses. _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.a... I have been using PackageMaker for a few years and it has worked well for what we needed. Now, we have changed our application to be available in two languages (more will follow) and I need to be able to load the appropriate manual and help files based on the language the customer is using. The application itself is no problem because it is built with Resource Bundles and chooses the correct strings for dialogs and messages correctly. But we don't want to copy all the available manuals and help documents in each language to the customer's disk.We would just like to copy the French manual and French help if the user is running the Installer in French, for instance. There are a couple of situations where your thinking will cause problems: - What if the administrator installs the app and her user account is set to a different language than that of the actual user? - What if multiple users using your app on the same machine are using different localizations? - I often keep around a user account named "English" to be able to send bug reports, etc. to the authors including screenshots in their native language. If the app installer had only installed my native language (German) then I would not be able to do that. I'm familiar with PackageMaker allowing for ReadMe, License etc files in different languages to localize the Installer itself and the fact that InstallationCheck and VolumeCheck can have their strings in different languages that are chosen at runtime.. But is this information (which language is being used by the Installer) available for our preflight, postinstall and postupdate scripts? You could probably hack something like this by removing all localized files for localizations that don't match the current one in the postflight script. But this is going against the grain. It could also be dangerous because the localization falls back to the CFBundleDevelopmentRegion if the exact localization can't be found. So you'd also have to keep that around. Why not just tell the user in your ReadMe or other documentation that they can reduce the size of the app by using the Finder Information window and manually deleting any languages they don't need? They can only do that if they are authorized to modify the app of course (which is good). Or you could make the localizations other than your CFBundleDevelopmentRegion optional and package them in optional sub- packages of a meta package. This email sent to site_archiver@lists.apple.com