iphone - 在 NSLocalizedString() 中使用 "real"键是否安全？是否有保证的后备语言？

Question

我知道很多开发者都是这样做的:他们开始用英语开发他们的应用程序，然后输入 NSLoclaizedString(@"Tap this to do that!", @"Telling what to do...") 而不是简单地 @"Tap this to do that!"。

然后他们运行 genstrings，它通过提取所有这些字符串以某种方式创建一个 Localizable.strings 文件。凌乱的部分:代码中使用的长文本成为关键。有用。直到有一天你快速进入你的代码并更改英文字符串并忘记本地化并且它作为所有那些 Localizable.strings 文件的键。

所以我倾向于使用不会与字符串混淆的“真实”键。为了进行快速测试，我创建了一个本地化为英语和法语的项目。然后我将模拟器语言设置为德语。因为，您知道，如果用户看到像 TTTDT 这样的 key ，那就太糟糕了。

因此，在只有英语和德语的情况下，我启动了演示应用程序。我得到的是来自 English Localizable.strings 文件的英文文本。

结论:如果应用未涵盖操作系统语言，NSLocalizedString 似乎会回退到英文文件。

问题:假设总是有一个Localizable.strings(英语) 文件，并且键和正确格式化的值都在文件中。是否存在NSLocalizedString 会失败然后直接显示 key 的情况？

Answer 1

回答您的问题:是的，我遇到过您担心的问题，即即使存在 localizable.strings 文件并包含这些键名的条目，键名也会出现。当您的项目中有多个 localizable.strings 文件时，就会发生这种情况。如果您将具有自己的 localizable.strings(例如 ShareKit)的开源项目的一组文件拖放到您的项目中，这很容易发生。

Here is a related question讨论这个问题。

但至少如果您使用 ID 样式的键名，您在测试任何语言的应用程序时都会注意到这样的问题。如果您使用英语(或基本语言)字符串作为键，那么在您测试本地化版本之前您不会发现这个隐患，并且它可能更容易被忽视。

因此，除了您必须记住在重写文本时更新键(所有语言)之外，还有一个问题是在使用英文文本作为键时可能会隐藏错误(英文看起来不错，但本地化版本不会)。因此，在我看来，使用“真实”键名而不是实际文本更为实用。如果您仍然担心由于某种原因可能会显示 key 名称，请选择一个至少具有足够描述性以易于理解的 key 。