lowering priority for now; still would like to do it!
but there's the problem of storing frequency tables, which most system
dicts don't include.

Note: once the dictionary "learns" we might want to revisit this.

raising prio and severity, since the alternative is localizing the
whole GOK dictionary!

much more desirable IMO to have some way to use or import the system
dictionary.  Perhaps the best workaround is to have a feature allowing
importation of the system dictionary.

ispell, at least, can dump the contents of its entire dictionary to
stdout.  We can use that to import the dictionary into GOK, setting
frequency of each word initially to '1' (will work best once the
frequency values are updated during word completion, i.e. when GOK can
'learn' a user's word usage patterns).

Created attachment 20414 [details] [review]
provides infrastructure for doing this and proof-of-concept implementation

above patch isn't really ready to commit:

* it uses a hard-coded location for the aspell system dictionary 
* it doesn't update the word frequencies
* it doesn't check for duplicates

possibly it'd be better to import the system dict (at first invocation
of gok?) as we've discussed, than to read in a dictionary at runtime.
 Also, instead of reading the dictionary from disk, it'd be more
acceptable to run either aspell C API (disadvantage- build-time
dependencies) or run 'aspell dump' to a tmpfile.  The latter is
probably safer and more reliable generally, and can be used for
importing the system dict.  

We should probably sort the dict too, that'd make things much more
efficient.

adding accessibility keyword

instead of a 'fixed' system dictionary, what is implemented is the
ability to specify a 'wordlist' or dictionarly anywhere in the user's
file system, via gconf.