I got some more great questions this morning:

“Couldn’t we just put a WeSay front-end onto FLEx (FieldWorks Language Explorer)? It uses the same underlying stuff, doesn’t it?”

Nothing is currently shared. WeSay is designed for really cheap, tough, low-wattage computers.

“Okay, it’s set up for one person to type into, but what if we want 10 people all typing into the same database–would it work for that?”

Ok, let’s back up. FLEx does allow you to very cleanly keep one database and share it over a LAN. However, while it does support export and import, no attempt is made at automatic merging or to guarantee round-trip-ability. So what do I do if we’re NOT all on a local network? FLEx will eventually support the (far more common) disconnected scenario (I will probably write the merge code needed for the basics).

WeSay has the reverse priority. We claim that if you can work disconnected, then you can always merge. And since these are both conceptually-modeled systems (not just ones that guess at backslash codes), merging isn’t hard. Our internal database system (db4o) actually does allow multi-user, networking access, but we think we should get the more flexible system (disconnected) going first.

So, for example, if FLEx were part of the project, then you’d merge the words collected with WeSay into the master FLEx db, using LIFT interchange files. I did a proof-of-concept with that earlier; it will need more work. From there, you could save the merged lexicon as LIFT or Standard Format, if you wanted to.

Not using FLEx? Someone is also going to write LIFT merger, and of course LIFT-to-Toolbox conversion should become commonplace. So if you wanted to stay in Toolbox land, you’d do this: merge the LIFT files from each WeSay user, then use a tool to convert that to Standard Format.

To summarize: our near term goal is to use LIFT interchange files to go to/from FLEx, and, through a converter, to/from Toolbox. Sound wrong-headed? Leave a comment and tell us so.