Extension talk:TemplateData

Jump to navigation Jump to search

About this board

Tinker Bell (talkcontribs)

Hi. I want to know if there's any way to assign a category to a parameter in TemplateData, or if there are plans to support it in the future. It would allow to generate tables like w:es:Plantilla:Ficha de persona, with sections.

Reply to "Categorizing parameters"
Czech.Fox (talkcontribs)

Hi, I use SQLite version of MediaWiki. I've noticed that since upgrade to 1.31, and also in 1.32, the TemplateData info is not saved to [page_props] table, and thus VisualEditor will not show any hints and list of properties.

It's possible to test it with fresh install of 1.32 with SQLite and TemplateData and VisualEditor extension (or even without VisualEditor).

Any idea?

Thank you

Czech.Fox (talkcontribs)

I resolved the problem by migrating to portable MariaDB and running the maintenance script rebuildall.php

Reply to "No data saved to [page_props]" (talkcontribs)

When I put data with type "page name", they paste without double brackets, but I need with. What to do?

Tacsipacsi (talkcontribs)

Don’t use this data type. It’s for templates requiring the raw page name for further processing. (talkcontribs)

And how to do that one parametr will be changed only from three variants?

Tacsipacsi (talkcontribs)

Currently “line” is the best choice (and explain it in the parameter description), enumerators are not supported at this time.

Reply to "Page names into links"

inserting images/files in templates in the new wikipedia editor

Elastano (talkcontribs)

is shit. the software should recognize when file names have to be wrapped inside some wiki markup in order to be shown correctly. for example, if i try to insert the filename of a screenshot into a page that is using an infobox with a "screenshot=" field, it should at least alert me that this field expects something like File:Xy.png and maybe offer text completion instead of just saving the wrong string that just shows text after saving.

Tacsipacsi (talkcontribs)

This is neither the responsibility of TemplateData nor of the visual editor. These are just tools for storing and presenting template documentation; the on-wiki template documentation should make it clear what format the parameters should use (and stop using “file” data type if it does now, as that‘s clearly for bare-filename parameters).

Elastano (talkcontribs)

interesting. so you think it can be made to show all the wished behaviour i described above with just the right code in the template documentation?

Tacsipacsi (talkcontribs)

Of course it’s possible to say in the human-readable description field something like “The screenshot using the normal ‘[[File:filename.jpg|250px]]’ image embed syntax.” It’s not possible, however, to convert just the file name automatically into a file link, as that contains arbitrary options in addition to the file name, like the desired width. (By the way, if you save the page without checking the preview, that’s your problem.)

Reply to "inserting images/files in templates in the new wikipedia editor"
Zackmann08 (talkcontribs)

Is there any way to edit this information basically in a spreadsheet? It would just be really nice to basically go down the list updating fields. So I know that I want to set the type for fields. Rather than opening each param individually and setting the type, I could just work my way down the rows setting the values. Even an option to export/import to a CSV would be wonderful!

Whatamidoing (WMF) (talkcontribs)

I'm not aware of any existing script for this, but the end result is standard JSON, so it is theoretically possible.

Reply to "Edit in table format"

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"