Page MenuHomePhabricator

Give MIME on links to image pages + Switch to disable image linking
Open, LowestPublic

Description

It is a fact that search engines perform badly with wiki images, as they don't
index pages on image: namespace, assuming it will be an image and not a html
description.

See Commons search engine ranking thread on commons-l
(http://permalink.gmane.org/gmane.org.wikimedia.commons/1289) for more info. The
engines approach is not bad per se (what do you think when you see a .jpg ended
url?) but we're not giving a different information. Thus we should tag the links
in images with the type attribute indicationg the mime of linked document, as it
is done with <style> and <script> (yes, type is a valid attribute of <a>)
http://permalink.gmane.org/gmane.org.wikimedia.commons/1323


Version: unspecified
Severity: enhancement

Details

Reference
bz9248

Event Timeline

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

Give MIME on image links + Switch to disable image linking

Additionaly, this patch also provides a $wgLinkToImagePages setting to disable
links on images: http://permalink.gmane.org/gmane.org.wikimedia.mediawiki/18381

attachment bug9248.patch ignored as obsolete

ayg wrote:

Bug 4421 would also solve this (and probably more reliably, since it seems not improbable that
search engines won't bother with the type attribute).

(Note that at least Google has already fixed this particular problem and indexes
our image pages just fine.)

Using the type field as an extra hint _does_ give me the warm fuzzies, though
I'm not sure it would actually get used by anything.

I'm also undecided on the option to remove the image links. Certainly it's
something that sometimes gets requested, but as a global I'm not so sure it's
great. Any thoughts?

robchur wrote:

(In reply to comment #3)

I'm also undecided on the option to remove the image links. Certainly it's
something that sometimes gets requested, but as a global I'm not so sure it's
great. Any thoughts?

Oooh, evil thoughts abound. I don't like the idea of having it in core, but I do
like the idea of expanding the idea a bit further so extensions can take advantage.

A link is to a namespace, regardless of the nature of the link. The parser ought
to "ask" the namespace in question how to render a link to itself - an image
link would go to some sort of ImageLinker, a normal namespace link, or a link
where there's no custom handler defined would exist as it does now.

This would move us nicely along the path of potentially introducing an extension
which could allow for multiple namespaces that behave like tags (I won't call
them "categories"), rather than just the one.

sumanah wrote:

Comment on attachment 3334
Give MIME on image links + Switch to disable image linking

Marking patch obsolete since it doesn't apply cleanly to trunk, per automated testing: http://lists.wikimedia.org/pipermail/wikitech-l/2011-November/056340.html

sumanah wrote:

Sorry, Platonides. In the wait trunk changed such that your patch doesn't apply. Any interest in revising?

I don't think I'll revisit it in the near future. If anyone wishes to work on it, can do so.

Given that google likes our images now, and that in all probability, nobody looks at a type attribute on an <a>, should this be wontfixed?

The better approach would be to get rid of the "file extension" bit of file description pages. Using a format neutral name would allow PNGs to repülaced by SVGs, or JPGs by TIFFs, without hassle. And being format neutral is baest practice for URLs anyway.

Is there a task open for that somewhere?...