Skip to content

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!

{ 13 } Comments

  1. digdog | August 7, 2009 at 1:37 am | Permalink

    When will this apply to new Xcode’s default setting?

  2. eschaton | August 7, 2009 at 2:02 am | Permalink

    It’s not clear what you mean. This doesn’t change any of Xcode’s defaults, only the project you apply the changes to.

    If you’re asking whether or when Xcode will have these changes itself, that’s not the sort of thing upon which anyone can comment. And just to be cleat: In everything on this site I’m speaking strictly for myself, never my employer.

  3. Jens Ayton | August 7, 2009 at 2:02 am | Permalink

    I think it’s worth noting that although this has been recommended more or less forever, prior to Leopard it was a horrible thing to do because the Finder info pane which displays an app’s languages just showed the names of the folders. In much of the world, people are more likely to know what the English name of their language is than the language code. (Whether that pane serves any useful purpose is another matter…)

  4. Jeff_lamarche | August 7, 2009 at 5:38 am | Permalink

    Awesome, this is great. Would it cause problems to remove the old-style knownRegions and replace them with their ISO counterparts? I’m guessing it’s risky, but frankly, I’d like to see those gone for good.

  5. Alex Blewitt | August 8, 2009 at 4:57 pm | Permalink

    I recently created an XCode project for the iPhone, and it didn’t have the knownRegions section in the PBXProject. I’ve added it in there, but the localizable strings (en) still seems to come up as gibberish if I open it.

  6. eschaton | August 8, 2009 at 5:13 pm | Permalink

    Alex: Your issue doesn’t really have anything to do with the development region itself. Instead it’s a file encoding issue.

    If Localizable.strings is coming up as gibberish, the file probably has the wrong encoding set in Xcode. Get info on the file within Xcode and change what its encoding to “UTF-16 (Big Endian)” or whatever, and choose “Reinterpret” in the resulting alert until the text looks correct. (The “Reinterpret” button will cause Xcode to not change the file’s contents.)

    In Xcode 3.1 and later the actual encoding used for strings files in Xcode doesn’t matter. When copying them into your built product, Xcode will convert them to UTF-16 (Big Endian) automatically. This way you can keep your development-time strings files in UTF-8 and have them play nicely with SCM systems.

  7. Scott Little | August 10, 2009 at 9:46 am | Permalink

    My Project doesn’t have the knownRegions Section. I didn’t add it and it seems fine, but I still thought I’d ask to see if you know if that will cause problems later on?

    Thanks, scott

  8. eschaton | August 10, 2009 at 10:08 am | Permalink

    It shouldn’t be an issue; if it’s not present, its value should be equivalent to this:

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

    If you’re going to set developmentRegion to en you should probably add knownRegions too and add en to it.

  9. Pierre Bernard | August 19, 2009 at 11:01 am | Permalink

    Thanks a bunch @gloubibou

  10. Jesse Armand | October 6, 2009 at 9:37 am | Permalink

    I checked the latest sample code from Apple, “International Mountains”.

    It doesn’t have this developmentRegion key, and the localization works, why ?

  11. Mahboud | November 23, 2009 at 1:31 pm | Permalink

    Known regions did not exist in my project. (I am currently using Xcode 3.2.1)

    I added developmentRegion and knownRegions at the same time. I followed the rest of the instructions as above. It didn’t work. I went back in and noticed that developmentRegion was no longer in the file. Very odd. I put it back in. Now everything works as expected. When I create a localization, it is created inside an en.lproj subfolder and not English.lproj.

    Thank you Chris.

  12. mikezang | January 2, 2011 at 8:15 am | Permalink

    Hi

    I found if you keep

    developmentRegion = English; not modify to developmentRegion = en;

    That will be more like what Apple sample did.

  13. Cyril Godefroy | October 12, 2011 at 12:26 pm | Permalink

    Your post saved my day. I was really getting mad with this nonsense in Xcode, and the build creating en.lproj and English.lproj in final bundle. I guess when you add libraries and code from others, it best worse as the two code systems mix up.

    Thanks.

Post a Comment

Your email is never published nor shared. Required fields are marked *