在NSLocalizedString()中使用"真实"键是否安全？有保证的后备语言吗？

Question

我知道很多开发人员就是这样做的:他们开始用英语开发他们的应用程序,而NSLoclaizedString(@"Tap this to do that!", @"Telling what to do...")不是简单地开发@"Tap this to do that!".

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

所以我倾向于使用"真正的"键,这些键不会与字符串混淆.为了快速测试,我创建了一个本地化为英语和法语的项目.然后我将模拟器语言设置为德语.因为,你知道,如果用户看到钥匙就会非常糟糕TTTDT.

因此,只需使用英语和德语,我就启动了演示应用程序.我得到的是英文Localizable.strings文件中的英文文本.

结论:如果应用程序没有涵盖操作系统语言,NSLocalizedString似乎会回退到英文文件.

Quesion:假设总是有一个Localizable.strings (English)文件,并且文件中的键ID和正确格式化的值.是否存在NSLocalizedString失败然后直接显示密钥的情况？

Answer 1

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

这是讨论这个问题的相关问题。

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

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