应用程序扩展是不是应该有自己的 Localizable.strings?

Posted

技术标签:

【中文标题】应用程序扩展是不是应该有自己的 Localizable.strings?【英文标题】:Should app extensions have their own Localizable.strings?应用程序扩展是否应该有自己的 Localizable.strings? 【发布时间】:2015-04-11 12:18:44 【问题描述】:

目前使用 Xcode 6.3

在我们的(开源)application 中,我们有两个目标:

我们的主应用程序“客户端” 动作扩展“ShareTo”

两个目标都通过NSLocalizedString() 本地化字符串。

当我“为本地化导出”时,我在导出的名为 Client/Localizable.strings 的 XLIFF 文件中看到一个 <file> 扩展名,其中包含主应用程序和应用程序扩展名的字符串。

通过xcodebuild 从命令行导出时结果相同。

我非常确定这种导出行为会随着时间而改变:以前来自应用程序扩展的字符串最终会出现在 XLIFF 文件中的单独 Extensions/ShareTo/Localizable.strings 条目中。未在Client/Localizable.strings 中合并。

所以现在我想知道,这是新的正确行为吗?这是否意味着应用扩展会在其父包中查找字符串?

【问题讨论】:

【参考方案1】:

真的没关系。如果 Xcode 喜欢一个,那么您可以将两个文件连接在一起。 在较大的项目中,我们将使用多个 .strings 文件,而不是一个 Localizable.strings,每个类一个或一个使用 NSLocalizedStringFromTable(); 为特定类分配的每个类 只要确保字符串文件被复制到两个包中(检查文件检查器,右侧边栏第一个选项卡)。

【讨论】:

感谢您的回答。将单个 Client/Localizable.strings 添加到两个目标是一种解决方法,但不是真正的解决方案 IMO。 @StefanArentz 如果您不喜欢它,您可以随时将其拆分并使用NSLocalizedStringFromTable();。这不是一种解决方法,很多情况下,字符串在目标之间共享,因为许多字符串是相同的。

以上是关于应用程序扩展是不是应该有自己的 Localizable.strings?的主要内容,如果未能解决你的问题,请参考以下文章

可扩展,低开销,高性能的Java持久性框架

程序员应该有属于自己的看电视方式

使用 openssl 从自签名证书生成的证书签名请求是不是应该显示扩展属性?

TCP窗口扩展因子设置错误导致数据传输慢问题排查始末

每个微服务是不是应该管理自己的用户权限和用户角色?

verilog: 看代码时遇一问题:把两个12位的数扩展成13位相加,为啥在前面补最高位,不应该补0吗?