Module talk:Params

New function self

I have added a new function to the module, {{#invoke:params|self}}, however I am not sure whether the most idiomatic name for it is self or title (especially considering that self has a special meaning in Lua). --Grufo (talk) 00:36, 27 September 2023 (UTC)

@Grufo: I would prefer a different naming. Based upon magic words like {{PAGENAME}} and friends, things along the lines of PARENTNAME, TEMPLATENAME (sadly we already have a {{TEMPLATENAME}} with a slightly different meaning), INVOKERNAME or similar come to mind, along with the possibilites of things like CHILDNAME, MODULENAME, INVOKEENAME or similar; potentially with modifiers for other encodings a la {{PAGENAMEE}} and comparison of page title encodings, etc. (e.g., by returning mw.title:partialUrl() or similar), not to mention other options in line with things like {{FULLPAGENAME}}, {{FULLPAGENAMEE}}, etc. That said, perhaps those names are not really the best either and it would be better to stick to naming closer to Scribunto naming along the lines of parentPageTitle/modulePageTitle and stick to modifiers provided by mw.title object and/or mw.url API like partialUrl, queryEncode, pathEncode, wikiEncode, anchorEncode. Incidentally, I have often considered developing a Scribunto replacement for base (or even all the extensions in the default and/or WMF MediWiki packaging) magic words and then potentially extending it from there. This begs the need for these types of things more generally but I digress. —Uzume (talk) 19:51, 6 March 2024 (UTC)

@Uzume Sorry for my very late reply. Your suggestions would be {{#invoke:params|INVOKERNAME}}, or {{#invoke:params|CHILDNAME}}, or {{#invoke:params|MODULENAME}}, or {{#invoke:params|INVOKEENAME}}. These would break the convention used for function names in this module, and also would not be so immediate to understand (i.e. if template {{foobar}} invokes this module I would expect “INVOKENAME” and the other names you propose to return Module:Params instead of foobar). There is a convention used by many programming languages according to which the parameter zero is the name of the routine executing the code (e.g. in Bash $1, $2, $3, … are the parameters, whereas $0 is the name of the script or the name of the subroutine, much like our {{#invoke:params|self}}). However in these languages parameters can only be non-zero positive numbers, whereas in template syntax 0 can also be a parameter name (e.g. {{foobar|0=hello|1=world}}), so another solution needs to be found. There used to be an arguments.callee property in JavaScript with a similar meaning, but today is deprecated, and if we named our function {{#invoke:params|CALLEENAME}} I believe it would create confusion in redirected templates. The name “self” is what for me comes the closest to “parameter zero” in those languages that use the latter for the same purpose. And so “self” inside {{foobar}} is foobar. --Grufo (talk) 19:20, 22 May 2024 (UTC)

@Grufo: To me self tends to lend its meaning from Lua in much the same way as as this does in C++, namely an object reference (although in C++ these are always class-based and in Lua they do not have to be as they could be prototype-based, etc.). It is true that in MW "title" has several meanings but its most common meaning is a textual name of a page, that said I would try to avoid it based on things like Manual:Modeling pages. That said page "title" and PAGENAME tend to be the name of a page without a namespace, as opposed to frame:getTitle() and FULLPAGENAME, etc. You asked how people felt about the naming of the current self invocation target and though I am not a fan of "self", I do think it is better than anything with "title" in its name. —Uzume (talk) 10:16, 23 May 2024 (UTC)

It's true I asked, but my concern was not about how understandable the term is, but about the fact that “self” has a peculiar meaning in Lua. And although this still holds true, it is also true that this module is not meant to be called by other modules (i.e. it is not meant to be used in Lua), but it is meant to be called by templates, where “self” has no special meaning whatsoever (plus, template writers are required to know nothing at all about Lua, and maybe one day modules will be written in more languages other than Lua). And even if a template writer knows about Lua, self would still make sense (i.e. the “Lua-style self from the point of view of a template is the template itself”). If you mention words that are already in use, they would carry the reference they currently have (e.g. “title” would refer to the transcluding page, not the transcluded template), so we do need to invent new words that carry no references, since no magic word or template currently offers the same functionality. For me the only possible contender would be callee (but see what I wrote earlier about the case of redirected templates). --Grufo (talk) 10:42, 23 May 2024 (UTC)

Be verbose to avoid any confusion, it costs you nothing. How about calling_template_name? 68.199.122.141 (talk) 11:20, 23 May 2024 (UTC)

But that would be very confusing! This function is meant to be used in transcluded templates (otherwise one uses{{FULLPAGENAME}}); and if template {{foo}} calls {{bar}}, and the latter contains {{#invoke:params|self}}, we get bar, which is the called template, not the calling template (which instead would be foo – of course, technically the called template is also invoking a module, but users need to know nothing about Lua and modules for using {{#invoke:params}}). It is not a coincidence that in JavaScript the same functionality was called arguments.callee (and not arguments.caller – but again, “callee”/“called” create confusion in redirected templates). --Grufo (talk) 13:08, 23 May 2024 (UTC)

In your example, template {{bar}} is calling {{#invoke:params|self}}, so {{bar}} is the calling template (of your function), and its name is calling_template_name. It could be this_template_name as well. The word 'self' is usually used for the very object (with methods and stuff), not only its name. 68.199.122.141 (talk) 13:39, 23 May 2024 (UTC)

this_template_name would also be possible. Let's see if others prefer it to self. Contra: although the funcion is meant to be used in templates, nothing forbids to use it in non-transcluded pages, wehere there is no such thing as “this template”; or imagine the page Template:Foobar/doc using this_template_name for referring to itself instead of the actual template it is documenting (i.e. Template:Foobar – that would also create confusion with {{TEMPLATENAME}}). --Grufo (talk) 21:09, 23 May 2024 (UTC)

this_function_caller, I don't think it can be more precise; self, though, is a bit confusing when a page transcludes a template invoking a template invoking the function, or any such mumbo jumbo. 68.199.122.141 (talk) 22:50, 23 May 2024 (UTC)

I cannot say I like this_template_name. Without doing strange manipulations like frame:newChild, etc. the parent frame should always be the frame that calls #invoke. Even when frame:callParserFunction('#invoke', ...) is called this is normally true as it will either refer to the calling module or if specifically called off the parent frame, the invoker's invoker frame (i.e., a grandparent but the actual invoker frame is hidden then). This is why from the Lua standpoint something like parent_fullpagename probably makes the most sense, however, as you said this is designed to be understood from the template or parent's point of view (the users of which should not need to understand Lua, etc.) and as such there are way too many confusing page names to begin with. To that end, I still like invoker_fullpagename. full should probably be included as FULLPAGENAME includes a prefixed NAMESPACE as this function also returns. If you really like the caller nomenclature then how about module_caller_fullpagename and if you really like the this, how about this_module_caller_fullpagename. —Uzume (talk) 15:06, 11 July 2025 (UTC)

FYI: {{#invoke:TEMPLATENAME|main}} now does this same thing too but I am not a fan of its naming either. I personally believe names like template_name or module_name should be considered in situations where they are made to be used with msg: or #invoke:, i.e, the namespace is not prefixed for template or modules but it is otherwise, including for the empty main namespace (for example when you want to transclude a main space page and need syntax like {{:mainspacepage}} or {{msg::mainspacepage}} but you don't need such for Template and in a similar fashion you don't need Module for #invoke:. This is exactly what things like {{TEMPLATENAME}} do because they are designed for constructions like {{{{TEMPLATENAME}}|...}} (in this case typically from a /doc subpage but one wants it to also render properly from the main template and/or its /sandbox subpage, etc., i.e., everywhere /doc is transcluded from). —Uzume (talk) 15:06, 11 July 2025 (UTC)

Wrapper template with pass-thru params

I'm a template writer and have newly discovered this Module, and am still getting on board with it, but have not used it yet. I think it probably will handle some use cases I have, but I'm not quite sure. One case that is typical for me, is a wrapper template with "pass-thru params", that is, the case of a wrapper template A, that calls template B passing thru all or almost all of A's params to B without alteration, and one or two more params with hard-coded values. For a concrete example, consider template {{sfnlink}}. I want to create new wrapper template {{sfnlinknb}}, that will have the identical params that sfnlink has, less param |nb=; the job of the wrapper, is to pass through all of its params to {{sfnlink}}, and add |nb=yes as well. The "pass-thru" part of this seems like the kind of thing I ought to be able to do with Module:Params, but I'm not quite sure. Maybe using for_each? Thanks, Mathglot (talk) 00:09, 3 December 2023 (UTC)

It looks like you have a working implementation using double transclusion and for_each in {{sfnlinknb}} already, but if it's useful as an alternative approach, I just used concat_and_call to do the same thing in {{autnum plain}}: Special:Diff/1188117126. DefaultFree (talk) 13:26, 3 December 2023 (UTC)

DefaultFree, thank you so much for this. Your solution is infinitely better, and I've rewritten my wrapper using your idea. I had made multiple attempts—you can see the numerous failures at the history of User:Mathglot/sandbox/Templates/params_for_each and at Template:Sfnlinknb. At one point, I thought I had it because it worked perfectly at Special:ExpandTemplates, but then I found it didn't work anywhere else—it spit out the correct code (as if it were nowiki'ed), but didn't invoke it, except at ExpandTemplates, for some reason. Then I went off on a tangent, trying to add {{Eval}} in front of the whole thing to get it to execute, and as you saw, I got tangled up in double transclusion, and, oh, what a mess! Yours is so much better, and would make a great addition to the documentation of this Module, either as an example, or as a "Pro tip" note. (You might be interested to see what I did with the (on-page) /doc, the /sandbox, and the /testcases pages for {{Sfnlinknb}}.) Thanks again, and I owe you one! Mathglot (talk) 22:29, 3 December 2023 (UTC)

15th January 2024: New changes

The Module:Params/ChangeLog subpage now keeps the record of the most important changes in the module's code. Furthermore four new modifiers – mapping_values_by_calling, mapping_values_by_invoking, mapping_values_blindly_by_calling and mapping_values_blindly_by_invoking – were recently added to the module. These allow to pass each argument one by one to a custom template or a custom module in order to be preprocessed before further actions. --Grufo (talk) 04:07, 15 January 2024 (UTC)

growth and sandboxes

Hi @Grufo: - following on from your request over at WP:PERM. Got a few questions:

1. Do you know what has recently caused the large growth in calls to this module? Is such a large use necessary?
2. This module doesn't appear to have a /sandbox; now that it is so heavily used where are changes being validated prior to deployment?

Thanks, — xaosflux ^Talk 13:34, 22 April 2024 (UTC)

xaosflux, the drastic usage increase looks to be due to Special:Diff/1214727698. Primefac (talk) 13:42, 22 April 2024 (UTC)

Numbers should start falling, I've undone the above. Primefac (talk) 13:50, 22 April 2024 (UTC)

FYI to @Uzume: — xaosflux ^Talk 14:19, 22 April 2024 (UTC)

@Xaosflux: Thanks for the heads-up. I just fixed a minor documentation bug. Using something like this module insulated it from potential moves (or someone copying it for as a template, etc.) but there are obviously other ways to fix that issue and I certainly did not mean for it to have such ramifications (I would not want to prevent the author from development; the sandbox still allows such if somewhat more cumbersome). —Uzume (talk) 14:31, 22 April 2024 (UTC)

Hi Xaosflux. I have no idea. I tried to find out, but I believe that whoever is responsible for the growth did not follow the suggestion of adding {{Lua}} to the documentation of the templates that start using this module. So finding out where all the calls come from is hard (btw, someone has to improve the “What links here” special page and allow to list direct transclusions only…). I had planned some important improvements for this module, but I have been very busy in the last months. And as soon as I had a bit of time for the module I found out that I can no longer edit it. Concerning the sandbox: it's not hard to create one, is it? So far every time I posted an update I tested it locally on my machine, but I agree that it would be good to have a sandbox here too. EDIT. Primefac gave the answer while I was writing mine (@Primefac: Thank you). --Grufo (talk) 13:48, 22 April 2024 (UTC)

Always happy to help. For the record, I used an insource search to find where it was being invoked, specifically insource:/invoke:params/, as seen here. Primefac (talk) 14:19, 22 April 2024 (UTC)

I've lowered the protection level on this, you should be able to edit again. Suggest you build up a sandbox and incorporate it to the testcases. — xaosflux ^Talk 14:21, 22 April 2024 (UTC)

Thank you both @Primefac and @Xaosflux! The next changes in the code will pass through a sandbox. --Grufo (talk) 14:30, 22 April 2024 (UTC)

Ready for general use

Improvements are always possible, but I believe time has come to mark this module as ready for general use. --Grufo (talk) 18:52, 22 May 2024 (UTC)

Inverting parameters

At {{WP:RSPUSES}}, I needed not |1=key|2=value but |1=value|2=key. I achieved this with {{#invoke:params|sequential|mapping_by_calling|duses|values_and_names|setting|i|<br>|list_values}} when call_for_each didn't work. Are there plans to add a shortcut like call_for_each_value_and_key? 174.92.25.207 (talk) 21:56, 4 July 2024 (UTC)

You followed exactly the right way. There are no plans to create a call_for_each_value_and_key function, because that will mean that we will have to create also an invoke_for_each_value_and_key function, a magic_for_each_value_and_key function, a call_for_each_key function, and so on. This module is already quite rich in functions; if new functions will be added in the future it will probably be to add new functionalities, not just syntax sugar. --Grufo (talk) 00:56, 6 July 2024 (UTC)

Code link on mobile

@Grufo: Are you aware that the mobile view looks like this?

----------------------------------------
|               Function               |
| |----------------------------------| |
| |              count               | |
| |----------------------------------| |
|                  (                   |
|                code                  |
|                  )                   |
| Num. of arguments 0                  |

instead of the proper desktop view like this?

              |-----|
     Function |count| (code)
              |-----|
--------------------------------
| Num. of    0                 |
| arguments                    |

Ideally the entire header should be on the same line like on desktop. But the parentheses in the code link are currently a monstrosity on mobile. 174.92.25.207 (talk) 06:03, 8 July 2024 (UTC)

@174.92.25.207: Thank you. I think the quirk is too infobox-specific to be integrated in the {{./doc/link to the code}} template. However this should fix it. --Grufo (talk) 18:45, 8 July 2024 (UTC)

Minor limitation currently affecting some functions

There is currently a design limitation in the child frame object that affects invoke_for_each, invoke_for_each_value, mapping_by_invoking and renaming_by_invoking. The limitation affects these functions only when used on a large number of parameters (> 99). For more information see:

• Wikipedia talk:Lua/Archive 12 § Editing the args metatable of a child frame
• Topic on Extension talk:Scribunto/Flow § Design problem in the frame object

--Grufo (talk) 20:03, 14 April 2025 (UTC)

@Grufo: It seems like the best solution would be to avoid your current :newChild hacks and instead do actual #invoke: parser function calls via :callParserFunction. That also solves a number of problems with the current solution (besides the 99 frames limit), e.g., the current "invocation" method does not always work correctly for modules that attempt to detect such things (e.g., ones that test their inbound ... to see how the module is being loaded, either as a #invoke: "main" or as a require sub-library module, mw.loadData, etc.). It also allows you to jettison some error code as true #invoke: already throws errors when the function cannot be found, etc. Don't try and reinvent the wheel (I ran into a similar situation with 954154594). It also allows you the ability to potentially consolidate your code as your template call interfaces could be moved from :expandTemplate to :callParserFunction with msg: and both #invoke: and msg: could be implemented with your magic functions which already use :callParserFunction. The invoke function of Module:Lua call is a good example. Most uses of :newChild are typically poorly designed. One probably legitimate use would be to create an artificial parent frame for calling :callParserFunction off of (for modules that look at their parent frame, etc.). —Uzume (talk) 19:05, 9 July 2025 (UTC)

Thank you, Uzume. You make a strong point when you talk about modules that detect whether they have been called via require() or #invoke. I did not even know that was possible (how does one do that?). I have been thinking for a while about replacing :newChild() with :callParserFunction() + #invoke in the functions listed above. I have not done it so far because I was hoping to trigger a rethinking upstream on how :newChild() is currently designed. However no discussions have emerged so far as far as I know (and so maybe now it is the time to get rid of :newChild()). At the moment, when facing the bug described here, it is already possible to use {{#invoke:params|mapping_by_magic|#invoke|...}} instead of {{#invoke:params|mapping_by_invoking|...}} (which is why this did not seem to be an urgent fix). For instance, if we wanted to use {{#invoke:string|replace}} to replace spaces with hyphens in values (and forgetting for a moment that we already have {{#invoke:params|mapping_by_replacing|...}}), we could already do

...|mapping_by_invoking|string|replace|4|%s+|-||false|...

or, equivalently,

...|mapping_by_magic|#invoke|values_only_as|3|let|1|string|let|2|replace|4|%s+|-||false|...

Interestingly, while #invoke is recognized as a parser function, the same seem not to apply to msg, and so it seems not possible to use the latter in combination with :callParserFunction(). In any case, :expandTemplate() seems to work just fine. --Grufo (talk) 11:19, 10 July 2025 (UTC)

@Grufo: I am not sure why msg would not work as a parser function. I wonder if that is also true for msgnw (which is sort of similar to Scribunto mw.title:getContent() because it does not process page source through the main wikitext parser). I wonder if there is an issue with the way you are building your argument list or calling the parser function that is limiting things. —Uzume (talk) 21:29, 10 July 2025 (UTC)

Anyway, I am not sure about all the ways for Lua modules to detect how they are called but one of the primary ones would be to check ... during the execution of the module initialization block (which executes during #invoke before the function call to the its first argument and why it is possible to catch any argument as the function name using a metatable with __index like in Module:Ustring; oddly enough that also means one can process the frame args before the function name is provided to the module but of course nothing can be returned until later). require() passes in the module's name while Scribunto #invoke does not (imitating command line lua but the frame args are not put into ... or global arg so they are always empty/nil; probably because frame args have non-sequential parameter keys). Checking ... can be a good way to have the module return a different package table (often denoted as just p) based upon whether it is loaded via #invoke or not. In fact, that style of coding allows one to do away with the awkward leading underscore API functions and even allows the module to require itself during #invoke thereby using its own API while also providing frame wrapper function(s) for #invoke calls from wikitext. The name of the module used during #invoke is of course provided via frame:getTitle() which can be accessed from anywhere, including the module initialization block, via mw.getCurrentFrame(). —Uzume (talk) 21:29, 10 July 2025 (UTC)

I created an example module for demonstrating how a module can detect how it is loaded at Module:Sandbox/Grufo. Feel free to do with it as you see fit. Notice how your require() plus frame:newChild() implementation likely would not work with that construction but a frame:callParserFunction('#invoke', ...) construction would. You should consider which frame to call that off-of though. Frequently it makes more sense to call that off of the parent so that the new invocation has the same parent as where you call it from (i.e., they are effectively "sibling" invocations) as arguments to your module might not be particularly interesting to the module you are invoking (if they are, you should probably pass them to the module directly via its own arguments) but arguments to the parent template would otherwise be lost (due to frame depth; a module can only access its frame and one parent—no grandparents, etc.). I am not sure if it matters which parent frame is available for other parser functions/magic words but I encourage you to consider using frame:callParserFunction() from the parent frame. —Uzume (talk) 21:29, 10 July 2025 (UTC)

FYI: another little known fact is that Scribunto has translations of #invoke so such can actually be accessed via alias keywords on for example a Korean or Russian Mediawiki, etc.; that makes it pain to search for all such invocations of a module but luckily few people know and use aliases. —Uzume (talk) 21:29, 10 July 2025 (UTC)

Hi Uzume. Thank you for the sandbox module. I think I understand now. As for msg, you can check yourself:

• {{if|eq|a|a|x|y}}

  ↳ x

• {{#invoke:params|new|concat_and_call|if|eq|a|a|x|y}}

  ↳ x

• {{#invoke:params|new|concat_and_magic|msg|if|eq|a|a|x|y}}

  ↳

• {{#invoke:params|new|concat_and_magic|#ifeq|a|a|x|y}}

  ↳ x

You can also experiment with a new module and :callParserFunction() to see if there is a problem in Module:Params. But there are no reasons to replace :expandTemplate(). As for replacing :newChild() with :callParserFunction() + #invoke, we need to see if in these language in which they use a local translation of #invoke the English #invoke still works (I think it should). Otherwise this module will become a nightmare to maintain. If the English #invoke does not work we should leave the module as it is and simply warn that in case of > 99 parameters or in case of modules that check how they have been invoked, people should use the local version of {{#invoke:params|mapping_by_magic|#invoke|...}} instead of {{#invoke:params|mapping_by_invoking|...}}. I wonder what the performance difference is between using :callParserFunction() + #invoke and :newChild(). I will run some tests. --Grufo (talk) 15:34, 11 July 2025 (UTC)

@Grufo: I think msg not being recognized as a parser function is likely a bug. The question is where the bug is: your module, the Scribunto extension, MediaWiki proper or some other weird place (i.e., unforeseen interaction somewhere). As shown below, the first argument can cause this error in some cases:

• {{#invoke:params|new|concat_and_magic|canonicalurl|:ja}}

  ↳ https://en.wikipedia.org/wiki/Ja

• {{#invoke:params|new|concat_and_magic|canonicalurl|::ja}}

  ↳

This definitely needs more investigation. I might have to look into that. —Uzume (talk) 16:52, 11 July 2025 (UTC)

Yes, Scribunto ensures #invoke always works even when there are localized alias names. This is in a fashion similar to MediaWiki base namespace names, e.g., Chinese Wikipedia might have another name for Template but that name always works everywhere (even here we have a different base name for the Project namespace but Project still works; i.e. {{ns:Project}} yields Wikipedia and {{ns:Image}} yields File, etc.) they just act like a redirect alias to the localized name. —Uzume (talk) 16:52, 11 July 2025 (UTC)

FYI: Another little known fact is that all Scribunto module pages are in content language English (I am not sure that is really the right choice but I am not planning to fight it anytime soon) even on Mediawiki instances where English is really used nowhere else. As an example, try going to zh:Special:EditPage/Module:Var and type into the debug console: mw.log(mw.title.getCurrentTitle().pageLang.code). You will get: en. —Uzume (talk) 16:52, 11 July 2025 (UTC)

@Uzume: Now I don't have the time to create a test module and check :callParserFunction() with msg. However writing ::ja as argument seems to make the canonicalurl parser function invisible even when called directly (see third example):

1. {{#invoke:params|new|concat_and_magic|canonicalurl|ja}} corresponds to {{canonicalurl:ja}}; the latter yields

   ↳ https://en.wikipedia.org/wiki/Ja

2. {{#invoke:params|new|concat_and_magic|canonicalurl|:ja}} corresponds to {{canonicalurl::ja}}; the latter yields

   ↳ https://en.wikipedia.org/wiki/Ja

3. {{#invoke:params|new|concat_and_magic|canonicalurl|::ja}} corresponds to {{canonicalurl:::ja}}; the latter yields

   ↳ Template:Canonicalurl:::ja

As for moving from :newChild() to :callParserFunction() + #invoke, as soon as I have a moment I will update Module:Params/sandbox and run a few tests. --Grufo (talk) 18:13, 11 July 2025 (UTC)

@Grufo: Yes, that is interesting how the parser decides that syntax could not be a parser function call (because the argument is not a legal pagename?) and then falls back to parsing it as a template invocation of that pagename. The error from frame:callParserFunction() is definitely coming from the Scribunto PHP code but the point you bring up may in fact be related (see below). As memory serves, when the parser is parsing normal wikitext, it handles parser function calls by parsing out the name and the chunk of wikitext to the end of the call (i.e., }}) only separating them out by | and then calling the parser function code itself giving it a chance to "claim" the provided wikitext arguments (which are not yet fully parsed) and the parser function then decides how to parse such (some use the frame parser but many do not, e.g., #switch depends on the order/positioning of its arguments so it cannot use the frame parser and this is also why Scribunto #invoke can never perfectly emulate it) but I believe the parser function can also return to the parser stating it does not claim the provided wikitext arguments and in such a case the parser must march on assuming that it was not in fact a call to that parser function. I believe that is what is happening in your example above. Maybe something similar is happening in the frame:callParserFunction() path. It would kind of make sense there would be no way to actually call the parser function with entirely pre-parsed arguments so that path perhaps reconstructs the pseudo-unparsed wikitext arguments from the provided arguments and passes it to the parser function just as it would during normal wikitext processing. Then if the parser function rejects it, the parser assumes it was not a parser function call and eventually Scribunto yields the error: since there is probably no way to differentiate this from someone trying to call a nonexistent parser function, meaning the "not found" in the error is deceptive and should probably say something more like Maybe this is an issue with the way the pseudo-unparsed wikitext arguments are reconstructed that causes msg, msgnw and raw to always reject the call. There may also be something special about msg and friends as in the history of wikitext parsing it was the first—even before normal template syntax existed and template syntax was implemented as a simplification. I wonder if parsoid has the same issue. —Uzume (talk) 20:17, 11 July 2025 (UTC)

@Uzume: I agree that the error is deceptive. Let me know if you find out more. In the meanwhile I have updated Module:Params/sandbox with a new version that replaces :newChild() with :callParserFunction() + #invoke. It will still require extensive testing. --Grufo (talk) 05:17, 12 July 2025 (UTC)