Daniel Kinzler wrote:
To put it briefly: I want to remove the assumption that MediaWiki pages contain always wikitext. Instead, I propose a pluggable handler system for different types of content, similar to what we have for file uploads. So, I propose to associate a "content model" identifier with each page, and have handlers for each model that provide serialization, rendering, an editor, etc.
It's an ancient assumption that's built in to many parts of MediaWiki (and many outside tools and scripts). Is there any kind of assessment about the level of impact this would have?
For example, would the diff engine need to be rewritten so that people can monitor these pages for vandalism? Will these pages be editable in the same way as current wikitext pages? If not, will there be special editors for the various data types? What other parts of the MediaWiki codebase will be affected and to what extent? Will text still go in the text table or will separate tables and infrastructure be used?
I'm reminded a little of LiquidThreads for some reason. This idea sounds good, but I'm worried about the implementation details, particularly as the assumption you seek to upend is so old and ingrained.
The background is that the Wikidata project needs a way to store structured data (JSON) on wiki pages instead of wikitext. Having a pluggable system would solve that problem along with several others, like doing away with the special cases for JS/CSS, the ability to maintain categories etc separate from body text, manage Gadgets sanely on a wiki page, or several other things (see the link below).
How would this affect categories being stored in wikitext (alongside the rest of the page content text)? That part doesn't make any sense to me.
MZMcBride