Template:Yesno ispermanentlyprotected from editing as it is aheavily used or highly visible template. Substantial changes should first be proposed and discussed here on this page. If the proposal is uncontroversial or has been discussed and is supported byconsensus, editors may use {{edit protected}} to notify an administrator to make the requested edit. Usually, any contributor may edit the template'sdocumentation to add usage notes orcategories. Any contributor may edit the template'ssandbox. Functionality of the template can be checked usingtest cases.

Can we simplify this template a bit? It seems that the second parameter is always "yes". — Martin(MSGJ · talk)08:48, 1 May 2009 (UTC)[reply]

Is it? I remember we changed some (most?) of the defaults in WPBM to 'yes', but I can't remember if we got them all. And of course we'd need to check that no other templates are using this... good luck with that!!:DHappy‑melon10:20, 2 May 2009 (UTC)[reply]

I reckon (hope) no one else is using it yet. I'll double check, but I think all defaults should be yes. I got a little bit confused, as always, with the ¬, but I it's not affecting that. I noticed that you hadn't added yesno to the hooks yet, so I'll do that as well. Cheers, — Martin(MSGJ · talk)14:14, 2 May 2009 (UTC)[reply]

I have, I hope, clarified the documentation.RichFarmbrough,22:55, 31 August 2009 (UTC).[reply]

! is fairly standard as is ~, - and '.RichFarmbrough,09:06, 1 September 2009 (UTC).[reply]

What is ¬ used for in this template?PC78 (talk)15:41, 7 October 2009 (UTC)[reply]

Nothing. But, as always, it's important that a value of ¬ is passed through to the next level unaltered.Happy‑melon17:09, 7 October 2009 (UTC)[reply]

Recent discussions with Martin have left me a little unsure with regards to using{{yesno}}, particuarly where I've been using it at{{WPBiography/sandbox}}. Arethese changes good, or am I better using yesno within an #if statement? That banner does some pretty funky stuff if I enter ¬ as a value for some parameters,|small=¬ for example, or|filmbio-work-group=¬ which triggers the a&e-work-group parameter instead. I'm not sure if these are things to be genuinely concerned about, but I'm thinking these issues stem from either this template or my (mis)use of it.PC78 (talk)18:16, 7 October 2009 (UTC)[reply]

I think those edits look fine. Basically ¬ was chosen because it was assumed that no one would ever enter ¬ as a parameter value. It is generally used to determine whether a parameter has been defined or not. For example {{yesno|{{{test|¬}}}|¬=Hello}} produces Hello because {{{test}}} is not defined. — Martin(MSGJ · talk)18:59, 7 October 2009 (UTC)[reply]

Those edits are very clever, and to be fully supported and encouraged. As Martin says, no one should ever be consciously setting a parameter to ¬; for our purposes, "¬" === "undefined", and (most importantly) an 'undefined' thatstays undefined when passed through to subtemplates.Happy‑melon22:27, 9 October 2009 (UTC)[reply]

Could/should{{yesno}} interpret ? as a null parameter?PC78 (talk)01:04, 14 October 2009 (UTC)[reply]

That sounds like a sensible idea. And what about "yes/no" as well. — Martin(MSGJ · talk)11:33, 14 October 2009 (UTC)[reply]

Probably. I've seen it used.PC78 (talk)12:06, 14 October 2009 (UTC)[reply]

Could maybe copy some other ideas fromTemplate:WPBannerMeta/bchecklist/b as well, e.g. "fail" for no. — Martin(MSGJ · talk)12:25, 14 October 2009 (UTC)[reply]

Sounds like a plan. All of those would be valid for things other than B checks. Only danger I can think of would be things like|A-Class=, but I don't think we use yesno there, do we?Happy‑melon13:28, 14 October 2009 (UTC)[reply]

Add ??? to the list.PC78 (talk)01:23, 16 October 2009 (UTC)[reply]

Would it not be simpler and more logical to change the default from "yes" to "no"?PC78 (talk)14:17, 31 October 2009 (UTC)[reply]

No, there are lot of banners that overload note parameters with, eg, dates (|afd=20 July 2009, etc), these wouldn't be recognised. IIRC the default of this templatewas no, but was changed after we realised that...Happy‑melon19:09, 31 October 2009 (UTC)[reply]

Why would such parameters need to use{{yesno}}, though?PC78 (talk)19:47, 31 October 2009 (UTC)[reply]

Because they're mapped to|note #= parameters in WPBM: the parameter is overloaded to both trigger the note by its presence, and to contain information that the note uses.Happy‑melon19:54, 31 October 2009 (UTC)[reply]

Just for curiosity: how can this new Template (1 yr now) be so multi-used (~3mln?). Was there a predecessor? Just curious. -DePiep (talk)01:04, 10 July 2010 (UTC)[reply]

It was spun out from{{WPBannerMeta}}, which already had several million transclusions; by being integrated into that template, it gained most of its transclusions immediately.Happy‑melon22:48, 10 July 2010 (UTC)[reply]

At the risk of sounding stupid, why is this template needed? Why not just type in "yes" or "no"?D O N D E groovily Talk to me04:14, 4 January 2011 (UTC)[reply]

This is a normalisation template: it maps several different inputs into one output, thereby increasing standardisation. It's only "needed" in the same way that the templates it calls are 'needed': you could do away with them too and write the table code directly onto the page; but that would be a silly idea, because it would a) result in less standardisation, b) increase the amount of work each user would need to do to use the downstream page, and c) increase the size of the code on that downstream page. Like all templates, this one serves to encapsulate functionality which is used in many places so it can be easily called upon when needed.Happy‑melon15:29, 4 January 2011 (UTC)[reply]

Ifblank is undefined butdef is defined and the input is blank, should the output bedef? — Martin(MSGJ · talk)20:00, 28 March 2011 (UTC)[reply]

No, obviously. Fallback fromblank tono does make sense. Asblank is the companion ofno, anddef is the companion ofyes, we should not fallback to the opposite companion. --Ans (talk)12:15, 5 June 2020 (UTC)[reply]

Template:Yesno/testcases is an example of a problem

I tried to use this template in{{Infobox software license}} to conditionally include categories. I ran into a problem withWTFPL which contains this code:OSI approved = No<ref>{{cite web|url=http://www.opensource.org/minutes20090304|title=OSI Board Meeting Minutes, Wednesday, March 4, 2009}}</ref>.

Specifically,{{yesno|No<ref>...</ref>}} returns the default of "yes." I could change the default to "no," but then{{yesno|Yes<ref>...</ref>}} would also return no.

Can someone identify a way to fix this? – Pnm (talk)21:59, 10 January 2012 (UTC)[reply]

Fundamentally,No<ref>...</ref> isnotNo, so it's debatable whether anything is, per se, "broken"! But omitting refs from consideration is a perfectly reasonable new feature request. Unfortunately, bar using some of the godawful string functions to pick out the first couple of characters, there isn't really any way of doing this, AFAIK. And given how deeply this template is buried in a lot of other callstacks, incorporating string functions into it would most likelymassacre the performance of a huge range of templates.Happy‑melon22:19, 10 January 2012 (UTC)[reply]

Using{{str letter/trim}} I got it working inTemplate:Yesno/sandbox. Sounds like that wouldn't be a good way to fix it here, is that right? –Pnm (talk)22:23, 10 January 2012 (UTC)[reply]

Established atTemplate:Yesno2 until the problem can be fixed here. – Pnm (talk)22:39, 10 January 2012 (UTC)[reply]

Comments in the source scode says:

... |0        = {{{no|<!-- null -->}}} |         = {{{blank|{{{no|<!-- null -->}}}}}}...

I think the returned value is not Null (like U+0000 or ASCII 0x00 really?), but "Nullstring" (zero length string, sometimes called a "Blank"). -DePiep (talk)13:19, 27 June 2012 (UTC)[reply]

I suppose you are correct, but it is worth changing? — Martin(MSGJ · talk)14:30, 27 June 2012 (UTC)[reply]

No ;-) , or combine it with a next material edit. It's just checking my own knowledge. -DePiep (talk)15:22, 27 June 2012 (UTC)[reply]

I've been thinking about which values of this template are actually the most used, after the discussion atWP:VPT#Template:Yesno and Wikid77's proposed{{yesno/sandbox2}}. This version assumes that the "yes" and "no" values are most used, and therefore should be highest in the switch statement, but I don't think this is necessarily the case. When a template like{{WikiProject United States}} is transcluded, the vast majority of the parameters checked with yesno aren't specified at all,so the "¬" value may actually be the most used in the yesno switch. I think the rest are probably, in order, "yes", the blank value, "no", "y", "n", "1", and "0". However, it would be good to get some actual numbers to work out the most efficient order. Does anyone have any ideas on how this could be done? —Mr. Stradivarius^{♪ talk ♪}13:26, 24 March 2013 (UTC)[reply]

D'oh, that's not right at all, is it... if the user doesn't specify a parameter, then the value passed to yesno will be blank, not "¬". So then the order would be blank, "yes", "no", "y", "n", "1", "0", and "¬". Still, that's still slightly different from the order in sandbox2. —Mr. Stradivarius^{♪ talk ♪}21:24, 24 March 2013 (UTC)[reply]

And then again, looking at{{WPBannerMeta}}, the yesno instances there mostly have the form{{yesno|{{{parameter|¬}}}|¬=¬}}, which means that "¬" might be the most-used anyway. It goes to show that we should do a proper analysis before changing the template. Also, this situation may change it WPBannerMeta gets rewritten using Lua, which could happen in the conceivably close future. One question that could help resolve this: which templates, other than WPBannerMeta, is Yesno used in the most? Analysing those invocations first may be the fastest way to determine the actual most-used values. —Mr. Stradivarius on tour^{♪ talk ♪}02:59, 25 March 2013 (UTC)[reply]

Hi please switch the template toModule:Yesno please176.250.150.202 (talk)18:15, 28 February 2014 (UTC)[reply]

That's a bad idea - the code for the module does a slightly different thing than the code for the template, so switching would end up breaking millions of pages. Also, because there is an initial overhead incurred by starting up Lua, and because the template code for this template is so simple, doing so would actually be slower than the current setup. —Mr. Stradivarius on tour^{♪ talk ♪}21:39, 28 February 2014 (UTC)[reply]

Should this template support "true" for yes and "false" for no? Those are pretty standard Boolean values in most programming languages. I've mocked it uphere. --Ahecht (TALK
PAGE)22:46, 3 March 2015 (UTC)[reply]

Thisedit request has been answered. Set the|answered= parameter tono to reactivate your request.

Since there was no objection to my proposal for 4 months, I formally propose adding true and false per thesandbox.Ahecht (TALK
PAGE)14:18, 2 July 2015 (UTC)[reply]

 Done — Martin(MSGJ · talk)14:46, 2 July 2015 (UTC)[reply]

Thisedit request has been answered. Set the|answered= parameter tono to reactivate your request.

This should test for those values, too. A discussion atTemplate talk:As of indicates that some people prefer and have been using these values, so any attempt to add a YesNo test to such templates, to provide additional functionality, will fail for any instances using "on" or "off". We basically have no idea how many that is, but it's a trivial fix to add them here. — SMcCandlish ☺☏¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 23:40, 27 November 2015 (UTC)[reply]

Not done: I don't see a consensus there for adding "on" and "off" here in that discussion. Considering that this template is used on millions of pages, and often multiple times per page, we should make sure that there is a need to add more parameters before potentially slowing down the time this template takes to render. An alternative might be to add "on" and "off" as aliases inTemplate:As of if it is popular in that template in particular. Alternatively, if you want to find out how many uses there are, adding a tracking category toTemplate:As of can do that easily. —Mr. Stradivarius^{♪ talk ♪}02:51, 28 November 2015 (UTC)[reply]

Over two years with no substantive objection, so I'm reopening this. The code is inTemplate:Yesno/sandbox, tested at bottom ofTemplate:Yesno/testcases (produces same output with on/off as it does with yes/no, etc.).

It's not just about{{as of}}; a lot of templates use on/off, and some of them need this logic. If this isn't implemented here, I could just fork a{{Yesno2}} to resolve it, butWP:TFD will merge them later, so may as well do it right the first time. Lack of this has been holding up fixing{{Post-nominals}} (it is documented with and thus is mostly deployed with|on=) which has long been ungrammatically leaving out punctuation by default, when it needs to do the opposite and use commas unless told not to for some context-specific reason (e.g. to save space in a very tight table, or to mimic the exact formatting material in a quotation). I have the fixed version at{{post-nominals/sandbox}} now, but{{post-nominals/sandbox|comma=off}} does not work. The alternative would be to re-do the entire template in much more bletcherous code that doesn't use{{yesno}}, but that defeats the purpose of having{{yesno}}. More to the point, the purpose of{{yesno}} is to parse all the common positive/negative inputs people use. On/off is among those, and was just left out as an oversight.

Adding a single additional pair of yes/no tests to the switch has no measurable impact on performance. Some of our templates have 100+ cases to test for; two long ones (not quite that long) I've worked on areTemplate:S-rail/lines andTemplate:Single chart, neither of which cause any problems for anyone.
 — SMcCandlish☏¢ >^ʌⱷ҅_ᴥⱷ^ʌ< 10:43, 11 December 2017 (UTC)[reply]

Not done for now: There was an objection two years ago. (Whether you call it substantive is subjective.) And you still haven't shown consensus for this change. — Martin(MSGJ · talk)12:23, 12 December 2017 (UTC)[reply]

Fine, I'll just RfC it, but please seeWP:EDITING andWP:NOT#BUREAUCRACY andWP:CONSENSUS policies. Lack of non-addressed objections constitutes consensus to proceed, or WP would have virtually no content of any kind and would have failed the month it opened. — SMcCandlish☏¢ >^ʌⱷ҅_ᴥⱷ^ʌ< 21:23, 12 December 2017 (UTC)[reply]

Re-enabling edit request, per RfC below. — SMcCandlish☏¢ 😼 06:25, 23 January 2018 (UTC)[reply]

Done — Martin(MSGJ · talk)08:37, 23 January 2018 (UTC)[reply]

A while back, I created wrapper templates,{{YesNo-Yes}} and{{YesNo-No}}, for the two most commonly used sets of parameters: those to return "yes" unless an explicit negative value is provided, and the opposite. Forgot to mention it here. — SMcCandlish ☺☏¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 23:44, 27 November 2015 (UTC)[reply]

Thisedit request has been answered. Set the|answered= parameter tono to reactivate your request.

Please add<noinclude>{{subst:tfm|If affirmed}}</noinclude> to this template as I have nominated it for merging.{{3x|p}}ery (talk)19:05, 22 February 2019 (UTC)[reply]

 Not done Added to doc, but no need to causethat much server load (11 million + pages..) for a notice displayed only on this page.Galobtter (pingó mió)19:18, 22 February 2019 (UTC)[reply]

Thisedit request has been answered. Set the|answered= parameter tono to reactivate your request.

Please add{{{else}}} parameter as shownhere, so wecan simply write{{yesno|{{{1}}}|yes=123|else=456}} rather than{{yesno|{{{1}}}|yes=123|no=456|blank=456|¬=456|def=456}} --Ans (talk)03:33, 3 June 2020 (UTC)[reply]

 Question: why would you use "else" as a fallback for "yes"? Also, unless you are using the esoteric ¬ (which has very limited use) you can use just "no" as a fallback for blank. — Martin(MSGJ · talk)09:23, 3 June 2020 (UTC)[reply]

Since, in addition to{{yesno|{{{1}}}|yes=123|else=456}}, we sometimes also need{{yesno|{{{1}}}|no=123|else=456}} which is equivalent to{{yesno|{{{1}}}|no=123|yes=456|blank=456|¬=456|def=456}}.

Note: My diff link has been updated to fix my bug --Ans (talk)12:15, 3 June 2020 (UTC)[reply]

I would like to see a use-case, a situation in which the proposed change would be beneficial, where it would simplify matters. --Redrose64 🌹 (talk)22:37, 3 June 2020 (UTC)[reply]

@Redrose64: So we can use{{yesno|yes=show this text|else=otherwise show this text}} or{{yesno|no=show this text|else=otherwise show this text}} like we ever did withTemplate:Ifyes andTemplate:Ifno respectively. --Ans (talk)07:24, 5 June 2020 (UTC)[reply]

But where would this be used? --Redrose64 🌹 (talk)18:15, 5 June 2020 (UTC)[reply]

 Not done for now: please establish aconsensus for this alterationbefore using the{{edit protected}} template.Izno (talk)01:51, 5 June 2020 (UTC)[reply]

Thisedit request has been answered. Set the|answered= parameter tono to reactivate your request.

Please add "t" and "f" as alternative forms of "true" and "false", respectively.AntiCompositeNumber (talk)18:16, 24 August 2020 (UTC)[reply]

This seems appropriate givenModule:Yesno already supports them.Nardog (talk)18:24, 24 August 2020 (UTC)[reply]

 Not done (not yet) - this needs to be worked up in the sandbox and tested first. —xaosflux^Talk19:57, 25 August 2020 (UTC)[reply]

 Added to the sandbox, request reactivated.* Pppery *_{it has begun...}02:17, 26 August 2020 (UTC)[reply]

 Done - of course any admin should revert without delay if unforseen issues are caused. —xaosflux^Talk03:16, 28 August 2020 (UTC)[reply]

OnTemplate:Yesno-yes which outputs "yes" to everything not explicitly false, the options for blank, def and ¬ should probably fall back to {{{yes}}} so the syntax would be shorter. The code for this is on the/sandbox now. — Martin(MSGJ · talk)23:08, 19 November 2020 (UTC)[reply]

I one hundred percent agree but that's never gonna happen. Making sure noting breaks after such a change would require massive work considering the 500000 transclusions. When I merged{{if affirmed}} here with a fraction of the transclusions it took a long time with quite sophisticated queries to make sure nothing broke and even then I managed to temporarily break some signpost templates. --Trialpears (talk)23:40, 19 November 2020‎ (UTC)[reply]

Well never say never ... but I take the point that the costs seem to outweigh the advantages. The other thing I don't like about this template, is that {{{no}}} defaults to "no". No doubt that suited the purpose of the editor who created it originally, but it is a little incongruous with the default behaviour of the main template where {{{no}}} defaults to blank. — Martin(MSGJ · talk)12:20, 23 November 2020 (UTC)[reply]

I think that the intent was to return an explicit value whichever, rather than an explicit "yes" and implicit "no". This difference was recognised as long ago as the 1830s when theGreat Western Railway decided to signal their trains by means of green or red flags (later replaced by boards) instead of using a flag for "danger" and an absence of a flag for "all right", as other railways did. --Redrose64 🌹 (talk)21:53, 23 November 2020 (UTC)[reply]

I've createdTemplate:Yesno-yes/fallback, which implements this.Tol (talk |contribs) @00:36, 19 November 2021 (UTC)[reply]

Is there a better alternative that achieves the functionality of Martin/MSGJ's proposal than this?

{{yesno|{{yesno-yes|{{{1|}}}}}|yes=A|no=B}}}

Daask (talk)21:37, 7 June 2024 (UTC)[reply]

If you put|0        = {{{no|no}}} instead of|0        = {{{no|<!-- null -->}}}, the template will work better or at least more intuitive (with clear yes or no).

I suggest making template{{Either yes or no}} (with this title instead of 'yes/no' because{{yes/no}} already exists as redirect to{{yesno}}; instead of title 'Either yes or no' can be other title if more appropriate) for this purpose, with same source code except the change suggested above; there are cases when this is needed, simplifying the code (e.g. #if: or additional parameters not needed in such cases). --5.43.72.55 (talk)04:06, 10 December 2020 (UTC)[reply]

I think{{yesno-yes}} can be redirected to this template ({{yesno}}). It currently contains transclusion of{{yesno}} with some substing but has{{yesno}}'s documentation and talk page redirecting to{{yesno}}'s talk page. If not same, documentation should be made for{{yesno-yes}} to explain where it's different from{{yesno}} (and separate talk page enabled by removing redirect to this talk page). --109.163.168.201 (talk)19:29, 12 December 2020 (UTC)[reply]

It's a wrapper for this template. There is some information in "Comparison with related templates" on the doc page. — Martin(MSGJ · talk)19:31, 12 December 2020 (UTC)[reply]

Due to the<!-- null --> comments that are the defaults for the{{{no}}} parameter, the template ends up giving incorrect results when substed inside a substed #if for the "no" and "blank" cases. This is due to the differing behaviour of{{#if:<!-- comment -->|T|F}} compared to{{subst:#if:<!-- comment -->|T|F}}.

I don't know if the differing #if behaviour is intentional (in which case this template should be fixed by removing the<!-- null --> comments) or if it is is a bug in MediaWiki.GreenComputer (talk)15:26, 28 December 2020 (UTC)[reply]

It's not a MediaWiki bug, it's expected behaviour. The{{#if:...}} construct tests for whether the first argument is the empty string or not, and<!-- comment --> is not an empty string, it is a validHTML comment. --Redrose64 🌹 (talk)18:06, 28 December 2020 (UTC)[reply]

@Redrose64: Surely that would mean that the non-subst case{{#if:<!-- comment -->|T|F}} is buggy, as it currently results in "F" despite the first argument containing a comment?GreenComputer (talk)22:05, 28 December 2020 (UTC)[reply]

@Redrose64 More pertinently, doesn't this mean the template returns<!-- null --> instead of the empty string during substitution under certain circumstances (e.g. if|no= is undefined and the input is0), which could cause unexpected downstream behaviour? Is there a good reason for this difference between the substituted and unsubstituted cases?Theknightwho (talk)17:11, 16 November 2025 (UTC)[reply]

I'm not aMediaWiki developer, I wasn't a participant in the discussions that defined the specifications of the various #if: parser functions. I just use them, and occasionally attempt to explainwhat they do (and notwhy they do it) to those who have problems in using them. --Redrose64 🌹 (talk)23:22, 16 November 2025 (UTC)[reply]

It isrequested that an edit be made to thefully protected template atTemplate:Yesno. (edit ·history ·last ·links ·sandbox ·edit sandbox ·sandbox history ·sandbox last edit ·sandbox diff ·test cases ·transclusion count ·protection log) This template must be followed by acomplete and specific description of the request, so that an editor unfamiliar with the subject matter could complete the requested edit immediately. Edit requests to fully protected pages should only be used for edits that are eitheruncontroversial or supported byconsensus. If the proposed edit might be controversial, discuss it on the protected page's talk pagebefore using this template. Consider making changes first to thetemplate's sandbox andtest them thoroughly here before submitting an edit request. To request that a page be protected or unprotected, make aprotection request. When the request has been completed or denied, please add the|answered=yes parameter to deactivate the template.

To remove the<!-- null --> comments, as these cause differences in behaviour between substitution and transclusion.

For example, the input{{yesno|0}} transcludes the empty string, since|no= has not been defined. On the other hand,{{subst:yesno|0}} substitutes the text<!-- null -->. The reason for this is because HTML comments are removed prior to template expansion during transclusion (e.g.{{{no|<!-- null -->}}} resolves to{{{no|}}}), but this isnot the case during substitution, where HTML comments are simply treated like any other text.

This is a problem, because that unexpected output of<!-- null --> can cause any number of downstream effects (e.g.{{#if:{{yesno|0}}|foo|bar}} transcludesbar, whereas{{subst:#if:{{subst:yesno|0}}|foo|bar}} substitutesfoo).

Diff:

Theknightwho (talk)23:47, 16 November 2025 (UTC)[reply]

 Not done (as to the immediate edit request). I don't think this template is designed to be subst'd, and this string is in the discussion right above this one. Of course, feel free to continue discussing improvements to the template below - should a consensus for change emerge (and after extensive testing is successful), reactivate the edit request. —xaosflux^Talk19:11, 17 November 2025 (UTC)[reply]

@Xaosflux Then why does it includesafesubst:? I don't see how what you've said makes any sense at all, so I'm reopening this.Theknightwho (talk)17:04, 19 November 2025 (UTC)[reply]

I agree this should be done, although the fact that the parser behaves differently on transclude and subst may deserve a Phabricator report.* Pppery *_{it has begun...}22:26, 20 November 2025 (UTC)[reply]

@Xaosflux: Could you please respond to this?* Pppery *_{it has begun...}16:56, 25 November 2025 (UTC)[reply]

• Wikipedia fully protected edit requests