Обсуждение Викисловаря:Технические вопросы/Значительные усовершенствования
Начнем с начала править
Мне кажется, сама концепция не совсем верна (или я неправильно понял?). Порочность в том, что инструментарий все равно остается ориентированным на редактирование текста. А должен быть ориентирован на работу с объектно-ориентированными полями базы данных. Тогда не потребуется проверять, на своих ли местах находятся поля: никто физически не сможет их переместить в неправильное место.
Для этого надо отойти от концепции текстового редактора и сделать интерфейс наподобие того, которым приходится пользоваться в 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)