理想情况下，这就是我想要做的:
Localizable.strings和Storyboard NSLocalizedString形式的键，使用勤奋并在每个键fooViewController.barLabel外部化代码中的字符串xliff文件(单击“项目”，单击“编辑器/导出以进行本地化...，选择”仅开发语言”)xliff文件。fooViewController.barLabel键旁边添加实际的英语翻译，然后重新保存en.xliff nl.xliff创建en.xliff文件，并添加荷兰语翻译xliff文件导入Xcode，并为代码中定义的键和 Storyboard 中的键创建适用于荷兰语和英语的适当.strings文件；将新的.strings文件提交到我的源存储库en.xliff作为事实源en.xliff和nl.xliff文件，并突出显示已添加或删除了哪些键的工具xliff文件导入回到Xcode中，这将更新.strings文件，然后我可以签回到我的源存储库这有意义吗？这是一件合理的事情吗？我认为是这样，但这是行不通的。
这是我遇到的问题:
xliff格式可以将键标记为translate=no，但是无法在Xcode中对其进行注释(理想情况下，Xcode根本不会导出标记为占位符的键。)en.xliff文件中没有指定目标语言。有一种方法可以在Counterparts中更改目标语言(或至少将目标语言设置为EN创建一个新文件)，但是我找不到使用Xliffie的任何方法。 en.xliff文件时，Xcode告诉我"Localization failed reading "[...]/Supporting Files/en.lproj/Localizable.strings, Please address the issue at file location 782"我在哪个字符位置找到了...撇号。如果源xliff文件包含撇号，则Xcode无法导出.strings文件。 What in the actual F...？! fooViewController.barLabel密钥，看起来他们试图告诉我我没有英文翻译。尝试将en.xliff导入回Xcode后，它告诉我除新键外，我没有其他翻译，而当我继续进行操作时，它清除了en.lproj/Localization.strings文件中的现有翻译。 真是一团糟。
无法在Storyboard中翻译标签而无法手动设置其键，添加翻译注释或将特定标签标记为非翻译占位符是行不通的。我们已经采取了将每个标签连接到
@IBOutlet并将其翻译设置为viewDidLoad()和NSLocalizedString的方法。尝试导出包含撇号乞tro信念的
.strings文件时，Xcode阻塞。似乎还存在一个基本的假设，即如果Xcode中的“开发语言”是英语，那么开发人员将负责英语翻译。我可以想象，在单人独立开发者商店之外的任何情况下，都是如此。
最后，似乎我也缺少有关尝试使用的工具如何构建工作流程的信息。如果有人能启发我，我将不胜感激。
是否有人设法构建可行的本地化工作流，而开发人员无需承担对“开发语言”的最终编辑控制权，而 checkin 到存储库中的
.strings文件是事实的源头吗？ 最佳答案
您说的没错。说真的围绕您的开发流程进行打包，比起采用Storyboard本地化演变成的困惑局面，您将获得更好的 yield 。
它解决了第4点-您决定要在Localizable.strings中输入什么
它解决了第5点-默认情况下，您决定可本地化的所有内容都在其中。现在说实话，XCode7为add notes to resources添加了一种可能性。不要使用它。由于某些原因，只有Apple知道，因此并非适用于所有类型的资源。您无法注释例如表页眉和页脚。以后再说。
我建议您自己制作NSBundle.localizedStringForKey包装器(宏)，该包装器提供value。 NSLocalizedString将value设置为空字符串，本质上强制key用作后备翻译内容。在所有已经存在的可疑宏中，NSLocalizedStringWithDefaultValue接受value，还接受所有其他4个必需的参数-您不希望经常使用这些参数。
步骤10是由您尝试导入Base本地化引起的-它的英语事实没有任何区别。如果您想“翻译英语”(即专业纠正)，则必须在Base之上添加英语作为另一个独立的本地化语言。从技术上讲，它可以归结为缺少<file target-language>和<target xml:lang>属性的Base xliff。由于某些类似于您的xliff困惑，我不得不手动添加一次。你不想这样做:)
关于撇号故障:iOS本地化是一个虚幻的奇迹花园，但是我很确定这不是虚幻的:)尝试在一些显示十六进制代码的编辑器中打开文件-XCode呈现的内容可能与文件实际包含的内容完全不同。
对于我们来说，这就是Crowdin，它很好地显示了Apple的Storyboard本地化想法的所有错误。译者需要三件事来专业地完成工作:上下文，上下文和上下文。苹果公司似乎认为翻译人员会很乐意安装该应用程序，对其进行操作并提出问题以获取相关信息。因为默认情况下是xliff export 中没有人类上下文。现在，借助Xcode7，您可以添加注释，但是很奇怪，并非到处都有。即使在可能的地方，您的注释也将附加在已经很长的带有机器上下文的<note>字符串的末尾- Storyboard 导入匹配很容易理解，但是对于翻译者来说却毫无用处和阻碍。此外，实际上，翻译人员是专业代理机构或语言爱好者。即使您幸运地拥有了配备适当的发烧友，或者为获得额外的客户服务而支付了代理费，您仍然可以输入“Beta发行选择的敌对沙漠”。 Apple有趣的Testflight轮回将需要翻译者注册为Apple开发人员，或者等待Apple的Beta版审查-取决于您需要翻译在应用程序生命中的早期程度。
顺便说一句，我喜欢你的博客。有时我也想摆脱我的酸味和功能失调的疲劳，但是从来没有像你这样:)