User:Cscott/Ideas/A Plan for Global Templates

Apologies if you can here via a link which promised "some of my own ideas": this is a work in progress, and more of a collection of outline topics and notes-to-self than a coherent proposal for now. But if you're interested, contact me and I can probably spin these into a proper proposal.

Desiderata

Separating code from data from content

ref previous talks, ArrayFunctions
a composable type system for transclusions
try /not/ to generate HTML fragments directly from (eg) wikifunctions, but instead to generate a /data context/ from code, which is then formatted into HTML using a template system that allows separation (and editing) of the layout independent of the computation.

Everything localizable

ref previous talks, babeljs, multilingual lua
But this is also the reason to avoid generating HTML directly from wikifunctions/scribunto: the layout is part of localization.

Remove one to add one

Any new template mechanism must be powerful/compatible enough to completely replace one of our four-ish existing mechanisms. We can't just keep building new things, we must provide some transition mechanism (build incrementally, or provide translators, or...) that would prevent this from just adding "one more (unmaintained) template mechanism" to MediaWiki.

Fragment composition and memoization

Composition *should not* be turing-complete! (But it's so easy to make a turing-complete system without trying hard...)

Each fragment renderer should be able to register dependencies in a uniform manner, aka generate an appropriate hash key for memoization; also register time-dependency, indeterminancy, etc. WRT args and return types of fragment generators, see below.

Types

Regarding the four "types of types":

One of our composition types will probably be "a wikifunction type" with an appropriate Z id. This more-or-less corresponds to a "programmer type" like string, int, etc.
We will inevitably require some sort of "HTML tree type", roughly corresponding to the insertion modes of the tree building spec, but ideally this will be the domain of the "template with data context" layer, not directly exported from (eg) parser functions.
TemplateData will also need to know about any types introduced here, so {{#function}} may take an argument of a wikifunction type, or a Q id, etc, and VisualEditor should be able to present a rich input widget for that type.
Q ids will have a type, probably with an optional "refined by" element that will allow a rich widget to select a particular type of Q id from wikidata.

In the near-term, we'll introduce a new "structured argument" type of parser function argument; see below.

Proposals

Translate

UX for translating template information; ie support for TemplateData (and/or wikifunctions or whatever the backend is)

Scribunto

Migration tools from Lua 5.1, starting with a parser (2024 update: I have a parser now)
Prototype "localizable lua" (2024: I've begun a prototype)
Prototype "visual scribunto"
- Separate tabs for "code", "doc", "data", "layout", etc.
"Selectable runtimes"
one-click export from scribunto to wikifunctions (or to lua 5.3 or to localizable lua, etc)

TemplateData

parser function/extension unification (also: input/output types!)
prototype embedded semantic data

Core

unified Template UX w/ subpages
Versioning: "import from git" or "automatically import from git" (see also Synchronizer)
Add new SFD_STRUCTURED_ARGS type for parser functions. This accepts as parameter and returns as result a more-or-less opaque Arg type with toString and toJsonArray methods.
- The toJsonArray method should return a pretty flexible associative array with a _type_ (or @context, or...) property at top level. We can incrementally extend the set of types supported, to support the various types described above; but the primary initial goal is that we don't stringify the opaque type unnecessarily if you compose fragments, eg {{#function:foo|{{#function:bar}}}}