Ios – Why doesn’t the file move into “en.lproj” but instead into a new “English.lproj” after “Make file Localizable” in Xcode

iosipadiphonelocalizationxcode

This is a bit confusing:

First I used genstrings, which created me a Localizable.strings file inside an en.lproj folder (also exists on the file system like that).

Then I had a JSON file which I wanted to localize, so I opened the info-pane for that file and choose "Make File Localizable". Xcode then created an English.lproj folder on the file system and also a group called like this. It then moved my file into there.

So now I ended up having en.lproj and English.lproj for basically the same thing: English stuff.

I'm not happy with this situation. Can / should I do anything about it? How can I fix that?

Also, can someone point out what's the difference between using "English.lproj" vs. "en.lproj"? I bet there is a difference.

Best Answer

It's an Xcode bug. Just move everything in the English.lproj folder to en.lproj folder. I haven't checked with Xcode 4.1, but previous versions of Xcode wouldn't allow you to add new localizations if you delete the English.lproj folder, so don't delete it.

You could manually edit your project file to avoid the problem as this post suggest, but I've never really found doing so to be worth it.

Some background -- prior to Max OS X 10.4 the legacy (but more user-readable) names such as “English”, “Spanish”, etc., were used, but the Apple internationalization documentation states that these values are now deprecated:

In addition to the ISO language designators, the bundle routines also recognize several legacy language designators. These designators let you specify a language by a user-readable name, instead of by a two or three character code. Designators included names such as English, French, German, Japanese, Chinese, Spanish, Italian, Swedish, and Portuguese among others. Although these names are still recognized and processed by the NSBundle class and Core Foundation bundle functions, their use is deprecated and support for them in future versions of Mac OS X or iPhone OS is not guaranteed. Use the codes described in “Language Designations” and “Regional Designations” instead.

Related Topic