Provide a Lua method mw.loadTemplateData()
Open, LowestPublic


We now duplicate the effort done in TemplateData by building a separate Lua table that can be loaded with mw.loadData(). Instead we should load the TemplateData directly and translate it into a Lua structure. This is pretty straight forward. It can even be mimicked by transcluding the doc page, stripping it down to the TemplateData, and then converting the resulting JSON to a Lua structure.

Still, I think it is better to make a native method mw.loadTemplateData() that does the necessary checks and avoids heavy transclusions.

A problem with this function is that it ends up between two different extensions. It is a result of using both Extension:TemplateData and Extension:Scribunto, but it does not really belong in either of them.

jeblad created this task.Jul 28 2015, 12:18 AM
jeblad updated the task description. (Show Details)
jeblad raised the priority of this task from to Needs Triage.
jeblad added a subscriber: jeblad.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 28 2015, 12:18 AM
Aklapper renamed this task from There should be a Lua method mw.loadTemplateData() to Provide a Lua method mw.loadTemplateData().Jul 28 2015, 9:57 AM
Aklapper set Security to None.
Anomie added a subscriber: Anomie.

but it does not really belong in either of them.

Sure it does: it belongs in TemplateData, if reading it from the wikitext really is a problem. Much like how TitleBlacklist, ParserFunctions, FlaggedRevs, and Wikidata extensions provide Scribunto libraries for what they do.

Jdforrester-WMF triaged this task as Lowest priority.Sep 17 2015, 6:35 PM

as a temporary workaround, see [[he:Module:ReadTd]]. this short module uses
and mw.text.jsonDecode()

to look for <templatedata> tags in one or more pages, and return the first valid templatedata it finds, as a lua table.

this is a kludge, of course, and not a good excuse not to provide this directly, just like it's provided directly through the API.

the actual code is simple enough, so i'm pasting it here:

local docSubPage = 'תיעוד'

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
	if capture then return pcall( mw.text.jsonDecode, capture ) end
	return false

function readTemplateData( templateName )
	if type( templateName ) == 'string' then 
		templateName = { templateName, templateName .. '/' .. docSubPage }
	if type( templateName ) == "table" then
		for _, name in ipairs( templateName ) do
			local ok, result = _readTemplateData( name ) 
			if ok then return result end
	return nil


Rical added a subscriber: Rical.Jul 5 2016, 10:56 PM
IKhitron added a subscriber: IKhitron.
Kipod added a comment.Mar 13 2017, 4:25 AM

i do not understand why this was awarded "lowest" priority. reading templatedata from scribuntu is a natural and obvious requirement:
templatedata contains all kinds of "goodies", such as declaring parameters as "required", "obsolete", etc.
in the future' i see more valuable metadata included in TD, such as "if this parameter is not provided, take the value of property X from wikidata", or "this parameter is expected to have one of the following values: a, b, or x" (the last one, e.g., for parameters used with #switch ).
long story short, i think this should be _at least_ "normal priority - for me it's actually "high".


Izno added a subscriber: Izno.Jun 29 2018, 3:36 AM

T125105: Provide a way to show TemplateData content in custom format in template documentation and this one strike me as the same requirement; MCR seems to enable this use case.