Page MenuHomePhabricator

"What links here" for article sections
Closed, ResolvedPublic


So currently there's the "What links here"-feature that shows all Wikipedia-pages that link to the current article. However the entries don't signify whether or not those links are linking to just the page or to a specific subsection of it.
I'm proposing a change that either:

  • Also shows the subsections that pages link to on these "What links here"-pages (example).
  • Or (and I'd prefer that; it could also be done by an external AddOn/Gadget though): displays some kind of button next to the section-header at mouseover which at a click shows all articles that link to that section (for editors only; eventually also only for those who enabled this feature in the preferences). I think the first thing to do in this case however would be to get anchor links on section-headers -> I'm going to create a section in here on that in a minute as it's a separate issue.

So why would this be useful? -> it's useful when renaming section-headers to make sure the wikilinks that link to them don't break (amongst other things such as checking which sections are getting lots of attention for controversial articles).

I made a post about this on VillagePump and it got some support so I'm taking this here.

User Ceyockey also suggested some specific details on how this could be done and also proposed IDing those sections independently of their titles so that they can be "healed" (semi-)automatically (which could be harder to do though) - here's the quote:

I think this would be useful, but maybe not as a baseline addition to the system. I think that at first one would want to create a routine to analyze incoming links to see if the originations have # cues and then do a validation to determine whether the #-value exists in the target article. There might be a couple of ways of doing this; if memory serves, there is an ordinal value assigned to sections sequentially which is independent of the title of the section; thus, there might be a way of "healing" broken section references if the order of sections has not changed. This would require some significant bot-heuristics looking at, for instance, the content of the first sentence and the number of paragraphs in the section as measures of identity between old-name section and new-name section ... maybe more trouble than its worth, but I'm not bot designer, so it might be reasonable.

Event Timeline

Fixuture raised the priority of this task from to Needs Triage.
Fixuture updated the task description. (Show Details)
Fixuture added a subscriber: Fixuture.
Aklapper set Security to None.

I don't see how this is feasible to implement. :-/

I don't see how this is feasible to implement. :-/

Well how are the backlinks retrieved? I'd really like to take a look at the code for you know where I can find it?

And I mean until recently I thought there was another way people make sure section-links don't break but apparently there isn't and they actually have to do it manually (which usually doesn't work out for articles that are heavily linked)...

For a page such as, it'd be nice to know that "OV certificate" actually links to "Public key certificate#Organization validation" specifically. Outputting this information on the same line as the result seems fine.


OV certificate (redirect page) ‎ (links | edit)


OV certificate (redirect page) ‎(section: "Organization validation") (links | edit)

We can always tweak this later.

MariaDB [enwiki_p]> select redirect.* from redirect join page on rd_from = page_id where rd_namespace = 0 and rd_title = 'Public_key_certificate';
| rd_from  | rd_namespace | rd_title               | rd_interwiki | rd_fragment             |
|   333041 |            0 | Public_key_certificate |              |                         |
|   333052 |            0 | Public_key_certificate |              |                         |
|   602484 |            0 | Public_key_certificate |              |                         |
|   673043 |            0 | Public_key_certificate |              |                         |
|  1197945 |            0 | Public_key_certificate |              |                         |
|  2562583 |            0 | Public_key_certificate |              |                         |
|  4255945 |            0 | Public_key_certificate |              |                         |
|  4600720 |            0 | Public_key_certificate |              |                         |
|  5906073 |            0 | Public_key_certificate |              |                         |
|  7951465 |            0 | Public_key_certificate |              |                         |
|  9778503 |            0 | Public_key_certificate |              |                         |
| 20899362 |            0 | Public_key_certificate |              |                         |
| 24654163 |            0 | Public_key_certificate |              |                         |
| 26773704 |            0 | Public_key_certificate |              |                         |
| 32363286 |            0 | Public_key_certificate |              |                         |
| 33546983 |            0 | Public_key_certificate |              | Vendor defined classes  |
| 44377768 |            0 | Public_key_certificate |              |                         |
| 48994342 |            0 | Public_key_certificate |              |                         |
| 49383767 |            0 | Public_key_certificate |              |                         |
| 56150030 |            0 | Public_key_certificate |              |                         |
| 56584241 |            0 | Public_key_certificate |              | Organization validation |
| 56584244 |            0 | Public_key_certificate |              | Organization validation |
22 rows in set (0.00 sec)

We're already storing this information in the database as redirect.rd_fragment, so outputting it should be pretty easy. I also think this task is uncontroversial. It'll probably be warmly welcomed by editors to have the additional information. Given these factors, I'm marking this ticket with the good first task tag.

(If anyone disagrees with the use of the good first task tag, please thoroughly explain why and provide an opportunity to address your concerns before removing the tag.)

Change 410389 had a related patch set uploaded (by Legoktm; owner: Legoktm):
[mediawiki/core@master] SpecialWhatLinksHere: Display section anchor for redirects

@Danbloch Not being familiar with MediaWiki code, I'm wondering if/how your modifications work with multiple sections linked to from the same article (IOW, if article "A" links to both "B#First" and "B#Second"). Is it not necessary to worry about this, given how other parts of the code work?

@matej_suchanek I looked at but couldn't figure out exactly when you would expect it, if you know, to be in production. Do you know/have an estimate?

Depends on when it gets review but there is which conflicts and certainly is higher priority.

Change 410389 merged by jenkins-bot:
[mediawiki/core@master] SpecialWhatLinksHere: Display section anchor for redirects

On Special:WhatLinksHere, you can see whether the link is from a redirect. You will now see which section (heading or anchor) the redirect links to.

Just removing Patch-For-Review, not sure if this request is complete.

I don't get it. According to Tech News 2020 week 10, this change was due to be made weeks ago, but I have yet to see it anywhere. Can someone point to an example?

Edit: Nevermind, I see it now. Example: en:Special:WhatLinksHere/Firefox (search for "redirect to section").

I see there's no special indication on cases where the section title/anchor does not exist (e.g., the link to "Straddle bets" does not lead to a valid anchor in the article). Are there any plans to do that?

(In the meantime, there's the external tool for redirects linked to at the top of the special page.)

Krinkle claimed this task.
Krinkle added a subscriber: Krinkle.

I see there's no special indication on cases where the section title/anchor does not exist (e.g., the link to "Straddle bets" does not lead to a valid anchor in the article). Are there any plans to do that?

No, that would require significant processing or indexing of all article sections which is not something we currently host or index or can feasibly compute on-the-fly. Perhaps file a new task for that in which we might be able to gather other more impactful use cases enabled by such high investment.