Read Working With MediaWiki for Free Online

convert a value in a certain unit to another unit — like converting pounds to kilograms. Another interesting example is the “Chess diagram” template, which can display an entire chessboard layout. There are hundreds of other such templates on Wikipedia.
    Finally, there are extensions in which templates are used to format values — a template name is passed to a function, which then substitutes in to that template other values that it has generated. Semantic MediaWiki is one extension that uses such a trick, with its "template" results format. We’ll talk more about that last usage in later parts of the book. And we’ll also talk quite a bit about infobox-style templates, which are a key building block for the Semantic MediaWiki system.

Parser and tag functions
    Pre-defined calls within MediaWiki are all referred to as “magic words”. There are three kinds of magic words: parser and tag functions, variables, and behavior switches. We’ll get to parser and tag functions first.
    Parser and tag functions are both pre-defined functions that take in a set of inputs and display a result, or otherwise perform some action. The main difference between the two is that parser functions are called by wrapping the function with curly braces, while tag functions are called using angled brackets, in the manner of HTML or XML tags.
    As an example, let’s take a (fictitious) function, ’#reverse’, that takes in a string and displays its characters in reverse. If it were a parser function, a call to it could look like:
{{#reverse:abc}}
    ...or:
{{#reverse:string=abc}}
    In other words, a parser function can be defined as either taking in named or unnamed parameters. If they’re unnamed parameters, they’re defined by the order in which they’re called.
    If ’reverse’ were a tag function, on the other hand, a call to it could look like this:
abc
    ...or this:

    In all of these cases, the call would produce the string “cba” on the page.
    Just as with HTML and XML tags, parameters to a tag function can be either a content string, placed between the start and end tag, or attributes placed within the tag. This means that tag functions can have only one unnamed parameter, all the rest must be named.
    How are multiple parameters passed in to parser functions? They’re separated using pipes. Here is a call to a real-life parser function, #sub, that displays a substring of a string, starting at a certain location and with a certain length:
{{#sub:This is a string.|0|4}}
    In this case, the #sub function takes the first parameter, the sentence, and returns the substring starting at character 0, with length 4. The resulting displayed string would be "This".
    The values passed in to #sub, and to all other parser functions, are separated by pipes.
    But what about values that actually contain pipes — how can they be passed in without confusing the function? There is a standard solution to this that’s somewhat of a hack: a template called "!" is defined in the wiki, which contains simply the string "|". You could then have a call like:
{{#sub:This is{{!}}a string with a pipe.|0|4}}
    When the parameters are evaluated, the "{{!}}" will change to a "|". (The result will simply be “This”, so this is a contrived example, but hopefully you get the idea.)
    That brings us to the last difference between parser and tag functions, although it’s a difference that’s becoming less of an issue. For most of the history of MediaWiki, the big weakness of tag functions was that inputs passed in to them were not first parsed.
    To take an example, let’s say that there are parser and tag functions named ’spacify’, that put spaces in between all the characters in a string (this is a hypothetical example — there’s probably no reason why anyone would ever want such a thing). The following calls will both display the string "c b