iOS 核心数据中的 i18n

Question

我正在为 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 编辑器使其工作......

谢谢。

Answer 1

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

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

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

但是，我认为您犯了一个错误，即使用大型复杂系统（带有面向对象包装器的关系数据库）来解决一个非常简单的问题（键值查找）。复杂的解决方案几乎总是比简单的解决方案更慢且更占用内存。

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