Last modified: 2014-07-03 02:52:00 UTC
MediaWiki pages that contain redlinked files by default, and example being MediaWiki:Filerevert-intro (there may be others), create wanted files when the page is created and the redlink remains. It appears to be because the redlink links to Special:Upload rather than the file page. Creating the file page with something doesn't work - the system does not appear to recognise the page as being created unless there is an actual file there. Nothing can be uploaded in place of the file as the file type, such as .jpg or .png is added to the end of the file name whether you want it or not.
MediaWiki:Filerevert-intro is a (translatable) message shown in the user interface, and the red link $1 is a placeholder for a variable (but I guess you know all that). Hence not sure if I understand the problem correctly ("because the redlink links to Special:Upload rather than the file page"), and where this is exposed to "normal" users that don't look up UI strings in the MediaWiki: namespace? Assuming you run MediaWiki 1.19.1 I'd first recommend to upgrade to 1.19.3 and check if the problem remains (likely nothing will change, but at least you'd run a supported version).
I've also corrected the Mediawiki version, it is 1.19.3, I apparently misread it. Either way, I'm coming from Wikia and have no way to update MediaWiki versions, not forgetting the last upgrade Wikia did was from 1.16. I'm also aware of how $1 (or $2, $3, etc.) are variables altered depending on usage. As an example, the link references /wiki/Special:Upload?wpDestFile=$1 an example of which can be seen http://camtest.wikia.com/wiki/MediaWiki:Filerevert-intro as opposed to linking to the filepath that would be there when the image has been uploaded. When the page is created it then links to the file - http://camtest.wikia.com/wiki/Special:WhatLinksHere/File:$1. You'll notice I've also created File:$1 redirecting it to another, which doesn't resolve the issue. I wouldn't say this poses any major problem, likely there's not very much point in adding to the page under normal circumstances. It just seems a little odd to have a system message that automatically creates a redlink as soon as it's created. I assume the same is true of links to [[User:$1]], [[$1]], etc. which are normally redirected to a placeholder page in my experience, although in this case that doesn't work. It would probably be nice to recognise those as issues here too. Perhaps those should automatically redirect to a placeholder system message?
(In reply to comment #2) > I've also corrected the Mediawiki version, it is 1.19.3, I apparently misread > it. Either way, I'm coming from Wikia and have no way to update MediaWiki > versions, not forgetting the last upgrade Wikia did was from 1.16. I'm pretty sure this issue would still be present on latest (git) mediawiki, so don't worry about versions too much. >I'm also > aware of how $1 (or $2, $3, etc.) are variables altered depending on usage. > > As an example, the link references /wiki/Special:Upload?wpDestFile=$1 an > example of which can be seen > http://camtest.wikia.com/wiki/MediaWiki:Filerevert-intro as opposed to > linking > to the filepath that would be there when the image has been uploaded. When > the > page is created it then links to the file - > http://camtest.wikia.com/wiki/Special:WhatLinksHere/File:$1. You'll notice > I've > also created File:$1 redirecting it to another, which doesn't resolve the > issue. > > I wouldn't say this poses any major problem, likely there's not very much > point > in adding to the page under normal circumstances. It just seems a little odd > to > have a system message that automatically creates a redlink as soon as it's > created. You're correct it is a little odd. However, we would still want to recognize red links though as a missing file if someone just added [[file:nonexistent.jpg]] to some message. So we don't want to ignore them in general. Maybe there could be special casing for links to $<number>, only in mediawiki namespace, to not register the link in the link tables. > > I assume the same is true of links to [[User:$1]], [[$1]], etc. which are > normally redirected to a placeholder page in my experience, although in this > case that doesn't work. It would probably be nice to recognise those as > issues > here too. Perhaps those should automatically redirect to a placeholder system > message? I think the automatic redirect to a place holder is something the users manually make, not something that mediawiki does itself. The reason the file link doesn't follow redirects, is that the page [[file:$1]] is a page redirecting to a non-file page, where the actual link text is [[media:$1]] which should link directly to the image in question (not its description page). If the link was [[:file:$1]] (Note leading colon) then the redirect would work more as expected. --- moving component to i18n. This isn't really a file management issue as the issue is present for other link types too. This is more a parser or i18n issue imo
(In reply to comment #3) > However, we would still want to recognize > red links though as a missing file if someone just added > [[file:nonexistent.jpg]] to some message. So we don't want to ignore them in > general. Maybe there could be special casing for links to $<number>, only in > mediawiki namespace, to not register the link in the link tables. So how's this an i18n problem? Seems about fixing the query pages. Probably a WONTFIX anyway, I don't see much value in it.
(In reply to comment #4) > (In reply to comment #3) > > However, we would still want to recognize > > red links though as a missing file if someone just added > > [[file:nonexistent.jpg]] to some message. So we don't want to ignore them in > > general. Maybe there could be special casing for links to $<number>, only in > > mediawiki namespace, to not register the link in the link tables. > > So how's this an i18n problem? Seems about fixing the query pages. Probably a > WONTFIX anyway, I don't see much value in it. By special casing the i18n system to think those are not links for the purpose of linksupdate (as one possible solution). Perhaps thats really more the parser component. I agree this is a rather low priority issue ( but dont quite think its a wontfix). Its presumably not just the query pages that we would want to change but anywhere that queries the link tables (special:whatlinkshere, various api calls) thus probably better to just not register such links in the first place.
At translatewiki.net we use certain hooks to suppress categories on pages in MediaWiki: and other translation namespaces for everything except /qqq pages. I'd also like to use the TextContent type for those pages when it is less buggy.
Looking back on this, part of me is tempted to do something along the line of and il_to not like '$_'; in Special:Wantedfiles, as a hack to make them stop appearing. Not sure if that's silly.
