It would be very useful if Scribunto could have access to the raw string of the calling #invoke (and, ideally, the parent frame template), as it's not currently possible to accurately reconstruct the raw wikitext which generated the frame.args
and frame:getParent().args
tables. Alternatively, access to the raw parameter array would work, too.
The problem I have in mind is English Wiktionary's en:wikt:Template:temp (powered by en:wikt:Module:template link), which is used to generate wikitext-style template/magic word links for documentation and discussions. Since the input can't be reconstructed, it has to normalise based on various assumptions, which sometimes leads to bad results:
- The template/magic word being parameter 1 leads to an unsolvable offset issue (e.g. the template call
{{l|foo|bar|4=baz}}
- a very common Wiktionary idiom - would (intuitively) take the input{{temp|l|foo|bar|4=baz}}
, but template link misinterprets it as{{temp|l|foo|bar|baz}}
since it can't know the difference between the fourth implicit argument received and one given explicitly with4=
. This is extremely confusing to a casual user. - Much worse, when dealing with parser functions (which mainly treat their inputs as arrays), the input gets completely garbled: for instance, it has no way of knowing that "qux" must come after "bar=baz" when displaying
{{temp|SWITCH:foo|bar=baz|qux}}
.
There are workarounds to this, of course: we could change the syntax, but this would break continuity with a template that's been around since 2006, and is pretty ingrained to regular users. You can also pass everything under a nowiki tag to parameter 2, which is the only way to solve the SWITCH: issue at the moment, but this is awkward-at-best, unintuitive to most users, and undermines the convenience of the template in discussions.
Having the raw template string would solve all of these issues, with the added advantage of making parameter processing simpler, too.
I don't foresee any obvious security or isolation issues with this, but I'll defer to others on that point.