Using “en” instead of “English” for your Xcode project’s development region

Various pieces of Mac OS X and iPhone documentation have said for quite a while that the “preferred” method is now to use ISO-639-1 (two-letter) or ISO-639-2 (three-letter) language codes codes for localization purposes. Out of the box, Xcode’s project templates still use “English” rather than “en” as their default localization.

How can you use the ISO-639 language codes everywhere in your project, rather than in just your non-English localizations?

It’s pretty straightforward, but it does require hand-editing of your Xcode project file. This means that before doing anything else, you **must quit Xcode and Interface Builder**.

The first step is to rename your existing localizable resource directories *on disk* from `English.lproj` to `en.lproj`. You can do it at the Terminal or in the Finder. If you’re using an SCM system such as Subversion, use it to do the renaming so it preserves your file history and such as well.

The next step is to adjust how your existing localizable resources are referenced in your Xcode project file. Open the `project.pbxproj` file inside your Xcode project in a plain text editor such as TextEdit (rather than Xcode) and replace **all but one** occurrences of the string `English` with the string `en`. The one you don’t want to replace is in a property under the PBXProject section named `knownRegions`: This is an array of localizations Xcode knows about. Just make sure `en` is at the end of the array:

knownRegions = (
English,
Japanese,
French,
German,
en,
);

At this point, this should be the only place `English` appears in your `project.pbxproj` file.

Finally — and this is the important step, and non-discoverable step — you need to **add a property** to the `project.pbxproj` file to tell Xcode what the Development Region for your project is. Again, this gets put into the PBXProject section before the `knownRegions` key from above (Xcode will alphabetize the keys when saving your project for you); it should look like this:

developmentRegion = en;

The default value of this key within Xcode is `English` and Xcode won’t write the key into the project if the default isn’t changed. However, there’s no user interface within Xcode for actually changing this property, making it non-discoverable. Furthermore, if you are changing your project to use `en` as its default localization, and you *don’t* change this property, you won’t be able to add new localizations by inspecting your resources. (This is a known issue.)

At this point, you can save your modified `project.pbxproj` file and open your project again in Xcode. There’s one more thing you’ll have to change, this time in your product’s Info.plist file (or your products’ Info.plist files), before you can get back to work: You need to change the `CFBundleDevelopmentRegion` property to `en` rather than `English`.

Once you’ve made that change, you should safely be able to use your Xcode project normally, adding localized variants of your resources, building and running, and so on, and everything should Just Work — now using modern ISO language codes instead of the English language names!

Xcode: Understanding Xcode Projects

Anyone interested in Mac OS X development should check out the latest Xcode article on the Apple Developer Connection, Understanding Xcode Projects:

To become truly proficient with Xcode, whether you’ve been using it for a while or are just starting to make the transition, an understanding of the Xcode user interface and how it is used to organize a software project is required. This understanding will take you a long way towards understanding the philosophy behind Xcode and how it works, and will help to make it work better for you.

In short, the article introduces what we call the Xcode project model, which defines how Xcode projects are organized, how Xcode generates products from targets, and how projects and targets relate to one another.

It doesn’t cover the details of the build settings that are used by targets or how they’re collected in target and project configurations. Both topics are covered in depth in the Xcode User Guide. I also wrote about configurations when they were introduced in Xcode 2.1 as a replacement for build styles.

Update: The article Working with Xcode Build Settings was recently posted covering configurations and build settings.