https://bugzilla.wikimedia.org/show_bug.cgi?id=37901
--- Comment #15 from Quiddity <[email protected]> --- (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 -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
