Closed loufranco closed 9 years ago
Hi @loufranco, Strings files should go in en.lproj when using Base Internalization too.
You could see this mentioned in Managing Strings Files Yourself:
Don’t add Localizable.strings to the Base localization
Fair enough. The NSLocalized... macros do find them in Base.lproj (as does Xcode's XLIFF generation). Also, Xcode puts InfoPlist.strings files there itself when you choose Base Internationalization for the plist file. I understand if you want to support it as documented.
I also ran into this and it's very surprising even if it is what the documentation says. It might be worth adding a log or assert in this case, if you really don't want to change the behavior. But since NSLocalized... does look in the base project, I'd encourage you to add that behavior.
@aleffert -- I ended up moving .strings to en.lproj because all of the Xcode XLIFF support doesn't work right with the strings in Base. Just a heads up if you use those features.
I am using Base i18n as described here:
https://developer.apple.com/library/ios/documentation/MacOSX/Conceptual/BPInternational/InternationalizingYourUserInterface/InternationalizingYourUserInterface.html
When I look up a string for my Base locale ("en"), it doesn't try looking it up in Base.lproj/table.strings. If I pass "Base" as a locale to
pluralizedStringWithKey:defaultValue:table:pluralValue:forLocalization:
then it doesn't know the plural rules to apply.I think I would also want Base to be in the fallback list for other locales but I haven't gotten that far yet.
I can work around now by using
pluralformf
and looking it up myself. Since this is only a problem for my Base language, I don't mind losing your fallback mechanism.