I've asked Jason to setup a wiktionary-l. I don't know if he has yet, but when he has, I intend for there to be a big notice posted on wikitionary.org, on the wikipedia-l and wikien-l mailing lists, as well as on Wikipedia itself, inviting a sort of "global summit meeting" to discuss some of the things that I outline below.
Wiktionary has been cranking along happily in a state of technical neglect for quite some time.
There are currently 32,246 entries. That's enough that we must preserve the work that's already done. It also precludes any change of license, whether that's fortunate or unfortunate I don't know.
There is an active community there, with a lot of overlap to the broader wikipedia community. The need to be consulted on any changes that we implement.
They have an existing schema whereby they are doing in freeform text just what we ought to try to help them formalize with actual database functionality. One can only assume that their scheme is sometimes followed inconsistently because human editing is inevitably inconsistent. However, there appears to me to be enough consistency that a semi-automated conversion process should be possible.
Anything that we do should favor the needs of editors over abstract a priori desires for the end product. That is to say, if some fancy and clever thing requires a lot of work from editors, we just skip it. The editors are primary, or any wiki community will be destroyed.
At the same time, we should design a "structured wiki" with one eye on campatibility with re-use. If there are existing XML schemas that have prominence in the wider community, we should look to them as a part of our design, even if we deliberately choose not to implement every possible aspect in order to favor ease-of-use for editors.
Consider this for an example: http://wiktionary.org/wiki/Vision
As a rank amateur database designer, I see several immediate possibilities which would make an instant and easy improvement. Even if we had a simple and less-than-ideal design, we could lay the groundwork now for something better in the future.
I'm a huge fan of incremental change in cases like this. We'd like to improve the software for the wiktionarians in a way that conforms to how they like to edit, while laying the groundwork for further revisions down the line.
--------
Consider a really bad database design, a 'flat file' design, or nearly so.
word AHD pronunciation IPA pronunciation SAMPA pronunciation definition synonym list related terms list translation list
This is a horrible design, with multi-valued fields, etc. It can be improved in just a few minutes of work. But even this horrible design would be better than freeform text.
Developer time and energy is at a premium (at least, until some clever developer really takes this up as a cause!) and so simplicity is a huge virtue. A little bit of fixing done soon, is better than an imaging hypothetical perfect system that's too intimidating and never gets off the ground.
--Jimbo