Page MenuHomePhabricator

Hovercard could show an extract from the id downward when #IDname links are used
Open, LowPublic


  1. Enable the Hovercards beta feature on enwiki.
  2. Visit the Sheep article, scroll down to Flock behavior
  3. Find the text "Sheep can become hefted" and hover over "hefted"

A popup appears displaying what seems to be generic "sheep" information: a picture of sheep and text "The raising of domestic sheep has occurred in nearly every inhabited part of the globe, and the variations in cultures and languages which have kept sheep has produced a vast lexicon of unique terminology used to describe sheep husbandry." I'm already reading the Sheep article!

Expected result:
The popup for "hefted" only makes sense if it includes the title of the linked page, "Glossary of sheep husbandry". In this specific case Hovercards could do a better job: If "Hefted" redirected to [[Glossary of sheep husbandry#Hefted]], and someone added {{anchor|hefted}} to this term, and T65792: #section-links should preview the correct subsection worked for {{anchor}}, then the hovercard text would be "Hefting (or heafing) – the instinct in some breeds of keeping to a certain heft (a small local area)..." But that's a lot of pieces to align. I'm sure there are other cases where you need to see the title of the page that the hovercard is previewing in order to understand what it's showing and to decide whether to visit it.

Link preview in the Wikipedia Beta Android mobile app avoids this problem by always showing the linked page's title (overlaid on the lead image if there is one). With Hovercards in many cases this is redundant since the title is identical or obviously related to the link text to which the hovercard points. But some logic like
If the link redirects, or if the link has an anchor, or if the link text is dissimilar to the actual linked page title, then display the actual linked page title
would be close to doing the right thing.

Without Hovercards enabled, wiki links always display the title of the page to which they link in a title tooltip (that doesn't handle redirects).

Another example: the Hovercard for a link to a disambiguation page sometimes displays "Check may refer to:" but other times it displays the most common usage "John Williams is a composer" with no indication that the page covers a dozen other meanings.

See also / closed partial-duplicates

Event Timeline

Spage raised the priority of this task from to Needs Triage.
Spage updated the task description. (Show Details)
Spage added projects: Page-Previews, Design.
Spage subscribed.

Thanks for filing this @Spage, its been on my mind for a while. In hopes of T65792 to resolve I never thought of alternative solutions like these.

We bold the title of the page if it appears in the text. One option could be to prepend the title to the excerpt if no matches were found. @Vibhabamba, does that sound like an alright idea?

@Prtksxna This Flock > Hefted case is one where the word points to a disambiguation page.
Do we think that prepending the word will solve the problem. And would it be worth it?

For instance:

Screen Shot 2015-06-26 at 9.40.27 AM.png (426×383 px, 232 KB)

Even if we prepended Flock before Herd, would it inform the user that
the Flock article leads to Herd.

@Prtksxna This Flock > Hefted case is one where the word points to a disambiguation page.

You are right, prepending the title in that case wont' be useful, but, I don't think you followed @Spage's instructions.

@Spage wants us to hover over hefted and not flock, in the same paragraph. That page links to a Glossary of sheep husbandry, and the hovercard for it looks like this —

Screen Shot 2015-07-21 at 4.20.11 PM.png (427×347 px, 219 KB)

Jdlrobson subscribed.

Seems like an edge case with no clear solution. Am changing the title to be clearer.

Jdlrobson renamed this task from Hovercard needs to sometimes display linked page's title to Hovercard could show extracts of text extract fragments of articles when # is used.Sep 23 2015, 6:55 PM
Jdlrobson set Security to None.

Screenshot of how Navigation Popups gadget handles this case:

Screen Shot 2017-03-02 at 15.33.31.png (380×844 px, 131 KB)

Jdlrobson lowered the priority of this task from Low to Lowest.Jun 27 2017, 10:44 PM

Until page previews is enabled everywhere by default.

Quiddity renamed this task from Hovercard could show extracts of text extract fragments of articles when # is used to Hovercard could show extracts of text extract fragments of articles when #section-links are used.Dec 12 2017, 8:04 PM
Quiddity updated the task description. (Show Details)
SMcCandlish renamed this task from Hovercard could show extracts of text extract fragments of articles when #section-links are used to Hovercard could show an extract from the id downward when #IDname links are used.Dec 19 2017, 10:41 AM

This is not an "edge case", it's how millions of links are done, and the hovercards can be at least frustrating and often very confusing as a result. The OP's case is a good one, and I encounter the same problem all the time.

For glossary articles, I made a partial workaround, (it gives a tooltiip message like "See '[entry name]' in [Glossary name]" indicating where the link goes). This works whether you use hovercards or not. See and hover over "cue ball" in the second sentence of that section for a demo. But it doesn't do anything for articles in general. The problem reported here is also illustrated very clearly in the first sentence of the same Nine-ball article section; there's a link to the Billiard_table article and a "pocket" link immediately after it which goes to a subsection of that article, but the hovercard shows the same thing in both cases.

Since a regular Web browser places the viewport with the line containing the id anchor (or an old-school <a name=...> anchor) at the top of the viewpoint (at least if there is more than a screenful of content below the anchor), the expected and reader-practical behavior would be for hovercards to do the analogous thing, and extract content from that line downward.

Okay, @SMcCandlish point taken. Edge case was probably not the right phrase. I have definitely seen these cases, and I understand the bug, but if we were to count all the links that this impacts, I'm guessing it would be less than 10% of all links so that's why I'm advising a lack of focus right now until we've shipped a first version.

That said it is technically much more complicated (not impossible but complicated) to provide a summary based on a hash fragment right now as we need to work out how to extract that efficiently and provide space to store and address those via an API. Providing an API that works to the level of traffic will take some time and people which we don't have right now. That's why this is low priority.

Oliver_Gramberg raised the priority of this task from Lowest to Low.May 3 2018, 11:51 AM
Oliver_Gramberg subscribed.

Reverting to the original priority level, now that the feature has been rolled out globally.