"**Transclusion / Template s..."

Transclusion / Template system

Templates and Scribunto power most of the strucured information across Wikimedia (exception: Wikidata), most notably the infoboxes, links to related pages, and notice templates, but also a huge number of other specific functions. They are an incredibly flexible tool which makes it possible for users to create and maintain things that would never be done if each page had to be updated by hand, and hides complexity from less technical users who can easily include them in pages by copying existing examples.

This is not an easy feature to get right, but something which fills their function is essential to attract editors from any existing mediawiki wiki.

MW started off with basic transclusion+parameters, then added various parser functions in a way which turned out to be ugly and inefficient to the point where they were forced to add (limited) lua scripting.

(WIP, will come back to this with more thoughts)

Comments

Eric Bruylant

Seems like there's main two parts:

How do we make it intuitive for editors

Displaying template parameters in the text scales badly, is not a natural way of entering information, and generally scares away editors. My current best idea for solving this is copying TemplateData's method (click on the infobox template, it lets you open a form to edit template parameters), but have the template call code highlighted in source editor (), and make clicking that bring up a form to edit the parameters.

A bonus is storing the parameters separately makes it much easier to reuse the structured information.

What features does it need to be handle the major use cases

Essential:

Single layer transclusion
Template parameters

Important

A way to conditionally hide parts of a template when a variable is not present.
Possibly via a basic parser function for IF?
Possibly by using the syntax for parameters so it's easy to specify which parts should only be shown if the parameter is included?
Core magic words
PAGENAME, PARENTS, CHILDREN, DOMAIN, some time/date ones?

Would be good:

Multi layer transclusion
Not certain about this, but not having it probably causes more problems than having it.
More flexible scripting for complex templates
The only really good implementation I know of is Scribunto
MW got by with parser functions for a while. It worked, but it was ugly and terrible. Maybe a with some thought a parser function like solution could be made less bad.
A wider collection of magic words

Wishlist:

Use the structured data stored in templates to improve search
Allow in-page display of structured data, like SMW's Inline Queries

Eric Bruylant

(This part was written first, but the conclusion/outline seemed more valuable than this background thought) I realized why I'm struggling to come up with good ideas for this one: I only really know much about MW's system.

So, did a bit of research into how it's done on other software. They mostly do similar things, and all major wiki software includes some form of templating, but many have different takes on the core idea (e.g. Cofluence is clearly optimized for non-technical users).

Misc thoughts/findings:

Some wikis have non-global templates.
This seems mostly bad. It would allow short domain specific templates, but having the same text display differently seems like a much worse problem
However, it does bring up the question of how to handle templates between subdomains. Probably allow templates from the main arbital repository to be called from private groups, with slightly different syntax (a ! at the start of the name or something)?
Templates are generally stored separately from pages, but often use the same edit interface.
Most wikis allow multiple layers of transclusion.
This can be very useful for maintaining consistency and ease of template creation, but can also lead to unreadable mazes with 8 layers of template which are inefficient to unpack every time a page is served (MW gets around this through extensive caching).
- There are several different attempts to make templates more user friendly. The main approach is having a flexible form which allows you to input variables, rather than doing it directly as text.
The variables are usually stored in page text, but they could be stored separately.
In text has the advantage of being editable from the normal edit window, but the disadvantage of having a lot of scary visual clutter at the top of edit windows (a lot of users would get put off by this, for example).
Separately has the advantage of having structured information stored in a form which invites complex searching and analysis, and would work by having templates show up differently in the edit window, with the option to click on them to edit their variables via popup form.
I suspect separate storage is significantly better, but requires extra UI work. Wikimedia's use of Wikidata rather than adoption of SMW and their creation of the TemplateData extension both feel like attempts at approximating the advantages of it, patching over a bad design decision which got baked in.

Some other links: