Концепция

Идея кратко

добавить визуальное редактирование статей
облегчить написание ботов и подготовку данных для ботозаливок

Идея подробнее

За первый пункт давно выступает Al_Silonov. Идею можно продемонстрировать следующим сценарием работы: пользователь создает новую статью, из списка вбирает язык, далее из появившегося списка выбирает часть речи и другие параметры слова, в конце может редактировать любую из доступных секций – значения, перевода и т. д.

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

Очевидно, что для создания такого интерфейса программа должна сравнительно легко и свободно работать со структурой документа. Эта легкость работы не помешала бы и ботам. Например, что-то типа задания «дай раздел по адресу: статья ХХХ/язык ХХ/перевод/на язык Х, если такого пути нету - создай».

Предисловие к решению

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

Предлагаемое решение

Решение строится на основе существующего Викисловаря или его развернутой копии. Существующий движок Wikimedia обеспечивает хранение статей и их версий, сравнение версий, управление правами пользователей и списки наблюдения, доступ к редактированию по сети и многое другое, от чего неразумно отказываться. Нужно добавить новый программный слой, который будет работать следующим образом:

создается новое служебное пространство имен (например, с именем «xml» - в дальнейшем в этом документе так и будет называться)
для каждой статьи из основного пространства имен создается копия в служебном пространстве имен
статьи в (пространстве имен) «xml» находятся в другом формате - комбинированном xml+wiki
wiki-формат позволяет продолжать использовать многие шаблоны – например, шаблон «по слогам» сравнительно удобен и настолько широко применяется, что его можно оставить
xml-формат задает структуру статьи – разделение по языкам, деление статьи на блоки перевода, этимологии и т. д.
при нажатии на кнопку редактирования статьи в основном пространстве имен, происходит перенаправление на редактирование соответствующей статьи в «xml»
при редактировании статьи в «xml» отображается визуальный html-редактор, но при желании можно редактировать и текст напрямую
боты могут редактировать статьи в «xml» напрямую по сети
после завершения редактирования статьи в «xml» (пользователем через графический интерфейс или ботом через традиционный API), вызывается компилятор статей, который обновляет соответствующую статью в основном пространстве имен (создать документ в вики-разметке намного проще, чем анализировать)
редактирование скомпилированных статей (в основном пространстве имен) бессмысленно, так как будет перезатёрто следующей компиляцией. Для большинства пользователей такое редактирование не очевидно, так как ссылки на редактирование скомпилированной статьи нигде не будут отображаться.

Функции компилятора статей

проверка структуры статьи на допустимость. Только разрешенные блоки в разрешенных позициях в разрешенном количестве.
стандартизация структуры статьи. Вынесение языкового раздела ru на первую позицию, сортировка остальных языковых разделов по языку, перенос интервики в конец статьи и т. д. Все это сейчас должны запоминать пользователи или учитывать писатели ботов.
генерация статей в основном пространстве имен по статьям в «xml»
добавление дополнительной стандартной информации. Например, проставление категорий «длина слова» по языку каждого языкового раздела.
учет перенаправлений (redirect). Если в xml-статье содержится только слово в неосновной форме – в wiki-статье нужно прописать перенаправление. Однако, если в той же статье добавилось еще одно слово, то уже нужно прописывать не перенаправление, а выбор перехода на основную статью. Если в ту же статью добавился раздел про слово в основной форме - то документ должен выглядеть еще иначе
генерация статьей для мобильного викисловаря и для offline-словарей (в виде отдельных программ). Им не нужны пустые блоки типа пустой секции перевода или пустого раздела этимологии, ссылки «редактировать», и им пригодится дополнительная информация (например, чтобы отображать только заданные языки).
проставление interwiki. Централизованное управление проставлением интервики-ссылок позволяет забыть про эту заботу, снизить нагрузку на сервер и проставлять их более оперативно

Для традиционных ботов выгода разнообразная:

xml можно анализировать почти на любом распространенном языке программирования. Доступно множество инструментов, типа XQuery/XSLT.
практически невозможность что-то «испортить» с необходимостью потом исправлять. Сбереженные нервы :) (Сужу по себе – мне перехотелось заливать статьи дальше из-за нескольких глупых ошибок, причем, было понимание, что при интенсивной работе такие ошибки будут возникать постоянно из-за особенностей вики-разметки – работая вслепую, иного ожидать не приходится. А ведь это была простейшая работа, а если начинать крупные проекты… Желание пропадает насовсем)
нужно учитывать меньшее количество условий и ограничений
возможность создания облегченных интерфейсов. Например, стандартные действия «проверь статью XXX/языковый раздел ХХ/блок перевода/на язык Х, и если какого-то раздела статьи на этом пути нету - создай». То есть, бот сам создаст или целую статью, или языковый раздел, если статья есть, а такого языка внутри еще нету, и т. д. Эти действия можно будет прописывать даже в файлах для ботозаливки, по аналогии с современным pagefromfile.py. Таким образом, многие рутинные действия даже не потребуют написания ботов, копания в регулярных выражениях и т. д.

Описание xml-формата

xml-шаблоны

Где-то нужно хранить информацию об ограничениях. О допустимых внутренних блоках каждого раздела, их количестве. В традиционном xml для этой цели применяется xsd, но в данном случае желательно применять абстракцию шаблонов.

отдельный шаблон – отдельная статья. Возможно, в отдельном пространстве имен.
шаблоны могут содержать вики-разметку
могут вызываться с именованными и неименованными параметрами
могут вызывать другие шаблоны
могут содержать перечисление допустимых блоков – как простым перечислением («перевод», «этимология»), так и перечислением категории («склонения существительных»)
для допустимых блоков – опциональный параметр «делать подстановку шаблона вместо вызова». Аналог конструкции subst
условные выражения if(определен параметр) и т. д.

Детализация формата

Обычно в xml создается разнообразие тегов. Проблемы:

статьи могут содержать знаки пунктуации в имени, а в xml такое не проходит. Значит, прямого соответствия «имя шаблона»-«xml тег» не выйдет. Пробелы можно было бы заменять на знаки подчеркивания, а с другими знаками не выйдет
не английский язык. Все ли движки xml будут корректно обрабатывать такие теги?
некоторые теги придется сделать предварительно определенными (какой-то if/template/for/allow/call и т. п.). Тогда возникнут ограничения на создание шаблонов с такими именами.

Возможное решение – сделать ограниченное количество тегов, которые будут соответствовать синтаксису, а основную информацию передавать в виде значений атрибутов и текста внутри тегов. Например, тег вызова шаблонов с именем t и с атрибутом name=”ru сущ” - именем вызываемого шаблона.

Передача параметров в шаблоны

Чтобы параметрами могли выступать сложные структуры с другими тегами, параметры нужно делать не атрибутами, а внутренними тегами. Для экономии памяти, имена подбираются покороче. P = parameter. Например, пример вызова шаблона с неименованным параметром:

<t name=”сущ”><p>стол<p></t>

. Другие варианты:

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

Корневой тег

Корневым тегом статей предлагается сделать pre. Возможно, в комбинации с nowiki. Это дает:

ускорение обработки – парсер не тратит время на анализ статьи
возможность просматривать исходный код в качестве основной статьи

Если изменения в движке Wikimedia будут достаточно глубокими, то оба этих преимущества могут не потребоваться. Но на период разработки и тестирования как временный вариант вполне сгодится.

Хранение вики-текста в статьях

Вики-разметку можно хранить в виде текста внутри специального тега w. Любые спецсимволы кодируются по правилам xml. Можно обойтись без специального тега (w), а хранить в виде обычного текста вперемешку с другими тегами – но в некоторых случаях этот подход менее удобный. Например, в некоторых движках обработки xml (как у описанного в моей странице обсуждения) за отдельный тег может отвечать отдельный класс, а в случае текста «на ровном месте» могут потребоваться дополнительные изменения. Кому как удобнее, есть ли другие соображения? Возможность вставки вики-текста должна быть не в любом месте, а только в местах, специально разрешенных в шаблонах. А именно, внутри уже размеченной структуры – внутри блоков перевода/этимологии и т. д., а также для всей статьи – для проставления дополнительной информации типа «к удалению». Но и такую дополнительную информацию можно вынести в отдельные шаблоны, сделав вставку на выбор шаблонов «к удалению» и прочих, оставив дополнительный шаблон «неучтенная ситуация» с возможностью вставки любого вики-текста внутри.

Поэтапная миграция

Первый этап – данный режим работает только для статей, у которых созданы дубли в xml. Это должно дать возможность освоиться и отладить работу на немногих статьях. После отладки, дубли создаются для всех статей в основном пространстве имен (не затрагивая страницы обсуждения и проч).

Поэтапное переформатирование статей

В начале работы, статьи можно переносить без изменений викиразметки в пространство xml целиком, заключая лишь в тег верхнего уровня. В дальнейшем, при помощи ботов поэтапно добавлять структуру. Самое легкое – добавить разделы статьи по языкам, убрав традиционные = {{-ru-}} =, затем – вынести в отдельные теги перевод и этимологию, и т. д. Для случаев сложных шаблонов, с трудом поддающихся анализу, можно написать «заглушки-конвертеры», которые будут выводить готовый xml-код в основную статью (может быть, скрытый от просмотра), а парсерам будет оставаться перенести его из сгенерированной статьи назад в xml.

Служебная информация внутри статей

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

Таблицы склонений

С сайта aot.ru можно скачать словарь Зализняка со всеми склонениями каждого слова. Эту информацию можно внедрить в служебный блок компилируемых страниц. Если есть правильная таблица словоизменений, которая работает через шаблон словоизменения по Зализняку, то отображается она. Иначе – то, что уже есть. Преимущества:

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

С одного только aot.ru можно сразу импортировать около 20 млн. основных и неосновных словоформ русского, английского и немецкого языков.

Поэтапный импорт внешних источников данных

Разделение труда – великая вещь. Кто-то может импортировать тот или иной словарь внутрь Викисловаря. Например, разделить переводы словаря Мюллера на словарные статьи, но не на подпункты. Кто-то – правильно его обработать и занести внутрь соответствующих разделов. Неразумно требовать, чтобы эту работу непременно выполнял один и тот же человек – так теряется время и другие возможности.

Критика и пожелания

Перед тем, как браться за реализацию, хотелось бы услышать критику. Вдруг кто-то предложит существенные изменения? Ошибки архитектуры – самые дорогие и сложно устранимые, поэтому их желательно выявлять как можно раньше.

Так как вводная статья уже вышла немаленькой, обсуждение лучше проводить на странице обсуждения. Там же обсуждать и детали реализации. Neurocod 21:13, 22 февраля 2010 (UTC)[ответить]

Викисловарь:Технические вопросы/Значительные усовершенствования

Содержание