There have already been requests for short descriptions to be available within the text of a wiki-page, especially for Commons, where a page or category may be linked to an article on a Wikipedia. I can imagine the same functionality being of use in other projects as well.

Since directly querying the API for article text would normally be done client-side using JavaScript, that would imply having a piece of script that would need to be installed in the common JavaScript for every project that wanted this feature. It seems to me to be far cleaner to expose the API's prop=description value to Lua, which moves the processing server-side. That would also allow the flexibility of integrating short descriptions into existing modules or creating new ones as required.

I agree there's no great urgency in this, but it would be useful to implement at some point.

I'm reading this as wanting to have a Lua module so that on Commons you can retrieve the description of a english wikipedia page... ?

I'm not sure if the new descriptions have the cross wiki capabilities of Wikidata... Remember that for cross wiki functionality, the change event has to propagate to all the other wikis. Currently only Wikidata and Commons have infrastructure in place for that (and both very dedicated towards their own use case).

Now that the descriptions are local, I suspect they cannot be used by other wikis in the same way, similarly to how other wiki's have no idea if an interwiki page even exists, they cannot know it's local description as they cannot know their local interwiki links either.

It was Mike Peel who asked for the capability, not I, but the result is the same.

I was under the impression that calling the API like this:

https://en.wikipedia.org/w/api.php?action=query&prop=description&titles=Scuba_diving

was completely cross-wiki compatible. After all, it defines the language of the wiki, the article, the query action and the property (as well as the format if required). If the API could be interrogated from Lua, then I would have expected that sort of functionality to become available.

In Lua I can read all sorts of properties from Wikidata for other language wikis into the English wiki, including monolingual text in other languages that is stored in claims, as well as sitelinks, but that's because Wikidata already has this cross-wiki capability.

It may be that the simplest solution for now is to run a bot every once in a while to import short descriptions from each language that uses them into Wikidata to replace the corresponding description when it differs. The we could go back to pulling the short description from Wikidata for Mike's cross-wiki jobs, secure in the knowledge that the information is up-to-date (more or less :-) .

The problem is not the reading. Its tracking where it is used and being able to inform those uses of any potential changes to the value. And since there is no change event bus between english wikipedia and Commons.... seems complex to me. (there is a reason we centralized this complexity)

We may be considering different things here. As I understood it, Mike's suggestion was to be able to display English short descriptions in a page on Commons. That would be what you're thinking of as "where it's used". If the code on the Commons page pulled the value of the short description via the API every time the page was reloaded (but not otherwise), I can't see where we would need to notify the Commons page of any potential changes to the value. That's merely the reciprocal of the situation where we don't see that a Commons image has changed until we refresh a Wikipedia page that contains that image.

I can understand the value in centralising complexity and I agree that taking the short description from Wikidata was always going to be the simplest route, as Wikidata was designed for that sort of application. But the lack of policy meshing between Wikidata and the English Wikipedia has left us with no choice but to decentralise the sourcing of those descriptions.

Perhaps I underestimate the difficulties of exposing some of the API to Lua. However, the API provides functionality beyond what can be easily provided on a Wikipedia page to the reader using current tools. It would be worth having.

API every time the page was reloaded

But we have parser output caching, so that means that a page reload doesn't query the api every time (by design). So any change to the value would not be reflected in the HTML, until someone changes the page on commons.wp (or waits until it drops out of the cache).

I agree that caching would introduce predictable lag whenever a short description is changed, but I doubt that the descriptions are going going to be changed very often, if at all.

If the worry is vandalism, then the caching is irrelevant. The vandalism is just as likely to be caught as soon as it becomes visible whether the cache introduced a delay or not.

This is unlikely to happen for the same reasons T243931: Allow a module to load (require) another module from a global module repository wiki didn't.