Help talk:File redirect

From Wikimedia Commons, the free media repository
Jump to: navigation, search

I have been drafting an entry for this help page, trying to write it as an information page about why and where redirects are used. I see there is now a more detailed page here that delves much more into technical aspects, but perhaps information more suited as technical footnotes (though I haven't actually looked at the content or structure of other help pages, to compare ;-). I have tried not to list pros/cons but just the how/when/why. Anyway here is my draft:

How and why redirects are used on Commons for file pages[edit]

Redirects allow an individual file to be referred to by two (or more) distinct names. There are a number of instances where this is useful.

1) After renaming a file
2) After merging two identical files (duplicates)
3) Too avoid having multiple copies of a file where we want to use different names for it in different contexts

Redirects after renaming files or merging duplicates[edit]

The objective of Commons is to make material freely available, file redirects attempt to maintain internal and external references to that content despite our internal housekeeping that might otherwise break existing access paths.

Retention of internal access paths[edit]

After renaming files or merging duplicates we attempt to replace all usage on the wikimedia projects with the new or remaining filename (delinking). But there may be many residual uses of, or references to, the old filename. Some of these uses we may be aware of, and others we have no technical way of finding nor correcting.

For wikimedia projects the redirect facilitates finding the file by using the old/redundant name in cases that the delinker could not handle, for example:

the delinker can not always replace usage, eg for protected pages
the delinker does not change references in article page histories
the delinker does not change log entries (eg a users upload log)
the delinker does not change references that are not [[wiki-linked]].

Retention of external access paths[edit]

We have no way of knowing about all external uses (eg references on the rest of the internet and printed publications). File redirection is only partially successful in maintaining access for content that we have moved or merged. It is successful in maintaining attribution paths that are required by many of our licenses, but does not repair 'hotlinks' from external sites that link directly to our media files.

Redirect for other purposes[edit]

For example we occasionally have a set of file whose names have been "harmonised" to a regular naming pattern so that they can easily be used as icons in templates or some other context requiring automatic selection of the appropriate image. eg of the form File:Basename - en.JPG, File:Basename - de.JPG. There may be occasions where an image is used by two different naming schemes in two completely separate contexts - rather than duplicating the image by a different name, we can simply create a file redirect to the image. This is liable to be an infrequent requirement and the utility of this needs to be assessed on a case by case basis.

(revised) --Tony Wills (talk) 22:19, 5 April 2012 (UTC)
OK, good. Please put that into the main page, and move the technical bits into a separate section ("Technical issues", perhaps). 12:23, 5 April 2012 (UTC)
Needs a bit of work, but I've got to go now, I'll come back in the morning and see how it's going :-) --Tony Wills (talk) 12:27, 5 April 2012 (UTC)
Very well done, but I don't think that "In this context the redirect would most likely have categories added, possibly different ones from the destination file" is OK; this is a source of confusion and an invitation to create all sorts of redirects. Category redirects should never be categorised, so shouldn't galleries nor file redirects.
The nice thing of redirects as used by templates is that a better version, resolution, crop or coloring scheme can be selected without having to remove the original file first or to to overwrite the existing file with a better one. This should avoid many edit wars and discussions as for example the one around File:Army-FRA-OR-01_(alt).svg.
Some people make a redirect over an existing file to supersede it or point to a better version. This should be clearly forbidden. --Foroa (talk) 05:37, 6 April 2012 (UTC)

Where we don't currently use redirects[edit]

This may be a more controversial addition, so I will suggest it here first.

Shall we provide an explanation of other possible uses where we don't create redirects. For examplewe do not create redirects as different language versions of a filename. A possible entry on this page would be something like:

==Unsupported use of file redirects== While a possible use of file redirects is to provide different language entries for the same file, this is totally unnecessary (and discouraged). The filename for any individual file can be in any language and is not of primary importance for locating the content of the file. File description pages and categorization are the primary means for locating content - the file description page should contain multilingual descriptions and useful categories so that a file will be found whatever the searcher's language is. It is a far simpler task to revise a file's description than to maintain multiple filename redirects in different languages.

--Tony Wills (talk) 22:52, 5 April 2012 (UTC)
I think that's right. I'm not sure if it's actually policy, but I believe it is practice. Rd232 (talk) 23:21, 5 April 2012 (UTC)
I have a terrible tendancy to try and write an essay about the topic (over explain), like I am doing with this reply ;-). I suspect that:

==Unsupported use of file redirects== Creation of different languages redirects to an existing file is unwanted, multi-lingual translations on the file's description page is used instead. With a link to the relevant policy (if it can be found) will suffice for this page. --Tony Wills (talk) 00:31, 6 April 2012 (UTC)

Commons:File redirects[edit]

I created Commons:File redirects not knowing this one existed. Mayebe it should be merged and redirected (ha!) into this one. Jean-Fred (talk) 13:48, 17 December 2012 (UTC)