Mailing List Archive

the parts of a template
Hallo.

What are the parts of a template?

When templates started in 2003 or 04, they were just simple pages, whose
content you could add ("transclude") to multiple other pages.

Over time they acquired more features: noinclude, includeonly, onlyinclude,
parser functions, documentation pages, TemplateData, Scribunto,
TemplateStyles, and more.

If we now take a look at the parts from which a template is built, what
will we identify? I'm not talking just about the technical parts, i.e. how
the parser sees it, but also about the functional parts—how the template
maintainers and users perceive it.

Here's what I can think of:

* The body: The content that is actually inserted into other pages. This
can be further divided into text, formatting, images, and logic using
parser functions and invoked modules, but for the sake of parsing it's
probably one blob of wikitext, but do correct me if I'm wrong. Sometimes,
but not always, appears in <includeonly> or <onlyinclude>.
* The documentation: As a separate page (Template:Name/doc), as some
content in <noinclude>, or a mix of both.
* The categories: Self-explanatory. Usually in <noinclude>.
* TemplateData: Usually in a <templatedata> tag on the template page
itself, or on the /doc page.
* TemplateStyles: On a separate page with a different content model, and
linked using <templatestyles> tag. One TemplateStyles page can serve
several other pages, so it's autonomous and modular.
* Testing pages: A few complex templates also have testing or sandbox
pages. I'm familiar with some examples, such as
https://en.wikipedia.org/wiki/Template:Infobox_philosopher/sandbox , but
I'm not an expert on how consistent it is. It's probably not right to call
it a "part" of a template _technically_, but it's closely related to it, so
it can be considered a _functional_ part.

A couple of comments:
1. I mostly deal with Wikimedia use cases. Comments from other wikis are
welcome, too—SMW wikis, your enterprise wiki, Fandom, other farms, etc.
2. I intentionally don't include in this list other templates and Scribunto
modules that a template transcludes or invokes. It's very common, but these
are autonomous. (I do include TemplateStyles, which can also serve several
pages, and maybe I should exclude them, too).

So, two questions:
1.Does it make sense generally?
2. Am I missing anything?

Thanks :)

--
Amir Elisha Aharoni · ?????? ????????? ??????????
http://aharoni.wordpress.com
?“We're living in pieces,
I want to live in peace.” – T. Moore?
Re: the parts of a template [ In reply to ]
> On Jun 14, 2021, at 10:13 AM, Amir E. Aharoni <amir.aharoni@mail.huji.ac.il> wrote:
>
> I'm not talking just about the technical parts, i.e. how the parser sees it, but also about the functional parts—how the template maintainers and users perceive it.

I know this is a bit of a tangent, but since you mentioned parsing, I'd like to go off in that direction. The way parsoid represents a page is a mix of HTML and json (RDFa), with the template details being in the json parts. There are good tools for processing HTML documents and searching for specific nodes based on the tree structure. While there are tools for working with RDFa, it's a much sparser ecosystem (see https://rdfa.info/tools <https://rdfa.info/tools>). As far as I know, there are no tools that let you do queries like:

Find all the xyz templates with a foo=bar attribute that exist inside a <div class="blah">

because that crosses between the HTML and RDFa domains. Writing such a query is easy with many existing tools that use either XPATH or css selector syntax.