Tools to Help Test Localization

Apple provides some pretty slick tools to help with localization testing in your apps. I had completely forgotten about two launch parameters that make it possible to find those pesky layout problems early:

• NSDoubleLocalizedStrings – Any calls made to NSLocalizedString will double the strings to simulate languages with longer words, like German.
• NSShowNonLocalizedStrings – Replaces any text from NSLocalizedString that doesn’t have an entry in a strings file.
• AppleTextDirection – Simulates a Left to Right language.

In Xcode 7 there is an easier way to provide these options. Edit the scheme for your app, click on the Run section, then the Options tab. You’ll see Application Language has two options – Double Length Pseudolanguage and Right to Left Pseudolanguage. There is also a check box for Show non-localized strings. These three options are equivalent to the launch arguments above.

There’s more about testing the localization of your app in Apple’s Internationalization and Localization Guide.

Why Isn’t it Working!?!!?!?

This past week I spent a good chunk of a day trying to figure out why Xcode’s options for localization testing weren’t working. I tried the three items above and also tried sending them as launch parameters like -NSDoubleLocalizedStrings YES with no avail. I checked the contents of NSUserDefaults upon launch and verified that the launch parameters made it into the defaults as expected. Why wasn’t it working??

I then tried to set the user default myself in the app delegate. At first it didn’t work. Then when I restarted the app suddenly the strings were being duplicated. I was confused to say the least.

I dug deeper and discovered that two test apps I had written for RayWenderlich.com worked just fine with the Xcode options and launch arguments approach. My project that didn’t work had CocoaPods – so I thought maybe that was the problem. It wasn’t because the second test app had CocoaPods. I then decided it had to be one of the pods causing the problem.

I went back to the original app and started removing pods from the Podfile. Turns out the pod causing the issue was AFNetworking! I then added AFNetworking to my demo project that was working and it stopped working after that. Then I dug through each subspec in AFNetworking and found that the NSURLSession spec was the culprit.

Turns out there is a single line of code in a method swizzle in AFNetworking’s AFURLSessionManager’s private class _AFURLSessionTaskSwizzling that’s causing the issue.

I opened an issue on GitHub to help track this. It does seem to be an issue even in AFNetworking 3.

How do I Fix it Right Now?

Simply comment out the line of code referenced above in your checked out copy of AFNetworking. If you’re using CocoaPods you’ll get a warning message saying you have to unlock editing of that file. Go ahead and do that but don’t forget to undo the change after.