Advanced Templating in MediaWiki: Creating Dynamic Content

Why “advanced” really matters

When a wiki grows beyond a handful of pages, copying‑and‑pasting the same table, infobox or navigation bar becomes a nightmare. A basic template saves a few keystrokes, but advanced templating lets you turn a static snippet into a miniature application that reacts to the page it lives on.

Variable templates – the “template‑within‑a‑template” trick

At first glance, you might think a template name has to be hard‑coded. MediaWiki says otherwise:

{{{{NAMESPACE}}}}

The inner {{NAMESPACE}} expands to the current namespace (e.g. Manual), then the outer braces treat that string as a template name. If you have Template:Manual, the call above will render whatever you placed there. The same idea works with ordinary parameters:

{{{{{2}}}x|{{{1}}}}}

Pass “3” as the second argument and “Hello” as the first, and MediaWiki looks for Template:3x and feeds it “Hello”. It’s a cheap way to get branching without pulling in the ParserFunctions extension.

Passing whole templates as arguments

Templates can be fed into other templates in two flavours:

• Result passing – the inner template runs first, its output becomes the argument.
• Name passing – the inner template’s name (as a string) is handed over, and the outer template decides what to do with it.

Result passing in action:

{{3x|{{tc}}}}

Here {{tc}} returns “in”. The outer 3x template repeats its first parameter three times, yielding ininin. A nested version demonstrates recursion:

{{3x|{{4x|{{tc}}}}}}

The inner 4x turns “in” into “ininininin”, which the outer 3x repeats once more.

Passing a name looks a bit stranger, but it opens doors to dynamic composition:

{{tto|tt|V}}

Template Tto receives “tt” as its first parameter, “V” as the second. Inside Tto you’ll find something like:

{{{{{1}}}|a{{{2}}}b{{{2}}}c{{{2}}}d}}

The double‑curly trick turns the string “tt” into a call to Template:tt, which finally spits out Tt/aVbVcVd. In short: you can hand over a template name, let another template splice it into a longer name, and the engine does the rest.

Variable parameter names

Ever wanted a template that accepts an unknown parameter? The trick is to use triple braces inside a double‑brace pair:

{{{{{param_name}}}}}

If the calling page supplies param_name=Title, the outer braces turn “Title” into a call to Template:Title. This is handy when you build a generic wrapper for a family of infoboxes – you supply the infobox name as a parameter, the wrapper stitches the rest.

Branching without ParserFunctions

ParserFunctions are powerful, but they add a dependency. Some wikis prefer a “pure” solution that works out‑of‑the‑box. One technique is to pre‑define a series of tiny templates that represent each branch, then select among them via a variable template name.

Example: imagine a status badge that can be “new”, “beta”, or “stable”. Create three tiny templates:

# Template:Badge_new
New

# Template:Badge_beta
Beta

# Template:Badge_stable
Stable

Now a single wrapper does the selection:

{{{{{status}}}_badge}}

Pass status=new and you get the “New” badge; pass beta and the “Beta” badge appears. No ParserFunction, just one level of recursion.

When to reach for Scribunto (Lua)

If your logic starts to look like a tangled web of nested templates, it’s time to ask: “Would a short Lua script be cleaner?” Scribunto lets you write a .lua module that receives parameters and returns a string. The advantage is real programming constructs – loops, tables, error handling – while still being called from wikitext:

{{#invoke:MyModule|render|items=10|style=progress}}

That said, variable templates remain useful for quick hacks, for wikis that can’t install extensions, or for editors who are more comfortable with “template algebra” than code.

Practical use‑cases

• Localized navigation – a wrapper template picks a language‑specific menu based on the {{LANGUAGECODE}} magic word.
• Dynamic infoboxes – a generic Infobox template receives the name of a specialized infobox (e.g. Infobox_movie) and delegates rendering.
• Versioned documentation – a “change log” template reads a version number, then calls a template named Log_2.3 to display that slice.
• Self‑updating tables – a table‑builder template accepts a list of page titles, iterates via recursion, and spits out a summary row for each.

Tips to keep your template garden tidy

1. Prefix everything. Use a short namespace like Template:Util/ for helper templates. It prevents accidental name clashes.
2. Document the contract. At the top of each template, write a small comment describing expected parameters and side‑effects. Future editors will thank you.
3. Avoid infinite loops. Recursive templates are great, but remember that MediaWiki caps recursion depth (default 100). A stray {{{{{1}}}}} can bring the whole page down.
4. Test with subst:. Pre‑pending subst: to a template call shows you the exact result before it gets re‑expanded – perfect for debugging complex nesting.

Wrap‑up

Advanced templating isn’t magic; it’s just a clever reuse of the same expansion engine that powers every wiki page. By treating template names and parameter names as variables, you can build tiny building blocks that snap together on the fly. Whether you stay in pure wikitext or take a quick detour through Lua, the result is the same: a wiki that feels more like a living application than a static collection of pages.