https://bugzilla.wikimedia.org/show_bug.cgi?id=15842
--- Comment #21 from ChrisiPK <[email protected]> 2009-03-19 18:58:24 UTC --- (In reply to comment #20) > (In reply to comment #18) > > If they have basic experience with MediaWiki, they will have a look at the > > deletion log and find the correct file name. If they don't, I'm sorry for > > them, > > but there's not much we can do. File redirects break our own tools, IMHO we > > should first think of our own projects and after that of the reusers. > > ... > > Are you serious? > > *Not breaking links* helps everyone, ESPECIALLY US FIRST AND FOREMOST. > > If CheckUsage is broken, fix CheckUsage. > > If CheckUsage can't or won't be fixed, let us know so we can replace it with > something that works. > > The user-hostile attitude of "well you can hunt around for hours trying to > figure out why the link broke, nothing we can do" is completely unacceptable > for a project like Wikimedia which has the explicit aim of getting useful and > interesting material into peoples' hands. > > Sometimes it's necessary to let a suboptimal situation go for a while when > there's limited attention, but this isn't one of them -- this is a case where > you're advocating *spending active effort to hurt users* by breaking links, > and > this is not a position the Wikimedia Foundation can support. > See http://commons.wikimedia.org/wiki/Commons:Administrators%27_noticeboard/Archives/User_problems_7#User:ChristianBier (see my contribution, 5th comment from botton of the ChristianBier section) for a more detailed explanation why redirects don't work with CheckUsage. If this can be fixed, great! Another reason to not use redirects is the additional pages which provide more attack space for vandals. I don't know whether some of you remember the situation with [[File:Red pog2.svg]]. This was basically a redirect to [[File:Red pog.svg]], which was at that time created only for use on the English Wikipedia to bypass the server's image cache for Red pog.svg. However, this is used in a template for geolocation (the infobox thingies showing you the location of a city etc., this file is the red dot marking the location), so it is heavily used on en-wp. To make things worse, other projects copied this template (with the redirect as red dot file) from en-wp, so loads of project suddenly used the redirect. The actual file was protected from editing, because changes to this file can break a huge number of sites all across the WMF projects. The redirect, however, was not protected, so a user uploaded a file over the redirect. This file was now included instead of the actual red dot. Luckily the newly uploaded file was just a slightly modified red dot, but it could also have been a vandalized image. Protecting a file will then mean also finding all redirects for this file and protecting those as well. Same goes for unprotection. I don't think this is a very practical solution. Another way to address this issue would IMHO be to always display a deletion log excerpt on non-existing image pages. This way reusers would not have to find the logs on their own, just to find out what happened to their file. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
