Jump to content

Wikinews:Water cooler/technical/archives/2010/March

From Wikinews, the free news source you can write!


Clean Delete Reasons

Would an admin mind adding b:MediaWiki:Gadget-CleanDeletions.js here? This would keep the deletion log uncluttered and help in navigation. To add this, one needs to import (copy?) the page from WB, import/copy b:MediaWiki:Gadget-CleanDeleteReasons and update MediaWiki:Gadgets-definition accordingly. Pmlineditor discuss 15:30, 5 March 2010 (UTC)[reply]

Maybe if you told me what it does. Blood Red Sandman (Talk) (Contribs) 18:15, 5 March 2010 (UTC)[reply]
When you go to delete a page, if the auto-summary contains the substring:
  • content was
  • page was empty
  • content before blanking was
  • page was empty

It will change the autosummary to be empty. (personally, I might consider the auto-summary to be useful, (I'm lazy, and who wants to write their own summary when going rouge ;) but i don't see any harm as importing it as a gadget). Bawolff 18:23, 5 March 2010 (UTC)[reply]

Sounds fine to me. Blood Red Sandman (Talk) (Contribs) 19:04, 5 March 2010 (UTC)[reply]

┌─────────┘
What Bawolff said. Sorry for not explaining what it was; was in a hurry. Pmlineditor discuss 06:00, 6 March 2010 (UTC)[reply]

proposal: hide the search this discussion on lqt

I propose we hide (with css) the search this discussion box on the Liquid threads box, as people are getting confused, typing the section they want to create into that box (and thus by following links, creating pages like Al shabaab ondiscussionpage:Comments:Somali opposition group al-Shabaab to block WFP food aid), instead of clicking the create new discussion link. See also bugzilla:22678. Thoughts on hiding the search box? Bawolff 03:47, 7 March 2010 (UTC)[reply]

When I was testing out lqt, I was mistaken there too, so I agree that the search bar should hidden. --Mikemoral♪♫ 04:03, 7 March 2010 (UTC)[reply]
I agree completely. It works ok for a well established, long thread, but for our purposes the search box is nothing but a nuisance. I'd like to see it removed —- or even hidden with an expandable clickie link to show the full box. Gopher65talk 04:17, 7 March 2010 (UTC)[reply]

Done Oh Oh, it's CSS magic... ya knowwwww --ShakataGaNai ^_^ 07:42, 7 March 2010 (UTC)[reply]

Hmm, whitespace looks a little odd now, or maybe its just me. Anyone else think so? (If it isn't just me I'll change it to visibility:hidden). Cheers. Bawolff 07:52, 7 March 2010 (UTC)[reply]

Lost in limbo. Not sure how to go about looking for more like it (though that might be partly because I don't really understand what happened to it, other than a vague notion that Easy Peer Review was missing some cylinders around that time); I stumbled on this one because I was idly browsing RockerballAustralia's Special:Contributions. --Pi zero (talk) 02:04, 14 March 2010 (UTC)[reply]

Ahh. This article got lost because it wasn't "sighted" during the review; that caused it not to appear in the newsroom (because of the {{publish}} tag), but at the same time not appear on front page or RSS feeds due to it being unsighted. This is why I encourage everyone to always check if an article has been auto-sighted by EZPR after reviewing. There are probably a few other unfortunate articles that got lost that way; but i'm not aware of any easy way to find them (DPLs, perhaps?) Tempodivalse [talk] 03:12, 14 March 2010 (UTC)[reply]
DPL solves all problems (and soon even more on next wmf update):

There are no articles for this topic. (Note this will also include stuff published before flagged revs was used. since its ordered we can ignore stuff once those articles start appearing. This should probably be worked into the newsroom or something). Bawolff 18:18, 14 March 2010 (UTC)[reply]

There was one other EzPR failiure (Woman blows herself up in Iraq; over 140 casualties), and 2 self-published for recent articles. The rest go back to 2009 (about 5 of non-sighted but reviewed ones in December 2009). There's also Refinery explosion burning 10% of Puerto Rico's fuel which was reviewed by a non-editor and not sighted. Since its so old i think we should just leave it as is. Bawolff 18:45, 14 March 2010 (UTC)[reply]
A legitimately reviewed article that just didn't get sighted is one thing (would the act of sighting it now dispatch it to current newsfeeds? yikes), but we shouldn't allow articles dated post-flaggedrevs to lie around with a {{publish}} tag on them if they weren't legitimately published.
Should we (it appears we don't already) have a category for articles published before flaggedrevs? Either in addition to or even alternative to Category:Published? It should then be possible to coax DPL into listing only published-but-unsighted articles that postdate flaggedrevs. --Pi zero (talk) 14:18, 15 March 2010 (UTC)[reply]
We could just sight those articles. I don't think we should have a category just for them. We could use the archived category to coax dpl not to list them. Bawolff 17:52, 15 March 2010 (UTC)[reply]
Good point; category Archived should do for that particular technical problem.
There's another issue involved, though. In the recent discussion at WP:IRS, a sampling of archived articles to check their quality first turned up articles that pre-dated flaggedrevs — and the person doing the check simply didn't realize that without being told. IMHO there should be some straightforward way of telling, by looking at an article, whether it pre-dates flaggedrevs. The peer review template on the collaboration page is a telltale, but that again requires inside knowledge, and something on the article itself seems like a good idea — either a category, or a notice, or both. I'm guessing that this would not be a lot of work because one would simply wire the {{publish}} template to do it. --Pi zero (talk) 03:45, 16 March 2010 (UTC)[reply]
I'm of the opinion they were published by the standards of the time - its not like we published random crap, we still had standards, just less formal ones - and thus they don't need to be distinguished. (but thats just imho). I don't see how {{published}} could be used. If we really want to we could abuse {{date}} i suppose, but if we must do that, I'd much rather see a bot just add a new template. Bawolff 05:33, 16 March 2010 (UTC)[reply]

There are new messages for you.

How to get rid of this please??? -- Cirt (talk) 23:03, 17 March 2010 (UTC)[reply]

Based on chat on irc, I'm assuming you're refering to the LQT thing on the watchlist. Which i must say is rather ugly. add the folowing to special:mypage/vector.css
.lqt_watchlist_messages_notice {display:none}

Bawolff 00:08, 18 March 2010 (UTC)[reply]

I added it here too, [1]. Will that work okay? -- Cirt (talk) 00:13, 18 March 2010 (UTC)[reply]
If you use monobook, yes. Bawolff

Making it easier to resubmit for review

I think a "review" button (already on {{develop}}) should be added to {{tasks}}. Any thoughts? Benny the mascot (talk) 14:56, 30 March 2010 (UTC)[reply]

How much of the message from {{develop}} should be reproduced on {{tasks}}? The cut-rate version of this would be a line — I'm assuming it would be just below the one that lists tasks to be performed — that doesn't include either of the two extra reminders appended by {{develop}}, something like
If we wanted to include either or both of the reminders from {{develop}}, they should probably be an additional sentence after "reviewers.", but those reminders might be redundant, depending on what tasks were listed.
(My mock-up wouldn't actually work right because, in order to get the button, I used develop_to_review_link, since there is no tasks_to_review_link.) --Pi zero (talk) 16:36, 30 March 2010 (UTC)[reply]
The reminders aren't needed, IMO. How can we get that button to work? Benny the mascot (talk) 17:34, 30 March 2010 (UTC)[reply]
This would be an addOnloadHook for tasks_to_review_link on MediaWiki:Common.js, very similar to the existing addOnloadHook for develop_to_review_link which is way down near the bottom of the file (with "develop" changed to "tasks" throughout). --Pi zero (talk) 19:20, 30 March 2010 (UTC)[reply]
(I've changed the button in the above mock-up to use the non-existent tasks_to_review_link. --Pi zero (talk) 23:21, 30 March 2010 (UTC))[reply]
I've made this change to {{tasks}}. Right now, though, there's no button, since the javascript patch hasn't been made (which would require an admin); so {{tasks}} always has the edit link that is, after all, what anyone with javascript turned off would see on {{develop}}. --Pi zero (talk) 01:12, 31 March 2010 (UTC)[reply]
Unfortunately, there is one possible problem with this, in that I gather {{tasks}} is sometimes used on articles that have already been published. Anyone have any ideas how best to address this? --Pi zero (talk) 01:17, 31 March 2010 (UTC)[reply]
I've never seen this before. Do you have an example? Benny the mascot (talk) 01:30, 31 March 2010 (UTC)[reply]
Nope. I don't remember seeing it either. Hopefully I was wrong, and, now that you've forced me to triple check, I'm going to operate on the assumption that I was wrong. After all, the pre-existing message on {{tasks}} pretty much says that the article hasn't been published. (I just got nervous when I noticed it was listed on Wikinews:Article flags, but the idea that that might just have been a minor glitch is reinforced by the fact that it isn't listed on Wikinews:Article stage tags.) --Pi zero (talk) 02:50, 31 March 2010 (UTC)[reply]
Okay, I'm consistently behind the curve, here. Article flags is the stuff that goes on disputed (hence unpublished) articles, and Article stage tags is the stuff that goes on undisputed articles. So the only thing wrong with this picture is that there's nothing wrong with it. At least I seem to be limiting my mistakes to this talk page (knock wood). --Pi zero (talk) 03:21, 31 March 2010 (UTC)[reply]