Topic on Talk:Global templates/Proposed specification

This long proposal, most of which I wrote, does not currently fully and precisely address a rather important issue: What does the mechanism that delivers the template from the repository to the local wiki actually deliver—the template's code or its output? The same question also applies to modules: should the Lua code of a global module run on the repo or on the local wiki?

I don't know nearly enough about the intricacies of template parsing and context and about Lua evaluation. But it will be necessary to decide about these things sooner or later, so I need professional help :)

What makes sense to me is that the code should be delivered and parsed on the local wiki, although I might be missing something. This way it will probably be easier to parse it on the local wiki and check whether local version of templates transcluded within this template need to be loaded, and to parse magic words in local context.

Since I am really not an expert on how this works, it's quite possible that I'm totally wrong about this, and that maybe they should be at least partly parsed on the repo.

Any thoughts?

Tagging some people who may have an idea; feel free to ignore if you're busy with something else :)

@DKinzler (WMF), @SSastry (WMF), @TK-999, @Tacsipacsi, @ערן, @Yurik, @Brion VIBBER.

(Originally, this post was much longer and detailed my naïve thinking process, but then I decided to just write that process' result. If anyone is interested for some reason, I can post the rest, but it's not really exciting.)

Use the same as Commons and Wikidata. Output can be translate to several languages using Mediawiki translation tolls (see how pages are translated in Mediawiki site ).

This is completely irrelevant here. The translation tools on Commons, Wikidata and MediaWiki.org deliver neither the code nor the output—they’re not global.

The current wikitext model requires the processed template output (= wikitext) to be merged into the top-level page before the output of the full page is converted to HTML. This is the preprocessing model where a transclusion ({{some-tpl|..args..}}) is evaluated. This preprocessing will fetch other templates where necessary, and so on recursively. I should go look at the code to be sure, but in the current model, every one of these template fetches will be resolved to a target. And, so if template target resolution goes through a global template repository, then it is likely every recursively referenced template will be impacted by that. An alternative model of course is to change the code so that during template preprocessing, all template references resolve on the local wiki where the top-level template target resolves to.

<tangent>Parsoid is eventually trying to get to a model where a transclusion is processed independent of everything on the page and so the output of the transclusion is always HTML / DOM (or if we are able to arrive at typed templates, then it will be some typed value, with the default being HTML/DOM always). In addition, we are trying to get to a place where Parsoid doesn't care what component generated it as long as the types match up. So, both the above preprocessing systems would be compatible with Parsoid. And, at some level, extension are no different than templates in that regard. Everything produces a typed value. So, you can build whatever transclusion system you want as long as you adhere to the type contract. Getting to this point is a bit slow since we are still trying to get to Parsoid being the only wikitext engine.

For example, Scribunto could be considered to be a different templating model from the native wikitext templating model. They look the same on the surface because editors have adopted a mechanism where the module #invoke calls are hidden behind a typical wikitext transclusion.

So, from the ideal Parsoid POV, the qn. of global templates vs local templates or some-other-form-of-templates is an implementation decision of the implementor and they can all coexist as long as they can be appropriately namespaced / disambiguated. But, of course from a product POV, wikis might choose to pick a single mechanism.</tangent>

Hope that helps.

It helps. I wish it be adopted soon for global templates and global template repository 👏🏼👏🏼👏🏼👏🏼