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.

More hooks from articles

Not just "the data object for an article" and "the code module for an article" but also "the layout" for an article -- and make this extensible! In some sense this is what "subpage" is for, but I want better UX and tabs and maybe orthogonal axes, although we can get pretty far with [[ArticleTitle/code/doc/es]] (the spanish translation of the documentation for the code module for article ArticleTitle). (Isn't this just Multi-Content Revisions?)

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.

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}}}}