VisualEditor: Links are not shown as redlinks when their target is blank (or as 'stub-alternate-colour' if appropriate)
Closed, ResolvedPublic

bzimport set Reference to bz37901.
Jdforrester-WMF created this task.Via LegacyJun 24 2012, 7:22 PM
GWicke added a comment.Via ConduitJun 24 2012, 8:07 PM

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.

Matanya added a comment.Via ConduitApr 25 2013, 9:12 PM

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.

Jdforrester-WMF added a comment.Via ConduitJun 12 2013, 2:56 PM
  • Bug 49475 has been marked as a duplicate of this bug. ***
matmarex added a comment.Via ConduitJun 22 2013, 2:40 PM
  • Bug 50020 has been marked as a duplicate of this bug. ***
TTO added a comment.Via ConduitJul 9 2013, 7:12 AM
  • Bug 50974 has been marked as a duplicate of this bug. ***
GWicke added a comment.Via ConduitJul 9 2013, 4:08 PM

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.

Inez added a comment.Via ConduitJul 11 2013, 3:18 PM

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.

GWicke added a comment.Via ConduitJul 11 2013, 3:20 PM

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.

Superchilum added a comment.Via ConduitJul 26 2013, 10:55 AM

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.

Thryduulf added a comment.Via ConduitJul 31 2013, 8:39 PM

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.

Jdforrester-WMF added a comment.Via ConduitJul 31 2013, 8:46 PM
  • Bug 52173 has been marked as a duplicate of this bug. ***
Jdforrester-WMF added a comment.Via ConduitJul 31 2013, 8:48 PM

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

bzimport added a comment.Via ConduitAug 18 2013, 3:35 AM

vssun9 wrote:

Right now the linking problems detected only after saving the page. So please raise the importance of this bug and fix it on priority.

John_Broughton added a comment.Via ConduitAug 31 2013, 2:57 AM

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.

Quiddity added a comment.Via ConduitAug 31 2013, 6:18 AM

(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

Jdforrester-WMF added a comment.Via ConduitAug 31 2013, 2:36 PM

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

PamD added a comment.Via ConduitSep 1 2013, 10:13 PM

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

bzimport added a comment.Via ConduitSep 2 2013, 6:33 AM

jonathan.haas wrote:

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

Jdforrester-WMF added a comment.Via ConduitNov 1 2013, 3:44 AM
  • Bug 56442 has been marked as a duplicate of this bug. ***
Amire80 added a comment.Via ConduitNov 25 2013, 8:43 AM

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

Jdforrester-WMF added a comment.Via ConduitNov 25 2013, 8:47 AM

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.

gerritbot added a comment.Via ConduitMar 11 2014, 1:22 AM

Change 118045 had a related patch set uploaded by Jforrester:
[WIP] Red link support

https://gerrit.wikimedia.org/r/118045

gerritbot added a comment.Via ConduitMar 18 2014, 9:45 PM

Change 118045 had a related patch set uploaded by Jforrester:
[WIP] Red link support

https://gerrit.wikimedia.org/r/118045

gerritbot added a comment.Via ConduitMar 20 2014, 2:44 AM

Change 118045 merged by jenkins-bot:
Display links to nonexistent pages as red

https://gerrit.wikimedia.org/r/118045

PamD added a comment.Via ConduitMar 20 2014, 4:42 PM

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.

Jdforrester-WMF added a comment.Via ConduitMar 20 2014, 4:44 PM

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

Ricordisamoa added a comment.Via ConduitMar 28 2014, 7:07 PM

Verified, working fine on the English and Italian Wikipedias.

Mattflaschen removed a subscriber: Mattflaschen.Via WebDec 3 2014, 5:29 AM

Add Comment