Last modified: 2010-04-12 15:11:09 UTC
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: The PURE READER: 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/expectance for that particular link. You may not follow it at all, choose another link, or visit it, but with the lowered expectation, knowingly that will not find your desired information instantly, but that you will have to spend some time to find your desired content. The ENTHUSIASTIC READER/EDITOR: 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. RELATED ISSUES: Bug 10310 - Show whether links to the page are to the whole page or to a section Is concerned about the same problem: A link to a non-existing section. But mine takes rather the approach "per visitor" (reassessing expectancy + possibly correction) whereas this one's purpose is rather for batch processing.
*** This bug has been marked as a duplicate of bug 16561 ***
Within my research prior to filing my issue, bug 16561 also came across my way! BUG 16561 NOT REALLY A DUPLICATE BUG: Its reporter Piotr Kubowicz argued for "Wiktionary pages" and their "broken section links" and the negative local link effect, nevertheless mentioned that implementing his suggestion could be beneficial to ANY MediaWiki, whereas my suggestion dealt with the same "broken section links" but focused more on the negative effect on Wikipedia cross-page links to broken sections! As shown in my example. SADLY, BUG 16561 PROCESS STALLED: The last process is almost 1.5 years ago, the status still "new", not resolution observable. I STRONGLY ADVOCATE FOR THIS ENHANCEMENT: Those who argued against bug 16561 were mainly arguing defensively from a technical status-quo and seemingly ignorant to the potential benefit! (Smelled a little bit of pure self-referential techno/bureau-cracy) 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. But from my memory, it happens quite sometimes! Hopefully some person (eventually a developer) recognizes the potential of this, and realizes it! If it helps this person to have some reasoning/evidence, I am ready to provide/collect! LAST QUESTIONS: 1) Is my bug now really considered a duplicate? 2) Shall I thus continue my reasoning here, or better at the (supposedly) duplicate bug site?
(In reply to comment #2) > Within my research prior to filing my issue, bug 16561 also came across my way! > > BUG 16561 NOT REALLY A DUPLICATE BUG: > Its reporter Piotr Kubowicz argued for "Wiktionary pages" and their "broken > section links" and the negative local link effect, nevertheless mentioned that > implementing his suggestion could be beneficial to ANY MediaWiki, whereas my > suggestion dealt with the same "broken section links" but focused more on the > negative effect on Wikipedia cross-page links to broken sections! As shown in > my example. > It's the same bug in the software. The only difference between the other bug and yours is the *reason* why you think it's bad (both reasons are equally valid), but *what's actually wrong in the code* is the same. So from a software point of view, the bugs are definitely duplicates. > SADLY, BUG 16561 PROCESS STALLED: > The last process is almost 1.5 years ago, the status still "new", not > resolution observable. > That happens, because most bugfixers are volunteers who work on what they want to work on. Spreading this issue over two separate bugs only works against progress, not for it. > I STRONGLY ADVOCATE FOR THIS ENHANCEMENT: > Those who argued against bug 16561 were mainly arguing defensively from a > technical status-quo and seemingly ignorant to the potential benefit! (Smelled > a little bit of pure self-referential techno/bureau-cracy) > That bug wasn't argued against, people were just pointing out that fixing the bug is *difficult*, not that they *disagree* with it. There's nothing wrong with that: fixing this bug *is* difficult, it's OK to acknowledge that. Read Chad and Brion's comments carefully and you'll see that Chad agrees with you "Would be neat" but points out that it's difficult to fix, and Brion simply lists some technical requirements without explicitly stating his opinion.
1) Roan Kattouw, your abstraction clearly showed that my bug IS a duplicate indeed! Thanks. 2) So what are my options now to realize the enhancement without being a developer myself? 3) And where shall discussion continue? Here or at the original bug 16561?
(In reply to comment #4) > 1) Roan Kattouw, your abstraction clearly showed that my bug IS a duplicate > indeed! Thanks. > 2) So what are my options now to realize the enhancement without being a > developer myself? 1) Become a developer :D 2) Hire a developer 3) Convince a volunteer developer 4) Wait > 3) And where shall discussion continue? Here or at the original bug 16561? Over at the original bug. The exact reason we mark duplicates is so discussions aren't split up.
THE BUG DISCUSSION ENDS HERE! I move the discussion over to original bug 16561, will partially copy what has been discussed here, and hope for a volunteering developer! :-)
