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

概述我知道许多开发人员就是这样做的：他们开始用英语开发他们的应用程序,然后把NSLoclaizedString(@“点击这样做！”,@“告诉做什么……”)而不是简单的@“点击这个要做到这一点！”. 然后他们运行genstrings,通过提取所有这些字符串以某种方式创建Localizable.strings文件.凌乱的部分：代码中使用的长文本成为关键.有用.直到有一天你快速进入你的代码并更改英文字符串并 我知道许多开发人员就是这样做的：他们开始用英语开发他们的应用程序,然后把NSLoclaizedString(@“点击这样做！”,@“告诉做什么……”)而不是简单的@“点击这个要做到这一点！”.

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

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

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

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

Quesion：假设始终有一个Localizable.strings(英文)文件,文件中的键ARE以及格式正确的值.是否存在NSLocalizedString失败然后直接显示密钥的情况？

解决方法 回答你的问题：是的,我遇到了你担心的问题,即即使存在localizable.strings文件并且包含这些键名的条目,键名也会出现.当您的项目中有多个localizable.strings文件时,会发生这种情况.如果从具有自己的localizable.strings(例如ShareKit)的开源项目中删除一组文件到项目中,则很容易发生这种情况.

Here is a related question讨论了这个问题.

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

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

总结

以上是内存溢出为你收集整理的iphone – 在NSLocalizedString()中使用“真实”键是否安全？有保证的后备语言吗？全部内容，希望文章能够帮你解决iphone – 在NSLocalizedString()中使用“真实”键是否安全？有保证的后备语言吗？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。