views:

221

answers:

2

I've created an OS X installer package that includes localized resources (License.html, Readme.html, etc.) In particular, it includes a localized postflight script, since some of the post-install actions differ from language to language; opening a per-language file after the install completes, for example. The package is created as part of an automated build, not through Package Maker.

Originally I used the 'full' locale name as the localized Resource folder name; for example, English.lproj. Everything worked fine. Recently, I switched to the ISO name, i.e. en.lproj, since I discovered that was what Package Maker was using, and this question indicates that form is preferred. Everything worked exactly the same, except that the postflight script is no longer executed.

I did some more testing, and noticed that, even when it works (using the full language name as the name of the folder), it logs this message to the console:

Localized installer script postflight found in the <name> package. Using compatibility mode.

I can find barely any mention of Installer localization in Apple's developer docs, much less anything specific about scripts. Does anyone have experience with this? Is it a bug for it not to work with en.lproj, or was it a bug for it to have worked before?

A: 

Things that I don't understand:

  1. If you're not creating these packages with PackageMaker, what are you creating them with?

  2. Why would a postflight script ever need to be localized when conditional logic would almost surely suffice?

Azeem.Butt
They're created by a script; the installer package format isn't very complicated. I could have the script switch on the output of 'locale', but that adds a more complexity to the script, and makes it difficult to localize. It's much easier to create separate translated copies of something than to insert multiple translations into a single file. Having Installer do the switching, as it seems to when using full folder names, makes my life much easier. I'm just interested in knowing whether that's an option.
DNS
PackageMaker provides a command line tool which can be run from any build script. If you're not going to use it then you're accepting all responsibility for keeping whatever it is you've written up to date. What's actually much easier is looking at all the environment variables that have been set for your script and adjusting its behavior accordingly at runtime. Maintaining a completely separate script for every single language you support is a waste of both time and bandwidth.
Azeem.Butt
The postflight script is run with root privileges, so unless someone set the language preferences for the root user (which is not done by default) you can not get this info from the environment variables.
MatsT
A: 

It turns out that, no, this is not supported anymore.

DNS