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）的开源项目中删除到项目中，则很容易发生这种情况。

讨论此问题的

Here is a related question。

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

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

Answer 2

我们倾向于使用“真实”密钥，但它们通常是英文文本（或缩写形式），并在末尾添加“密钥”。这很清楚。

Answer 3

我写了一些自定义代码，它实际上验证了应用中的所有密钥都出现在所有localizable.string个文件中。此过程有两个步骤 - 使用genstrings生成一个新的可本地化的字符串文件，其中包含当前在源中引用的所有键。然后我使用了一些Objective-C api来加载我现有的localizable.strings文件，并比较它们都拥有与新生成的密钥完全相同的密钥组（不多也不少）。

Answer 4

我认为更好的方法（尤其是对于我们的程序员）可以是：

1）在代码中放入技术字符串

2）使用专用便利功能进行翻译

通过这种方式：

a）为我们提供更多详细信息

b）我们只修改“ Localizable.strings”中的本地化字符串

c）我们可以从外部发送一个简单的“ Localizable.strings”，而不会疯狂地在代码上搜索字符串并替换，一旦获得翻译。

d）添加语言只需单击两次，然后粘贴文本即可。

e）我们可以使错误对最终用户更通用/更温和：

样本：

“ NETWORK_ERROR” =“网络错误”;

“ NETWORK_ERROR_NO_DATA” =“没有数据。请检查设置”;

“ NETWORK_ERROR_NO_JSON” =“没有数据。请检查设置”;

最终用户无法理解404或JSON解析错误，就像google一样。

“很可能...发生网络错误”。（编码员会在代码中看到真正的原因）

最后...尽早开始本地化。

便利f。：

func localized(_ msg: String)->String{
    let s = NSLocalizedString(msg, comment : "")
    return s
}

在NSLocalizedString（）中使用“真实”键是否安全？有保证的后备语言吗？

4 个答案: