Начнем с начала[править]

Мне кажется, сама концепция не совсем верна (или я неправильно понял?). Порочность в том, что инструментарий все равно остается ориентированным на редактирование текста. А должен быть ориентирован на работу с объектно-ориентированными полями базы данных. Тогда не потребуется проверять, на своих ли местах находятся поля: никто физически не сможет их переместить в неправильное место.

Для этого надо отойти от концепции текстового редактора и сделать интерфейс наподобие того, которым приходится пользоваться в Commons при загрузке файлов. Только в данном случае надо делать, наверное, страницы с вкладками (tabs). Статья представляет собой набор объектов - языковых секций; языковая секция - набор объектов - секций по лексемам; лексема - набор объектов - значений. Структура внешне должна быть такой:

Для каждого языка - отдельная вкладка (плюс кнопка "Добавить язык", причем при добавлении можно выбирать из списка).
Внутри языковой вкладки - вторичные подвкладки для омонимов ("Лексема I", "Лексема II"... - плюс кнопка "Добавить лексему").
Внутри лексемы либо третичные подвкладки, либо уже без вкладок, а с отдельными секциями для значений: Значение 1, Значение 2.... - плюс кнопка "добавить значение". Благодаря этому больше не придется мучиться с нумерацией значений
Внутри вкладки/секции для значения - зоны/поля (Морфологические свойства, Фонетические свойства, Семантические и т. п.). И только на уровне свойств используются окошки для редактирования текста. А, скажем, при выборе пометы опять должен быть список из уже определенных помет.

При такой организации легко будет портировать существующие статьи в другие языковые разделы. Интерфейс также легко будет размножить на все разделы, все будет единообразно (админы - а может, и пользователи, индивидуально - должны иметь возможность настраивать "скины" для отображения этой структуры в виде статьи для читателей). --Al Silonov 20:00, 6 марта 2010 (UTC)[ответить]

Пункт «добавить визуальное редактирование статей» как раз и подразумевал отход от ориентации на редактирование текста. Текст виден только при дополнительных усилиях, да еще ботам. По умолчанию – графический интерфейс с невозможностью нарушения структуры. Отличие от подхода «разные поля в БД» только в том, что структура хранится хоть и в БД, но лишь в одном текстовом поле «статья» - а это то же поле, что уже есть в современном движке. Визуальное редактирование становится примерно таким, как вы и описали.

Добавить или удалить новое поле в БД – это куча работы, согласований с разработчиками, переписывание кода создания БД, написание кода обмена с интерфейсом, указание ограничений, связей между полями и т. д.
В случае изменения структуры БД, нужно придумать другой механизм работы с ботами. Так как боты с БД напрямую по сети вряд ли будут работать, нужен новый программный слой – например, в виде того же xml в качестве промежуточного формата. В случае изначального xml, это менять не нужно.
У варианта с хранением структуры в xml, добавлять «новые поля в БД» очень легко. Нужно или создать новый шаблон, или в существующий шаблон добавить новый параметр (даже через визуальный редактор). В случае нового поля - прописать его характреистики: имя, текст с подсказкой, обязательное или нет. Без привлечения программистов, без переписывания кода.
Появляется возможность коллективно расширять «структуру БД» через просоте редактирование статей. Пусть хотя бы и с ограничениями для одних только администраторов.
Вместо переформатирования всей БД словаря под новую структуру БД, можно постепенно экспериментировать с частями словаря, вводя новые шаблоны и тестируя их в отдельных статьях. Без остановки и перезапуска БД на каждое внесение изменений.
Еще легче (в сравнении с чисто БД) с хранением иерархических отношений, подразделов в статьях. В традиционных БД, для каждого нового вида разделов нужно создавать отдельную таблицу, таблицы согласовывать между собой по какому-то полю типа идентификатора (идентификаторы лексем, идентификаторы языков и т. д.). Например, в ВикисоваряХ (WiktionaryZ, теперь ОмегаВики) пошли путем именно хранения всего в БД – у них вышла схема с десятками таблиц, картинка есть на их сайте. Через несколько лет эксплуатации они пришли к более детализированной схеме с учетом большего количества полей и отношений, и запланировали вторую версию. Но такие изменения требуют пересмотра всего кода, и внедрение тоже растягивается на несколько лет.

Про интерфейс. Возможно, правильнее будет добавить в любой шаблон параметр «способ отображения внутренних секций», с вариантами «показывать во вкладках», «сворачивать в дерево», «всегда в развернутом состоянии». Например, шаблон с переводами по языкам показывать в виде вкладок, а содержимое этих вкладок - внутренний блок переводов на заданный язык – всегда в развернутом состоянии. В первой версии я планирую реализовать только «всегда в развернутом состоянии» - как и сейчас во всех статьях. Возможно, с указанием уровня вложенности через небольшие отступы – учитывая то, что сейчас количество уровней вложенности небольшое, меньше 10, и вряд ли будет больше. Скины с учетом персональных настроек тоже реализуемы, но позже. Например, можно по умолчанию разворачивать только некоторые языки, которые пользователю интересны, эти же языки предлагать по умолчанию при создании новой статьи, и т. д.

Про текущее состояние. У меня есть небольшой опыт создания подобной системы на html+JavaScript (но без PHP), где у каждого раздела можно было добавлять и удалять свой набор секций. Например, секция «команда» с параметром идентификатора и количества срабатываний, внутренняя опциональная секция «правила срабатывания», в ней – возможные секции «и»/«или»/«не», и т. д. Отличия в том, что в той работе возможная структура документа задавалась изначально и один раз, а тут будет распределена по разным шаблонам, хранящимся в отдельных статьях, и изменяющихся динамически. Сейчас дошел до изучения ООП в PHP, через 1-3 недели смогу анализировать xml на PHP, тогда можно будет начинать проводить первые эксперименты. Если делать динамический html (добавление секций по щелчкам мыши без перезагрузки страницы) на основе существующих библиотек, а не изобретать велосипед, то еще некоторое время понадобится для изучения библиотек AJAX. Экспериментировать можно через интерфейс ботов API, но в финальной системе нужно будет сшить код с движком (хотя бы чтобы изменения вносились не под данными бота, а под данными пользователей) - это еще время на изучение движка Wikimedia. Для этого, вероятно, нужно будет также выучить способы работы с БД в PHP. В одиночку можно успеть до лета :) Neurocod 03:12, 8 марта 2010 (UTC)[ответить]

Обсуждение концепции[править]

Параметры шаблонов[править]

В статьях, все, что хранится внутри тегов - это вызов шаблонов формате xml и параметры шаблонов в xml. Никакой иной промежуточной разметки между шаблонами нету. Параметры вызова шаблона могут иметь два вида: вики-текст (как правило, для секций самого нижнего уровня, типа текста перевода), и параметры в виде вызова других шаблонов. Например, новая секция языка - это шаблон "статья по языку ХХ", прописывать вручную название языка не надо. Другие шаблоны: "перевод на язык ХХ", "вариант перевода внутри секции переводов на некоторый язык". А вот внутри последнего - уже обычное поле для ввода текста перевода.

Гипотетический пример для статьи "бежать", с намеренно длинными именами шаблонов, чтобы было понятнее:

<t name="ru">
  <t name="lexem">
    <p name="oldWikiBlock">{{Гл5b-ж ...
{{морфо||беж|а|ть}} ...
    </p>
    <t name="translation-block">
      <t name="translate-en">
        <t name="concrete-translation">
          <p name="text">(быстро передвигаться, нестись) hurry {{пример|текст примера}}</p>
        </t>
        <t name="concrete-translation">
          <p name="text">(течь, литься) run {{пример|текст примера}}</p>
        </t>
      </t>
    </t>
  </t>
</t>

Чтобы внутри определения шаблонов (а не внутри вызова шаблонов в основных статьях) не плодить много одинакового текста (вида: шаблон "Перевод на язык XX" содержит возможность вызывать шаблоны "concrete-translation" неограниченное количество раз), в определении шаблона нужно уметь подключать другие шаблоны. Например, прописать в вызове название языка перевода, а вызываемый шаблон добавит разрешенные параметры - возможный параметр concrete-translation и прочее.

Конкретные шаблоны[править]

Шаблоны перевода[править]

Можно было бы не хранить языки, перевода для которых еще нету. Так как пользователи при добавлении нового языка в блок переводов просто выберут язык из списка, а визуально страница редактирования будет чище.

Решается, если за конкретные языки перевода отвечают отдельные внутренние шаблоны. Если шаблон возможен, но не вызван - в статье ничего не отображается, а при редактировании статьи появляется выпадающий список с выбором языков - для вставки вызова шаблонов.

Реализация[править]

Оборудование[править]

Сначала отладка на домашних компьютерах. Затем могу предоставить домашний сервер с RAID 1 (2 диска) и 12 Гб ОП. Большой объем ОП можно использовать для кеширования страниц в память или для переноса в память БД – для ускорения работы.

Ссылки редактирования[править]

Изменить ссылки для редактирования страниц с основного пространства имен на xml можно при помощи следующей переменной: http://www.mediawiki.org/wiki/Manual:$wgActionPaths

Отдельный программный сервер[править]

Для отладки концепции, компилятор статей может быть реализован в виде внешнего сервера. Возможно, исполняемого на том же компьютере. Его должны вызывать Wikimedia API при редактировании статей ботами и пользовательский интерфейс. Тогда изменений в исходниках Wikimedia на PHP придется делать немного.

Язык разработки[править]

Внешний сервер можно писать на чем угодно. Особенно, на время отладки концепции. Например, я пока не определился, писать его на PHP или С++. С++ я знаю намного лучше, примитивный сервер на С++ уже писал, с xml на С++ активно работал, с wiktionary – тоже. С++ может быть намного быстрее, да и отлаживать его часто удобнее – с остановкой исполнения и просмотром всех переменных. С другой стороны, самодельный сервер не такой надежный, как Apache+PHP, в том числе к хакерским атакам и к обработке непреднамеренных ошибок.

Решил писать на PHP. Теперь нужно время, чтоб его подучить. Neurocod 15:56, 28 февраля 2010 (UTC)[ответить]

Импорт БД[править]

Для начальных тестов можно использовать полупустую БД, для средних – импортировать Викисловарь с только последними правками статей, и для финального теста – Викисловарь со всеми правками (размер разархивированного файла – 5 Гб).

После окончания импортирования, может потребоваться вручную запустить обработку очереди заданий. Windows-аналог команд:

cd c:\xampp\htdocs\wiki\maintenance\
c:\xampp\php\php.exe runJobs.php --conf ../LocalSettings.php

Вывод в консоль будет в формате UTF-8. Прочесть вывод легче, перенаправив вывод в файл.

Визуальное редактирование статей[править]

Визуальное редактирование статей имеет смысл разрабатывать после того, как пройдут первые эксперименты с компилятором статей. Так как станет примерно ясно, какой формат будет использоваться. А также накопится немного настоящих примеров, и можно будет сразу тестировать результат во всех направлениях - интерфейс <=> xml => wiki.

Приостановка[править]

Проект временно откладывается. Причины:

Производительность: статьи из xml-дампа импортируются (под windows без акселератора) со скоростью 2-3 статьи/сек – даже на импорт БД (со всей историей) требуется пару недель, а еще несколько этапов редактирования всех статей... Разрабатываются некоторые программы, которые импортируют статьи сразу в БД (а не через редактирование статей стандартному интерфейсу PHP) – но на тот момент они отставали от последних версий движка викимедиа.
Язык: PHP все-таки непривычен для меня
Стоимость: веб-серверы с запланированной нагрузкой пока слишком дорогие.

Легче всего с последним пунктом – сервера дешевеют в 2 раза каждые год-два. Нужно подождать пару лет, и можно будет держать дома сервер, которого хватит на несколько викисловарей. Что до остального – в последнее время склоняюсь к принципиально другому решению. Написать движок нового словаря:

на С++ (используя инструменты типа http://en.wikipedia.org/wiki/Wt_–_Web_toolkit ) - многократное ускорение движка
с БД, которая вся располагается в оперативной памяти (сохраняет данные на диск фоновым процессом с некоторой задержкой) – еще одно значительное ускорение работы

Высокопроизводительный движок сможет обслуживать тысячи пользователей одним компьютером – тогда снижается стоимость оборудования, и упрощается администрирование всей системы (я не профессиональный администратор, и установка серверов балансировки/акселераторов PHP и подобного ПО на малознакомый linux отнимает много времени и усилий). Neurocod 17:06, 26 июля 2010 (UTC)[ответить]