Mathieu Tozer's Dev Blog

And here's the notes that made it all come about:

I still have to think again about how the dictionaries can associate themselves to more than one language. Right now a to many relationship can not effectively be set because there is only one pivot language.

Maybe playing around with the software will be more effective in determining what will work.

I was thinking it would be nice if the dictionary always translated to your native language. What if I could get that from the system? But I decided that wouldn't be helpful anyway, because it's dangerous to assume that there are going to be always dictionaries available to translate to the user's native language.

Ideally, what kind of setup do I want? I should implement a design. The design should force the implementation, NEVER the other way around.

I've been dangerously creeping toward this so watch out!
------------------------------------------------------------------------------------------------
Checked dictionaries will be used in looking up definitions for JAPANESE
Here are the dictionaries that have Japanese capabilities.


------------------------------------------------------------------------------------------------

Obviously the UI won't be so verbose, but it's helpful in determining what the implementation needs to cough up stating it in this way.

Which means that the display shouldn't only show which

Another problem is that I've set things up to work for lookup in a unidirectional manner... but.... that's kind of what Words does. It's unidirectional. Think about it.

Users say they're learning "Japanese"
But it also means that they're going to want to translate words from English INTO Japanese. How will words support this?

Back to the UI drawing board.

What would be nice is if the program KNEW which language the word being input was.

Ok, so here's what I thought on the way home.

The language will only know to ask along that pipeline for definitions, for whatever it considers a word. Therefore it's left up to the dictionary itself to spit definitions of the word back, or not to.

So the dictionary manager should show the user a list of dictionaries that declare that they have the capabilities in EITHER direction for the currently selected language, and that I have been in error over the 'pivot' language idea.

So I have to modify the predicate to be in accordance with what I have decided here. It might be wise to modify the model to have a 'capabilities' attribute.

So the predicate will be more like:
(capabilities contains[c] 'languagename')

And then the user will be able to check the box to associate it with the currently selected language (ie, connect the pipeline).

yeah! I think I got it working alright.

See, I forgot about an old friend called [App delegate]

Which gives you the object that is pretty much available to everyone, including model objects, which use it all the time when asking for [[App delegate] managedObjectContext];

The next step is to set it up to actually do some word defining.