Last modified: 2011-05-02 21:08:25 UTC
In this example page: http://test.wikipedia.org/wiki/User:Huji/Titles Both redlinks have a title attribute, as does the first blue link ("pages"), but the last link ("Wikipedia") doesn't have a title. On larger pages in other sister projects, it seems like some of the blue links (roughly less than 50% of them) are randomly missing a title attribute. User:Companionship on Persian Wikipedia should be credited for notifying me about this bug.
This was intentional, to avoid titles that duplicate the link text, see Bug 542.
Blue links only get the page in title if it's different than the text, per Bug 542. See r76127 (I thought that wasn't still live on wikipedia?). Although given the annoyance to people reported here (waiting for a title that never appears) and the problems to get it right, I'd revert and close 542 as wontfix.
There do seem to be a fair number of people attached to that title attribute. That's a lesson for what happens when you change existing behavior in a widely used application.
It's not only attachment. Apparently, some users benefited from the title attribute in their bot codes, and now they have to resolve all redirects in a separate step.
(In reply to comment #4) > It's not only attachment. Apparently, some users benefited from the title > attribute in their bot codes, and now they have to resolve all redirects in a > separate step. Please use the api.php for bots ... Some Gadgets or user js were broken due to this change.
It was javascript. And it makes sense to extract it from the a tag rather than performing a XMLHttpRequest (in some cases there's no other option). Unconditionally extracting it from the title attribute was much easier than the parsing they need now. The main problem I see is that now you don't know if a link will have a title or not, which reduces its usefulness (humans are bad at timeouts). Plus I don't see what are the benefits mentioned in bug 542 ("authors could rely more on this feature to convey useful information"), Given that it is then gzipped, I don't consider the space gainings to be definitive, on either way.
This (reverting bug #542's fix) is an issue that should get more input before a decision is made either way.
After discussion, I'll revert the fix for bug #542.
r87030
