Author: banyantreewp
Description:
Currently, using {{CURRENTYEAR}} in a redirect breaks that redirect. See http://en.wikipedia.org/w/index.php?title=Recent_celebrity_deaths&diff=next&oldid=266593298, where "#REDIRECT [[Deaths in {{CURRENTYEAR}}]]" does not work.
Making this functional would save the hassle of having to remember to change these pages manually every year.
Version: 1.15.x
Severity: enhancement
If we're going to do this, we need to open all wikitext to redirects. Currently, we just do a quick regex to check if a page is a redirect, rather than fully parsing it prior to redirection.
Only implementing this for {{CURRENTYEAR}} would be a hack.
In what way is this a dup of bug 14323? This bug is about allowing magic words in the redirect target link, while 14323 is about rendering the wikitext that comes '''after''' the redirect magic. That's two completely different things; in particular, fixing bug 14323 would most certainly not fix this bug.
Yes it would. As mentioned in the other bug, attempting to only allow some things to parse prior to redirect (like in this bug: {{currentyear}}) is half-assing it. If we're going to parse an article, then we need to parse it properly.
Perhaps you're unfamiliar with how the redirect code works?
To find the target of the redirect from the page wikitext, it just looks for "#REDIRECT [[...]]" in the raw text at the beginning (properly localized and such, of course). It never parses the wikitext at all. See newFromRedirectInternal() in Title.php.
When doing a redirect=no page view, it parses the wikitext of the page in order to get categories, template backlinks, interwiki links, and such. But at the moment, it just throws the output text of that parse away. Not throwing it away is bug 14323. See view() in Article.php, at lines 878-886 in r53792.
Stopping the throwing-away won't at all affect the function used to find the target, and changing how the target-finding function works won't stop throwing the parser output away.