Make links to nonexisting sections being easy distinguishable

Assigned To
Blocked By
T10955: Special page listing broken section anchors
scfc, Nemo_bis, He7d3r and 2 others
"Like" token, awarded by Nemo_bis.

Author: derbeth

On Wiktionary it is common that one page hosts many completely different entries - like "just" has English section, German section, Swedish section etc. Usually users looking for words only in the language they are learning, and editors adding missing words in their favourite language are interested only in one language.

On Wikipedia, if you see a red link, you know immediately that the entry you want is not there. You also know that you can write this entry. On Wiktionary, it does not work. You see a blue link, but when you click on it, there's no (suppose) Swedish word you are looking for - only English and German (all three words are spelled the same). If you are Wiktionary editor, you won't add this missing Swedish word, because you see a blue link and think that everything's all right. That's all very counter-intuitive and annoying.

What I want is:
in the same way as links to missing entries are marked red and existing entries are marked blue, links to nonexisting sections in existing entries should be (for example) brown.

How will it help? Most Wiktionaries see that their users want to jump directly to the language they want when they click on a link. So they prefer links like [[just#English|just]] and [[just#German]] to simple [[just]].

Suppose that there's an entry "just" with English word described but there's no Swedish section there. Currently [[just]], [[just#English]], [[just#Swedish|just]] are all _blue_. In my proposal, [[just]] and [[just#English|just]] will remain blue, but [[just#Swedish|just]] will be (suppose) brown.

This feature will help not only Wiktionary, but all projects. You'll immediately see that link you made to a section of some another entry is broken.

Version: unspecified
Severity: enhancement

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz16561.
bzimport created this task.Via LegacyDec 4 2008, 12:42 PM
bzimport added a comment.Via ConduitDec 4 2008, 12:49 PM

derbeth wrote:

See also: (another issue with link colouring)

demon added a comment.Via ConduitDec 4 2008, 12:50 PM

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.

  1. 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.

bzimport added a comment.Via ConduitDec 4 2008, 1:00 PM

derbeth wrote:

  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.
bzimport added a comment.Via ConduitDec 4 2008, 1:21 PM

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.

demon added a comment.Via ConduitDec 4 2008, 1:27 PM

(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.

bzimport added a comment.Via ConduitDec 4 2008, 1:40 PM

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.

brion added a comment.Via ConduitDec 20 2008, 1:54 AM

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......?

IAlex added a comment.Via ConduitApr 11 2010, 8:13 AM
  • Bug 23144 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitApr 12 2010, 3:43 PM 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?


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!


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


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.

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.

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!

bzimport added a comment.Via ConduitNov 29 2010, 11:54 AM

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.

He7d3r added a comment.Via ConduitOct 1 2013, 8:14 PM

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]]

Nemo_bis awarded a token.Via WebDec 12 2014, 8:45 AM
Ricordisamoa added a subscriber: Ricordisamoa.Via WebDec 27 2014, 8:28 AM

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.