See also T65792: #section-links should preview the correct subsection, but note that this task is about a specific use case.

Support for displaying hash fragments in this way would require pulling the entire page content down via the API. This would slow down the display of the hovercard. It's an interesting idea, provided we do it only for hashes but taken out of context information could be confusing.

@ovasileva @Nirzar over to you for thoughts.

This is useful for glossaries, not for articles in general.

Extracting fragments can be done at the server, there are no need for pulling the whole page.

Yes, extracting fragments can be done at the server. Something like RESTBase would make this easier though as we only store the entire block of HTML in MediaWiki and would need to turn it into a DOM tree and parse it to determine the fragment. Although we'd only return the fragment we'd still need to parse the whole page.

Right now a link on a wiki page would have no knowledge of whether it was pointing to a glossary page. The help namespace might be enough but I don't know enough about how that is used.

Parsing the page and pulling a fragment are separate tasks, and pulling a specific fragment for hovercards should pose no real problem.

(Since it's in Hovercards Pt2 moving to later)

Isn't it possible to get the wikicode of specific section and render just it?
like when you edit a specific section.

@nyemini the difficulty here is that summaries need to be html and not wiki code.

I agree that previewing sections would be awesome to see but given the non trivial work involved in creating an API to support this (touched on in my blog post) this isn't so straightforward.

If such an api existed the result of this would be a little bit more trivial to do but an api endpoint would be the next logical step.

I'm sorry, I'm new here, but how things are usually going here?
I mean, how the decisions are made and who does the work of writing/fixing the code of mediawiki extensions?

@nyemini: Decisions are made by whoever maintainers a project. Whoever feels like writing code or whoever gets paid for writing code writes the code. See https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker for more information and better venues to discuss this. Thanks! :)

The links in the task description point to empty pages. Anyone know some good examples of links to glossary pages?
What API is needed here?

@bearND while the task talks about help pages, what it is essentially asking for is being able to generate summaries of sections e.g. https://en.wikipedia.org/wiki/Spain?oldid=876459623#History
would summarise as:

Iberia enters written records as a land populated largely by the Iberians, Basques and Celts. Early on its coastal areas were settled by Phoenicians who founded Western Europe's most ancient cities Cadiz and Malaga. Phoenician influence expanded as much of the Peninsula was eventually incorporated into the Carthaginian Empire, becoming a major theatre of the Punic Wars against the expanding Roman Empire. After an arduous conquest, the peninsula came fully under Roman Rule. During the early Middle Ages it came under Germanic rule but later, much of it was conquered by Moorish invaders from North Africa. In a process that took centuries, the small Christian kingdoms in the north gradually regained control of the peninsula. The last Moorish kingdom fell in the same year Columbus reached the Americas.

If such a capability existed, hovercards could show previews in this fashion.

If this is for all pages then that could turn out quite expensive on the server side, at least if we pre-generated the API responses. Maybe a specific API is in order?

If this is for all pages then that could turn out quite expensive on the server side.

Agreed and not trivial ( T156041#4707501).