问题
According to the official document Internationalization Programming Topics:
if your Mac app had localizations for United States, Great Britain, and Australian users, the bundle routines would search the appropriate region directory (en_US.lproj, en_GB.lproj, or en_AU.lproj) first, followed by the en.lproj directory. The same application on the iPhone would look only in the en.lproj directory.
But I tried to put my Localizable.strings in en_US.lproj directory, not en.lproj, I still can find the string in English by using NSLocalizedString()
function.
What's the problem?
回答1:
I'm not sure, but here's my educated guess.
First thing to recognize is that OS X and iOS share a large amount of code. You can actually find quite a few features that are officially OS X - only, that actually work on iOS, too.
Here's what I observed on my phone:
If I only had
- en_US.lproj
- Localizable.strings
then, it would read the value from that file, contradicting what the documentation you found says (as you noted).
However, if I had:
- en_US.lproj
- Localizable.strings
- en.lproj
- Localizable.strings
then, it would take the value from en.lproj, sort of respecting the spirit of the documentation.
Now, when I use Xcode, graphically, it will only let me choose a localization for en-US
, which is not the same thing as en_US
(US region). So, I'm guessing that you (like me), went outside of Xcode, added the en_US.lproj
directory manually, then later added it to your Xcode project.
Perhaps the thinking of Apple was that although iOS can still recognize en_US.lproj
, since they've configured Xcode to not allow you to directly create that localization, apps won't wind up there? So, you've hacked your way (kind of) into that feature.
One more note: if you did as I did, and manually created .lproj folders, you have to be careful that when you change them around, outside of Xcode, they're really gone when you think they are. Also, you may have to uninstall your app to blow away old .lproj directories that you added (and deleted) in this way. So, that's one more way to see strange behaviour.
Long story short, with the documentation as it is, I wouldn't submit an app with this type of localization to the App Store. It might either be rejected, or break (not find a string value) in the future, since it's not officially supported on iOS. That said, it also wouldn't surprise me if this feature continued to work indefinitely.
来源:https://stackoverflow.com/questions/15848566/does-ios-look-for-region-specific-lproj-directory-e-g-en-us-lproj