ios - iOS 核心数据中的 i18n

标签 ios core-data internationalization fetched-property

我正在为 iOS 开发本地化架构。我有不同的实体可以有翻译字段,所以我为每个实体创建了一个Translation实体。这两个实体之间始终存在一对多关系,允许我在未来添加新语言,并且我可以通过 Entity.translations 访问翻译。到目前为止一切顺利。

Entity
EntityTranslation

1) 首先,我想知道这样的方法听起来是否不错。是我将在纯 SQL 环境中使用的解决方案,因此我想我可以遵循该路径。

2) 然后...我只想使用 Entity.text 为用户显示适当的文本(通过 NSLocale preferredLanguages)。当 translations 返回一个 NSSet 时,一种选择是手动将属性添加到实体模型,并更改 getter:

// Entity.h
@property (nonatomic, retain) NSString * text;

// Entity.m
@synthesize text;

- (NSString *) text
{
  NSString *locale = [[NSLocale preferredLanguages] objectAtIndex:0];

  NSSet *filteredTranslations = [self.translations filteredSetUsingPredicate: [NSPredicate predicateWithFormat:@"locale = %@", locale]];
  EntityTranslation *translation = [[filteredTranslations allObjects] objectAtIndex:0];

  return translation.text;
}

它有效,但它有意义吗?我会遇到性能问题吗?是否可以使用 Fetched properties 做类似的事情?有些东西告诉我这应该是可能的,但我无法使用 Xcode Core Data 编辑器让它工作...

谢谢。

最佳答案

您是否会遇到性能问题取决于您的数据库有多大以及您获取值的频率。您应该通过 Instruments 运行您的代码,以检查它占用了多少 CPU 时间,并根据需要缓存内容。

我要做的一个调整是将 NSPredicate 对象存储在静态变量中,因为它不会经常更改。

如果表中的记录不多,最好一次获取整个记录集,然后将其保存到 NDDictionary,您可以随时查找。

但是,我认为您犯了使用大型复杂系统(具有面向对象包装器的关系数据库)来解决非常简单的问题(键值查找)的错误。复杂的解决方案几乎总是比简单的解决方案更慢并且更需要内存。

推荐的本地化方法是使用 .strings 文件,我想不出使用核心数据有什么好处。您有 200MB 的本地化文本吗?如果没有,那么我认为最好使用 .strings 文件而不是核心数据。

关于ios - iOS 核心数据中的 i18n,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/8295677/

相关文章:

objective-c - 如何向 uinavigationcontroller 添加右键

xcode - 编辑核心数据对象时发生 fatal error

database - 标记内容系统 - 使用 i18n

internationalization - google 的 CSE API 的 lr 参数不只以定义的语言返回页面

ios - 具有固定高度/宽度的自定大小的 UICollectionViewCell

ios - 如何在 swift (SpriteKit) 中绘制作为单个节点的圆点

ios - 跟踪通过我的应用程序发送和接收的数据的使用情况

ios - 与网络服务器同步核心数据

ios - NSManagedObjectContext - 如何在 parent 改变时更新 child ?

ios - 如何使用 Xcode 5 本地化我的应用程序?