6

我知道许多开发人员就是这样做的：他们开始用英语开发他们的应用程序，然后NSLoclaizedString(@"Tap this to do that!", @"Telling what to do...")把@"Tap this to do that!".

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

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

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

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

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

4

4 回答 4

4

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

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

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

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

于 2011-11-26T20:06:49.907 回答
1

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

于 2011-11-26T20:02:39.870 回答
0

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

于 2011-11-27T03:08:42.023 回答
0

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

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

2）具有专用便利功能的翻译

这样：

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

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

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

d) 添加语言只需单击 2 次，然后粘贴文本。

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

样本：

"NETWORK_ERROR" = "网络错误";

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

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

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

“哎呀……发生网络错误”。（Coder会在代码中看到真正的原因）

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

方便 f.:

func localized(_ msg: String)->String{
    let s = NSLocalizedString(msg, comment : "")
    return s
}
于 2019-03-17T09:00:26.527 回答