Last modified: 2011-12-30 06:49:03 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T33469, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 31469 - tracking category names messages may not expand {{NAMESPACE}} magic words relative to the right title
tracking category names messages may not expand {{NAMESPACE}} magic words rel...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
1.18.x
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-10-07 01:09 UTC by Betacommand
Modified: 2011-12-30 06:49 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Betacommand 2011-10-07 01:09:08 UTC
http://en.wikipedia.org/wiki/Category:Articles_with_missing_files should be limited to mainspace only pages, after preforming a null edit the pages are sorted correctly (there are three different categories, one for templates http://en.wikipedia.org/wiki/Category:Templates_with_missing_files , the one above for mainspace, and http://en.wikipedia.org/wiki/Category:Pages_with_missing_files for everything else). After some time the job queue comes around and re-parses a page and then its back in the articles category even though {{NAMESPACE}} should place it in the proper category. 


<from the talkpage of the related message http://en.wikipedia.org/wiki/MediaWiki:Broken-file-category>

This doesn't appear to work reliably; the {{NAMESPACE}} etc get transformed by the generic message transformation and I'm not convinced it's consistently related to the namespace of the page being parsed. On a local test, for instance, when editing a template I see a background job queue item to rebuild links on the page using it -- which ends up labeling the page as a 'Template'. On the live site these'll be happening from background job queue runners, so not sure what title the message cache might think they're on. --brion (talk) 21:43, 6 October 2011 (UTC)
Comment 1 Brion Vibber 2011-10-07 01:33:00 UTC
Add'l notes:

The tracking category gets added with addTrackingCategory, which simply takes the given message key and expands it with wfMsgForContent(), so whatever the MessageCache is hooked up to will get used.
Comment 2 Sumana Harihareswara 2011-11-09 01:18:08 UTC
Clarifying the steps-to-reproduce from the original bug report:

* Verify that http://en.wikipedia.org/wiki/Category:Articles_with_missing_files starts off containing only mainspace only pages.
* Perform a trivial edit.
* Notice that http://en.wikipedia.org/w/index.php?title=MediaWiki:Broken-file-category&action=edit properly splits pages into their three categories: one for templates
http://en.wikipedia.org/wiki/Category:Templates_with_missing_files , http://en.wikipedia.org/wiki/Category:Articles_with_missing_files (as mentioned
above) for mainspace, and
http://en.wikipedia.org/wiki/Category:Pages_with_missing_files for everything
else).
* Wait till the job queue is processed (this will take a few hours).  When it re-parses a page, no matter what category it belongs in, then it'll go back into the http://en.wikipedia.org/wiki/Category:Articles_with_missing_files page that ought to only contain the articles category.
Comment 3 Bawolff (Brian Wolff) 2011-12-30 06:49:03 UTC
fixed in r107623.

I'm going to open another bug (bug 33431) for how MessageCache should be using correct title during job queue jobs.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links