i18n в iOS Core Data - PullRequest
Новая
       20

i18n в iOS Core Data

1 голос
/ 28 ноября 2011

Я работаю над локализованной схемой для iOS.У меня есть разные сущности, которые могут иметь переведенные поля, поэтому для каждого я создаю сущность Translation .Между этими двумя сущностями всегда существует отношение один-много, что позволяет мне добавлять новые языки в будущем, и я могу получить доступ к переводам через Entity.translations .Пока все хорошо. 

Entity
EntityTranslation

1) Прежде всего, я хотел бы знать, звучит ли такой подход хорошо.Является ли решение, которое я буду использовать в среде чистого SQL, так что я полагаю, что могу пойти по этому пути.

2) Тогда ... Я хотел бы просто использовать Entity.text для отображения соответствующего текста для пользователя (через NSLocale preferredLanguages).Поскольку translations возвращает NSSet, тогда одним из вариантов будет ручное добавление атрибута в модель сущности и изменение метода получения: 

// 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;
}

Это работает, но имеет ли это смысл?Могу ли я иметь проблемы с производительностью?Можно ли сделать что-то подобное, используя Полученные свойства ?Что-то говорит мне, что это должно быть возможно, но я не могу заставить его работать с помощью редактора Xcode Core Data ...

Спасибо.

1 Ответ

2 голосов
/ 28 ноября 2011

То, будут ли у вас проблемы с производительностью, зависит от размера вашей базы данных и от того, как часто вы выбираете значения.Вы должны запустить свой код через Instruments, чтобы проверить, какой процент процессорного времени он вам стоит, и кешировать все, что необходимо.

Один твик, который я бы сделал, - сохранить этот объект NSPredicate в статической переменной, поскольку он не изменится.часто.

Если у вас не много записей в таблице, лучше всего один раз извлечь весь набор записей, а затем сохранить его в NDDictionary, который вы можете искать в любое время.

Однако я думаю, что вы делаете ошибку, используя большую сложную систему (реляционную базу данных с объектно-ориентированной оболочкой) для решения очень простой задачи (поиск значения ключа).А сложные решения почти всегда медленнее и требуют больше памяти, чем простые.

Рекомендуемый способ локализации - использовать файл .strings, и я не могу думать о каких-либо преимуществах использования основных данных.У вас есть 200 МБ локализованного текста?Если нет, то я думаю, что лучше использовать файл .strings вместо основных данных.

...