See also: https://bugzilla.wikimedia.org/show_bug.cgi?id=16562 (another issue with link colouring)

Would be neat, but I can't see it happening easily.

1. First and foremost, the section titles aren't stored in the database, so

you'd have to reparse every article to check for section existence. I'm
doubting we're adding a 'sectionlinks' table.

2. Sections change easily and often. Unlike a page deletion, where it's easy to

see what cache to invalidate (and turn the link blue->red), you don't have that
with sections (see problem 1)

Suggest WONTFIX.

1. The goal of software is to be useful, not to be easy to write. There's a table for deleted images, there's an implementation for image comparison in order to search duplicates on Commons. If there's a table for deleted (mostly) rubbish, why shouldn't there be a table for useful (or, from the perspective of Wiktionary, essential) things? There's an autocomplete function; it's quite resource-consuming I guess and needed some work.
2. You can limit this to level-2 sections (only those are used to distinguish between languages in Wiktionary). They change rather sparse (on Wiktionary; but I think in general). You can turn this feature on only on those projects that really need it.

abxabx wrote:

@ ^demon : On the other hand when you change template there is process which refreshes its "what links here" and all you need is to do exactly the same. So once somebody edits a page then software has to refresh "what links here" and invalidate cache. Just like for templates.

(In reply to comment #4)

@ ^demon : On the other hand when you change template there is process which
refreshes its "what links here" and all you need is to do exactly the same. So
once somebody edits a page then software has to refresh "what links here" and
invalidate cache. Just like for templates.

The only difference being:

1. If it's a template, we can quickly check if it's being transcluded, so we know if we need to update the cache.
2. If it's being created/deleted/restored, we know where to check to turn links blue/red appropriately.

In either scenario, we are only invalidating caches in a subset of editing scenarios. Adding this would require either
A) A sectionlinks table storing this metadata so we know what to fix,
or B) Reparse all links to the page, they *might* have a section needing updating

Both of which apply to all situations in which headers (or potentially, only 2nd level headers) are updated, which is a much larger subset of editing.

abxabx wrote:

That's true, however without it every wiktionary (or every project in general) has to frequently dig in snapshots of all pages separately to find & recognize missing sections to prepare lists of such sections for contributors in cooperative editing. I believe that centralised support for marking up such links would improve it and line it up to the class="new" and class="mw-redirect" classes currently provided by the software.

Obviously an implementation of this would need to track section existence and usage. :) Let's consider what would be required:

Required additions:

• fragment identifier column on pagelinks

-> adjustment of unique indexes to allow tracking multiple links from one page to different sections on the same target page
-> adjustment of Whatlinkshere to display these sorts of things

• section info table listing current sections names and fragment IDs for a given page:

sec_page -> page_id
sec_name "Resource (Windows) article is broken or something..."
sec_fragment "Resource_.28Windows.29_article_is_broken_or_something..."

May or may not be necessary to store both visible name and collapsed fragment id. Consider also length limits.

Additionally, there's the consideration that some pages may be defining custom anchors with direct <div id="blah"> and linking to them, or linking to reference IDs etc -- these would not appear in section TOCs. They could either be extracted and stored as well, or......?

• Bug 23144 has been marked as a duplicate of this bug. ***

p.org wrote:

From the technical reasoning above, it seems that the technical implementation of this enhancement is not so easy. In particular I am not familiar with the MediaWiki source code. And in general my programming skills are on a low level.

Despite this technical circumstances, I see a HIGH POTENTIAL in this enhancement for the USABILITY of MediaWiki for both READERS and EDITORS, positively affecting content quality control/improvement! (Reasoning in detail below)

@Developers: Please, someone volunteer!

Besides this: Is there a formal possibility to submit a feature request to WikiMedia Foundation, which if convinced, then puts "official emphasis" on a particular enhancement towards the volunteering community, or even commissions it to paid developers?

CURRENT STATUS:

On PageA: Some text. A link to [[PageB#Section1]]. Some more text.
Some time later, PageB is restructured, featuring no more Section1.
If I then read PageA, the link to [[PageB#Section1]] appears as a completely ordinary link.
If I click on it, I get to the root of PageB (at least), but not to the dedicated section!

SUGGESTED IMPROVEMENT:

The link to the non-existing section shall have a different appearance.

BENEFITS:

IMPROVED USABILITY for the PURE READER:
S/he knows that the link points to a page which still exists, but that the section does not exist anymore. This visual distinction helps to quickly mentally reassess the accuracy/expectancy for that particular link. You may not follow it at all, choose another link, or visit it, but with a lowered expectation, knowingly that you will not find your desired information instantly, but that you will have to spend some time to find your desired content.

QUALITY CONTROL/IMPROVEMENT tool for the ENTHUSIASTIC READER/EDITOR:
S/he knowingly spots the broken section link and can correct it. Either to a new section, which more or less closely matches the old one, or to the root of the page at least, or to a totally new page, if necessary.

FACTUAL BASIS:
I have not collected empirical evidence, how often I encounter broken cross-page section links, and how long it takes me to eventually get to links supposedly content. AFAIR it happens quite sometimes! If it helps a potential volunteering developer to have more reasoning/evidence, I am ready to provide/collect!

olafmat wrote:

I didn't know about this thread, and I have implemented it in JavaScript on Polish Wiktionary. When a gadget "Zabarwienie na fioletowo linków do nieistniejących sekcji językowych" is on, all links to non-existing language sections are colored purple. Works quite fine on every browser with JS support, except Opera Mini, where it makes the page load very slowly - Opera proxy server waits for complete data needed to render the page.

Are redirects to nonexisting sections also in the scope of this bug?

Specifically, is a fix for this bug enough to make redirects to nonexisting sections appear at Special:BrokenRedirects or should I make a separate request for that?

PS: This was suggested at
pt:Special:PermaLink/37024844#Redirecionamentos para seções

You can vote for the inclusion of section links in WhatLinksHere on the Community Wishlist Survey 2022.