[Foundation-l] Wikitext isn't a programming language, but... - Wikimedia-l

19 Jan 2007

The introduction of ParserFunctions was reluctant, but look how it's taken
off. Reluctance against programming-language-style extensions is many-fold,
but primarily is this concern: Wikitext is not a programming language. It's
a markup to simplify formatting in articles. So complicating it with
parameters and arguments and functions is just wrong wrong wrong. I agree.

The problem is, users of Wikitext *want* to program. But not in articles, in
templates.

It's simply true that the way templates are used is not entirely as they
were originally intended. Originally they were very simple transclusion
devices. Now they are complex ways of organising and structuring data in an
easy and efficient way - the point being that users (without technical
know-how) can include templates in their articles with simple code (e.g.
{{template|a|b|c}} ) and receive a specially generated result tailored to
the applicable article by the template code. This is obviously a massively
useful way of allowing articles to have better information better presented,
and allowing non-tech-savvy users (or even the tech-savvy ones) to very
quickly and easily and intuitively insert complex formatting like
a (dynamic) infobox into their articles.

So the way I see this, it's only really in *templates* that the advanced,
programming-like features are required, and the reason is that, simply due
to evolution, templates are being used like subroutines or functions. And
for good reason. That's a very very *very* useful thing for them to be able
to do. Which is why they are all doing it. That kind of functionality makes
MediaWiki an extremely powerful wiki engine - it's extendible from within.

But if these "functions" are being written in Wikitext, that makes Wikitext
more than just markup, which is confusing - so scrap them. And yet, software
support for such "functions" is incredibly useful - so keep them!

There's a solution here. How about we introduce another language ****that is
only available in the Template namespace****, specifically for this
function? Call it Wikisyntax. Wikisyntax is a pure (and simple) programming
language, with no markup. Wikitext is a pure and simple markup language,
with no code.

Normal users (who can use Wikitext fairly easily) rarely ever look at the
template namespace anyway. It's a simple fact that your average user of
MediaWiki has no idea what a template is, and will never create or edit one
until he or she is quite advanced and has got a strong understanding of the
system. Thus it is not objectionable on usability grounds alone to expand
the code for the template namespace. In fact, usability is a *reason* to
support the idea of Wikisyntax: templates *are* being used like this because
it's an extremely fruitful feature, so it would make things easier, but it
would keep the complexity seperate and hidden away from normal markup and
articles. Of course, users can still write templates with just Wikitext, but
the Wikisyntax option is there.

Crucial is the point that the Wikisyntax code is only parsed when written in
the template namespace. This allows Wikitext to remain a pure markup for use
in articles by normal users, without confusion. But the Template +
Wikisyntax idea is, essentially, a way of allowing a wiki to have *custom
subroutines* that **aid** those normal users in normal articles. No other
Wiki engine has that kind of power.

Would this idea be difficult to implement? I don't think so at all.
Wikisyntax can be a seperate file, say, SyntaxParser.php, called only when
necessary. Its contents can simply be (mildly altered, although not much) a
copy-and-paste of the ParserFunctions extension that is already written, and
any others we'd like to include, e.g. StringFunctions and VariablesExtension
(discuss later). We *already have the code* (pretty much) for this new
template language!

I have made a page on Meta for this suggestion:
http://meta.wikimedia.org/wiki/Wikisyntax , please leave your comments
either here or there. Thanks.