Тогда, несомненно, следует так же добавить и опциальное поле для комментариев к каждому переводу и примеру. Чем скорее это будет сделано, тем скорее у пользователей появится возможность присылать более качественно оформленные статьи.
Был еще вопрос по более точному определению направления перевода. Например, бриновский Edict может искаться большинством оболочек в обоих направлениях, однако основным является яп.-англ., и это особо оговаривается в приложении. Не вполне понятно, на сколько будет качественным перевод из одной словарной базы (словаря) в обоих направлениях, но Мультитран вроде бы и с этим справляется.
Насчет комментариев.
В мультитране реализовано так:
рус слово - анг слово - (комментарий на рус. языке)
Пример:
великан - jumbo - (о человеке, животном)
При таком подходе есть несколько ограничений:
1) при переводе в обе стороны (и с анг. на рус., и с рус. на анг.) комментарий все равно выдается на рус. языке, причем один и тот же комментарий
2) комментарий может стоять только ПОСЛЕ заглавного слова
—————
Я думал, как реализовать комментарий, и пока остановился на таком подходе - просто сделать комментарий частью слова, поместив его в скобки.
В окне "Добавить статью" внизу в поле "Информация" есть подсказка о том, что "комментарии помещайте в скобки".
Таким образом, комментарий может стоять впереди основного слова:
———————————————-
(денежный) капитал
<экон.>
資本金 【 しほんきん 】
———————————————-
... или позади основного слова:
———————————————-
девальвация (снижение паритета валюты)
<экон.>
平価切下げ 【 へいかきりさげ 】
———————————————-
Причем, для каждого слова - комментарий на своем языке:
———————————————-
(昆布の)群落
<рыб.х-во>
заросли (морской капусты)
———————————————-
Сейчас комментарии везде выдаются как часть основного слова, но потом можно будет их легко извлечь и осуществить с ними любые действия. Их можно, например, не показывать в основном списке слов.
Насчет направления перевода. Поскольку словарная база состоит из пар "слово"-"перевод", то перевод может осуществляться в обе стороны. Причем, оба направления равнозначны. Этот подход, как можно убедиться, прекрасно работает у Мультитрана.
Объясню поподробнее, в чем здесь засада. Похоже, что большинство .Net'овских программок требуют своей (той, под которую создавались) версии Net Framework. Причем, установка новой версии не удаляет старую. В результате, у меня уже стоят Net Framework 1.0, 1.1, 2.0 beta. Стоит зайти на Windows Update, и если там имеется кокой-нибудь фикс для Net Framework, он опять-таки загружается отдельно для каждой версии. Все это съедает и много времени, и много места на диске. Но я (и не только я) конечно же, готов потерпеть на стадии разработки прграммы и базы. 
Меня вообще-то тоже удивляет, почему так сложно распространять программы написанные с помощь .Net языков. Кстати, у меня у самого три версии Net Framework.
Этот Net Framework загружается и ставится довольно долго. И вообще вся эта заморочка с .Net не имела бы смысла, если бы не перевешивалась простотой программирования. Если бы с самого начала на Visual Basic 6.0 писал, то проблем бы не было.
Так что насчет неудобства .Net я в курсе. Будем думать.
