Topic on Extension talk:Scribunto

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 with 4=. 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.

@Theknightwho Wikipedia's Template:Tlx (also present here at MediaWiki) has a similar functionality, and gets used all the time with complex arguments.

My solution for the SWITCH example you posted would be to call it as:

• {{tlx|SWITCH:foo|bar{{=}}baz|qux}} which produces: {{SWITCH:foo|bar=baz|qux}}.

Ditto the previous example:

• {{tlx|l|foo|bar|4{{=}}baz}} => {{l|foo|bar|4=baz}}.

Using {{=}} to turn named parameter assignments into positional parameters is a well-worn aspect of using template-linking templates that most Wikipedians seem to adopt pretty quickly, and which doesn't seem all that onerous.

The other issue is, if Wiktionary's en:wikt:Template:temp is anything like {{Tlx }}, it probably has a lot of parameters of its own, that it has to differentiate from the arguments to the linked template. I'm not sure how handing the module all of its parameters unparsed would make parameter processing simpler, because now it would have to do all of the processing to consume its own arguments. It feels like ultimately making one thing perhaps a bit easier, by making a lot of other stuff much harder.

@FeRDNYC So we've intentionally avoided giving it any parameters to avoid this issue, though we've never had any need for them anyway (with one exception, but en:wikt:Template:tempn fills that niche, which is the same but doesn't wrap the output in <code> tags).

The workaround you suggest works fine, and it's what people do, but I was just hoping we could make things a bit more user-friendly.

You make a good point about processing unparsed parameters, but what I didn't mention (though perhaps should have) is that we at Wiktionary have en:wikt:Module:template parser for that kind of thing, which abstracts away all the complexity of parsing raw template code.

However, I'm not sure it'd be necessary to do all that, as it would make more sense for the raw arguments to be given as an array. A PHP version of that array is actually what Scribunto uses to construct the argument table in the first place, so it shouldn't be too complex to make it available in Lua as well, which would mean no raw template parsing is necessary.