Many templates, on English wikipedia at least, have boolean parameters which take any non-empty value as "true". Commonly entered as "option=y", but "option=0" would work just as well.
This is sufficiently common that I think a parameter type for this would be useful. The existing "boolean" type uses 0/1, which doesn't work; the pattern is blank/nonblank.
I agree, it would be very useful; currently I documantate such fields as unknown type. I think the most common way to store them is “1”, probably customer applications (such as VisualEditor) should use this.
It is more complicated than that, suppose an infobox has a value that determines if someone has grandchildren. This can either be true, false or unknown. Leaving it blank may mean that the editor simply doesn't know if someone has grandchildren, as opposed to setting it deliberately as false.
Still, it might be a good idea to a way to enter a set of truthy or falsey values allowed in a template.
The grandchildren example is already documentable with the boolean type. This is about the parameters where all values are evaluated as true. Let’s suppose there’s a template which produces a table that may have a border, but doesn’t have by default. The border parameter is used to make it bordered. The following code evaluates it in the template:
<table {{#if:{{{border|}}}|style="border:1px solid;"}}>
In this case, there can’t be unknown as the editor should know whether they want a border. Any value is considered true so I can’t enter every truthy value.
I'd say the benefits of allowing specific values for true outweigh the costs. It is especially important in the context of templatedata, as it is meant to bring a bit of sanity to the templating chaos.
Currently with that template any gibberish can mean true, e.g. "...........", "zbzbzb", etc.
Like noted before the solution might be to define truthy and falsey values, e.g.:
True values: [1, yes, y, true] - default = 1
False values: [null, 0 , false, n, no] - default = null
Null would be equivalent to setting false, e.g:
{{mytable| border = }}
Or
{{mytable}}
Perhaps these could be set as sitewide defaults to make it less burdensome, and eliminate the need to set it in every template while still maintaining some standards. In fact, in english wikipedia, that's what seems to do.
"... that's what https://en.wikipedia.org/w/index.php?title=Template:Yesno seems to do".
I think I haven’t written that each template should store its truthy and falsey values, of course most of the time it’s not needed. (The rest should be rewritten to at least understand the standard values.) I wrote that we should have two boolean types:
Personally, it seems that the current state works for most cases. Two state is fine, but it will probably need to be a different phabricator request, as the current spec was specifically designed to have 3 states if it is important for several wikis.
Maybe a templatedata flag (or option) for any truthy, and null falsey.
The complexity of coming up with which of the hundreds of definitions of truthy we'd use are exactly why we didn't implement this. I don't think we'd likely get consensus on which definition to use.
The thing is that for better or worse MediaWiki got people used to the notion that a template parameter with a "any text" is true, and no text is false because of the {{#if parser function. Although that parser function isn't part of mediawiki, there is likely a core magic word that treats it like that.
It will be hard to convince people to change thousands of templates to change this assumption, but it will be easy to add to the spec and make it to treat it differently e.g.:
Parameter = border
{{mytable | border = 1 }} -> True
{{mytable | border = }} -> false
{{mytable}} -> false
Changing any template that doesn't fit those assumptions is way easier than changing most templates to consider "0" as false.
Other alternatives include setting a new magic word, that evaluates to truthy or falsey ,e.g. {{+}} or {{-}}, {{✓}} or {{x}}. These could still substitute the above values. The final alternative is to set an interface page that defines the values of truthy and falsey.
New magic words or parser functions are bad solutions. As they just add to the complexity instead of reducing it.
One example of a core functionality that works this way is the default template argument, e.g.:
{{{border|1}}}
It will only fallback to red if border has no string. So I guess you'd easily get consensus for truthy that works like that because that's what mediawiki established as a norm, and has used close to a decade (or more).
I'm a little worried about this approach, which seems to indicate surprising and unwanted results:
{{mytable |border = false}} -> True? {{mytable |border = no}} -> True?
Maybe we should have better logic than that in our templates.
It’s about existing templates’ existing transclusions. One won’t go through all transclusions one by one to check if there are any “surprising” values (which may be not as surprising, depending on the parameter name) just to make sure VisualEditor won’t mess up everything. So yes, these values should be accepted as “true”, although no tools are required to store them this way.
> I'm a little worried about this approach, which seems to indicate surprising and unwanted results:
Well, previously wikitext editing couldn't help the editor with which values are "default", but VisualEditor and the newer source editor have a dialog that can help. So it is easier to change fewer templates to conform to the null boolean (value / NULL).
Alternatively, in other instances, the template editors can always change it to accept something like this:
<table {{#if:{{yesno|{{{border}}}}}|style="border:1px solid;"}}>
So the template can keep working with minimal changes. The point remains that these changes should preferably be the exception not the rule.
Here's a crazy idea:
Instead of changing templateData to conform to editors' strange templating "techniques", a flag / setting can be added to Extension:Parserfunctions to treat 1 / 0 as true / false in addition to the default. If this is customizable then that would eliminate the need for template:yesno as admins could set it wiki wide. So in effect the two template calls below would be essentially the same:
MediaWiki:Boolean-parserfunction true = 1 , true, y , yes, default = *string* false = 0, false, n, no , default = *null*
mytable template
{{#if:border|red-border| blue-border}}
{{mytable | border = true}} === red-border
{{mytable | border = 1}} === blue-border
{{mytable | border = false}} === blue-border
{{mytable | border = 0 }} blue-border{{mytable | border = true}} === red-border
{{mytable | border = 1}} === red-border{{#if:}} shouldn’t be changed. It works this way for over ten years, simply it cannot be seen what it will break in and outside of the Wikimedia world.
I'm thinking that actually should be changed, if the behavior is truly as surprising as this "War = Peace" construction seems to be.
MediaWiki has a process for announcing potentially disruptive changes, so that people can prepare for them. There's a series of disruptive changes being planned now, and no clear reason why using standard conventions for marking a value as false couldn't be added to the list.
Let's see: User:Tim Starling (WMF), is this "false=true" thing in template logic part of Parsing's remit? Or should it be brought to another team's notice?
If we change, it can break really many templates, I don’t know about any other such big changes in MediaWiki. On the one hand, we don’t have to create {{yesno}} on many wikis; on the other hand, it needs i18n, which makes it less portable, or can cause problems even within one language. For example, “nem” means “no” in Hungarian, which would have false value. But it also means “gender/sex”, which should be true in an infobox building template:
{{#if:{{{1|}}}|<tr><th>{{{1}}}</th><td>{{{2|}}}</td></tr>}}
which is called as
{{Infobox/General|Nem|Férfi<!-- Male -->}}
Lua also interprets the string “false” as true:
a = "false"
if a then
return 1
else
return 0
end
returns 1.
Compared to Parsing/Replacing Tidy, I think that this is a pretty small change. See, for example, these 1,000+ pages at huwiki that will have formatting errors – and that's just for one of multiple changes in that project.
It's important to remember that no templates require editors to put in |para=false to evaluate an expression as true. No changes will need to be made to the templates. So what we're really looking at is a tiny percentage of template uses that might have unexpected results. Unless your wiki has someone who has been deliberately and systematically adding |para=false because he thinks it's fun to see MediaWiki's templates evaluate "backwards" from common programming conventions, this change is unlikely to affect many pages.
What will change around <br>’s? They are auto-closing tags so any form should be equivalent to the XHTML <br />, shouldn’t it?
As I mentioned some kilobytes before, I have written “no” in template parameter, which was processed as true, but not because I think “it’s fun to see MediaWiki’s templates evaluate ‘backwards’ from common programming conventions”, just because given the parameter name and the meaning of the filled parameter, it made sense this way.
I still don’t know why is it worth to change a function after ten years: it doesn’t make extension programming easier as we still need a two-state and a three-state boolean type to handle properly if there’s an undefined state. However, it makes many things backwards incompatible and is way harder to fix than some HTML tags.
Those pages don't have <br>. They all have </br>, which isn't 'legal' according to any standard.
I know this search is for </br>. I meant “<br>’s” for all tags with the tag name “br”, i.e. <br>, <br />, and </br>. I know the latter is “illegal”, I wondered what will actually change around it. If the only change will be that from then on it won’t be valid HTML5, but browsers display it as now, than it’s not a problem. If it will be rendered in another way, e.g. hidden or displayed as it is (as text), it should be changed, which is a very easy task for any bot.
It will be displayed in articles as plain text (similar to what you'd see now if it were nowiki'd). And, yes, this is a very easy task for a bot.
There is a fairly long series of similar changes being planned for this year. Some are easily fixed by bot (assuming that your wiki has a bot and an operator willing to do this; not all of them do), and others are not (e.g., wikitext tables that are missing the closing |} tag).
Thank you for clarifying. This very wiki (huwiki) has quite a number of bots, so fixing here won’t be a problem.
The {{#if parser functions have no effect on MediaWiki whatsoever because they are not part of it, and are merely added by an extension. A true boolean should leave no room for ambiguity, and currently users are simply making up their own definitions of true and false, which again doesn't exist in wikitext.
So, giving it more thought, the lesser evil here would probably be introducing the notion of boolean to mediawiki wikitext. Or at the very least to Wikimedia, it would be trivial for them to add new global magic words / parser functions for true and false. Like so:
{{+}} - > true
{{|}} - > false
{{mytable | border = {{+}} }}
{{mytable | border = {{|}} }}
As both + and | are invalid characters in page titles, this would work seamlessly, and it can transclude whatever truthy values people expect, although some other characters could be used.
It would remain backward compatible even with lua, and would probably encourage users to use a much saner symbol for true and false. It also wouldn't need any i18n, because these are just symbols, and have no meaning aside from what people assign to them.
Making false explicit is always superior to automatically assigning it when a string doesn't exist.
I realize this case looks a lot like a traditional boolean, but it's more like a "defined" vs. "undefined".
So in wikitext, we only have defined vs undefined, which is actually closer to true booleans than anything else we have in wikitext. On top of that we built boolean values, which are basically 'template specific' and as such don't truly exist in wikitext, yet that not existing element seems what we are trying to model in VE templatedata.
It's logical that this causes us to run into some problems. We have to remember however that this is a common case, simply because it is more readable to write: {{table}} and {{table|border=y}} than it is to write {{table|border=0}} and {{table|border=1}}. I thus think that we probably need to be a bit smarter about this in TemplateData. Maybe boolean can be a subtype that is a specific version of: defined with a value and undefined with a default.
It is true that this is more like defined vs undefined. It doesn't however change the fact that the graphical interface has to somehow represent those 3 states. Not selecting anything in some templates may be equal to "true", and adding text may be false. It wouldn't be surprising if some wikipedias treat this as the norm, considering that some languages write from right to left, and others from top to down, which is an odd concept for some.
So despite all the alternatives presented here, it seems like a deliberate spec (1 /0) is certainly the superior approach, and that the developers made the right call and shouldn't change or augment it. As JDforrester noted, attempting to treat true and false as it works in the parser function may fix a lot of templates but may break even more.
Perhaps an alternative is a deliberate enum like templatedata construct that allows options like "values = {"yes" = "y", "no" = y}".