Mathieu Tozer's Dev Blog

I'm going to remove the second context because it doesn't really make
all that much sense to have a second managed object conext. It would
be better to simply have an import exporter function and automate
this process on the first start up or something. Ie, just keep them
in the bundle as .wordslanguage files or something.

What is the goal of what I'm working on now???
To be able to have the user select from an internally supported list
of languages which have dictionary files already set up to use.
So be able to export and import dictionaries first.
Then implement a way to insert these dictionaries into the user's
dictionary sql file so that can start adding and learning words.

It is perhaps more intelligent to leave the dictionaries separate
from the languages when archived. This way languages too can be
passed about freely, without the weight of dictionaries attached to
them. Although it is not intended that languages be passed about as a
commodity like dictionaries will be.

Therefore when the user clicks export, a neat little bundle of
archived language data will be exported somewhere.

When a user adds a new language, the supported languages bundle will
be searched, the contents (or just their names) unarchived, and then
presented to the user. The user will then choose one of the supported
languages and then it will be copied into the user dictionary.
This way unneeded and unused languages won't be making the database
heavy.

So the next step is to enable languages to archive and unarchive
themselves.
This would include the words and that come default with that language...

The final release will be fine tuned, so leave that for later. Make a
simple import export method for what a language constitutes today.

Done! In a single train ride.

This stuff is too easy.