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.

as a temporary workaround, see [[he:Module:ReadTd]]. this short module uses
mw.title.makeTitlet()
title:getContnet()
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
end

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

peace.

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

peace.

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.

Change 468901 had a related patch set uploaded (by Putnik; owner: Putnik):
[mediawiki/extensions/TemplateData@master] Lua method for TemplateData

https://gerrit.wikimedia.org/r/468901

I made a patch that adds a method to get TemplateData in Lua. The method is currently named mw.ext.TemplateData.loadTemplateData(), which is long, but according to the conventions available, the prefix for the extension should be mw.ext.TemplateData. Alternatively, it's possible to change the name of the method itself (e.g. to load()). Or, perhaps, someone can indicate the reasons for which the prefix can be removed.

In T107119#4684407, @putnik wrote:

I made a patch that adds a method to get TemplateData in Lua. The method is currently named mw.ext.TemplateData.loadTemplateData(), which is long, but according to the conventions available, the prefix for the extension should be mw.ext.TemplateData. Alternatively, it's possible to change the name of the method itself (e.g. to load()). Or, perhaps, someone can indicate the reasons for which the prefix can be removed.

If mw.ext.templateData is a required prefix, it’s probably better to opt in for .load or .loadData as a name of the method.

@eranroz, would you like to review the patch?

This lib still has the problem that it only makes sense when both Lua and Templatedata exist in the environment. It is a fundamental flaw for several extensions, they add some functionality together with some more or less hack-ish code to figure out whether they shall run in the current environment.

T107119#4684407: The naming schema used for Lua is pretty weird and should be revised. As it is now it creates way to long names without any real need. Such names are only necessary in a system where code can be loaded at will from external sites. Within a controlled system it is not necessary.

I wonder if anyone at all read this… Probably none.

In T107119#4907698, @jeblad wrote:

I wonder if anyone at all read this… Probably none.

I read this and I'm sure there are other people who do.

For what it's worth, I very much support this suggestion, but unfortunately I'm not much of a Scribunto developer.

Change 468901 had a related patch set uploaded (by Putnik; owner: Putnik):
[mediawiki/extensions/TemplateData@master] Lua method for TemplateData

https://gerrit.wikimedia.org/r/468901

The repo for my work on this is at Github: jeblad/TemplateData. I don't remember if it works as it is, it probably don't.

I've started to mess around with an idea to use TemplateData as a conf object, and make two link objects that pulls in data from either a Frame object or a Wikibase object. Thus it would be possible to access the value itself from the TemplateData object, which is called Root at the repo.

There are probably some code I did not check in when I put this into cold storage, but usually I leave the code at the repo in working order.

The docs folder is generated by ldocs. There is a convenience method at composer.json. There are no documentation in the wiki, everything is generated docs. The current doc can be navigated at jeblad.github.io/TemplateData/mw.templatedata.html.

In the description of this task we can see:

Instead we should load the TemplateData directly and translate it into a Lua structure.

But, in my understanding, this is a lost of a direct usefull acces to the datas themslves.
Then functions to acces independantly at datas and at the template seems better.

I think the direction in https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/TemplateData/+/468901/ is good and simple approach.
It doesn't work as is, but require very small change for fix (replacing loadTemplateData to load in the lua module). I like it as it doesn't require too tight and coupled Lua code to the structure of TemplateData (which is usually dealed with JS code and can evolve later).

Utility functions to easily access to specific values (such as getNamesFromSets etc) can be a good addition to the base functionality, but first we should have the base functionality :)

I posted the links, and a description, but I'm not going to invest more work into this.

can someone please explain

a) why is this marked "lowest priority"? there's significant need and interest. the fact this ticket is followed by 18 people is a clue. @Jdforrester-WMF - you assigned the priority back in 2015. can this be re-prioritized?
b) what's going on with the patch? is it going to sit there forever? according to eranroz, a simple fix will make it functional, and he is ready to review such a fix. what's next?

peace

In T107119#5829963, @Kipod wrote:

can someone please explain

a) why is this marked "lowest priority"?

Probably because maintainers might have different priorities. See https://www.mediawiki.org/wiki/Bug_management/Development_prioritization

b) what's going on with the patch? is it going to sit there forever?

Someone needs to improve and fix the patch. That could be you or anyone else interested in it.

@jeblad @Kipod

I notice the task description is currently prescribing a very specific solution, but lacks any description of a currently experienced problem ("bug") and also lacks any high-level outcome that it would enable ("feature"). It is not uncommon than once the reason for something is understood, the maintainers and other developers like yourself, might iterate on the idea and come up with a perhaps even better solution. This is currently not possible though, and is likely why it has little engagement and low priority. It's currently Yes/No situation without any apparent downside or invitation to help.

TLDR: Why do we want to load TemplatatData into Lua? What are some use cases for that? I can imagine some of course, but I'd like to hear yours.

For one, currently there is a Lua module https://ru.wikipedia.org/wiki/Модуль:TemplateDataDoc (used on 404 doc pages judging by linkcount.toolforge.org) that has to parse page contents of a doc page instead of just using some sort of built-in way to fetch TemplateData for a page.

Why not use the action=templatedata API? Example: https://ru.wikipedia.org/wiki/Special:ApiSandbox#action=templatedata&titles=Template%3Aref-ru

Well, because API isn’t available in Lua modules :-)

In T107119#8630033, @stjn wrote:

For one, currently there is a Lua module https://ru.wikipedia.org/wiki/Модуль:TemplateDataDoc (used on 404 doc pages judging by linkcount.toolforge.org) that has to parse page contents of a doc page instead of just using some sort of built-in way to fetch TemplateData for a page.

…which doesn’t work in cases where it makes sense for pages to share one common TemplateData documentation (see https://ru.wikipedia.org/wiki/Шаблон:Вложенный_список and https://ru.wikipedia.org/wiki/Шаблон:Вложенный_список/2 for a quick example).

@Krinkle A couple of possible use cases:

• autogeneration of documentation, template examples, TemplateData display improvements, etc:
  • https://ru.wikipedia.org/wiki/Модуль:TemplateDataDoc
  • https://en.wikipedia.org/wiki/Template:Format_TemplateData
• TemplateData validation
• autogenerated templated based on TemplateData

The most important use case is described at https://www.mediawiki.org/wiki/Translatable_modules . Basically, making Lua modules as convenient to translate as MediaWiki extensions.

In T107119#8629980, @Krinkle wrote:

@jeblad @Kipod

I notice the task description is currently prescribing a very specific solution, but lacks any description of a currently experienced problem ("bug") and also lacks any high-level outcome that it would enable ("feature"). It is not uncommon than once the reason for something is understood, the maintainers and other developers like yourself, might iterate on the idea and come up with a perhaps even better solution. This is currently not possible though, and is likely why it has little engagement and low priority. It's currently Yes/No situation without any apparent downside or invitation to help.

TLDR: Why do we want to load TemplatatData into Lua? What are some use cases for that? I can imagine some of course, but I'd like to hear yours.

saw this a bit late.

in general, scribuntu is tightly linked to templates, and access to templatedata enables better/more sophisticated handling of the parameters.

i described the real-world use case above, but i will repeat:

in hewiki, we use a "template parameter validator", which adds maintenance categories, and provides enough information to fix parameter errors: which template(s), which parameter, and what is the problem.
currently the validator is active for any use of some 1000+ templates, most importantly all the infobox templates in hewiki. it flags the following errors:

• undefined parameter
• missing "required" parameter
• use of obsolete parameter
• conflicting values to a parameter and its alias
• non-numeric value for parameter with "numeric" type (the tool can be easily expanded to support more type-checking, but we don't usually define other param types on hewiki)
• value outside of "suggested values"

there is an active ongoing "bugfix" effort using tracking cats, constantly resolving the errors, which positively improves the articles where templates are shown not as intended due to such errors.

this "linter" depends on templatedata, which it consumed in the super cumbersome way shown in the snippet in my message from March 27 2016.

to see it in action:

• go to hewiki and enable "הראה הודעות שגיאה ממערכת בדיקת הפרמטרים" gadget on hewiki,
• open any article in the tracking cat. (there are sub categories for each template under the system, and for each error type)

notice a red ugly button at the top, indicating the number of templates with errors in the article. clicking on it will show which template, and what are the errors (e.g., "missing required para meter "author" ").

hope this use case is real enough.

"feature" was described several times, but in a nutshell:

• provide mw.ext.TemplateData lib, which exports load(template name) function, returning templatedata as a lua table.

peace.

second real-world use-case:

lua modules to handle complex templates are often ported from one wiki to another. more often than not, the imported module has to be modified to localize parameter names.
using templatedata localization becomes order of magnitude simpler:

• define localized "alias" for each parameter in templatedata,
• teach Module:Arguments to consume templatedata, and use the alias to implement localization,
• voila! templatedata automagically provides parameter localization.

granted, this will only work for modules which consume their arguments via Module:Arguments, but practically, this means vast majority of modules anyone wants to import.

in addition to the vast simplification of localization, avoiding local modification of imported modules:allows importing to small projects where there are no lua programmers, and maybe more important, it allows the consumer project to keep abreast of the upstream (incorporate improvements and bug fixes), which is a major PITA when the local version is modified,

peace