А вот создавать клон MediaWiki - имхо, лишнее. Если дело в шаблонах, то у нас тут есть 3 вещи: клонирование страниц (например, можно клонировать страницу-шаблон), шаблоны страниц в категориях (page.docs.tpl), встраиваимые шаблоны CoTemplate (хранимые в БД). Я бы лучше обошёлся без последнего, но в крайнем случае можно задействовать и их.

На счет клона MediaWiki согласен полностью, лишнее.

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

Добавлено 2 минуты спустя:

Опять же, начать можно и нужно с малого (markdown+history), а расширить эту связку inline-шаблонами можно отдельным плагином. Просто при разработке связки надо держдать в голове эту возможность.

Не понял, зачем Wiki нужен свой шаблонизатор. По-моему, хватит обычных TPL, а внутри - однозначно разметка на Markdown. Парсер и редактор Markdown у нас уже есть.

Тут смотря что именно мы понимаем под Wiki. 

1. Если все, что нужно это система версионирования документа и поддержка простой разметки, то да - TPL + markdown будет достаточно.
2. Если говорить о «нормальной Wiki-совместимой» системе, то это использование встраиваемых шаблонов, неограниченная вложенность шаблонов, вызов шаблонов с параметрами, встроенная разметка для таблиц, TOC (и прочее), т.е. некое подобие MediaWiki - то тут обычными TPL думаю не обойдется.

Первый вариант относительно прост в реализации. Это да. И это тот вариант с которого надо начинать в любом случае. Но… это не Wiki. 

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

(Условный пример для понимания о чем я: создаем одну страницу «Шапка страницы документации», а потом на каждой последующей странице документации прямо в тексте пишем {{Шапка страницы документации}}. Все! Теперь на каждой странице имеем единую шапку без необходимости повторять текст.) 

[Поразмыслил еще немного…] 
Хотя можно просто реализовать и на основе CoTemplate, чуть его расширив примитивным функционалом черных/белых списков для вызова функций. (Тем более, что о подобном расширении речь уже заходила.)

Есть ли смысл делать сайты на Cotonti, когда можно вылкадывать страницы статике на github.io? :)

Нет, делать сайты надо только на Cotonti)

Господа, есть ли смысл создавать такой плагин, если все это можно делать в githib, там же есть вики-раздел для репозитория?

Или это необходимо из-за того, что нужна мультиязычность базы знаний?

Есть ли смысл делать сайты на Cotonti, когда можно вылкадывать страницы статике на github.io? :)

Или это необходимо из-за того, что нужна мультиязычность базы знаний?

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

Основные требования, которые описал Владимир:

• Совместимость с модулем page и плагином i18n.
• История изменений и их визуализация
• Управление доступом через систему прав
• Модерация

от себя добавлю:

• функционал истории изменений хотелось бы видеть отдельным плагином (т.к. хранение истории и визуализация изменений - это отдельный и объемный функционал)
• сделать плагин истории изменений максимально универсальным (как минимум, чтобы можно было использовать с простыми страницами, вне зависимости от парсера, а то и вообще с любым ресурсом). вызов через функции и хуки.
• без необходимости не создавать дополнительных полей в таблице cot_pages (и дургих стандартных), лучше завести отдельную таблицу, как более универсальный и гибкий вариант.
• для экономии (а мелких правок могут быть тысячи) - версии документа хранить только как последнюю версию + изменения в сравнении с предыдущей версией. 
• по необходимоти промежуточные скомпилированные версии документов хранить в кеше.

Компоненты, назначение и функционал:

• Wiki-шаблонизатор. - класс который будет обрабатывать секции, ссылки, внутренние шаблоны.(что-то наподобие CoTemplate, но с учетом wiki специфики, возможно что это будет некий препроцессор, который будет генерить на выходе CoTemplate совместимый шаблон, тогда мы сильно сэкономим на реализации шаблонизатора. Вопрос в скорости.) 
• Парсер-wiki разметки. Код который будет преобразовывать текстовую разметку в html код.
  
  Пока не очень разбираюсь во внутренней кухне wiki. Возможно модуль шаблонизатора и парсера можно/надо надо будет объединить. Основные требования к ним это:

1. умение обрабатывать вложенные шаблоны/конструкции 
2. возможность задавать правила базовой разметки в удобном виде без необходимости правки кода
3. само собой кеширование 

• редактор wiki разметки (например на базе markitup)
• интерграция редактора с простым загрузчиком файлов, для загрузки и сктавки в текст соответствующих ссылок на иллюстрации или документы (как пример тот же elFinder).

Вопросы:

• на сколько стоит придерживаться правил оригинальной mediawiki разметки (особенно выхов шаблонов и вызов с аргументами)? Уж больно страшно там выглядят некоторые конструкцуии для неподготовленного человека.

Ссылки по теме:

• Кратко о том как работает Wiki парсер
• Реализация Diff на PHP - вариант 1, вариант 2 (второй показался мне более гибким)

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