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!
August 7, 2009
When will this apply to new Xcode’s default setting?
August 7, 2009
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.
August 7, 2009
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…)
August 7, 2009
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.
August 8, 2009
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.
August 8, 2009
Alex: Your issue doesn’t really have anything to do with the development region itself. Instead it’s a file encoding issue.
If
Localizable.stringsis 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.
August 10, 2009
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
August 10, 2009
It shouldn’t be an issue; if it’s not present, its value should be equivalent to this:
If you’re going to set
developmentRegiontoenyou should probably addknownRegionstoo and addento it.August 19, 2009
Thanks a bunch
@gloubibou
October 6, 2009
I checked the latest sample code from Apple, “International Mountains”.
It doesn’t have this developmentRegion key, and the localization works, why ?
November 23, 2009
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.
January 2, 2011
Hi
I found if you keep
developmentRegion = English;
not modify to
developmentRegion = en;
That will be more like what Apple sample did.
October 12, 2011
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.