Last modified: 2014-03-28 19:07:01 UTC
To show red links (and stub links) correctly, Parsoid will need to hint on each link as to the status of its target. Also some work in CE and UI. ;-)
So far my idea is to keep link existence checks out of Parsoid, and add the colors from JS or CSS instead. This should avoid some parser cache invalidations and makes the parser output less dependent on user preferences. To do this, a data structure with the status of all outgoing links in a page would need to be fetched separately. This could be a JSON structure, or a CSS file that directly matches some target-hash-based classes on links. Doing the same for media or images would be harder, and is not something we plan to do right now. We'll instead render them normally, and perform the existence check in the parser while retrieving the image dimensions.
It is actually shown as blue links which are considered to be existing pages. This is confusing. I understand the parsoid isn't doing existence checks at all, so better use a natural color for all links.
*** Bug 49475 has been marked as a duplicate of this bug. ***
*** Bug 50020 has been marked as a duplicate of this bug. ***
*** Bug 50974 has been marked as a duplicate of this bug. ***
This can be implemented with a generated CSS file containing attribute selectors matching red link targets like this: a[href="./Foo"], a[href="./Bar"] { color: red } Alternatively a JSON file containing the redlink targets could be fetched and a redlink class set on each of them. CSS seems to be the more elegant solution without a need for JS and DOM changes though. In the longer term this is something we should implement for core too.
Normally, in article view mode, redlinks have CSS class "new" and I'm suggesting doing it in the same way for the sake of consistency.
We don't want to encode this information in the DOM to avoid cache updates for the page content. There is really no need to do so since CSS selectors work well these days, and purging / regenerating CSS is much cheaper than updating page content.
Would it be possible also to make other kinds of pages to appear in different colours, by changing CSS pages on the local wikis? I know that some wikis have different colours for redirects (green), others make links to disambiguation pages appear highlighted in yellow.
There has just been another editor on en.wp requesting this functionality. (In reply to comment #9) > Would it be possible also to make other kinds of pages to appear in different > colours, by changing CSS pages on the local wikis? I know that some wikis > have > different colours for redirects (green), others make links to disambiguation > pages appear highlighted in yellow. That is bug 52173. Although there was some discussion about whether that was a duplicate of this the consensus seemed to be that it wasn't.
*** Bug 52173 has been marked as a duplicate of this bug. ***
(In reply to comment #10) > There has just been another editor on en.wp requesting this functionality. > > (In reply to comment #9) > > Would it be possible also to make other kinds of pages to appear in different > > colours, by changing CSS pages on the local wikis? I know that some wikis > > have > > different colours for redirects (green), others make links to disambiguation > > pages appear highlighted in yellow. > > That is bug 52173. Although there was some discussion about whether that was > a duplicate of this the consensus seemed to be that it wasn't. That bug was asking for the same problem to be fixed, but was suggesting a different technical solution (and one which is a WONTFIX from the Parsoid team, as it makes the cached pages get invalidated by other pages getting created/deleted/expanded out of the stub threshold/made into/out of a redirect/made into/out of a disambiguation page). Sorry for the confusion.
Right now the linking problems detected only after saving the page. So please raise the importance of this bug and fix it on priority.
This is an 80/20 issue - 80% of the value comes from fixing just the coloring of internal wikilinks. Coloring of external links isn't critical. (There can be significant time-delay in getting 404 or similar error codes for page non-existence, as well as false negatives when a website is temporarily down.) And of the internal wikilinks, most of the value is redlinks, some of the value is disambiguation pages, and little of the value is stubs (which, again, are subject to false positives, since article assessments aren't automated). In short, the priority ought to be to code internal wikilinks that go to non-existent pages (as red), and internal wikilinks that go to disambiguation pages (as yellow, I think), and not to worry all that much about anything else.
(In reply to comment #14) > This is an 80/20 issue - 80% of the value comes from fixing just the coloring > of internal wikilinks. Coloring of external links isn't critical. I don't think anyone suggested (or has ever implemented?) coloring of external links. They only change color based on your browser settings, for clicked/unclicked links (essentially). > And of the internal wikilinks, most of the value is redlinks, some of the > value > is disambiguation pages, and little of the value is stubs (which, again, are > subject to false positives, since article assessments aren't automated). Stubs are colored based on byte-count, not whether they're tagged-as-a-stub. You can change the byte-count in your [[special:preferences]], under "Appearance->Threshold for stub link formatting (bytes):[dropdownmenu]" > In short, the priority ought to be to code internal wikilinks that go to > non-existent pages (as red), and internal wikilinks that go to disambiguation > pages (as yellow, I think), and not to worry all that much about anything > else. Agreed that only redlinks are crucial. For disambig links, possibly the new Property system can help? https://en.wikipedia.org/wiki/Special:PagesWithProp?propname=disambiguation&propname-other= For anything more complex than that, Anomie's Linkclassifier code might be useful/insightful. 300+ users have it installed. I recommend the "run on demand" version. https://en.wikipedia.org/wiki/User:Anomie/linkclassifier code at https://en.wikipedia.org/wiki/User:Anomie/linkclassifier.js
(In reply to comment #14) > This is an 80/20 issue - 80% of the value comes from fixing just the coloring > of internal wikilinks. Coloring of external links isn't critical. (There can > be > significant time-delay in getting 404 or similar error codes for page > non-existence, as well as false negatives when a website is temporarily > down.) > And of the internal wikilinks, most of the value is redlinks, some of the > value > is disambiguation pages, and little of the value is stubs (which, again, are > subject to false positives, since article assessments aren't automated). > > In short, the priority ought to be to code internal wikilinks that go to > non-existent pages (as red), and internal wikilinks that go to disambiguation > pages (as yellow, I think), and not to worry all that much about anything > else. The solution we're considering is a service that, given an array of links, returns a set of CSS selectors that VE applies to the page, to give the appropriate hinting on links. To be very specific, we are talking about: * Internal links ** If the page does not exist, colour it red ** If the page does exist but is a disambiguation page, colour it yellow ** If the page does exist but is under (arbitrary) stub threshold, colour it purple ** Elsewise, colour it dark blue * External links ** If the link is to a wiki that is "internal" (i.e., an interwiki), colour it mid-blue ** Elsewise, colour it mid-blue with an "external link" icon. It is a mistake to think that doing this but only for internal link state and only for existence/non-existence is 20% of the work for 80% of the gain; it's much more like 90% of the work for 80% of the gain. :-) Building the service itself is definitely the hard part of this.
(In reply to comment #16) > * Internal links > ** If the page does not exist, colour it red > ** If the page does exist but is a disambiguation page, colour it yellow > ** If the page does exist but is under (arbitrary) stub threshold, colour it > purple > ** Elsewise, colour it dark blue If the link is a redirect, will the system pick up the properties of the target page or just code it as a stub because it's short? (Target could be a dab page, stub, or normal page).
(In reply to comment #16) > * Internal links > ** If the page does not exist, colour it red > ** If the page does exist but is a disambiguation page, colour it yellow > ** If the page does exist but is under (arbitrary) stub threshold, colour it > purple > ** Elsewise, colour it dark blue Don't forget about redirection pages. In some Wikipedia's it is probably bad practice to link them. In german Wikipedia, it's okay to link them, but only if the link target makes more sense than the main page title. So in any case it's nice to see that the link target is a redirect. A bonus would be a tooltip which shows the page the redirect redirects to. (In reply to comment #6) > This can be implemented with a generated CSS file containing attribute > selectors matching red link targets like this: > > a[href="./Foo"], > a[href="./Bar"] { color: red } This is a really horrible idea. About 5% of the population are color blind, you really don't want to hardcode colors like this in any way. If embedding this information in the page source is technically impossible for whatever reason, then load a list of external pages using JS and add css classes or other attributes on the fly.
*** Bug 56442 has been marked as a duplicate of this bug. ***
Changing importance to "Normal". Even though it's not a regression compared to the source editor, common sense says that it should be a basic feature of VE and not an "Enhancement".
Revert. Lots of "basic" features are enhancements. Bugs are "this should already be working and its lack of presence is a code failure". Noting however that this is high priority.
Change 118045 had a related patch set uploaded by Jforrester: [WIP] Red link support https://gerrit.wikimedia.org/r/118045
Change 118045 merged by jenkins-bot: Display links to nonexistent pages as red https://gerrit.wikimedia.org/r/118045
It doesn't seem to be resolved. I found https://en.wikipedia.org/wiki/Demented_Are_Go#Studio_albums by hitting "Random article" until I found a redlink, tried to edit it in VE, and the red link ("Welcome back to Insanity Hall ") looked blue. Am I missing something? In case it was any of my settings, I tried again using my (declared) alternative account which has default settings for everything: went to preferences to enable VE, tried editing that article, still a blue link.
(In reply to pamdavies7 from comment #25) > It doesn't seem to be resolved. I found > https://en.wikipedia.org/wiki/Demented_Are_Go#Studio_albums by hitting > "Random article" until I found a redlink, tried to edit it in VE, and the > red link ("Welcome back to Insanity Hall ") looked blue. Am I missing > something? > > In case it was any of my settings, I tried again using my (declared) > alternative account which has default settings for everything: went to > preferences to enable VE, tried editing that article, still a blue link. The code is not yet deployed to the English Wikipedia. It will be deployed today to MediaWiki.org (hence the date in the "milestone"), and to the English Wikipedia in a week, following the regular schedule.
Verified, working fine on the English and Italian Wikipedias.
