Author: vinhtantran
Description:
Although I set cmnamespace=6 (File namespace), the result still add "Category" namespace (10) and "Template" namespace. I suggested it is a bug in API.
It makes my bot delete some unwanted pages :(.
Version: unspecified
Severity: normal
URL: http://vi.wikipedia.org/w/api.php?action=query&list=categorymembers&cmtitle=Th%E1%BB%83+lo%E1%BA%A1i%3AC%C5%A9ng+c%C3%B3+s%E1%BA%B5n+%E1%BB%9F+Wikimedia+Commons&cmnamespace=6&cmlimit=50&format=xml
Reopening and changing product to Wikimedia, so it has a somewhat better chance of showing up in bug searches. A workable (if not optimal) fix has been in MediaWiki for weeks, but no one has bothered to use it to fix the completely-broken live hack on Wikimedia wikis (and a scap doesn't seem particularly forthcoming).
A dupe is a dupe is a dupe. Closing again.
(In reply to comment #3)
A dupe is a dupe is a dupe. Closing again.
Good to know that "A live hack broke Wikipedia, and despite it being fixed in MediaWiki it still isn't fixed on Wikipedia" isn't a bug you care about.
herd wrote:
(In reply to comment #4)
Good to know that "A live hack broke Wikipedia, and despite it being fixed in
MediaWiki it still isn't fixed on Wikipedia" isn't a bug you care about.
The "Live Hack" disabling the feature was applied to MediaWiki, and deployed to Wikimedia after, and was then later fixed in MediaWiki more properly, but this later fix is not YET deployed to Wikimedia. This happens sometimes. The disabling was immediately deployed because it was causing server lag. The fix eventually /will/ get deployed to Wikimedia, during the next code review and scap. This is not considered urgent as it isn't causing server problems. There are thousands of changes between scaps, the few server administrators available can't immediately deploy any of them except the urgent ones.
And... Wikimedia's Bugzilla policy is to mark MediaWiki bugs as fixed when they are fixed in trunk, not when they are deployed Wikimedia. This is and was a MediaWiki bug (introduced in, and corrected in), not a Wikimedia issue. The Wikimedia issue will sort itself out in a few days/weeks.
(In reply to comment #5)
This is not considered urgent as it isn't causing server problems.
Just client problems. For almost a month, with no end in sight.
And... Wikimedia's Bugzilla policy is to mark MediaWiki bugs as fixed when they
are fixed in trunk, not when they are deployed Wikimedia. This is and was a
MediaWiki bug (introduced in, and corrected in), not a Wikimedia issue.
So just because the live hack was put in trunk before being applied to Wikimedia, it's not a Wikimedia issue? Fun. It would be different if the bug was due to something that went through code review and was normally scapped.
herd wrote:
(In reply to comment #6)
Fun. It would be different if the bug was due to something that went
through code review and was normally scapped.
No it wouldn't. It would be corrected in trunk and would go live at the next scap. It has happened exactly this way for thousands of bugs already.