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
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.
wikitech-l@lists.wikimedia.org