Page MenuHomePhabricator

Apply unstyled CSS class on inline links to redirects
Closed, ResolvedPublic


Author: retodon8

It is impossible for the software to see if a link points to a real article or
just a (double) redirect? If links to redirects would be a different colour, it
would cost a lot less time (and blind luck) for Wikipedians to find and fix
them. I'm assuming this would mean checking the first line of text for redirect
code, and render the link differently if you're on a page pointing there. It may
be better if this only happens for logged in Wikipedians, because differently
coloured links would be confusing for other visitors. (This would take more
processing power compared to redlinks because the actual article needs to be read.)

Thank you.

(I suggested this here earlier:

Version: unspecified
Severity: enhancement



Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 9:02 PM
bzimport set Reference to bz4709.
bzimport added a subscriber: Unknown Object (MLST).

Redirects are meant to be a transparent part of the user interface. Behaving
just like other links is desired behavior, not a bug.

retodon8 wrote:

(The pages about submitting bugs and feature request are a bit confusing, but I
kept getting pointed in the direction of the bug submitting method even for
requests. I know it's not a bug.)

Redirects should of course be transparant for visitors, but I personally think
they should not be for Wikipedians. I believe a custom skin that's not used by
default, maybe called something like "Advanced" to scare newer Wikipedians away,
could help remove redirect clutter. (I don't think many would make bypassing
redirects their main job anyway, but I don't know.) Of course if the conclusion
is "There is nothing wrong with redirects, they usually don't cause any
problems." it doesn't matter. Thank you for reviewing this.

gangleri wrote:


Redirects can be gruoped according to different aspects
a) a normal redirect at page foo which generates a link that targets at page bar
b) a redirect at page foo which generates a link that targets at page foo; such
a redirect is not displayed as bold text; they are quite confusing
c) a broken redirect that targets at a page that does not exist
d) a double / multiple redirect
e) pages using redirect syntax / exotical redirects as
e1) redirects to other projects
e2) redirects to itself as (it should be
visible at [[special:DoubleRedirects]] after some time)

[[special:BrokenRedirects]] and [[special:DoubleRedirects]] can be used to fix
the associated types.

Another problems are known regarding

  1. links as [[bar|foo#bar]] where bar is a redirect: some browsers jump to

bar#bar but some not

  1. redirects with anchors (bug 218): the anchors are ignored

Regarding the colors of the link please rememeber also anchors: Their color is
the same as the color of the other "internal" links.

Bug 2318: Special:Allpages should mark redirects distinctly
was fixed allowing the usage of individual settings in user:foo/monobook.css.
See bug 2318 comment 9.

If you (re-)consider to allow to distinguish some of these redirects / anchors
from normal links / selfreferencing links please allow it as CSS setting.
[[MediaWiki:Mainbook.css]] can use a configuration which is "backward"
compatible. Let it to the users to set the colors they prefer.

*performance issues*
It does not make sense to querry the nature of redirects every time. A new
identifier field associated for every title (and a target field for "valid"
redirects) can store the information once.

best regards reinhardt [[user:gangleri]]

robchur wrote:

*** Bug 5777 has been marked as a duplicate of this bug. ***

I've reopened the bug following a discussion with Rob Church on IRC, and edited
the summary appropriately.

It may be possible to add an unstyled CSS class to redirects, as is done in
Special:Prefixindex and Special:Allpages. The software already checks if inline
links point to redirects with the similar 'stub' CSS class feature (as described
at Currently, that
features checks if it is a redirect and, if so, does not add the 'stub' class.
That might be modified to add a 'redirect-inline' CSS class if it is a redirect,
which users could style to their heart's content from their user stylesheet.

fdp1 wrote:

I think a make of different link colours for redirect & disambig pages permite to faster
searching and rectify erroneous links.

(In reply to comment #6)
Antares: If a CSS class is added, this could easily be done using user styles;

ayg wrote:

*** Bug 6962 has been marked as a duplicate of this bug. ***

brianna.laugher wrote:

Does this WONTFIX apply to [[bugzilla:5346]] (make category redirects appear as
different coloured links)? Since category redirects don't work as they should,
it is not really a "feature" for category redirect links to appear "just like
other links" (per comment#1).

robchur wrote:

(In reply to comment #9)

Does this WONTFIX apply to [[bugzilla:5346]] (make category redirects appear as
different coloured links)?

No, not really, but it would be preferable to fix category redirects in some
manner rather than introduce a sloppy workaround.

timwi wrote:

No reason has been given for this WONTFIX. Please provide an adequate reason
which a reasonable developer can be happy with as to why this feature should not
be added if you wish to mark this as 'WONTFIX'. Thanks.

I believe the stated reason was:

"Redirects are meant to be a transparent part of the user
interface. Behaving just like other links is desired behavior,
not a bug."

That said, with the current consolidation of data in the page
table it may well be virtually 'free' to get both the stub size
and redirect state along with existence checks, if appropriate
nudging were done in the code. So adding such a class for the
people who reeeeaaalllyyyy want it might be feasible.


timwi wrote:

"Redirects are meant to be a transparent part of the user interface. Behaving
just like other links is desired behavior, not a bug."

How is this a reason to WONTFIX this feature request? No-one claims that it's a
*bug*, but this doesn't explain why we shouldn't have this feature. Especially
if the default behaviour remains what it is now.

It explains why IMO there was no reason to make the change: the change is not
required and not desirable. But if you just want to sit around crying about
what I said a year ago instead of commenting on current discussion, maybe do
it offline instead of clogging up bugzilla?

timwi wrote:


  1. I am not "crying" and I am not "clogging up bugzilla". Please take such

polemic flames elsewhere.

  1. The change is clearly desirable, otherwise people would not be requesting it.
  2. It has already been mentioned that it is trivial to code and that there is no

extra database inefficiency. I would have already done it myself if your
treatment of volunteers wasn't so discouraging - I feel it is going to be a
waste of time because you're not going to put it live on Wikipedia anyway. Maybe
you should think about that for a bit?

robchur wrote:

OK, enough flaming and arguing - from all sides. Further discussion on this bug
can be limited to a technical implementation, please.

(For the record; Brion consented in a thread on wikitech-l to this, given that
we can do it in a non-intrusive manner, and it incurs no additional performance
penalties as Linker::makeSizeLinkObj() does a page size lookup as it is...)

juergentappe wrote:

One reason why this feature can be sensefull for (expiriencened) users is: It can make finding links to disambig-pages easier. In the preferences it is possible to mark links to "short" pages in a different colour. This "feature" isnt working for redirects to short pages. If all redirects can be markes in a different colour (i.e. usung the private monobook.css) it will be easyly possible to itdentfy links to redirect and check them i.e. in a preview windows to see if a disambig page might behind. Otherwise "disambig-hunters" would have to check every singe link because of possible redirects.

ayg wrote:

*** This bug has been marked as a duplicate of bug 12968 *** wrote:

*** This bug has been marked as a duplicate of bug 166 ***