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