Extension talk:TemplateData

Jump to navigation Jump to search

About this board

Options to select different date formats

George Ho (talkcontribs)

I was given a suggestion at Topic:Unpy3y332x9rk1ji that I request some change on TemplateData to allow users to select different date formats. Here I am suggesting this especially for consistency with Wikipedia articles.

The current default format is "YYYY-MM-DD". I hope that the calendar feature would allow "DD Mon Year" and "Mon DD, Year" someday. If that is too complicated, alternatively, I made a suggestion there that an editor should have an option to manually type a date in a date parameter, similar to UploadWizard's.

Whatamidoing (WMF) (talkcontribs)

This function already exists at the English Wikipedia, and some other wikis that have up-to-date copies of the CS1 modules. If you combine |date=2018-11-20 with |df=dmy, then it will automagically display the specified date format to the reader. Better still, this parameter is something that could be added via AWB or bot to every citation template in every article that has the {{use dmy dates}} template in it, and the corresponding codes could be added for other date formats. Then editors wouldn't need to switch back and forth between formats when editing different articles, or to specify anything manually.

George Ho (talkcontribs)

I see that it works on "date" parameter but not "accessdate" parameter; see this diff. BTW, scrolling down to see the "Date format" parameter amongst the "Optional parameters" column can be a pain; the column is very long.

EDIT: I re-tested the "URL access date" parameter; I realize that the auto date formatting is not supported for that parameter.

George Ho (talkcontribs)

I'm becoming annoyed that the calendar sub-feature won't allow inserting of month and year without day for monthly magazines. (talkcontribs)

Whatamidoing: It won't solve the underlying problem. The issue is that it relies on ISO date which is deliberately limited. For instance it can't record any historical dates before the 1800s. The primary concern is that for a tool that is meant to serve multilingual wikis it fails to address the fact that there are several calendars (e.g. arabic, etc) currently in use around the world. It would be perfect if there was a single unambiguous calendar to denote all existing dates (both ancient and current), but such a convenient system doesn't exist. Dates are really complicated concepts.

George Ho: This extension is a bit like a documentation manual, it only specifies how things must work but it can't do anything to actually require that tools that implement it work that way. So while it certainly needs a way to determine how to format dates, or even specify different calendars it is up to each editing tool to implement it properly.

However, the request for adding just month and year needs to be logged in the specific extension talk page or the bug tracker because the ISO standard already supports it.

George Ho (talkcontribs)

You mean separate "Topic", right? (talkcontribs)

Yes, either that or by following Bugreport, and reporting it to phabricator.

Whatamidoing (WMF) (talkcontribs)
Whatamidoing (WMF) (talkcontribs)

> it relies on ISO date which is deliberately limited. For instance it can't record any historical dates before the 1800s.

True, but it's unlikely that websites, magazines, and news articles from the 1700s or earlier will be commonly cited on Wikipedia, right? ;-) (talkcontribs)

Err, the principle of an encyclopedia is documenting historical events. Wikipedia has distorted that and basically become triviapedia as well as futurepedia, but even if one wants to talk about current events, it is easy to find cases that don't neatly fit into the Gregorian calendar, e.g. this article (https://bn.wikipedia.org/wiki/%E0%A6%AC%E0%A7%8D%E0%A6%AF%E0%A6%BE%E0%A6%B8%E0%A6%A8%E0%A6%97%E0%A6%B0).

Feel free to try and explain how one would go about adding that date using the inflexible ISO. The same applies to historical dates on pages like https://lrc.wikipedia.org/wiki/%D8%B5%D9%84%D8%A7%D8%AD_%D8%A7%D9%84%D8%AF%DB%8C%D9%86_%D8%A3%DB%8C%DB%88%D8%A8%D9%8A.

Also, while the gregorian calendar is in the year 2018, the arabic calendar is current somewhere around 1441 (according to google). So recent news articles can demonstrably contain dates earlier than 1700.

The suggestion here is legitimate even if developers don't have the time or interest to implement it.

Whatamidoing (WMF) (talkcontribs)

Even if you managed to find a website from the 1700s, most Wikipedias would discourage citing it. (talkcontribs)

Either you're wildly confused or you simply don't understand what's being asked here. Some views seem to include:

  1. Emphasis on citations. Dates aren't only used in citations, they can be used in descriptions boxes containing a person born 1000 years ago, or in a quote template or in any number of near infinite use-cases.
  2. The notion that most Wikipedias use the gregorian calendar when citing current events. It is mostly irrelevant. A template can express dates using any calendar or even using localized digits.

The world doesn't revolve around English or even latin based calendars. To give a concrete example, today's date is 2018-11-13 (gregorian) === Rabiʻ I 5, 1440 (arabic calendar). There is nothing wrong with citing an event today, and state that it happened in 1440 nor is there anything wrong in citing the date using localized digits or calendars.

Introducing extra calendars to templatedata would resolve most problems remaining problems.

Whatamidoing (WMF) (talkcontribs)

This feature is almost never used outside of a particular set of citation templates. (talkcontribs)

The fact is the parameter was about as useful as bullets without a gun, all it did was document that a particular parameter accepts dates. Only recently, did it get some use by way of templatewizard. There are also more than 300000 templates (see https://en.wikipedia.org/wiki/Template:Infobox_product/doc) currently using dates, along with a similar a hacky {{xxx|month|year|date}} format, that's without even counting uses outside the bigger wikis.

There was simply no motivation for anyone aside from bored users to add that templatedata definition to templates. The notion that it won't get used because it wasn't used before makes no sense. Guns didn't get used before they became available, now some people have gone as far as claiming that it is some sort of human right to wield such things.

Reply to "Options to select different date formats"

Partial dates should be supported

Summary by Jdforrester (WMF)
George Ho (talkcontribs)

A monthly magazine, like Vibe and Men's Health, uses just month and year. Some, if not many, academic journals don't use full date, e.g. this one, that one, and another source that uses season and year (but can't think an example at the moment). However, the TemplateWizard currently wouldn't allow insertion of partial date; instead, either inserting full date and leaving a "date" parameter blank are the only available options to me.

If partial dates, e.g. month-year or season-year, are to be supported, I would appreciate it. Thanks.

Ciencia Al Poder (talkcontribs)

How about marking that parameter as plain text instead of date?

George Ho (talkcontribs)

Either I think I almost forgot that, or I've not clarified well. Either way, I should say that there's an option to insert the parameter without filling in anything in the TemplateWizard but then filling the paramater manually. (talkcontribs)

Err, partial dates are already supported by Templatedata because it supports ISO_8601. TemplateWizard, and the related mediawiki widget would have to support it if deemed useful. See the linked wikipedia page for examples.

Of course if this is fully implemented in templatewizard or visualeditor then editors must prepare themselves for very weird dates. Stuff like --11-09 and 2018-313 or 2018-W45 is perfectly acceptable with iso, according to that page.

George Ho (talkcontribs)

Confusing, could use an overview and links to examples

Summary by
Skierpage (talkcontribs)

(Hi!) I was struggling over on Lyrics.wikia with all the MediaWiki markup in their page skeletons when all you really want is to enter some data {{band: "Corduroy", album: "Out of Here", song:"Mini"}} and have a song template produce the markup. It seems like TemplateData could really help, so I came here to remind myself about it. Alas the extension page lacks a simple explanation of how TemplateData interacts with actual templates, nor does nor does it give examples of it in use. The page says "This information is available as a nicely-formatted table for end-users", but my recollection is the stuff you put in the template data is somehow made available to other templates for them to output in their chosen wiki markup. There's a conceptual piece missing (or a screw loose in the reader...).

Whatamidoing (WMF) (talkcontribs)

TemplateData doesn't affect how the template behaves. It only tells VisualEditor which boxes to show when you insert a template.

Reply to "Confusing, could use an overview and links to examples"
קיפודנחש (talkcontribs)

one of the oldest, and widely used parser function is #switch

when a template uses a parameter as feeder to #switch, templatedata should be able to list the "legal" values, and also allow indication whether the #switch expression has #default clause, so a wizard will be able to provide a drop-down with the values, and optionally make it a "drop down combobox" which allows the user to feed a value not in the list.

if such syntax already exists, and it's only my ignorance speaking, please teach me. otherwise, please add switch property (call it whatever - html uses "select" and "options" i think), e.g.

"params": {
  "bla": {
    "description": "bla bla bla",
    "switch": ["preset value 1", "preset value 2" ...],
    "other": true


Whatamidoing (WMF) (talkcontribs)
קיפודנחש (talkcontribs)

no. i'd like to see phab:T144155 also solved, but it's not the same issue.

in hewiki, we have "template wizard" since circa 2012, so it predates templatedata. we created our own "metadata" spec, which supported both the "boolean" attribute in the ticket, and a "select" attribute. the UI would present a checkbox for "boolean -like" parameters - selecting it would set the parameter to the prescribed value defined by the metadata. we had a separate "select" attribute, with "options" values, which behaved much like html "select" - the input field for such parameter was a drop-down listbox, so the editor would select one of predefined values, instead of a free text field as is with "normal" parameters.

some time after the introduction of templatedata, we modified our wizard to use templatedata instead of our "proprietary" metadata format, but we are missing the lost functionality, as described above.


Whatamidoing (WMF) (talkcontribs)
קיפודנחש (talkcontribs)

I am. I even left him a love letter on his talk page on enwiki a while ago. Twisi, his wizard is crippled by not being able to digest an existing template on the page, so it's a one-shot thing: get it right the first time, or you're on your own. My old wizard is ugly, but better behaved. Peace.

Reply to "select"
קיפודנחש (talkcontribs)

it is very disappointing, and IMO should be considered a bug, that templatedata does not support scribunto. there should be an established scribunto library that let me consume "templatedata" of a given template from my lua module (return nil or empty table if template does not exist or does not have TD).

scribunto is used mainly with templates, and the ability to consume templatedata should be considered elementary. User:Anomie explains that it is in the responsibility of each extension to generate the linkage library. see phab:T107119 - open since 2015.

currently, we plug this deficiency by executing the following abomination ("docSubPage" is predefined, to the "ducumentation" convention name of the specific wiki):

local function _readTemplateData( templateName ) 
	local title = mw.title.makeTitle( 0, templateName )  
	local templateContent = title and title.exists and title:getContent() ''-- template's raw content''
	local capture =  templateContent and mw.ustring.match( templateContent, '<templatedata%s*>(.*)</templatedata%s*>' ) ''-- templatedata as text''
''--	capture = capture and mw.ustring.gsub( capture, '"(%d+)"', tonumber ) -- convert "1": {} to 1: {}. frame.args uses numerical indexes for order-based params.''
	if capture then return pcall( mw.text.jsonDecode, capture ) end
	return false
local function readTemplateData( templateName )
	if type( templateName ) == 'string' then 
		templateName = { templateName, templateName .. '/' .. docSubPage }
	if type( templateName ) == "table" then
		for _, name in ipairs( templateName ) do
			local td, result = _readTemplateData( name ) 
			if td then return result end
	return nil

please follow the instructions (here), and be done with it.


Whatamidoing (WMF) (talkcontribs)

Realistically, the priority level on that patch means that the team will cheerfully accept patches written by others. If you are waiting for the team to do this themselves, then I don't think this will happen any time soon.

קיפודנחש (talkcontribs)

i responded on phabricator back when.

the priority level of this ticket is grossly wrong. you guys need to jack up this priority. see, e.g., how many people subscribe to the ticket (look at the dupes also!) this is elementary - every extension that adds to the API, where it makes sense, should make it accessible to scribunto. it's hard to think of anything _more_ relevant to scribunto than templatedata.


Whatamidoing (WMF) (talkcontribs)

The priority level is meant to accurately communicate the team's actual intentions. In this case, AFAICT they don't mean to work on it during at least the next year. Reasonable people might disagree with their decision, of course, but the level marked in the ticket is meant to communicate that decision.

I'll ask the product manager to re-consider. To be candid, I don't have much hope for a change. The team is not focused on adding new features to TemplateData. Realistically, I expect they'll say that if the Scribunto people want to use TemplateData, then the Scribunto people need to write the patch.

קיפודנחש (talkcontribs)

in view of this comment, you can interpret my comment about "the priority level of this ticket is grossly wrong" to mean "the team's intention is grossly misguided"...

we are not talking here about "adding new features". twisi, it's about fixing a bug.

the thorn here touches the question who are those "scribunto people". the simplest interpretation is that "the scribunto people" are the community members writing modules in lua, in the different wikis, and often share/import those modules from one wiki to another.

these are decidedly different group of people from the group who create the mw libraries _available_ to those modules.

for instance, the wikidata team created an interface library enabling lua modules access to wikidata database, which proved to be very very successful. the people who created this interface library _are not_ generally thought of as "the scribunto people" - they are "wikidata people", but thanks to this interface' "the scribunto people" can now write modules that utilizes wikidata.

in a similar fashion, "the templatedata people" should write the interface library betwixt their stuff and scribunto.

tagging User:Anomie, hope to hear his take on which people should do what.


Anomie (talkcontribs)
tagging User:Anomie, hope to hear his take on which people should do what.

As was mentioned, anyone who wants to could submit a patch. The problem is finding someone who wants to, and has the necessary skills, and has the time to do it.

You're welcome to try to convince a WMF team to take it on, but if they say no then you may have to accept that answer. You're also welcome to work out how to do it yourself and submit a patch, or to convince a third party developer to write and submit a patch to your specifications.

Reply to "scribunto"
Samwilson (talkcontribs)

Is there an existing Javascript library (outside VisualEditor etc.) for parsing the TemplateData format syntax? Wanted for TemplateWizard (task T186653). @cscott: are you someone to ask about this?

Cscott (talkcontribs)

The implementation in Parsoid starts around here:


and the specification is


I think the entirety of the parser is basically this:

  /^(\n)?(\{\{ *_+)(\n? *\|\n? *_+ *= *)(_+)(\n? *\}\})(\n)?$/;

var formatStringSubst = function(format, value, forceTrim) {
  if (forceTrim) { value = value.trim(); }
  return format.replace(/_+/, function(hole) {
    if (value === '' || hole.length <= value.length) { return value; }
    return value + (' '.repeat(hole.length - value.length));
Samwilson (talkcontribs)

Thanks! That's brilliant info. :)

Reply to "Parsing custom formats in JS"
XanonymusX (talkcontribs)

I have read that it should be possible now to define a custom format, but I cannot find any information about how to do that on the page. Does it still need to be updated?

Jdforrester (WMF) (talkcontribs)
XanonymusX (talkcontribs)

Thank you for the link! So now I have a concrete question about the format: in my case, the template is a combination of unnamed (thus, numbered) parameters, which should always be inline, and named parameters, which should be formatted as block. Is there any possibility to specify separate formats for selected parameters in TemplateData? I am thinking of a potential combination of paramOrder and format, or something like that.

Jdforrester (WMF) (talkcontribs)
in my case, the template is a combination of unnamed (thus, numbered) parameters, which should always be inline, and named parameters, which should be formatted as block. Is there any possibility to specify separate formats for selected parameters in TemplateData?

No. This sounds like a very odd use-case. I would strongly discourage this pattern of wikitext.

XanonymusX (talkcontribs)

Besides the fact that this might be used much more frequently than one can think, there simply is no other way, because having a list of short unnamed parameters as a block makes the source look ridiculous; at the same time, however, inline is no solution, as the long list of other parameters would make the source unreadable if put on one line. Certainly, the better of the two is block, so other users will just have to correct the source by deleting the unnecessary breaks, which seems like an easy task. A possibility to define the format correctly already in TemplateData would however be much appreciated.

XanonymusX (talkcontribs)

Actually, I just tried it, and it seems that the unnamed parameters will be put inline automatically, even if block is specified! In that case everything is fine!

Whatamidoing (WMF) (talkcontribs)

Can you give an example of this? I don't remember seeing it before.

XanonymusX (talkcontribs)

Well, the use case is de:Vorlage:Charttabelle. TemplateData is of course not able to follow the usual order of the parameters in the example given, but at least it leaves all the unnamed parameters in one line.

Jdforrester (WMF) (talkcontribs)

I don't understand. TemplateData is definitely able to write out in the order of parameters, except that templates's TemplateData block is invalid so it won't work. If you click "Vorlagendaten verwalten" to load the editor, it will warn you:

Ungültiges JSON-Format. Du kannst diese Operation zum Korrigieren abbrechen, die aktuellen <templatedata>-Tags löschen und es erneut versuchen oder mit dem Ersetzen der aktuellen Vorlagendaten durch neue fortfahren.

I'm not quite sure how you've managed to save past the error. The TemplateData block lacks the customary whitespace which makes reading it hard, and the descriptions try to use wikitext which won't work, but I'm running between meetings so I can't see how to obviously fix it.

XanonymusX (talkcontribs)

That has nothing to do with this template, but with de:Vorlage:TemplateData, which makes the Vorlagendaten-verwalten button useless (not my invention). The TemplateData works fine with this template (except obviously for tasks T52407 and T178341 that need to be solved in order to actually allowing the use of the complete template in VE).

But let me give you more detail. The usual parameter order of this template is (traditionally) the following:


|DE|AT|CH|UK|US|Quellen =

| Art =



TemplateData currently makes it look like this:


|Quellen =

| Art =



In the end I do not mind, it still makes sense.

Jdforrester (WMF) (talkcontribs)

Well, if the editor hadn't been broken, I would say "just drag the parameters into the order they should be in and they'll be saved that way", but of course it's not helpful. :-(

Maybe that meta-template can be deleted?

XanonymusX (talkcontribs)

I have now changed the order (which is working absolutely fine, just edit Vorlage:Charttabelle/Doku)! :) But what I actually meant with order was the predefined position of some parameters in the traditional use of the template as shown above. I really do not like to have the unnamed parameters in the same line as the template name, but I can live with it.

I doubt that the meta-template will be deleted, even if it was heavily criticised just some days ago. It is already used quite a lot and I have to say that I like the visuals of it, otherwise I would not have used it for my template.

Whatamidoing (WMF) (talkcontribs)

PerfektesChaos, do you have any idea what the JSON problem is with Vorlage:Charttabelle?

PerfektesChaos (talkcontribs)

Showing up incidently today.

No idea at the first glance, but it seems to me the local German de:WP:VWS would have been a faster and more specialised help desk ttan internnational stage.

I'll continue on loval level and solve the problem over there; may be regarded as "solved" here.

Reply to "Custom format" (talkcontribs)

Use case

As a user, I'd like to guide and validate user input so that each input is always valid.


Input masks provide a way to validate and indicate the exact format of the data entered, for example:

  • Telephone - (___) ____ ____
  • Zip code - ___ ____
  • email, barcode, ISBN, color codes, etc

A good example of this is microsoft word inputmasks or alternatively actual html5 patterns. While it is possible to implement this for each of those, there are an infinite number of ways to require input.

Proposed solution:

Add a new field(s) to templatedata that governs the exact input. For example:

params": {
    "phone": {
            "label": "Phone",
            "type": "number"
            "inputmask" : "(000) 000-0000",
            "usemask-output" = "false"

Once the page is saved, the input is normalized to the basic wikitext, e.g. "phone = 123123123", and vice versa when the template dialog is loaded. Alternatively, for certain templates it could output it as shown when using the usemask-output parameter.

Whatamidoing (WMF) (talkcontribs)

I don't think that this has been considered before. The team is still wondering when it might be safe to start enforcing much simpler things, such as fields for URLs not containing non-URLs, fields for files not containing non-File: links, etc. This looks like a step well beyond that point. (talkcontribs)

The enforcement should probably be the default, as long as there is a fallback to override it. For instance, probably 80%+ of the world's population has no clue what an ISBN is or what the exact length of it should be.

This would probably resolve a lot of issues that end-users have. There is a often limit to the exact amount of text allowed by most parameters, as such any user adding more than that is likely not inputting it correctly.

Side note: Apparently the page on Input mask did not contain even a single reference (before I added it). Maybe if the editing tool had input masks, more editors would actually know what to add there and how :).

Reply to "Suggestion: Provide input masks"

Suggestion: Add a template type property (or field)

Summary by Whatamidoing (WMF) (talkcontribs)


It is currently impossible for a user to differentiate templates (either programmatically or with tools) without using categories.

Use cases

  • Discourage certain templates in certain namespaces - e.g. Template:documentation (documentation type) in main namespace
  • Create specific tools to target specific templates - e.g. a customized infobox editor, visualeditor / wikitext editor insert dialog for specific types of templates
  • Retrieve data related to specific templates - infobox templates provide rich data that can be used in many contexts (search, translation, mobile apps, etc), but it is impossible to differentiate an infobox template from a "quote" template.

Proposed solution

Add a new property

<templatedata> {
template-type : "infobox"

Categories don't really work for this because many templates are over categorized or mis-categorized.

There is a similar extension by wikia (https://github.com/Wikia/app/tree/dev/extensions/wikia/TemplateClassification) that might be worth forking. It seems to use some heuristics to automatically detect the template types, and also allows editors to overwrite those (see Help:Template types).

Reply to "Suggestion: Add a template type property (or field)"

Could use another boolean type

Summary by (talkcontribs)

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.

Tacsipacsi (talkcontribs)

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. (talkcontribs)

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.

See : https://phabricator.wikimedia.org/T144155

Tacsipacsi (talkcontribs)

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. (talkcontribs)

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 = }}

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. (talkcontribs)
Tacsipacsi (talkcontribs)

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:

  • 3-state is what we have now (1=true, 0=false, null=unknown).
  • 2-state is the new (any value [stored by VE as 1]=true, null=false). Empty string is usually false, but it can be sometimes true. The string “0” means true. There’s a template in Hungarian Wikipedia where the parameter is named in a way that writing “no” is the logical text while it means technically true. Processing this as the 3-state would produce it to be displayed (or even overwritten) wrongly. Of course when using a checkbox, it’s all right to store it as “1”. (talkcontribs)

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.

Jdforrester (WMF) (talkcontribs)

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. (talkcontribs)

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. Template:+ or

, Template:✓ or Template: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. (talkcontribs)

One example of a core functionality that works this way is the default template argument, e.g.:


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).

Whatamidoing (WMF) (talkcontribs)

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.

Tacsipacsi (talkcontribs)

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. (talkcontribs)

> 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. (talkcontribs)

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:

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 (talkcontribs)
{{mytable | border = true}}   === red-border
{{mytable | border = 1}} === red-border
Tacsipacsi (talkcontribs)

{{#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.

Whatamidoing (WMF) (talkcontribs)

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?

Tacsipacsi (talkcontribs)

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:


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
	return 0

returns 1.

Whatamidoing (WMF) (talkcontribs)

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.

TheDJ (talkcontribs)

Template logic is really complex, and really dependent on these kinds of paths. I think it is much more difficult to predict the effects for this, than compared to tidy changes.

Tacsipacsi (talkcontribs)

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.

Whatamidoing (WMF) (talkcontribs)

Those pages don't have <br>. They all have </br>, which isn't 'legal' according to any standard.

Tacsipacsi (talkcontribs)

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.

Whatamidoing (WMF) (talkcontribs)

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).

Tacsipacsi (talkcontribs)

Thank you for clarifying. This very wiki (huwiki) has quite a number of bots, so fixing here won’t be a problem. (talkcontribs)

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.

TheDJ (talkcontribs)

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. (talkcontribs)

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}". (talkcontribs)

>"values = {"yes" = "y", "no" = ""}".

Reply to "Could use another boolean type"