Independent of whether wikifunctions usage in wikitext is going to be a parser function or an extension tag, we want to ensure that clients (specifically editing clients like VE) can easily identify wikifunction markup so as to provide dedicated editing support for their usage.
Context: Parsoid's current HTML spec doesn't have any special support for parser function markup -- they are currently represented with a "mw:Transclusion" typeof attribute with the data-mw attribute embedding the knowledge of the parser function deep inside the attribute. Since we cannot reasonably change this representation without a breaking version change, it makes more sense to use his opportunity to prototype a better representation for parser functions that we can migrate everything over to at a future date.
Current plan, as of 2025-03-17:
| Before: Attribute/sub-value (jq notation) | Before: Value | After: Attribute | After: Value | Change |
|---|---|---|---|---|
| typeof | mw:Transclusion | typeof | mw:Transclusion mw:ParserFunction/padleft | Add mw:ParserFunction/key with the key being the message key for the parser function name |
| data-mw.parts[0].template.target | {"wt":"padleft:xyz","function":"padleft"} | data-mw.parts[0].parserfunction.target | {"wt":"#padleft","key":"padleft"} | template -> parserfunction ; function -> key; wt has zeroth param moved out |
| data-mw.parts[0].template.params | {"1":{"wt":"4"},"2":{"wt":"-"}} | data-mw.parts[0].template.params | {"1":{"wt":"xyz"},"2":{"wt":"4"},"3":{"wt":"-"}} | Zeroth param in wt is now first param, others renumbered |
Note also that the data-mw.parts[0].parserfunction.target.wt value will have the # included iff the original wikitext did, but the key is the magic word ID and will never have a #.
- Add support for generating the new format in Parsoid
- Add mechanism for parser functions to register that they want this new format
- Add support in Wikifunctions's VE integration to read/write the new format
- Switch Wikifunctions's code over to the new format