我正在建立一个新的iOS项目，想知道我是否应该使用Localizable.strings文件来保留我的字符串，即使没有计划增加对其他语言的支持。
我曾经尝试过使用struct保留字符串，但是我想知道这是否是一个好习惯。使用Localizable.strings在库R.swift上也可以很好地工作，这也是我努力选择策略的另一个原因。
答案 0 :(得分：1)
在这种情况下，没有“最佳实践”。有一些做法，有些可能比其他情况更适合您的情况。
您的意思是您不打算增加对其他语言的支持，但是如果您改变主意，似乎希望为此做好准备。所以首先要问自己，您正在寻找解决方案的实际问题是什么。我想说的问题是，一旦应用程序退出，您将获得开销，您需要查找在应用程序中使用过的所有字符串并将它们包装到NSLocalizedString中。通常这包括无休止的测试，最后您仍然很可能会忘记本地化至少一些字符串。
您可以从一开始就将内容包装到NSLocalizedString中，这最终将帮助您使用本机工具从代码中提取所有字符串。那时的问题仍然是情节提要。不是从情节提要中提取字符串，而是删除您没有计划翻译的默认文本（例如，“名称”实际上是一些名称，不应翻译）。因此，以我的经验，这是一个半解。
要解决情节提要的问题，应该有一个工具（我不记得是哪个，也许还有其他一些CocoaPod），它使您可以忽略不应翻译的视图。因此，在这种情况下，您需要使用2种东西： NSLocalizedString并忽略IB中不可翻译的项目。
您已经说的不错，您可以使用R.Swift直接从strings文件中获取字符串。这非常整洁，但随着您的发展而分心。这样做是在迫使开发人员在使用前先在strings文件中输入文本。我个人讨厌。同样，这可能是多个开发人员发生冲突的问题。更不用说这还不能解决您的情节提要问题。
创建一个单独的结构系统来容纳所有字符串的确很不错。您不必遍历代码中的所有字符串，也不必跳至strings文件（开发时转到另一个源会更加令人愉快，因为您可以很轻松地导航到它） 。假设您像label.text = Strings.Settings.User.firstNamePlaceholder那样维护结构，也可以保持良好的结构，这可以帮助您轻松查找需要或不建议使用的字符串。您可以轻松删除整个屏幕。但这仍然是开发人员的开销，而且您仍然遇到一个问题，现在您需要从情节提要中拖动所有出口以将本地化字符串设置为它们。
执行此过程，您最终可以选择直接使用NSLocalizedString或使用R.Swift。实际上，您什么也没用，并且切换到这两者中的任何一个都不会有太多的超时（同样，假设在代码中查找这些字符串会花费大部分时间）。
就我个人而言，我什么都不会做，或者会创建一个自定义结构系统，然后不使用任何东西，只返回原始字符串。但这实际上取决于您的项目的大小，项目的类型，情节提要中有多少东西……还取决于您何时期望拥有更多的资源，因此您现在花更多的时间而不会打扰稍后，或者您只需简单地做，现在就可以在确实需要本地化的情况下为大量工作做准备（希望发生这种情况是“最甜”的问题之一，因为这意味着您有大量的用户）。