2

根据官方文档Internationalization Programming Topics：

如果您的 Mac 应用程序具有针对美国、英国和澳大利亚用户的本地化版本，则捆绑例程将首先搜索相应的区域目录（en_US.lproj、en_GB.lproj 或 en_AU.lproj），然后是 en.lproj 目录。iPhone 上的相同应用程序只会在 en.lproj 目录中查找。

但是我尝试将我的 Localizable.strings 放在 en_US.lproj 目录中，而不是en.lproj 中，我仍然可以使用NSLocalizedString()函数找到英文字符串。

有什么问题？

4

1 回答 1

2

我不确定，但这是我有根据的猜测。

首先要认识到 OS X 和 iOS 共享大量代码。实际上，您可以找到相当多的官方OS X 功能 - 仅在 iOS 上也可以使用。

这是我在手机上观察到的：

如果我只有

- en_US.lproj
    - Localizable.strings

然后，它会从该文件中读取值，这与您找到的文档所说的相矛盾（如您所述）。

但是，如果我有：

- en_US.lproj
    - Localizable.strings
- en.lproj
    - Localizable.strings

然后，它将采用en.lproj的值，有点尊重文档的精神。

现在，当我以图形方式使用 Xcode 时，它​​只会让我为 选择本地化，en-US这与（美国地区）不同。所以，我猜你（和我一样）离开了 Xcode，手动添加了目录，然后将它添加到你的 Xcode 项目中。en_USen_US.lproj

也许 Apple 的想法是，虽然 iOS 仍然可以识别en_US.lproj，但由于他们已将 Xcode 配置为不允许您直接创建本地化，应用程序不会在那里结束？因此，您已经（某种程度）侵入了该功能。

还有一点需要注意：如果您像我一样手动创建 .lproj 文件夹，您必须小心，当您在 Xcode 之外更改它们时，它们实际上已经消失了。此外，您可能必须卸载您的应用程序才能清除您以这种方式添加（和删除）的旧 .lproj 目录。所以，这是另一种看待奇怪行为的方式。

长话短说，就文档本身而言，我不会向 App Store 提交具有这种本地化类型的应用程序。它可能会被拒绝，或者将来会中断（找不到字符串值），因为它在 iOS 上不受官方支持。也就是说，如果这个功能无限期地继续工作，我也不会感到惊讶。

于 2013-04-06T09:27:23.920 回答