应用程序的根语言是否需要 Localized.strings？
当我们启用我们的（英语）应用程序本地化时，我们用 NSLocalizedString() 调用替换了所有内联字符串。由于我们所有的英文字符串都与代码一致，例如 NSLocalizedString(@"OK, @"OK button in a message box")，我们是否需要英文版本的 Localized.strings？当我们尝试从 English Localized.strings 中删除字符串，该程序似乎工作正常，只是想仔细检查一下是否存在一些副作用，谢谢，alex。
As we're enabling our (English) application to be localized, we're replaced all in-line strings with NSLocalizedString() calls. Since all of our English strings are all there in-line with the code, e.g. NSLocalizedString(@"OK, @"OK button in a message box"), is there any reason we need the English version of Localizable.strings? When we try removing the strings from the English Localizable.strings, the program seems to work fine. Just wanted to double check if there was some side-effect to not having that around. Thanks, alex
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
使用 NSLocalizedString() 宏的要点之一是可以使用 genstrings 命令行工具解析您的编程代码，生成相应的 Localized .strings 文件（参见 资源编程指南：关于字符串加载宏和使用 Genstrings 工具创建字符串文件）。
然后，该
Localized.strings文件将作为翻译人员的起点，用于翻译成另一种语言。如果没有该文件，您的翻译人员基本上需要访问您的源代码才能查看您想要使用的所有字符串（这违背了目的）。是的，您的英文版本现在工作正常，因为如果您尝试在代码中获取字符串的本地化版本 –– 例如，
NSLocalizedString(@"OK", @"")–– 则不能可以在.strings文件中找到，它只是使用您传入的@"OK"字符串。您应该保留英语
Localized 的另一个原因.strings是你通常应该尽量避免的在代码中使用高位 ASCII 字符，但应在实际用户界面中使用全部可用字符。例如，您可能不想将以下字符放入代码中，但希望在用户界面中使用它们：…（水平省略号）(U+2026)
“（左双引号）(U+201C)
”（右双引号）(U+201D)
'（左单引号）(U+2018)
' （右单引号）(U+2019)
因此，在代码中，您可以执行以下操作：
然后在您的
.strings文件中（这是 UTF16，所以这很好）：One of the main points of using the
NSLocalizedString()macro is so that your programming code can be parsed with thegenstringscommand-line tool to generate the correspondingLocalizable.stringsfile(s) (see Resource Programming Guide: About the String-Loading Macros and Using the Genstrings Tool to Create Strings Files).That
Localizable.stringsfile then serves as a starting point for your translators, to use to translate to another language. Without that file to work with, your translators would basically need access to your source code in order to see all the strings you want to use (which kind of defeats the purpose).Yes, your English version works fine right now, since if a localized version of the string you try to get in code –– for example,
NSLocalizedString(@"OK", @"")–– cannot be found in a.stringsfile, it simply uses the@"OK"string that you passed in.Another reason why you should likely be keeping the English
Localizable.stringsis that you should generally try to avoid using high-ASCII characters in your code, but should use the full range of available characters in your actual user interface. For example, you may not want to put the following characters in your code, but would want to use them in your user interface:… (horizontal ellipsis) (U+2026)
“ (left double quotation mark) (U+201C)
” (right double quotation mark) (U+201D)
‘ (left single quotation mark) (U+2018)
’ (right single quotation mark) (U+2019)
So in code, you'd do something like this:
and then in your
.stringsfile (which is UTF16, so this is fine):不建议使用单词作为键，如果您想将
Ok更改为其他内容并且您有任何其他Localized.strings，则必须编辑每个单词其中更新Ok键。It's not recommended to use the words as keys, if you want to change that
Okfor something else and you have any otherLocalizable.strings, you will have to edit every single of them to update theOkkey.当然，您的翻译人员会希望使用您的 Localized.strings 文件。并希望它是所有字符串。
（确实，系统会回退到键，但依赖于此似乎是不好的做法。而且您会发现在 Unicode 文件中使用正确的标点符号更可靠，而源代码很少这样做。）
Surely your translators will want your Localizable.strings file to work from. And want it to be ALL the strings.
(It is true that the system will fall back to the key, but relying on that seems like bad practice. And you'll find it more reliable to use proper punctuation in a Unicode file, which source code seldom is.)