Module talk:Template wrapper

using positional parameters

This module was initially written so that positional parameters in the wrapper template are not passed on to the working template. That's fine for templates like the cs1|2 templates because they do not use positional parameters but is problematic for templates like {{ERIC}} which wraps {{Catalog_lookup_link}}.

So I've invented a new parameter for Module:template wrapper: |_pass-all= which when set to yes in the module {{#invoke:}} causes the module to pass all wrapper-template parameters except those listed in |_exclude= to the working template. Here is {{ERIC/sandbox}} which uses Module:template wrapper/sandbox with |_pass-all=yes to wrap {{Catalog_lookup_link/sandbox}} which invokes Module:Catalog_lookup_link/sandbox:

{{ERIC/sandbox|ED046562|EJ671671|url-access=free}}

ERIC ED046562, EJ671671

Here is {{EFloras/sandbox2}} which uses Module:template wrapper/sandbox without |_pass-all= to wrap {{cite web}} which invokes Module:Citation/CS1. Positional parameters are used by {{EFloras}} and not passed to {{cite web}}:

{{EFloras/sandbox2|1|233501007|Quercus alba |volume=3 |first=Kevin C. |last=Nixon | access-date = 18 August 2018 }}

Nixon, Kevin C. (1997). "Quercus alba". Flora of North America North of Mexico (FNA). Vol. 3. New York and Oxford. Retrieved 18 August 2018 – via eFloras.org, Missouri Botanical Garden, St. Louis, MO & Harvard University Herbaria, Cambridge, MA. {{citation}}: External link in |via= (help); Unknown parameter |editors= ignored (|editor= suggested) (help)CS1 maint: location missing publisher (link)

Compare the live {{Efloras}}:

{{EFloras|1|233501007|Quercus alba |volume=3 |first=Kevin C. |last=Nixon | access-date = 18 August 2018 }}

Nixon, Kevin C. (1997). "Quercus alba". In Flora of North America Editorial Committee (ed.). Flora of North America North of Mexico (FNA). Vol. 3. New York and Oxford: Oxford University Press. Retrieved 18 August 2018 – via eFloras.org, Missouri Botanical Garden, St. Louis, MO & Harvard University Herbaria, Cambridge, MA.

What have I missed?

—Trappist the monk (talk) 11:29, 19 August 2018 (UTC)

Unless I'm misunderstanding something, the below looks like it will add all the positional pframe_args regardless of |_exclude= or unset.

	if pass_all then
		for i, v in ipairs (pframe_args) do
			add_parameter (i, v, args, list);
		end
	end

I think the below would do what you intend.

local function pframe_args_get (pframe_args, args, exclude, pass_all, list)
	for k, v in pairs (pframe_args) do
		if (pass_all or type (k) ~= 'number') and not is_in_table (exclude, k) then	-- do not pass along excluded parameters
			if v and ('' ~= v) then													-- pass along only those parameters that have assigned values
				if 'unset' == v:lower() then										-- special keyword to unset 'default' parameters set in the wrapper template
					v = '';															-- unset the value in the args table
				end
				add_parameter (k, v, args, list)									-- add all other parameters to args in the style dictated by list
			end
		end
	end
end

It might make more sense to use |_pass_positional= instead of |_pass-all= since |_exclude= still applies. frame_args_get should also be adjusted so that the new parameter isn't passed. — JJMC89 (T·C) 18:11, 19 August 2018 (UTC)

I did not intend that positional parameters should be excludable. Perhaps they could be but how is that properly handled? If we pass {{{1}}} and exclude {{{2}}} what do we do with {{{3}}} et seq.? Does {{{3}}} become the new {{{2}}}? I just didn't want to venture along that cow track until there is a demonstrated need to go there.

I didn't consider the possibility of a positional parameter having the unset value. I'll fix that.

Using ipairs() as I did ensures that empty positional parameters are passed along to the working template. In the pairs() version, the if v and ('' ~= v) then prevents empty positional parameters from being added to the args table.

I overlooked adding |_pass-all= to frame_args_get(); I'll do that. As you can see I was not very successful in finding a good parameter name. |_pass-all= is the shortest I could come up with and was, I felt, marginally better than |_pass-positional= which I felt implied 'only' but was shorter than |_include-positional= which was the best in terms of describing what it does at the expense of length; I was hoping for a single word but was unable to find one that is suitable. I'll change to |_include-positional=.

—Trappist the monk (talk) 21:29, 19 August 2018 (UTC)

I misunderstood your comment in the module then. Let's not let positional parameters be excluded with |_include-positional=; I agree it would be difficult to properly handle. I made this edit. I think the sandbox looks good now. — JJMC89 (T·C) 21:53, 19 August 2018 (UTC)

Yeah, we edit conflicted over that. I've updated the live module.

—Trappist the monk (talk) 22:36, 19 August 2018 (UTC)

@Trappist the monk: Potentially a dumb question, but is there a way to pass all but one positional parameter? I tried a bunch of ways to exclude positional parameter "1" in Template:Multiref2/sandbox before reading this discussion. If there's not a clean solution, I'll leave it as is. Rjjiii (talk) 02:39, 12 July 2023 (UTC)

I don't think so. But why would you want to? Positional parameters have meaning so suppressing {{{1}}} in the call to the working template 'bumps' the subsequent positional parameters: wrapper template {{{2}}} becomes working template {{{1}}} and so on. For {{multiref2}} that doesn't much matter but for other templates it can make a hash of things.

I think that you will need to make a very strong case for a modification to this module.

—Trappist the monk (talk) 13:07, 12 July 2023 (UTC)

Gotcha, I'm not asking for a modification, just making sure that I understand how the module works. Rjjiii (talk) 19:20, 12 July 2023 (UTC)

An additional follow-up: On second thought, it made more sense to style the first positional reference rather than filter it out. Disregard my confusion above. Rjjiii (talk) 06:48, 16 July 2023 (UTC)

support for aliasing and parameter name reuse;

I have added code so that the wrapper templates can support parameter aliasing and same-name reuse. Also updated the documentation. Existing applications should not notice the change. But, famous last words, those, report anomalies here.

—Trappist the monk (talk) 13:46, 17 November 2018 (UTC)

_substall

@Pppery: If you are going to make changes to this module, please document those changes both in the code and in the doc page.

Please explain this:

if mw.isSubsting() and frame.args._substall == "no" then
	return require("Module:Template invocation").invocation(template, args)
else
	return frame:expandTemplate {title=template, args=args};				-- render the working template
end

How is the one different from the other?

—Trappist the monk (talk) 19:09, 19 February 2019 (UTC)

One of those actually transcludes the template, whereas the other one returns a wikitext version of the template. The purpose of that edit was, as I explained in the edit summary, to make this module easier to use for substituted templates. To demonstrate this, support you have a template {{X1}}, which contains the code {{#invoke:Template wrapper|wrap|_template=X2|xxx=yyy|_substall={{{_substall}}}|_exclude=_substall}}. If |_substall=no is specified, then substing Template:X1 will produce a transclusion of Template:X2, as opposed to a substitution of Template:X2 which is produced without the _substall param. {{3x|p}}ery (talk) 19:14, 19 February 2019 (UTC)

@Pppery: If you are going to make changes to this module, please document those changes both in the code and in the doc page.

—Trappist the monk (talk) 15:59, 22 February 2019 (UTC)

A substitute option would indeed be really useful. I see your edit summary when you reverted. Are these problems surmountable? — Martin (MSGJ · talk) 12:32, 8 February 2024 (UTC)

Reusing positional parameters

Why doesn't this work?

Code:

{{#invoke:Template wrapper|wrap|_template=IPA|_reuse=1|_include-positional=yes|1=⫽{{{1}}}⫽}}

Markup	Renders as
{{IPA double slash/sandbox|r}}	r

Nardog (talk) 18:00, 29 December 2024 (UTC)

Positional parameters in the invoke are ignored. In this particular example, there are two {{{1}}} positional parameters:

1. {{IPA double slash/sandbox|r}} – r is {{{1}}}
2. {{#invoke:Template wrapper|wrap|_template=IPA|_reuse=1|_include-positional=yes|1=⫽{{{1}}}⫽}} – |1= is also {{{1}}}

Attempting to figure out what an editor wanted when supplying two positional parameters using the same index is not possible with a simple script.

—Trappist the monk (talk) 19:50, 29 December 2024 (UTC)

So what can I do to make the template output essentially the same thing as

{{IPA|⫽{{{1}}}⫽}}

except all other arguments are passed on to {{IPA}}? I thought that was the whole point of _reuse. Nardog (talk) 22:18, 29 December 2024 (UTC)

I confess that I don't understand what is wrong with the current implementation of {{IPA double slash}}. Does it not do what you want it to do?

Because {{IPA double slash}} invokes Module:IPA via {{IPA}}, have you considered adding an exported function to that module that would do what you want and therefore skip the IPA template altogether?

—Trappist the monk (talk) 23:30, 29 December 2024 (UTC)

Forget {{IPA double slash}} exists for a moment. My question stands. Nardog (talk) 23:33, 29 December 2024 (UTC)

Did you try creating a named alias for {{IPA}} parameter {{{1}}}? Sommat like:

1. {{IPA double slash/sandbox|text=r}}
2. {{#invoke:Template wrapper|wrap|_template=IPA|_reuse=text|text=⫽{{{text}}}⫽}}

Insert at line 269 sommat like this:

args[1] = args[1] or args.text;

In my sandbox I wrote #1 above and then tweaked {{IPA double slash/sandbox}} as described in #2 above except that I switched wrap to list. When I previewed my sandbox with the tweaked template sandbox, Module:Template wrapper gave me:

{{IPA|text=⫽r⫽}}

—Trappist the monk (talk) 00:40, 30 December 2024 (UTC)

A little refinement:

1. {{IPA double slash/sandbox|text=r|lang=es}}
2. {{IPA double slash/sandbox|r|lang=es}}
3. {{#invoke:Template wrapper|list|_template=IPA|_reuse=text|text=⫽{{{text|{{{1|}}}}}}⫽}}

the above gave me:

1. {{IPA|lang=es|text=⫽r⫽}}
2. {{IPA|lang=es|text=⫽r⫽}}

—Trappist the monk (talk) 01:28, 30 December 2024 (UTC)

Again, you're not answering my question. Pretend {{IPA}} was interface-protected and no interface admin was around. Now what do I do? Nardog (talk) 01:03, 30 December 2024 (UTC)

I'm not going to play your game; heaping constraint upon constraint feels too much like hostility that I neither need nor want in my life. You asked:

what can I do to make the template output essentially the same thing as {{IPA|⫽{{{1}}}⫽}} except all other arguments are passed on to {{IPA}}?

my previous two posts answered that question.

—Trappist the monk (talk) 01:28, 30 December 2024 (UTC)

That was just an example. My inquiry has been a general one about this module and |_reuse=. Of course anything is possible if you just modify the template being transcluded; that's clearly not what I'm asking, or I wouldn't post it here. So does the module not support what is described in the doc but for a positional parameter? Shouldn't it? Nardog (talk) 01:52, 30 December 2024 (UTC)

I suck at documentation; it is known. Documentation updated to note that |_reuse= is not supported for positional parameters.

—Trappist the monk (talk) 15:35, 30 December 2024 (UTC)

Is it simply not implemented into the module or due to a limitation in Scribunto? Nardog (talk) 07:16, 31 December 2024 (UTC)

Inherit unknown parameter tracking

@Trappist the monk: (or anyone else who can answer) is there a way to use this module to also inherit the Check for unknown parameters? For example if I am looking at {{Infobox chef}} which is a wrapper for {{Infobox person}} do I have to call Check for unknown parameters on Infobox chef or can it somehow be inherited from Infobox person? — Zackmann (^{Talk to me}/_{What I been doing}) 06:36, 24 September 2025 (UTC)

Sandboxen and testcases are your friends. Create a testcase using {{Infobox chef/sandbox}}. In the testcase, include a nonsense parameter. Make sure that {{Infobox chef/sandbox}} does not call Module:Check for unknown parameters. Preview the testcase. What results do you get? Act accordingly.

—Trappist the monk (talk) 13:39, 24 September 2025 (UTC)

@Trappist the monk: thanks for the tip! Surprised I didn’t think of that… Help me understand a bit further? Can you point me to the bit of code that allows for this to be inherited? I’m very curious how it works and how Category:Pages using infobox chef with unknown parameters (0) is actually defined (using my example of {{Infobox chef}}). Looking to learn! —Zackmann (^{Talk to me}/_{What I been doing}) Zackmann (^{Talk to me}/_{What I been doing}) 21:04, 24 September 2025 (UTC)

The wrapper template is {{infobox chef}}. It uses Module:Template wrapper to call the working template {{infobox person}}. Module:Template wrapper passes all parameters given to {{infobox chef}} directly to {{infobox person}} except for |awards=, |prevrests=, |ratings=, |restaurants=, |style=, and |television=. These six parameters are passed to {{Infobox culinary career}} which returns a child infobox which is passed to {{infobox person}} as the value assigned to |module=.

{{infobox person}} knows that it is wrapped by {{infobox chef}} by the value assigned to |template_name= in Module:Template wrapper. This parameter is used to tell {{infobox person}} that it is being called from {{infobox chef}}. In {{infobox person}}, is this in the call to Module:Check for unknown parameters:

...[[Category:Pages using {{if empty|{{{template_name|}}}|infobox person}} with unknown parameters|...]]

Because |template_name= from {{infobox chef}} is not empty, the category for unknown parameters is:

[[Category:Pages using infobox chef with unknown parameters]] → Category:Pages using infobox chef with unknown parameters

Did I answer the question?

—Trappist the monk (talk) 22:01, 24 September 2025 (UTC)

@Trappist the monk: That is SUPER helpful!!! Thank you so much! Really appreciate the explanation. I feel smarter — Zackmann (^{Talk to me}/_{What I been doing}) 22:04, 24 September 2025 (UTC)

Exclude a parameter...

Is there a way to exclude a parameter from the PARENT template?

For example, {{Infobox sportsperson}} has |nickname= but {{Infobox rugby league biography}} does not support nicknames... IF I were to convert rugby league to wrap sportsperson, is there a way to make |nickname= an unknown parameter in {{Infobox rugby league}}? --Zackmann (^{Talk to me}/_{What I been doing}) 21:48, 23 October 2025 (UTC)

Could be that I don't understand what you're asking. Consistent terminology is helpful. I assume that you mean that the wrapper template (this is what you mean by parent?) is {{Infobox rugby league biography}} and the working template is {{Infobox sportsperson}}. To prevent the wrapper template from passing |nickname= to the working template, set |_exclude=nickname; this will not prevent editors from writing {{Infobox rugby league biography |nickname=whatever |...}} but if they do, {{Infobox sportsperson}} won't get it.

If I don't understand what you're asking, restate.

—Trappist the monk (talk) 22:14, 23 October 2025 (UTC)

@Trappist the monk: I mean literally the EXACT opposite. Sorry that wasn't the best explanation.

{{Infobox sportsperson|nickname=whatever}} works but I want {{Infobox rugby league biography|nickname=whatever}} to NOT work as rugby league decided to remove support for nicknames in their infobox. Zackmann (^{Talk to me}/_{What I been doing}) 22:17, 23 October 2025 (UTC)

Are you sure? Doesn't seem to be the EXACT opposite to me; seems like you have said more-or-less the same thing as you did in your OP. So, that being the case, I think that I understand what you are asking. But, I'll try again.

Internally, your {{Infobox rugby league biography}} wrapper template is going to look summat like this:

{{#invoke:Template wrapper|wrap|_template=Infobox sportsperson
|_exclude=nickname
... other control parameters here ...
... other preset or modified parameters here...
}}

Right?

In an article you might write:

{{Infobox rugby league biography
|name           = David Stephenson
|nickname=Sparky <!-- not really; I just made that up -->
|fullname       =
|image          =
|image_size     =
|caption        =
|position       = {{Rlp|FB}}
|birth_date     = {{birth date and age|1972|10|6|df=y}}
|birth_place    = [[Leeds]], England
...
}}

This template would call Module:Template wrapper which in turn calls {{Infobox sportsperson}}. Because the template wrapper call has |_exclude=nickname, 'Sparky', won't be passed to {{Infobox sportsperson}}.

Have you tried this is a sandbox?

—Trappist the monk (talk) 23:07, 23 October 2025 (UTC)

Facepalm I'm really doing a bang up job explaining myself... Appreciate your patience.

You are correct, it won't be sent to the parent infobox. That is helpful and good to know but also what I expected. So the issue and what I meant by treat as unknown, is that since it is excluded, not sent to {{Infobox sportsperson}} it won't trigger the {{#invoke:Check for unknown parameters|check}}. So what I was hoping for is some additional option that basically says "take this parameter in the parent template and treat as invalid". It sounds like I can exclude it so it won't work (which gets me halfway there) but I can't treat it as an unknown parameter for the check for unknown params.

Again, appreciate your help and sorry for not being a better explainer... Zackmann (^{Talk to me}/_{What I been doing}) 23:14, 23 October 2025 (UTC)

Because |nickname= isn't known to {{Infobox rugby league biography}}, you must trap it there (presumably with {{#invoke:Check for unknown parameters|check}}), just as you would trap any other parameter not known to {{Infobox rugby league biography}}. Because |nickname= is known to {{Infobox sportsperson}}, you must set |_exclude=nickname so that Module:Template wrapper does not include that parameter in the list of parameters passed to {{Infobox sportsperson}}.

—Trappist the monk (talk) 23:32, 23 October 2025 (UTC)

Gotcha. Thanks! Zackmann (^{Talk to me}/_{What I been doing}) 23:37, 23 October 2025 (UTC)

documentation mode?

Can there be a method of some sort that would help us automatically document template wrapper instances?

For example, if we were to invoke a template that then takes our desired wrapped template as an argument, loads its source, and does a replacement of

{{#invoke:Template wrapper|wrap|

into say

{{#invoke:Template wrapper|explain|

And then executes that?

And in turn that function would, instead of executing on the input parameters like wrap, just output explanations of what was going to happen.

TIA. --Joy (talk) 12:15, 12 November 2025 (UTC)

where does the explanatory text come from? what does the output look like for a given input?

—Trappist the monk (talk) 14:01, 12 November 2025 (UTC)

I mean we'd have to write it, but the idea would be that it would process the same parameters into explanatory text, such as saying "your wrapped template will reuse the following parameters:" and listing the entire thing that is in the code as maybe a {{div col}} list or as a table. As opposed to having to copy&paste the entire list from the code and format it and later maintain it manually. --Joy (talk) 14:06, 12 November 2025 (UTC)

Don't make me pull your teeth out. Show an example input (from real-life is best) and then show the expected example output. Do not presume that what you see in your mind's eye matches what my mind's eye interprets from a few sentences of descriptive text.

—Trappist the monk (talk) 14:27, 12 November 2025 (UTC)

I'm trying not to address you specifically to give you a work task as if you were some weird robot :) It would be unkind to a volunteer to do that.

I'm primarily asking if this looks to be something that would be plausible first.

For example, can we even slurp in this code call from another template and morph it that way. If we can't do that, or if it involves some sort of a monstrosity in code, then we might be back to copying and pasting anyway. --Joy (talk) 16:21, 12 November 2025 (UTC)

Is it so hard to mockup an example of what you want? Without a clear and concise demonstration of what is wanted, the answer to the plausibility question lies somewhere between a hard 'yes' and a hard 'no'. I cannot read your mind; perhaps there are others reading this who can...

—Trappist the monk (talk) 17:31, 12 November 2025 (UTC)

So the example where I would want to use this would be at WP:IAUP. Not having to copy&paste and reformat all this:

| _alias-map = coord_ref:coordinates_footnotes, image:image_skyline, alt:image_alt, caption:image_caption, logo:image_blank_emblem, logo_alt:blank_emblem_alt, area:area_total_km2, elevation:elevation_m, timezone:timezone1, utc:utc_offset1, timezone-dst:timezone1_DST, utc-dst:utc_offset1_DST, zoom:mapframe-zoom, local_map_id:mapframe-id, local_map_caption:mapframe-caption, postcode:postal_code

| _reuse = subdivision_type, subdivision_name, subdivision_type1, subdivision_name1, subdivision_type2, subdivision_name2, subdivision_type3, subdivision_name3, subdivision_type4, subdivision_name4, subdivision_type5, subdivision_name5, subdivision_type6, subdivision_name6, established_title, established_date, extinct_title, extinct_date, postal_code_type, seat_type, timezone_link, leader_title, leader_name, leader_title2, leader_name2, leader_title3, leader_name3, settlement_type, population_total, population_as_of, population_footnotes, population_est, pop_est_as_of, pop_est_footnotes, blank_name_sec1, blank_info_sec1, blank1_name_sec1, blank1_info_sec1, blank2_name_sec1, blank2_info_sec1, blank3_name_sec1, blank3_info_sec1, blank4_name_sec1, blank4_info_sec1, blank5_name_sec1, blank5_info_sec1, blank_name_sec2, blank_info_sec2, blank1_name_sec2, blank1_info_sec2, blank2_name_sec2, blank2_info_sec2, image_map, coordinates, mapframe, mapframe-shape, mapframe-marker, image_upright

| _exclude = type, state, region, city, county, parish, established, est, established_footnotes, abolished, timezone, utc, timezone-dst, utc-dst, mayortitle, mayor, logo, pop, poprank, pop_year, pop_footnotes, pop2, pop2_year, pop2_footnotes, density, density_footnotes, lga, lga2, lga3, lga4, lga5, stategov, stategov2, stategov3, stategov4, stategov5, fedgov, fedgov2, fedgov3, fedgov4, hundred, former_hundred, division, managing_authorities, gazetted, map_type, alternative_location_map, use_lga_map, force_national_map, pushpin_label_position_a, pushpin_label_position_b, _noautocat, maxtemp, maxtemp_footnotes, mintemp, mintemp_footnotes, rainfall, rainfall_footnotes, dist1, dist2, dist3, dist4, dist5, dir1, dir2, dir3, dir4, dir5, location1, location2, location3, location4, location5, image, image_alt, alt, url, relief, near, near-e, near-n, near-ne, near-nw, near-s, near-se, near-sw, near-w, wikidata, local_map, image2_upright, logo_upright, first_peoples1, first_peoples1_footnotes, first_peoples2, first_peoples2_footnotes

... would be the goal. If a piece of software could parse these same lists of strings and generate anything resembling human-readable output, it would eliminate or reduce a fair bit of annoying manual work and having to maintain a copy of all this in perpetuity. --Joy (talk) 18:08, 18 November 2025 (UTC)

Dental work is painful ... So all that ↑ is the input. All that ↑ is to be reformatted into what sort of output? Surely you must have something in mind for what the output should look like... Where do the explanations you mentioned in the OP come from that are to become part of the output?

—Trappist the monk (talk) 19:12, 18 November 2025 (UTC)

Well, from the specification of this template. For example:

• Each of the _underscored parameter sections should be its own unnumbered list. Maybe wrapping it in {{div col}} makes sense in case it's this long.
• The text above each _underscored parameter list should have an introductory sentence and a link to Module:Template wrapper/doc#$parametername for more information. These sentences can be stubs for a start, we could edit them later.
• If the lists are long, and they probably are, they should each generate a subheading level 3 (===) by default, but ideally modifiable, to make sure that when we transclude this in a specific template's documentation that it fits well into their table of contents.
• The list of alias maps should be format every pair with e.g. an arrow between the two values.
• If possible, the rest of the parameter names passed into the wrapper should also be listed in a final section. (Just the names would be enough, I don't know that we could try to show their values and have that not be a mess.)

--Joy (talk) 20:00, 18 November 2025 (UTC)

Module:Sandbox/trappist the monk/wrapper doc → {{#invoke:Sandbox/trappist the monk/wrapper doc|main|template=Infobox Australian place}}

Its output can be seen in my sandbox (permalink).

Not ready for prime time.

—Trappist the monk (talk) 00:42, 19 November 2025 (UTC)