Problem: When section names are updated in an article, it's difficult to find which articles link there, making it much more difficult to update broken section links.
Proposed solution: When caching Special:WhatLinksHere, add which section (if any) they link to. It would also then be possible to automatically generate a list of articles with links to sections that no longer exist.
Who would benefit: Editors trying to find broken section links, and so readers who will be redirected to broken sections links less frequently.
That works, but only if you know previous section names. I guess there are many thousand links to non existant sections in articles that aren't being watched by an editor. This would let a new editor find all of these with one click (otherwise they would have to go through the page history to find all previous section names, and this wouldn't catch any section name typos in links either). It could also easily compile a list of all the broken sections links that are in the mainspace, in case any editors wanted to work through and fix some of them. --YodinT11:18, 19 January 2022 (UTC)[reply]
I mis-read the proposal as targetted at the editor who is changing the section-name (to fix the inbound links themself at that time) rather than to catch broken links afterwards. I agree that some tools for finding and fixing inbound links to sections that don't exist would be useful. I think enwiki has some tool or bot, will look... DMacks (talk) 11:26, 19 January 2022 (UTC)[reply]
I support this, although I think it might be even better if section links were given a section of their own in the list.--YTRK (talk) 12:12, 22 January 2022 (UTC)[reply]
They (as well as anchors that do not actually exist in the article) are handled/displayed the same by WhatLinksHere anyway, so I doubt there would be a problem with that. ~~~~ User:1234qwer1234qwer4 (talk)21:42, 8 February 2022 (UTC)[reply]
I don't know if this holds true for all Wikipedias, but at least in the English Wikipedia, WhatLinksHere shows the target anchor/section of redirects in the list as
<page name> (redirect to section "<anchor>")
since perhaps two or three years ago.
However it does this only for redirects. I guess this is down to the fact that there can be only one such link in a redirect, but there could be many links pointing to the same page in an article and they do not necessarily all point to the same target anchor/section. Also, parsing a redirect for such target anchors is quickly done, but searching a whole article for them is an expensive operation (when done on demand and without caching). If there are multiple links from a page to the target page, but to different anchors in that page, WhatLinksHere could (group and) list them in separate lines like:
<page name> (link to section "<anchor>")
Since this is an expensive operation I think there should be a selection box in the header of WhatLinksHere to activate the feature only when it's actually needed.
It would also be great, if WhatLinksHere would actually check if a target anchor/section name exists on the target page, and display modified messages instead:
<page name> (redirect to non-existing section "<anchor>")
<page name> (link to non-existing section "<anchor>")
Given, that parsing the target article is an expensive operation as well, there should be a check box to enable this feature on demand only.
If the target article gets parsed for the anchors/section names already, the messages could actually distinguish between anchors and section names in the resulting messages like:
<page name> (redirect to section "<anchor>")
<page name> (link to section "<anchor>")
<page name> (redirect to anchor "<anchor>")
<page name> (link to anchor "<anchor>")
<page name> (redirect to non-existing section/anchor "<anchor>")
<page name> (link to non-existing section/anchor "<anchor>")
And finally a remark: Fixing broken anchor names is fine by either editing the source or the target, but it should be communicated to over-ambitious editors that blindly removing them is not. A link to a non-existing anchor does no "harm" by itself, it is perfectly valid HTML etc., the browser will just set the focus to the top of the page. There are often groups of links from articles and redirects pointing to the same anchor in a target article, and even if it does not exists, it still carries useful semantic information on which specific content is missing in an article, which of the incoming redirects are synonyms or at least semantically closely related, and which source links need to be updated in other articles and redirects when the missing contents get added/moved somewhere. This semantic infrastructure info is useful for article maintenance and reverse lookup, and by blindly deleting dangling anchor fragments, this information would get lost.
Thinking about it, it might even be useful to have an option in WhatLinksHere to sort the resulting list entries by anchor names (regardless if they exist in the target page or not), so that incoming links pointing to the same anchor can be grouped.
Sorry for the late reply, seeing this only now... That's a good point, as they are non-existing, they can't be distinguished. I have updated the suggested list above accordingly.
I agree with your points about redirects, and links to more than one anchor/section from one page. Grouping by anchor names would tie well into the suggestion by YTRK above. --YodinT00:42, 11 February 2022 (UTC)[reply]
Let me point you to a discussion in German Wikivoyage where we discussed broken links to anchors. In de-wv we're using excessively a template that as a side effect creates an anchor for the item. The known problems for sections apply here too. A fix would be a big help for the project. --4omni (talk) 13:24, 30 January 2022 (UTC)[reply]
Good example! Even if this proposal doesn't make it this year, I'm hoping that there's a chance that it (and sorting alphabetically, etc.) might be still included if WhatLinksHere is overhauled. --YodinT00:42, 11 February 2022 (UTC)[reply]
Support Broken section links are absolutely a problem, since bots fixing them haven't always been operational. This would help. {{u|Sdkb}}talk00:23, 29 January 2022 (UTC)[reply]
Support * Pppery * it has begun 18:43, 28 January 2022 (UTC)