Template talk:Parameter

How to syntaxhighlight a standalone parameter?

Is there a template that can easily highlight the "bar" in {{Foo|bar=baz, without the need for {{Foo? {{Para}} or {{Param}} seem like the most appropriate places to find this, but I could not. This would be very useful for template documentation.

Unfortunately, all permutations of |bar= on its own only produce |bar=.   ~ Tom.Reding (talk ⋅dgaf)  12:54, 4 July 2024 (UTC)

The template might be modified so that it renders:

<code class="mw-highlight mw-highlight-lang-wikitext mw-content-ltr" dir="ltr">|<span class="nl">bar</span>=</code> → |bar=

I have not attempted to experiment with the template itself.

Also, the template does support red/green coloring but those parameters also color the pipe, the parameter name, and the assignment operator:

|bar= ← {{para|bar|mxt=yes}}

|bar= ← {{para|bar|!mxt=yes}}

Are those colors sufficient for template documentation?

—Trappist the monk (talk) 13:52, 4 July 2024 (UTC)

@Trappist the monk: thank you for providing the appropriate code class!

The red/green option is definitely not appropriate for this base-case scenario, since it would be unnecessarily confusing to have the template name and any standalone parameters both the same color in different parts of the documentation. Standalone parameters should be the same color as they are when next to their parent template (muddy yellow).

Perhaps a new parameter can be added to the template to produce |bar=, say |syn=yes, for "syntax"?   ~ Tom.Reding (talk ⋅dgaf)  15:03, 4 July 2024 (UTC)

@Trappist the monk: implemented in the sandbox!

{{para/sandbox|foo|syn=yes}} → |foo=

Does anyone see an issue with making this live?   ~ Tom.Reding (talk ⋅dgaf)  14:47, 4 August 2024 (UTC)

If one is to believe this search there are fewer than 10 {{para}} templates that use either of |mxt= or |!mxt=. That makes me wonder if the better solution is to get rid of those two parameters in favor of |color= or |highlight= or some such with syntax as the default coloring so editors don't have to remember multiple parameter names so:

{{para|foo}} → |foo= – default uses <syntaxhighlight>...</syntaxhighlight> for coloration

{{para|foo|color=red}} → |foo=

{{para|foo|color=green}} → |foo=

{{para|foo|color=none}} → |foo= – don't know why this would be necessary but some editors might not want to colorize because reasons

I suspect that making this choice will simplify the code; one <code>...</code> tag as it exists now and then switch on {{{color|}}} to create the opening <span> tag and its attribute:

<span {{#switch:{{{color|}}}
      |red=style="color:#8B0000;"
      |green=style="color:#006400;" <!-- this 'green' color choice might want to be revisited -->
      |none=
      |#default=class="nl"
      }}>{{{1|}}}</span>

caveat lector: the above not tested

If one is to believe this search |style= is not used so I would propose that we delete support for that parameter.

—Trappist the monk (talk) 16:43, 4 August 2024 (UTC)

Yes, |color=/|highlight= (|highlight= can be the alias) are both more intuitive than |mxt=/|!mxt=. Also, the boolean pair |mxt=/|!mxt= logically doesn't work when 3rd & 4th options are available, syntax & none, so it makes sense to retire |mxt=/|!mxt=.

Yes, one <code>...</code> tag is preferable, since 2 adjacent tags produce an undesired thin vertical separator between them, visible in Template:Para/testcases#Spacing + syn=y & elsewhere.

|style= seems harmless to keep, and potentially useful, but I don't feel strongly either way. However, if keeping it makes implementing the above significantly more difficult, then remove it.   ~ Tom.Reding (talk ⋅dgaf)  11:41, 6 August 2024 (UTC)

|style= is gone. Here is a new sandbox version. In all of these examples, the pipe and 'bar' are colored #333, '=' is colored #666, these are the current <syntaxhighlight>...</syntaxhighlight> colors

1. {{para/sandbox|foo|bar}}

   |foo=bar – 'foo' uses <syntaxhighlight>...</syntaxhighlight> colors (currently #767600)

2. {{para/sandbox|foo|bar|color=none}}

   |foo=bar – nothing in the output is colored

3. {{para/sandbox|foo|bar|color=red}}

   |foo=bar – 'foo' uses #8B0000; same color used by {{!mxt}}

4. {{para/sandbox|foo|bar|color=green}}

   |foo=bar – 'foo' uses #008000; a slightly brighter green than the color used by {{mxt}} (#006400)

Not sure that this template should be subst'd because it produces a lot of stuff that, to my mind, is just so much clutter:

• {{para/sandbox|foo|bar}}

  <code class="tpl-para" style="word-break:break-word; " class="mw-highlight mw-highlight-lang-wikitext mw-content-ltr" dir="ltr">&#124;<span class="nl">foo</span><span class="o">&#61;bar</span></code>

—Trappist the monk (talk) 22:16, 6 August 2024 (UTC)

For some reason, these changes aren't being reflected in Template:Para/testcases, even after a purge, even with only 1 example (to rule out un/mis-closed tags), but they appear as intended (thanks to your descriptions!) above...

That aside... "bar" in examples 1, 3, 4 was darker than the "bar" here: {{example|foo=bar, which I fixed.

The brighter green is definitely better, and if people want the lighter version or some other color, then they can easily add it to the #switch.

No comment on the subst-y-ness, since I've no experience with/need of it.

Looks fantastic!   ~ Tom.Reding (talk ⋅dgaf)  14:35, 7 August 2024 (UTC)

Good catches. Thanks. substing support is gone. Rewritten to simplify and add ability to include other colors. See ~/testcases.

—Trappist the monk (talk) 17:11, 7 August 2024 (UTC)

Even more functional & user-friendly. I only made 1 small tweak to the sandbox.

I added more testcases, and the only discrepancy I saw was |section vs. |=section (Live vs. Sandbox).   ~ Tom.Reding (talk ⋅dgaf)  09:53, 8 August 2024 (UTC)

Fixed that. Good catch.

—Trappist the monk (talk) 11:36, 8 August 2024 (UTC)

@Trappist the monk: no other comments after a month; time to go live?   ~ Tom.Reding (talk ⋅dgaf)  10:32, 11 September 2024 (UTC)

Go ahead. Umm, no. We should think about dark mode. In dark mode, <syntaxhighlight>...</syntaxhighlight> renders over a background color of #f8f8f8. Should we mimic that? Or, should we strike out on our own and develop new colors (assuming we can figure out how to detect dark mode)?

—Trappist the monk (talk) 11:58, 11 September 2024 (UTC) 16:04, 11 September 2024 (UTC) changed my mind.

Definitely mimic.   ~ Tom.Reding (talk ⋅dgaf)  11:17, 12 September 2024 (UTC)

And |mxt= and |!mxt= need to be replaced with |color=green and |color=red respectively. See this search.

—Trappist the monk (talk) 16:04, 11 September 2024 (UTC)

Yes indeed. I was actually preparing to do that yesterday, but luckily I took my sweet time and didn't go live.   ~ Tom.Reding (talk ⋅dgaf)  11:17, 12 September 2024 (UTC)

Tweaked ~/styles.css so that {{para}} on Minerva undark skin renders with the background color used by <syntaxhighlight>...</syntaxhighlight>. Does not change rendering on Minerva dark skin.

—Trappist the monk (talk) 14:46, 13 September 2024 (UTC)

dark mode

I have hacked the sandbox and created Template:Para/styles.css. These changes, at the least, make the rendered text somewhat readable. No doubt, there are better color choices to be made that look more-or-less the colors used by the undark mode. The chosen colors also need to be contrast accessible. —Trappist the monk (talk) 18:42, 11 September 2024 (UTC)

Assuming Template:Para/styles.css is what's displayed at Template:Para/testcases, para output looks similar to <syntaxhighlight>...</syntaxhighlight> in both light and dark modes.   ~ Tom.Reding (talk ⋅dgaf)  11:17, 12 September 2024 (UTC)

I'm confused. Here you seem to be in favor of supporting dark mode with our own color scheme yet, above you (more emphatically, I think) seem to be supporting a notion that we should simply mimic <syntaxhighlight>...</syntaxhighlight>. So what do you really mean?

—Trappist the monk (talk) 11:53, 12 September 2024 (UTC)

The whole point of this is to make {{para}} produce parameter output identical to <syntaxhighlight>...</syntaxhighlight>. If that happens, then both {{para}} & <syntaxhighlight>...</syntaxhighlight> should look the same in dark & light modes, right? In the testcases, to me, they do. Perhaps I'm not seeing styles.css being applied? All I did was purge the page. Is there anything more I should be doing? I have minimal experience with CSS.   ~ Tom.Reding (talk ⋅dgaf)  12:36, 12 September 2024 (UTC)

You did, at the top of the ~/testcases page, choose vector (2022) as the skin and then dark mode from menu at right, didn't you?

—Trappist the monk (talk) 13:29, 12 September 2024 (UTC)

Aha! I've never used any of those links...until now. I opened all 5 skins and toggled light/dark modes, and they all look good & as-expected.   ~ Tom.Reding (talk ⋅dgaf)  14:33, 12 September 2024 (UTC)

I have tweaked the dark mode colors using named colors from Web colors § Extended colors so that the dark mode colors are WCAG 2 AAA compliant (with the exception of |color=green which has a color difference that is slightly underspec at 496, should be >=500). Color evaluations were made using snook's color contrast checker (https://snook.ca/technical/colour_contrast/colour.html).

I also checked, but did not change, the <syntaxhighlight>...</syntaxhighlight> undark-mode colors. I did change the color for |color=green so that it would be WCAG 2 AAA compliant. More detail in Template:Para/styles.css.

WCAG 2 AAA is the strictest compliance specification. According to Wikipedia:Manual of Style/Accessibility § Color, we can fallback to en.wiki's minimum requirement of WCAG 2 AA if we decide to do that.

—Trappist the monk (talk) 17:02, 12 September 2024 (UTC)

Tracked in Phabricator
Task T285859

Tracked in Phabricator
Task T365926

I experimented with going back to using the same classes as <syntaxhighlight>...</syntaxhighlight> but that just broke <syntaxhighlight>...</syntaxhighlight> rendering in dark mode. Perhaps when <syntaxhighlight>...</syntaxhighlight> is made to be compatible with dark mode...

—Trappist the monk (talk) 21:42, 13 September 2024 (UTC)

@Trappist the monk, it looks like phab:T365926 has been resolved. I've only skimmed the above — does this mean it'd be possible to implement syntax highlighting in this template now? It'd be nice to have that, particularly when it's used with a value. Sdkb ^talk 20:57, 31 March 2026 (UTC)

I don't know. I haven't been back to this discussion since September 2024. In the interim, Editor Waddie96 usurped the sandbox. If the examples in the Template:Para/testcases page are any example, the sandbox doesn't work – and the dark-mode coloring provided by <syntaxhighlight>...</syntaxhighlight> is awful.

I'll try to think about coloring in the next week or so; I have other stuff, both here and in real life occupying my time.

—Trappist the monk (talk) 00:56, 1 April 2026 (UTC)

para2

{{para2}} created in the meantime for anyone that wants this functionality, for instance on documentation subpages, where syntaxhighlight is already in widespread use.   ~ Tom.Reding (talk ⋅dgaf)  11:56, 8 June 2026 (UTC)

Wait, I don't understand why this wasn't implemented within this template. Having a second template sounds like a mess, why can't we make the colour show up in this template by default, exactly? FaviFake (talk) 12:07, 8 June 2026 (UTC)

Per the latest comments in #dark mode, editor Trappist the monk said that they would make a determination when their time allowed. That was over 2 months ago, which I've teken as a WP:SILENT or soft veto due to the time involved, but I could be wrong.

Regardless, having a very simple {{para2}}, without all the bells & whistles of {{para}}, is hardly "a mess"; if/when syntaxhighlight-style formatting becomes implemented in {{para}}, the conversion is trivial. In the meantime, those wishing to implement consistent syntaxhighlight formatting in documentation pages or elsewhere can do so.   ~ Tom.Reding (talk ⋅dgaf)  10:51, 9 June 2026 (UTC)

Oh well. If anyone else is reading this and is experienced enough to make the change, I strongly support making the olive colour of {{para2}} the default on this template as well. FaviFake (talk) 13:24, 9 June 2026 (UTC)

this is an upgrade and non-breaking change, right? I.e., if it lacks syn=yes, it will appear the same way as it did before @Mathglot, in most other cases, syntax highlighting has been turned on by default, so I would expect the same here, with a parameter to opt out. It seems like an upgrade that will not break anything. If you anticipate that it might cause an issue beyond a few editors not liking the look of it (they can turn it off if they want), it'd be good to know. Cheers, Sdkb ^talk 06:09, 15 June 2026 (UTC)

If it changes the colors the way from the way they are, then I would like to have classes placed on all emitted strings so I can adjust in common.css or the param. Thanks, Mathglot (talk) 06:17, 15 June 2026 (UTC)

I'm guessing that there's already some method available to disable syntax highlighting in your CSS, given that it's already been rolled out to a ton of other parts of template documentation. More info might be at mw:Extension:SyntaxHighlight. Sdkb ^talk 14:28, 16 June 2026 (UTC)

I agree the updated template should be olive-coloured by default. FaviFake (talk) 15:43, 15 June 2026 (UTC)

I have restored the syntax highlighting experiment to {{parameter/sandbox}}. That experiment is dependent upon Template:Parameter/styles.css which is listed for discussion at Wikipedia:Templates for discussion/Log/2026 June 12 § Template:Parameter/styles.css. Template:Parameter/testcases shows what it looks like. Whatever discussion is there is likely out of date so should be taken with a heaping tablespoon of salt... More discussion at Template talk:Parameter § How to syntaxhighlight a standalone parameter? which may be helpful to someone who knows css better than I...

—Trappist the monk (talk) 16:10, 15 June 2026 (UTC)

Template-protected edit request on 7 July 2026

Following the merge discussion of {{Parameter}} and {{Parameter2}}, I have merged the two templates in this version of the sandbox (to be adopted as the current version). The changes were made in three steps:

1. First edit: I have added indentation (no changes, clarity)
2. Second edit: Don't hide the parameter with the empty name when {{{1}}} is empty (bugfix) _{Sorry, this was a mistake. --Grufo}
3. Third edit: Merge {{Parameter2}} here with some harmonization and additions, like the |name-color= parameter.

Happy editing :) Grufo (talk) 09:02, 7 July 2026 (UTC)

[Later side addition]: After further consideration, I think my second edit wasn't entirely mistaken. Writing {{para||foo}} should indeed display |=foo (i.e., that would mean that the empty named parameter {{{}}} has a value of foo); whereas, to display |foo, one should use {{para|2=foo}} (i.e., omitting the parameter's name altogether rather than assigning it the empty string). This version should show what I mean. --Grufo (talk) 14:59, 7 July 2026 (UTC)

Support – Looks good in the testcases. FaviFake (talk) 15:06, 7 July 2026 (UTC)

In tests 3 and 4 it says "nothing in the output is colored" but I can see color. In test 5, I am not seeing the red in the output. And in test 6, I am not seeing the bold green either. So based on this, the code is not working as intended — Martin (MSGJ · talk) 08:49, 8 July 2026 (UTC)

That's because there isn't a |color= parameter; there is a |name-color= parameter though. I have fixed the testcases page. --Grufo (talk) 11:35, 8 July 2026 (UTC)

Looking better. Please check test 2 — Martin (MSGJ · talk) 11:45, 8 July 2026 (UTC)

Test 2 works as expected (that is, |name-color= means no color). It should be especially useful in substitutions, because, unlike |name-color=inherit, it gets rid of the <span>...</span> element altogether. --Grufo (talk) 12:05, 8 July 2026 (UTC)

Update. I just added a |name-color=¬ option for using the default color. --Grufo (talk) 12:19, 8 July 2026 (UTC)

I think a blank parameter should almost always be treated the same as an omitted parameter. So {{para|foo|bar|name-color=}} should ideally be the same as {{para|foo|bar}} — Martin (MSGJ · talk) 13:11, 8 July 2026 (UTC)

Concur.

—Trappist the monk (talk) 13:25, 8 July 2026 (UTC)

Template:Parameter/testcases § Syntax highlighting describes colors expected for the pipe, the assigned value, and the assignment operator. None of the sandbox renderings use those colors. Testcases 5–9 all fail because |name-color= is not using the specified color.

—Trappist the monk (talk) 13:25, 8 July 2026 (UTC)

Answering here concerning both points (i.e. omitted and empty |name-color= should be treated the same and testcases 5–9 that were using a |color= parameter): This version of the sandbox uses |name-color=inherit to get rid of the internal <span>...</span> element and introduces a |color= parameter for the whole parent element. --Grufo (talk) 14:17, 8 July 2026 (UTC)

This from test 5 in testcases which says: 'foo' uses #8B0000; same color used by {{!mxt}}

{{parameter/sandbox|foo|bar|name-color=red}} → |foo=bar

'foo' is not colored #8B0000 or even red.

—Trappist the monk (talk) 14:39, 8 July 2026 (UTC)

Something's wrong. |foo and |foo should display identically, i.e. |foo - the situation is of positional (unnamed) parameters. But the sandbox one has an incorrect equals sign. This is a breaking change. --Redrose64 🌹 (talk) 14:53, 8 July 2026 (UTC)

The reason why {{para||foo}} and {{parameter/sandbox||foo}} appear different is explained here. --Grufo (talk) 15:06, 8 July 2026 (UTC)

That is contrary to the documentation. Show an example of a template that uses the empty string as a legitimate parameter name.

—Trappist the monk (talk) 15:29, 8 July 2026 (UTC)

The {{#switch}} parser function and how wikitext parameters work in general are things we do document, and the {{para}} template should comply to meet these cases. This is of course my opinion and the majority can think otherwise, in which case we can make the sandbox version incompatible with documenting the empty string parameter. --Grufo (talk) 15:58, 8 July 2026 (UTC)

A switch case may be empty (corresponding to an empty-string switch-value) but that is not the same thing as empty-string as a parameter name. Yes it is possible to write templates that might look like {{some template name|=assigned value}}. Just because it can be done does not mean that it should be done. This template should not provide an excuse for such practice.

—Trappist the monk (talk) 16:40, 8 July 2026 (UTC)

I don't have any opinions on whether people should use the empty string parameter. However this is a documentation template that depends on how wikitext works; in theory you could use it for saying “don't do this: |=”. --Grufo (talk) 17:55, 8 July 2026 (UTC)

My bad, there was a typo—fixed now. I have restored the previous testcases and I have added two tests for the |name-color= parameter --Grufo (talk) 14:57, 8 July 2026 (UTC)

|red= and |green= are also broken:

|foo=bar ←{{parameter|foo|bar|red=y}}

|foo=bar ← {{parameter/sandbox|foo|bar|red=y}}

|foo=bar ←{{parameter|foo|bar|green=y}}

|foo=bar ← {{parameter/sandbox|foo|bar|green=y}}

—Trappist the monk (talk) 15:29, 8 July 2026 (UTC)

They were not broken, simply now there is an additional color that must be taken into account, and that is |name-color=. This new version avoids using a color for the parameter's name when the parent's color is set. On a side note, now that we have a |color= parameter I would be in favor of removing all these |red=y, |green=y, etc. sugar parameters that only complicate the code. --Grufo (talk) 15:50, 8 July 2026 (UTC)

You make no sense. The examples I gave were broken because the sandbox rendering did not match the live rendering. |name-color= is not used in my examples.

I agree that |color= is better than |mxt=, |!mxt=, |green=, |red=. These four parameters may be replaced in the wild after the live version of the template is updated. After the update and replacement in the wild, |mxt=, |!mxt=, |green=, |red= may be removed from the template.

—Trappist the monk (talk) 16:17, 8 July 2026 (UTC)

Hey, why the anger? Ok, so we can do it in two steps: For now we can think of publishing the colored version more or less as it is, then we can remove all usages of |green=, |red= etc. from transclusions in the wild, and then we can remove these parameter from the template's code. --Grufo (talk) 16:23, 8 July 2026 (UTC)

If I were angry, you would know it. I claimed that with this version of the sandbox, |red= and |green= were broken. You denied my claim by asserting that my examples were not broken. Additionally, you made some claim about |name-color= which parameter is not used in my examples. So I claim that your claims make no sense to me.

We agree about what to do with |mxt=, |!mxt=, |green=, |red=.

The empty-string parameter issue is not yet resolved:

|bar ← {{parameter||bar}}

|bar ← {{parameter/sandbox||bar}}

The coloring of the pipe, the assigned value, and the assignment operator as specified at Template:Parameter/testcases § Syntax highlighting, has not been resolved.

—Trappist the monk (talk) 18:42, 8 July 2026 (UTC)

I probably should have expressed it differently. What I think was wrong was the criterion you used to define “broken”, which was the sandbox version and the current version not agreeing. In fact the following two examples also behave differently, but we don't say that the sandbox version is broken (it is actually a wanted behavior):

• |foo=bar ← {{parameter|foo|bar}}
• |foo=bar ← {{parameter/sandbox|foo|bar}}

The reason is the same: now there is another parameter to take into account, which is |name-color=. However I did get what you meant, I also agreed with it (i.e. the decision I had taken earlier was not optimal), and corrected the sandbox immediately afterwards. As for the empty string parameter, I agree that it is not yet settled, so maybe we can wait for other opinions about it? As for “the coloring of the pipe, the assigned value, and the assignment operator”, I admit I did not understand. Could you show here using plain wikitext the expected behavior that you find missing? --Grufo (talk) 19:05, 8 July 2026 (UTC)

Your example is not broken because the coloring applied to 'foo' is, ostensibly, the purpose of this entire exercise. The purpose of |mxt= and friends is to color the whole rendering. When 'foo' is not the same color as the rest of the rendering when |mxt= is set, the rendering is broken.

Using these classes from Template:Parameter/styles.css:

.para-syn {color:#767600}               /* syntaxhighlight color; not WCAG 2 AAA compliant */
.para-pipe, .para-value {color:#333}    /* syntaxhighlight color */
.para-assign {color:#666}				/* syntaxhighlight color; not WCAG 2 AAA compliant */

{{para|foo|bar}} might render this:

<span class="para-pipe">|</span><span class="para-syn">foo</span><span class="para-assign">=</span><span class="para-value">bar</span>

|foo=bar

these were the colors used by <syntaxhighlight>...</syntaxhighlight> as of 2024-08-07.

—Trappist the monk (talk) 21:12, 8 July 2026 (UTC)

Got it now. I think this version of the sandbox should cover the colors of the pipe, the assignment operator, etc. --Grufo (talk) 22:36, 8 July 2026 (UTC)

Update: Actually to me it seems that this other version would be more representative of what syntaxhighlight does: in fact with my browser I don't see the color #333 anywhere, I only see #101418, #767600 and #666. --Grufo (talk) 04:34, 9 July 2026 (UTC)

@Trappist the monk: How are we at this point? --Grufo (talk) 05:47, 11 July 2026 (UTC)

Has the empty-string parameter-name issue been resolved? If so, where was that discussion?

|bar ← {{parameter||bar}}

|bar ← {{parameter/sandbox||bar}}

—Trappist the monk (talk) 13:01, 11 July 2026 (UTC)

Since there hasn't been much participation around the empty-string parameter name question, we can think of applying this other version (diff) for now (which does not differentiate {{para||bar}} and {{para|2=bar}}, and later discuss this specific topic separately. In this way we could also have the time to remove |mxt=y, |red=y, etc. from the wild. --Grufo (talk) 17:21, 11 July 2026 (UTC)

Almost. Follow this link and look at test 4.

—Trappist the monk (talk) 19:26, 11 July 2026 (UTC)

Done. But to fully support dark mode we will need to use a separate CSS (and remove support for template substitution). --Grufo (talk) 19:41, 11 July 2026 (UTC)

@Trappist the monk: On that note, this should be a more or less faithful imitation of what <syntaxhighlight>...</syntaxhighlight> does, which would work properly also in dark mode:

<code class="mw-highlight"><span class="p">&#124;</span><span class="nl">foo</span><span class="o">=</span>bar</code>

However it requires syntaxhighlight's CSS, which I don't know how to embed. What I do know is that if I use <syntaxhighlight>...</syntaxhighlight> immediately before,

{{Syntaxhighlight|Hello world}}

<code class="mw-highlight"><span class="p">&#124;</span><span class="nl">foo</span><span class="o">=</span>bar</code>

the code prints:

Hello world

|foo=bar

--Grufo (talk) 23:50, 11 July 2026 (UTC)

<syntaxhighlight>...</syntaxhighlight> css might be embedded this way?:

<syntaxhighlight lang="wikitext" /><!-- required to fetch syntaxhighlight's css --><code class="mw-highlight"><span class="p">&#124;</span><span class="nl">foo</span><span class="o">=</span>bar</code>

—Trappist the monk (talk) 12:32, 12 July 2026 (UTC)

You will likely want to add inline to that so it does not add empty <div /> element but instead an empty <span /> element:

<syntaxhighlight inline lang="wikitext" />

—Uzume (talk) 06:07, 13 July 2026 (UTC)

I followed Trappist's and Uzume's suggestions (though I also had to add style="display: none;", otherwise, a visible element would be created), and I created this sandbox version. I also removed the |name-color= parameter, which no longer seems to make much sense. It seems to be working fine. --Grufo (talk) 09:24, 13 July 2026 (UTC)

@Grufo @Trappist the monk I don't have time to read this entire discussion but it seems the issue was sorted out. Are you ok with the TPER being restored? FaviFake (talk) 12:42, 19 July 2026 (UTC)

I agree. --Grufo (talk) 14:13, 19 July 2026 (UTC)

Actual edit request

Replace with sandbox version per discussion at § Template-protected edit request on 7 July 2026 to carry out the TfD merge. FaviFake (talk) 14:17, 19 July 2026 (UTC)

 Done — Martin (MSGJ · talk) 21:38, 20 July 2026 (UTC)

Thank you, Martin. Now the next step is to replace |mxt=, |green=, |!mxt=, and |red= with |color= in pages that transclude this template. --Grufo (talk) 22:39, 21 July 2026 (UTC)

Recent update "to support merging of Template:Parameter2"

MSGJ, in revision 1365193129 of 21:37, 20 July 2026 (diff), your edit summary reads, "changes to support merging of Template:Parameter2". But I don't see that; your edit added 436 bytes to the code, whereas {{parameter2}} was a very small template. Here it is in its entirety, in rev. 1358241145 as of 18:00, 12 July 2026—just prior to the Tfd boilerplateadditions:

<code><nowiki>|</nowiki>{{Olive|{{{1|1}}}}}={{{2|}}}</code><noinclude>
{{Documentation}}
</noinclude>

Can you explain why this should not be reverted? It complicates the code considerably, and seems to have nothing to do with Template:Parameter2. Thanks, Mathglot (talk) 01:21, 9 August 2026 (UTC)

I note a lot of the diff was in reformatting code like {{SAFESUBST:<noinclude />#if:{{{1|}}}|{{{1}}}&#61;}} into

{{safesubst:<noinclude />#if:{{{1|}}}
	| {{{1}}}&#61;
}}

and rearranging {{SAFESUBST:<noinclude />#if:{{{plain|}}}{{{mxt|}}}{{{green|}}}{{{!mxt|}}}{{{red|}}}|color: {{SAFESUBST:<noinclude />#if:{{{mxt|}}}{{{green|}}}|#006400|{{SAFESUBST:<noinclude />#if:{{{!mxt|}}}{{{red|}}}|#8B0000|inherit}}}};}} into

{{safesubst:<noinclude />#if:{{{color|}}}
	| color: {{{color}}};
	| {{safesubst:<noinclude />#if:{{{mxt|}}}{{{green|}}}
		| color: #006400;
		| {{safesubst:<noinclude />#if:{{{!mxt|}}}{{{red|}}}
			| color: #8B0000;
			| color: inherit;
		}}
	}}
}}

The "merge" part of the diff was to add

<syntaxhighlight lang="wikitext" inline style="display: none;" /><!-- required to fetch syntaxhighlight's css --><code class="mw-highlight"><span class="p">&#124;</span>{{safesubst:<noinclude />#if:{{{1|}}}
	| <span class="nl">{{{1}}}</span><span class="o">=</span>
}}{{{2|}}}</code>

(along with a wrapping #if). The change to that from what was in Template:parameter2 was discussed above, most relevantly starting at #c-Grufo-20260711235000-Trappist_the_monk-20260711192600. Anomie⚔ 11:44, 9 August 2026 (UTC)

Furthermore, a lot of the current template's code will be removed as soon as we replace |mxt=, |green=, |!mxt=, and |red= with |color= in the pages that transclude this template (anyone who volunteers?). --Grufo (talk) 23:51, 26 September 2026 (UTC)

How are we planning to support dark mode with the |color= parameter? Having specific parameters does allow us to define the color, for example to use <span style="color: var(--color-content-added, #006400)"> as I have done in the sandbox. Axolitl (talk | contribs) 03:20, 6 October 2026 (UTC)

Wrapping

I just used this on a page, as {{para|name}} and the pipe appeared on the end of a line with "name" on the next.

Can we use {{nowrap}} or equivalent, to prevent this? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits; 13:52, 13 September 2026 (UTC)