How to represent a localized string type in Core Data?

Question

I'm new to Core Data, and am struggling with some of it conceptually (relative to, say, SQL, which I understand).

I'm trying to build a model which for the sake of simplicity looks like:

"Category" entity, which has a name, and a relationship to-many Products
"Product" entity, which has a name

I want those names (string) in both entities to store localized variants. That implies another join. There are a small number of possible localizations. I know that I could put each localization as an individual attribute ("name_en", "name_de", etc), but that doesn't scale, and I want to understand the "right" way of accomplishing this.

My gut tells me I want two more entities here, a Localizations one (which simply contains the set of possible localizations) and some sort of LocalizedString one, which related to the Localization. But Xcode warns me about not having Inverse relationships set up, etc.

Can someone who groks Core Data model design deeply please help out a newbie understand how to think through this problem?

(My next problem will be building the weirdly multi-pivoted UI that lets you set the name for each localization that's available, but that will be another set of investigation. :) )

Answer 1

I don't know if I qualify as somebody who groks core data but I've used something like this in the past:

name in Something is the english name. So I don't have to search the relationship in english language devices (which covers 70% of the devices for my app).
And there is a getter called localizedName in the Something subclass that either returns name or the string for the currently used language code.

When I did this I thought that I could save the localized string in the name property because languages usually don't change often on devices that are not used by developers. But finally I decided against this because that wasn't a performance problem.

Another variant I thought I could use to fight against non-existing performance problems:

currentLanguageString basically points to the localized string of the current language. It is changed everytime the language changes (in 99.9% of all cases this happens one time, when the app is first launched).

---

if you have more than one string in the Something entity I would make LocalizedString an abstract parent class of subclasses specifically created for the string you want to localize.
You have to use such strange constructs because you can't create a relationship to more than one entity.

---

Or if you know what you are doing, ignore the "no inverse relationship" warning

but if you go this way you have to make sure that you never delete a LocalizedString object that is still in use. You don't want to end with an inconsistent storage.