I think this is either a genstrings bug or "feature", but wanted to see if anyone has come across this or knows the answer. I was planning on opening a Radar for this.
We use our own localization macro. Let's call it CustomLocalizedString. In our code base, it's quite large and we use a lot of 3rd Party libs. For the vast majority of 3rd Party libs, we don't want any of their localized strings if they happen to have them. When we do want to use their localized strings, we modify the 3rd Party lib to use our CustomLocalizedString macro. Since the strings we don't care about are using the NSLocalizedString* macros, the thought was this would be a non-issue.
Localization basically started flagging a few strings with problems. After a little research, I realized it was coming from a 3rd Party lib. I then further realized that we were also including other strings that shouldn't be there (we have a large number of strings). These were strings using the NSLocalizedString* marco.
So our invocation of genstrings is something like:
genstrings -o output -s CustomLocalizedString
I actually use xargs and find to create the file arguments, so for brevity, I'm omitting that part. Based on the output, it looks like genstrings puts both NSLocalizedString and CustomLocalizedString strings into the Localizable.strings file.
To further verify I created a file with this:
NSLocalizedString(@"Normal localized string macro", nil);
CustomLocalizedString(@"Custom localized string macro", nil);
And ran:
genstrings -o out -s CustomLocalizedString localized_string.txt
The output was:
/* No comment provided by engineer. */
"Custom localized string macro" = "Custom localized string macro";
/* No comment provided by engineer. */
"Normal localized string macro" = "Normal localized string macro";
Running man genstrings yields this:
-s routine
Substitutes routine for NSLocalizedString. For example, -s MyLocalString will catch calls to MyLocalString and MyLocalStringFromTable.
Which makes it sound like NSLocalizedString* macros would get ignored, but this is not the case.
Note I have already re-written the find to be able to only include the 3rd Party libs we want to be localized. Our 3rd Party libs are essentially all in one directory. Since there are a lot of devs on the team, I'd rather try and find if I'm missing a flag or something else which would allow me to include the 3rd Party lib directory and have it properly use only the CustomLocalizedString macro. Else I can foresee someone not realizing how we are running genstrings and we suddenly find out too late that strings we needed localized were not because they were not added into our genstrings find list.