ios8 - 使用Xcode 6，iOS 8， Storyboard 和xliff的Sane本地化工作流程？

Question

理想情况下，这就是我想要做的:

使用基本的英语本地化版本在Xcode中设置项目。最终，我想要英语，并说荷兰语版本的Localizable.strings和Storyboard

使用NSLocalizedString形式的键，使用勤奋并在每个键

中添加适当的上下文注释来使用fooViewController.barLabel外部化代码中的字符串

将荷兰语本地化添加到我的 Storyboard 文件

将 Storyboard 中的特定标签标记为占位符，这些占位符将在运行时设置，并且不需要翻译

在 Storyboard 中为需要翻译的标签添加注释

导出“开发语言” xliff文件(单击“项目”，单击“编辑器/导出以进行本地化...，选择”仅开发语言”)

使用Counterparts或Xliffie之类的工具或基于Web的

之类的工具打开英语xliff文件。

在fooViewController.barLabel键旁边添加实际的英语翻译，然后重新保存en.xliff

从原始nl.xliff创建en.xliff文件，并添加荷兰语翻译

将两个xliff文件导入Xcode，并为代码中定义的键和 Storyboard 中的键创建适用于荷兰语和英语的适当.strings文件；将新的.strings文件提交到我的源存储库

中

在我的源代码和 Storyboard 中添加，删除和更改键之后的某个将来，再次导出“开发语言” en.xliff作为事实源

使用当前翻译来更新en.xliff和nl.xliff文件，并突出显示已添加或删除了哪些键的工具

将这些xliff文件导入回到Xcode中，这将更新.strings文件，然后我可以签回到我的源存储库

这有意义吗？这是一件合理的事情吗？我认为是这样，但这是行不通的。

这是我遇到的问题:

Xcode不支持第4步-xliff格式可以将键标记为translate=no，但是无法在Xcode中对其进行注释(理想情况下，Xcode根本不会导出标记为占位符的键。)

Xcode不支持第5步-无法为标签设置翻译者注释。甚至没有一种方法可以独立于您放置在 Storyboard 上的标签中的占位符文本来设置键，如果在布局 View 时发现用Lorem Ipsum填充标签很有用，这将是一个很大的麻烦。

进入步骤10时，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...？!

步骤12和13变得很奇怪，我只是不明白发生了什么。 Counterparts和Xliffie都用英文翻译替换了我原来的fooViewController.barLabel密钥，看起来他们试图告诉我我没有英文翻译。尝试将en.xliff导入回Xcode后，它告诉我除新键外，我没有其他翻译，而当我继续进行操作时，它清除了en.lproj/Localization.strings文件中的现有翻译。

真是一团糟。

无法在Storyboard中翻译标签而无法手动设置其键，添加翻译注释或将特定标签标记为非翻译占位符是行不通的。我们已经采取了将每个标签连接到@IBOutlet并将其翻译设置为viewDidLoad()和NSLocalizedString的方法。

尝试导出包含撇号乞tro信念的.strings文件时，Xcode阻塞。

似乎还存在一个基本的假设，即如果Xcode中的“开发语言”是英语，那么开发人员将负责英语翻译。我可以想象，在单人独立开发者商店之外的任何情况下，都是如此。

最后，似乎我也缺少有关尝试使用的工具如何构建工作流程的信息。如果有人能启发我，我将不胜感激。

是否有人设法构建可行的本地化工作流，而开发人员无需承担对“开发语言”的最终编辑控制权，而 checkin 到存储库中的.strings文件是事实的源头吗？

Answer 1

We've resorted to connecting every label to an @IBOutlet and setting its translation in viewDidLoad() with NSLocalizedString.

您说的没错。说真的围绕您的开发流程进行打包，比起采用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呈现的内容可能与文件实际包含的内容完全不同。

7. ... even something web based

对于我们来说，这就是Crowdin，它很好地显示了Apple的Storyboard本地化想法的所有错误。译者需要三件事来专业地完成工作:上下文，上下文和上下文。苹果公司似乎认为翻译人员会很乐意安装该应用程序，对其进行操作并提出问题以获取相关信息。因为默认情况下是xliff export 中没有人类上下文。现在，借助Xcode7，您可以添加注释，但是很奇怪，并非到处都有。即使在可能的地方，您的注释也将附加在已经很长的带有机器上下文的<note>字符串的末尾- Storyboard 导入匹配很容易理解，但是对于翻译者来说却毫无用处和阻碍。此外，实际上，翻译人员是专业代理机构或语言爱好者。即使您幸运地拥有了配备适当的发烧友，或者为获得额外的客户服务而支付了代理费，您仍然可以输入“Beta发行选择的敌对沙漠”。 Apple有趣的Testflight轮回将需要翻译者注册为Apple开发人员，或者等待Apple的Beta版审查-取决于您需要翻译在应用程序生命中的早期程度。

顺便说一句，我喜欢你的博客。有时我也想摆脱我的酸味和功能失调的疲劳，但是从来没有像你这样:)