Also hook documentation pages (we already parse hooks.txt) and configuration variable documentation pages (just needs some phpdoc parser).

A past attempt to do (partially) that was T91626: Technology to transclude git content into wiki pages (intended as an OPW project but did not make the cut). In hindsight it's probably overcomplicated.

The task to discuss how this should be implemented is T155024: Store structured data needed for MediaWiki documentation. Probably should be turned to an RfC at some point.

Original task description:

(10:36:32 AM) bawolff: Id really like the extension infobox to be loaded from extension.json
(10:36:54 AM) bawolff: Almost all of our code works
(10:37:14 AM) James_F: bawolff: I'd really like to kill most of the content of MW.org and load it "live" from git.
(10:37:19 AM) ***brion hmm, i may want to realign my priorities for 2017 to support roadmap & docs explicitly
(10:37:23 AM) addshore: James_F: +1 to that
(10:37:32 AM) bawolff: yep
(10:37:48 AM) James_F: bawolff: That way we can version the documentation properly for the version you have, rather than in one document try to explain config for MW 1.12 all the way up to master.
(10:37:50 AM) MatmaRex_mobile: James_F: hmm, didn't we have an OPW intern who wrote an extension to allow that?
(10:37:57 AM) MatmaRex_mobile: load stuff into MediaWiki from a Git repo

Don't see any actionable config change request here.

Meets an important requirement of the MediaWiki Usage Report 2015: extension management :-)

This project is selected for the Developer-Wishlist voting round and will be added to a MediaWiki page very soon. To the subscribers, or proposer of this task: please help modify the task description: add a brief summary (10-12 lines) of the problem that this proposal raises, topics discussed in the comments, and a proposed solution (if there is any yet). Remember to add a header with a title "Description," to your content. Please do so before February 5th, 12:00 pm UTC.

Due to the natural separation of content in the current reality (one in git, one on-wiki) there is currently a problem that is mostly invisible, but will likely become a problem if this process is automated. Namely the fact that most users do not run master, they run stable versions instead. As such, we need to find a solution to this separation.

One way to do this would be to consider integration with the extension distributor in some fashion. It is already capable of tracking multiple branches. From that special page, it could extract additional information and for example inform users that the master version of the extension requires MediaWiki 1.29alpha+ or higher, but that the "REL1_28 (current stable)" branch still supports MediaWiki 1.23 and higher. (e.g. the breaking change to drop older support happened recently in master, but we don't want to discourage users from using the extension between now and the release of 1.29).

This was the eleventh most popular item in the Developer Wishlist results.

I made the minimum possible version of this (Perfect is the enemy of barely good enough)

Hence https://www.mediawiki.org/wiki/Module:ExtensionJson

@Bawolff we'd like to keep this moving forward and know you've done a lot here. Could you point us to how the lua is generated on wiki?

@MarkAHershberger Tool:Extjsonuploader has a nutshell explanation of the process.

In T155029#5424117, @DannyS712 wrote:

Assuming that https://www.mediawiki.org/wiki/Module:ExtensionJson is kept updated by bot, I can update the template to extract data from there. At https://www.mediawiki.org/wiki/Module:Extension/sandbox I'm rewriting the current template display in lua, which eventually will control the entire infobox rather than just providing specific pieces of data.

One thing to keep in mind, is not all extensions are in gerrit (and not all extensions that are in gerrit fully use extension.json). So there still should be a way to override the infobox for extensions not in gerrit or doing config stuff in callbacks.

Thanks @DannyS712, that would be great! (The specific task for it is T222479: Display autogenerated extension information in Template:Extension, FWIW.)

In T155029#5424117, @DannyS712 wrote:

Assuming that https://www.mediawiki.org/wiki/Module:ExtensionJson is kept updated by bot, I can update the template to extract data from there. At https://www.mediawiki.org/wiki/Module:Extension/sandbox I'm rewriting the current template display in lua, which eventually will control the entire infobox rather than just providing specific pieces of data.

@DannyS712 Are you still working on this? If not, I was thinking maybe parts of this could be broken into smaller chunks and made into GCI tasks

Hmm. We might soonhit a scaling limit with the bot, as Module:extensionJson is getting close to 2mb max page size

Should the information be split up across different pages?

Or we can implement gzip in Lua :)

Yeah, just chunk by size or first letter, probably.

Alternatively, create a separate Lua module per extension/skin. That would prevent use cases which involve presenting information about many extensions at the same time, but do we have such use cases?

In T155029#7592678, @Tgr wrote:

Or we can implement gzip in Lua :)

+2!

Alternatively, create a separate Lua module per extension/skin. That would prevent use cases which involve presenting information about many extensions at the same time, but do we have such use cases?

I was thinking of using the information in Module:extensionJson to install extensions (T297384) and, as long as there is a way to find all the information in Module:extensionJson from a single endpoint (even if I have to do more queries from there), this is fine.

In T155029#7592684, @MarkAHershberger wrote:

I was thinking of using the information in Module:extensionJson to install extensions (T297384) and, as long as there is a way to find all the information in Module:extensionJson from a single endpoint (even if I have to do more queries from there), this is fine.

As long as you do not need it inside a wikitext context specifically, you should just use https://extjsonuploader.toolforge.org/ExtensionJson.json (which does not have size limits).

I was thinking of using the information in Module:extensionJson to install extensions (T297384) and, as long as there is a way to find all the information in Module:extensionJson from a single endpoint (even if I have to do more queries from there), this is fine.

Not sure if you mean via a Lua module, but if you don't: the info is available in a JSON file at https://extjsonuploader.toolforge.org/ExtensionJson.json

In T155029#7592805, @Samwilson wrote:

I was thinking of using the information in Module:extensionJson to install extensions (T297384) and, as long as there is a way to find all the information in Module:extensionJson from a single endpoint (even if I have to do more queries from there), this is fine.

Not sure if you mean via a Lua module, but if you don't: the info is available in a JSON file at https://extjsonuploader.toolforge.org/ExtensionJson.json

I got confused. Of course, the entire json file is available, but that isn't what my comment is about.

The git repository is not available from the toolforge url. There is no pointer, for example, to SemanticMediaWiki's repository at https://github.com/SemanticMediaWiki/SemanticMediaWiki.git ...

There is the url field, but that points to the "home page" for the extension (in SMW's case, https://www.semantic-mediawiki.org/).

And, in case it wasn't clear, this would be especially helpful for extensions not hosted in Gerrit.