使用Xcode6,iOS8,Storyboards和xliff的Sane本地化工作流程？

理想情况下,这是我想做的事情:

使用英语基础本地化在Xcode中设置项目.最终我想要英语,让我们说我Localizable.strings和故事板的荷兰语版本

在代码中外部化字符串NSLocalizedString,使用表单的键fooViewController.barLabel,勤奋并为每个键添加适当的上下文注释

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

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

添加注释在故事板哪些标签做需要翻译

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

使用Counterparts或Xliffiexliff等工具打开英文文件,甚至可以使用基于Web的工具

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

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

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

在我的源和故事板中添加,删除和更改密钥之后的某个未来点,en.xliff再次导出"开发语言" 作为事实的来源

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

将这些xliff文件导回Xcode,.strings然后更新文件,然后我可以将其检入我的源存储库

这有意义吗？想要这样做是否合理？我想是这样,但它不起作用.

以下是我遇到的问题:

Xcode不支持第4步 - xliff格式可以将键标记为translate=no,但是没有办法在Xcode中注释(理想情况下,Xcode根本不会导出标记为占位符的键.)

Xcode不支持第5步 - 无法为标签设置翻译注释.甚至没有办法设置密钥独立于您放置在Storyboard标签上的占位符文本,如果您在布局视图时发现Lorem Ipsum的填充标签很有用,那将是一个巨大的痛苦.

当你进入第10步时,Xcode会抱怨en.xliff文件中没有指定目标语言.有一种方法可以EN在Counterparts中更改目标语言(或者至少创建一个目标语言设置为的新文件)但是我找不到任何方法来使用Xliffie.

在尝试en.xliff使用更新的密钥重新导出文件时,Xcode告诉我"Localization failed reading "[...]/Supporting Files/en.lproj/Localizable.strings, Please address the issue at file location 782"我找到了哪个字符位置...撇号.xliff如果源.strings文件包含撇号,Xcode无法导出文件.什么在实际F ...？!

第12步和第13步变得奇怪,我只是不明白发生了什么.对口部门和Xliffie都用fooViewController.barLabel英文翻译替换了原来的钥匙,看起来他们试图告诉我我没有英文翻译.在尝试将en.xliff背面导入Xcode时,它告诉我除了新密钥之外我没有翻译,当我继续时,它擦除了en.lproj/Localization.strings文件中的现有翻译.

这是一团糟.

在Storyboards中翻译标签而无法手动设置密钥,添加翻译者评论或标记特定标签,因为占位符非翻译不起作用.我们已经使出浑身标签连接到@IBOutlet并设置其翻译viewDidLoad()用NSLocalizedString.

Xcode在尝试导出.strings包含撇号乞丐信仰的文件时会出现窒息.

似乎还有一个潜在的假设,即如果Xcode中的"开发语言"是英语,那么开发人员负责英语翻译.我可以想象在单人独立开发商店之外的情况不是这样的.

最后,我似乎也错过了一些关于我试图使用的工具如何构建其工作流程的内容.如果有人能够启发我,我会非常感激.

有没有人设法构建一个可行的本地化工作流程,开发人员不负责对"开发语言"的最终编辑控制,并且.strings检查到存储库的文件是真相的来源？

我们已经将每个标签连接到@IBOutlet并使用NSLocalizedString在viewDidLoad()中设置其转换.

你这样做是对的.认真.围绕它展开你的开发过程,你会比试图采用Storyboard本地化演变成的混乱更好.

它解决了第4节 - 你决定放入什么 Localizable.strings

它解决了pt.5 - 默认情况下会有注释,因为您决定可以进行本地化.说实话,XCode7增加了向资源添加注释的可能性.不要使用它.出于某些原因,只有Apple知道,它不适用于所有类型的资源.您无法注释例如表格页眉和页脚.稍后会详细介绍.

我建议制作你自己的NSBundle.localizedStringForKey包装器(宏)提供value.NSLocalizedString设置value为空字符串,基本上强制key用作后备翻译内容.所有已经存在可疑的宏,NSLocalizedStringWithDefaultValue采用的value也是所有其他4点需要的参数-不是你想经常使用.

第10步是由您尝试导入Base本地化引起的 - 事实上它的英语没有任何区别.如果您想"翻译英语"(即专业修正),您必须将英语作为另一个独立本地化添加到Base之上.从技术上讲,它归结为基础xliff缺失和属性.由于一些奇怪的xliff混乱与你的相似,我不得不手动添加一次.你不想那样做:)

撇号故障:iOS本地化是一个奇迹般的虚幻花园,但我确信这不是不真实的:)尝试在一些十六进制显示编辑器中打开文件 - XCode呈现的内容可能与文件真正包含的内容完全不同.

......甚至基于网络的东西

这对我们来说是克罗丁,很好地说明了苹果公司故事板本地化的想法.翻译人员需要3件事来专业地开展工作:背景,背景和背景.Apple似乎认为翻译人员很乐意安装应用程序,玩它并提出问题以获取上下文.因为,默认情况下,xliff导出中没有人工上下文.现在使用Xcode7,您可以添加注释,但奇怪的是并非随处可见.即使你可以,你的笔记也会在已经很久的时候附上带有机器上下文的字符串 - 可以理解为故事板导入匹配所需,但对翻译者来说是无用的和阻碍的.此外,实际上,翻译是专业机构或语言爱好者.即使你有适当装备的爱好者的运气,或者你为获得额外的客户服务支付了代理费,你也可以进入The Hostile Desert Of Beta分销选项.苹果公司有趣的Testflight轮回将需要翻译人员注册为Apple开发人员,或等待Apple的beta审查 - 取决于您需要翻译的应用程序生命的早期.

顺便说一下,我喜欢你的博客.有时我觉得自己也会倾倒我的酸涩和疲惫的疲惫,但从来没有像你一样:)