sed complains when I feed it the files from Pd*.app/Contents/Resources/*.lproj/InfoPlist.strings because it finds what it calls "illegal byte sequences" in those translation files. I can prepend a LANG=C to my sed command, but then OSX's sed flat out refuses to match the relevant string ("nwjs" in this case). I'm guessing the unknown byte sequences are somehow throwing off the matching engine, but that's only a guess.
I'm giving up on fixing this myself. I've already spend at least twenty minutes fiddling with getting a for file in $(PD_APP_CONTENTS) solution that broke because of a different, subtle discrepancy in Pd-extended/L2ork's handling of the app bundle name. Now I've spent another twenty minutes "exploring" the differences between Gnu sed and OSX's sed, only to find that the common case of substituting "a" for "b" on OSX when LANG=C doesn't actually work in this case of working with translations. Too bad.
If someone else wants to fix this and send me a patch, feel free. FYI-- you must change the value of bothCFBundleDisplayName and "CFBundleName" to "Purr Data" to get the app name in the menu to display correctly.
Finally figured this out-- vi was automatically converting the binary file to some readable format (why I have no idea). So it's a matter of converting the file to some reasonably readable format like json, running sed, and then converting back...