Template talk:Wrapper

Help location

@Mathglot, not sure how that ended up in the template, and in any case it goes against WP:CLICKHERE. I'd say this is not the best place to direct people, since it's not heavily watched and is supposed to be for improving the wrapper template itself, not uses of it. WP:VPT might be a better destination if we decide we need one. Cheers, Sdkb ^talk 01:06, 31 March 2025 (UTC)

Sdkb, thanks for the feedback. I don't know what the intent was either, and there's nobody left to ask. I seriously considered just removing it entirely, but that seemed a bit too BOLD. I still favor that, but if you or anyone thinks it's worth keeping a second link somewhere, I don't object. VPT seems a little dramatic, maybe WT:WikiProject Templates instead? Mathglot (talk) 01:30, 31 March 2025 (UTC) ^[subscribed]

Let's default to removing it, since we can always add it back, and it doesn't seem like the decision to add it was particularly considered if there was no link added with it. Also better to point people to just one place to avoid decision paralysis. Thanks for flagging the issue! Sdkb ^talk 01:33, 31 March 2025 (UTC)

 Done. Had some concerns that the wording of it might sound a bit odd, if we were already on a Talk page because that's where it was placed (but why?). So I poked around, and there was just a handful, in User talk archives, and two or three others elsewhere so not worth coding anything special for that case. Thanks, Mathglot (talk) 01:41, 31 March 2025 (UTC)

Ahecht, regarding this edit, even if that was the original intent, I agree with Sdkb that this makes it less likely that the discussion will be found if there are two possible places for it. Do you agree? Mathglot (talk) 05:58, 31 March 2025 (UTC)

@Mathglot Fair enough. --Ahecht (TALK
PAGE) 15:43, 31 March 2025 (UTC)

I've restored a single link. Please have a look, and adjust the link or the wording, as needed. Note: this led to some other changes, which were sandboxed (new) and tested (new), and are now included as well. Mathglot (talk) 08:57, 1 April 2025 (UTC)

More descriptive version available

I created a more descriptive version of this template at {{simple:Wrapper}}. It explicitly shows which parameters are passed through, omitted, or modified, which may make wrapper relationships easier to understand and maintain.

I sketched a possible implementation for our wiki at {{Wrapper/sandbox}}.

For instance, in {{Don't ping}} we would write:

Wikitext:

{{Wrapper|Please ping
	| except = 1 -> no	
	| omitting = tps // nw // big // thanks // cond
	| passing-through =
}}

Effect (colors are different because this is a talk page):

Whereas, in {{Catlist/doc}} we would write:

Wikitext (indentation and new lines are totally optional):

{{Wrapper|Pagelist
	| except =
		delim -> <wbr /> //
		edelim -> //
		nspace -> <nowiki>{{#if:{{{project|}}}|:{{{project}}}:}}Category</nowiki>
}}

Effect (colors are different because this is a talk page):

How do we feel about replacing the current version with this one? For more info, see the documentation of {{simple:Wrapper}}. --Grufo (talk) 06:00, 10 June 2026 (UTC)

@Grufo Looks much better. However, the last two examples at {{Wrapper/testcases}} seem to be worse? FaviFake (talk) 14:37, 10 June 2026 (UTC)

@FaviFake: The current {{Wrapper/testcases}} page cannot work, because I have removed the |exclude= and |all= parameters. I could do that because very few documentation pages use those parameters, and so it will be easy to switch to the new syntax. --Grufo (talk) 17:59, 10 June 2026 (UTC)

Great! I replaced the live template with your version :)   FaviFake (talk) 21:53, 10 June 2026 (UTC)

Thank you! I have temporarily added Category:Template Wrapper temp tracking category to the template in order to find out which documentation pages use the |exclude= and |all= parameters. --Grufo (talk) 22:10, 10 June 2026 (UTC)

All done now. Documentation pages that used the old parameters now use the new syntax, whereas documentation pages that did not specify any parameter continue to display as before (although those may eventually be updated as well). The remaining question is what to do with Template:Wrapper/testcases, which has not yet been updated for the new syntax. As far as I am concerned, the examples that I put in Template:Wrapper/doc are broad enough to work as testcases as well, so it would be OK for me if we simply deleted Template:Wrapper/testcases. --Grufo (talk) 00:12, 11 June 2026 (UTC)

Thanks! Testcases are also useful to show how the template handles errors and such. Maybe it could be rewritten using {{Test case}}, but I don't think they should be removed. FaviFake (talk) 09:35, 11 June 2026 (UTC)

Pinging @Mathglot as the one who created the current Template:Wrapper/testcases page: What do you think we should do? --Grufo (talk) 16:12, 11 June 2026 (UTC)

Thanks for the ping. Agree it should be kept and rewritten, but I won't have time to do so in the near future; I've tagged the page with a Tmbox in the meantime. Template {{Test case}} is pretty straightforward, and anyone is encouraged to go ahead and make changes to the /testcases page.

Regarding the change, thanks for using slashes and not vertical bars for the delims, which would have been a nightmare in templates. That said, although I'm aware that slash is not a metacharacter in the String modules String or String2, I presume the double slash has no particular issues with other templates or modules I'm not aware of? I'm mulling over whether it might be an issue, as // has meaning in url schemes, Cirrus regex search escaping annoyance, comment delim in various programming languages, path separators, visual ambiguity when adjacent to italics or links, etc. Did you consider ## or other unique-ish bigrams, doubled or not? I think ;; would be my favorite, so you'd have:

| omitting = tps ;; nw ;; big ;; thanks ;; cond

which is easy to see, uncommon in normal prose, no template/parser meaning, no URL interaction, and makes for an easy Lua regex ( mw.text.split(v, '%s*;;%s*') I believe, but I am not a Lua programmer). What do you think? Cheers, Mathglot (talk) 18:15, 11 June 2026 (UTC)

Hi Mathglot, thanks for stopping by. Yes, URLs create conflicts with the default syntax, but that can be easily overridden by using the |separator= parameter. For instance, we can imagine a wrapper template that writes this in its documentation page,

{{Wrapper|Foobar
	| separator = ///
	| except = url -> http://www.example.org /// name -> example
}}

which yields

When I wrote the template I considered it a case rare enough to justify the burden of having to add |separator=/// (or whatever else) to these few cases. The double semicolon or the double hash can easily become the default separator as well (all we need to do is replacing all occurrences of {{{separator|//}}} with {{{separator|;;}}} or {{{separator|##}}} in the template's code). Personally I find them uglier (and the double hash also less idiomatic), but we can wait and see what others think. --Grufo (talk) 18:36, 11 June 2026 (UTC)

I actually agree about the 'uglier', in the typographic-artistry sense; it is not beautiful—that's for sure!—and not something I envision medieval scribes transported to the 21st century voting for. But I see 'ugly' as a possible slight benefit here, although the main benefit (assuming my assumption about its unique-ishness is correct) is still the unlikelihood of its having collisions with text in the wild (whether prose, code, or strings). Perhaps more importantly, the slightly jarring effect it gives to the template user seeing it in the doc, as in something like: 'Whoa, double semi-colon; that looks weird! Never seen that one before,' which I count as a positive because it is memorable and they are unlikely to misunderstand. Some doc readers may recognize slash as a maybe-metacharacter, and possibly wonder if those two slashes are meant to be just one (having it in fixed-width font in the doc might minimize that). In the struggle between elegance, beauty, and familiar-looking, with a bit of uncertainty on the one hand, vs. minimal collision likelihood, ugly, oddball, but clear on the other, I'll cast my vote for the latter. Others may disagree, and I'm eager to see how it all shakes out. Mathglot (talk) 21:22, 11 June 2026 (UTC)

I really don't have strong opinions about what the best separator should be (except my laziness that fights against correcting it in the template's transclusions). What I fear about the (double) semicolon is that people might feel tempted to add one also after the last entry (e.g. foo ;; ;; bar ;; hello -> world ;;), which would count as a further element (a fourth here) in the list of unnamed parameters:

In that respect a double comma (,,) would work much better: nobody will ever be tempted to close a list with that. It would also be the ugliest separator of all (I guess people will remember it even more). --Grufo (talk) 22:18, 11 June 2026 (UTC)

I'm fine with commas, though Wikipedia pagenames commonly have comma but only a handful have semicolon. For the last element issue, What if you create a reserved word that cannot be an except param value part (say, 'NIL') and then you would have:

| except = foo ;; NIL ;; bar ;; hello -> world ;;

and the last semicolons (or commas) get ignored, because no following value? Mathglot (talk) 00:15, 12 June 2026 (UTC)

Commas: Single commas would not create conflicts; only double commas would (,,). Reserved word: Yes, that is very easy to do (by adding one line). But it would have the inconvenience of forbidding templates from using that reserved word. I wonder what we would gain in return and whether it is worth the trade-off. As for ignoring the last separator, this would make it differ from template syntax; when I wrote the code, the idea was that one should be able to look at a template's code, encounter, for instance, {{Foobar|one|two|three|hello=world}}, replace every | with //, then every = with ->, and finally put {{Wrapper|Foobar|except=one//two//three//hello->world}} in the documentation page. Without the ability to express a trailing separator, a template such as {{Foobar|one|two|}} would be quite confusing to translate. My biggest question at this point is: What is the biggest problem with //? It seems to work quite flawlessly. --Grufo (talk) 01:30, 12 June 2026 (UTC)

No real big objection really; just things mentioned above. If you want to keep the slashes it's fine with me. Mathglot (talk) 05:11, 14 June 2026 (UTC)

A new parameter for syntaxhighlight?

At Template:Exams/doc @Cedar101 wrapped a parameter value inside a <syntaxhighlight>...</syntaxhighlight> tag. However, currently, this will produce <code><syntaxhighlight lang="wikitext" inline>...</syntaxhighlight></code>, which, of course, it is not good HTML. Do we feel we should add a |value-wrapper= parameter—containing one of these three possibilities: syntaxhighlight, code, nothing—like I did in this version of the sandbox? When I wrote the template I opted for the <code>...</code> tag because it is way more flexible. It is true though that it does not provide colors. Here is how the three options will look.

Wikitext 1, |value-wrapper=syntaxhighlight:

{{Wrapper/sandbox|Example
	| except = foo -> <nowiki>{{Bar}}</nowiki>
	| value-wrapper = syntaxhighlight
}}

Effect 1:

Wikitext 2, |value-wrapper=nothing:

{{Wrapper/sandbox|Example
	| except = foo -> <nowiki>{{Bar}}</nowiki>
	| value-wrapper = nothing
}}

Effect 2:

Wikitext 3, |value-wrapper=code (default when omitted):

{{Wrapper/sandbox|Example
	| except = foo -> <nowiki>{{Bar}}</nowiki>
	| value-wrapper = code
}}

Effect 3:

We can also decide that <syntaxhighlight>...</syntaxhighlight> will be the only container of values (replacing the current <code>...</code>). But at the moment I am not sure if this will be a wise choice. --Grufo (talk) 01:26, 14 June 2026 (UTC)

Edit: I replaced <code>...</code> with <syntaxhighlight lang="wikitext" inline>...</syntaxhighlight> in parameter values and everything seems to work just fine. So maybe we won't need the |value-wrapper= option after all. --Grufo (talk) 05:12, 14 June 2026 (UTC)