NSString's localizedStringWithFormat: does not show compiler error when number of arguments incorrect

The issue here is not

+localizedStringWithFormat:

but rather with your use of

NSLocalizedString

for the format string. For example, the following also doesn’t give a warning:

[NSString stringWithFormat:NSLocalizedString(@"%@ %@", @"two strings"), @"name"];

The problem is that

NSLocalizedString

is a macro that expands to a method call,

-[NSBundle localizedStringForKey:value:table:]

, and the compiler can’t tell that this method will return a string with the same number of directives as the input string (in fact, if your localisers mess up it’s actually possible for it to return a string with a different number of directives).

I agree it would be nice if the compiler could give a warning in this case; you should file a bug requesting that. Please post your bug number, just for the record.

One way to flush out problems like this is to add the following to your code:

#undef NSLocalizedString
#define NSLocalizedString(key, comment) (key)

This makes

NSLocalizedString

a simple pass through, allowing the compiler to see a constant format string and thus issue warnings.

You could, for example, have a build configuration that sets this up, allowing you to quickly find all these problems in your code base.

Share and Enjoy
—
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thank you for your reply.

While the #define you mentioned will help in making the compiler helpful, I think it cannot be a production releasable code for an app that supports localization.

And not doing this would mean that any bugs around the format will be found only when the app is run and has an exception at that format.

I guess, the solution would be to raise the bug. But the fix will be to have in Xcode the ability to be able to compile with the various localizations once we receive and upload the Xliff files?

Raised bug number : 23622446

Open Radar : rdar://23622446

Raised bug number : 23622446

Thanks.

While the #define you mentioned will help in making the compiler helpful, I think it cannot be a production releasable code for an app that supports localization.

Agreed. I wasn’t proposing that you use this in your final app. Rather, my suggestion was that you occasionally do this in order to flush out any lingering string format bugs. For example, you could set up a build configuration that enables this

#define

hack and then, on occasion, perhaps as part of the process for releasing a build to beta testers, build with that configuration and fix any problems it flags.

Share and Enjoy
—
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"