419 bank scam emails have an annoying tendency to link to news and reference sites like CNN, BBC News, and Wikipedia to make their phony claims sound more legitimate by linking them with some actual event. For example:
I am HARRYZAN BIN ABDULLAH.an attorney at law, A deceased client of mine,who here in after shall be referred to as my late client,died as the result of a heart-related condition on March 12th 2005.His heart condition was due to the death of allthe members of his family in the tsunami disaster on the 26thDecember 2004 in Sumatra
I have contacted you to assist in distributing the money left behind by my client before it is confiscated or declared unserviceable by the bank where this deposit valued at Seventeen million five hundrend thousand dollars(US$17.5 million dollars) is lodged. This bank has issued me a notice to contact the next of kin,or the account will be confiscated.
We tend to get a number of automated responses to such spams along the lines of “This email was received which is advertising a web site that appears to be hosted by you, please review the message and investigate this site”. It’s kind of annoying. :)
One thing we could do with frequently-targeted articles like this is put a template at the top warning that the reader may have been linked from a 419 scam mail; but this would be annoying to everyone who didn’t click on it from an e-mail, and the template would be hardcoded into the page and thus could show up in exports, printouts, PDFs, etc.
When I’ve tried this in the past, someone ended up removing the templates… didn’t seem worth getting in a wheel war over. :)
Even if we want to show this sort of warning, it should be handled as out-of-band information to keep from mucking up the article content itself. Similarly, notices about page protection and other such transitory editorial issues don’t really belong embedded into the core text.
What seems like a good way to allow these out-of-band notices to be easily added to a page and edited without being a core part of the page, or an overall performance drag when no notice is present?
Quick note — we’re now testing Werdna’s AbuseFilter extension on test.wikipedia.org. AbuseFilter will make it easier for on-wiki admins to set up automatic detection and tagging in response to common suspect editing patterns.
A lot of this kind of filtering is being done in client-side bot tools today, but it can be hard to coordinate what’s going on, and responses are usually limited to heavy-handed reversions… by building the filters into the wiki, actions can range from simply tagging an edit for human attention to emergency desysopping, depending on what’s appropriate.
Currently, sysops can define filter rules on Test Wikipedia, but with some limitations on what the system can do in response:
- Tagging with visibility in RecentChanges/History/Contribs/etc isn’t implemented yet (needs some support in MediaWiki core that hasn’t been merged yet)
- Filter-triggered blocks, range blocks, and removal from groups is disabled since we don’t want people going crazy just yet. ;)
Werdna will be polishing up the capabilities, interface, and capabilities of AbuseFilter over the next couple weeks … in response to your help testing and providing feedback. Go check it out! :D
So sometimes you’re editing away on a totally awesome page on Wikipedia…
When suddenly disaster strikes! You close your window by mistake, or the browser crashes, or a save failed and you can’t quite get back to where you were. All your work is lost. :(
Well, fear no more! With the Drafts extension in place, your work is saved in the background every 2 minutes, or every time you preview or hit the save draft button:
When you return to your article after your catastrophic event and click “edit” again, you’ll be presented withÂ a list of your saved draft(s):
Pick it out of the list, and you’re back in business!
When you successfully save, the draft is discarded. (You can explicitly discard one if you don’t want it… they’ll be automatically thrown away after 30 days.) You can also pull up a list of all your saved drafts at Special:Drafts, in case you forgot where your page was.
After some more testing on test.wikipedia.org and maybe a little tweaking, we’ll start rolling things out to the main sites…
The Drafts extension is one of the first bits of work our staff developer Trevor Parscal did for us, but testing it got pushed back in all the crazy recent times with fundraisers and holidays and everybody starting new projects. :) We’re now starting to get back down to regular business, and lots of nice new things are going to be popping up!
Updated 2009-01-18: Fixed typo mentioned in comment. :)
I’ll be speaking at FOSDEM in Brussels in February… be a good chance to meet up with many of our European volunteer devs. (Hi guys!) Come out and have a beer with us, or other coding beverage of your choice!
I’ll also be bringing along Tomasz Finc, one of our staff devs here in San Francisco. Tom did a lot of the technical work on our fundraiser campaign, and is now going to start poking at patching up our monitoring and testing infrastructure so we can smooth out the development process.
Here’s the abstract for my talk:
MediaWiki was born in 2002, when Wikipedia’s editing activity outgrew the concurrency limits of its original wiki engine. The first 6 years of this open-source wiki platform’s development were largely devoted to scaling and performance, ensuring that the world’s most editable online encyclopedia could keep up with the number of articles, visitors, and changes that come with being an insanely popular user-written site. But the user interface hasn’t changed much since 2003; if anything, packing in more features has made many aspects of the wiki harder to use over time.
In 2009, MediaWiki developers are turning their eye towards usability and design issues. As with the scaling problems we’ve tackled before, we have to be able to target anything from a tiny personal or intranet wiki to the massive Wikipedia sites, making a range of different use cases with different needs… It’ll be fun!
I’ll be going over some of the particular UI and workflow issues in editing, media uploading, and other areas that we intend to tackle, summarize some of the existing work toward those ends, and give a preview our upcoming Wikipedia Usability Initiative.
Latest changes to go live last night, up to r45489:
- Put restricted image moving back, with Brion’s permission (disabled pending some final tests)
- ([[bugzilla:6749|bug 6749]]) Terminology on history page [last -> prev]
- ([[bugzilla:11330|bug 11330]]) Improper use of WebRequest::getIntOrNull()
- ([[bugzilla:12433|bug 12433]]) DefaultSettings.php $wgReadOnlyFile comment clarifications
- ([[bugzilla:9243|bug 9243]]) Avoid exit to make MW handle page exceptions properly
- ([[bugzilla:16850|bug 16850]]) Allow $wgActionPaths to contain query strings.
- ([[bugzilla:5071|bug 5071]]) Image appears above text when viewing diff of an image page
- ([[bugzilla:16802|bug 16802]]) application/x-rar is not a known mime-type
- ([[bugzilla:16783|bug 16783]]) MediaWiki:Cannotdelete error should include a log extract
- ([[bugzilla:16659|bug 16659]]) Prettify permalinks. Just use ?oldid=x
- ([[bugzilla:16862|bug 16862]]) Non-content pages sometimes do not get autopatrolled
- ([[bugzilla:16429|bug 16429]]) “nominornewtalk” should not trigger e-mail notifications
- ([[bugzilla:16107|bug 16107]]) Rename Special:Imagelist to Special:ListImages to keep the consisten…
- ([[bugzilla:16045|bug 16045]]) Pagination links break on Special:Log/Username
- ([[bugzilla:16044|bug 16044]]) Vague error message in Special:Emailuser
- ([[bugzilla:16107|bug 16107]]) Imagelist -> ListFiles
- ([[bugzilla:15999|bug 15999]]) Rollback using markasbot (bot rollback) shouldn’t get a diff
- ([[bugzilla:16865|bug 16865]]) Access to pages via “curid” parameter should include meta noindex
- ([[bugzilla:15498|bug 15498]]) Provide links to revisions listed at the Special:Contributions page
- ([[bugzilla:14970|bug 14970]]) Add a number of revisions column to the Special:ImageList page
- ([[bugzilla:14737|bug 14737]]) Allow the autoconfirmed timer to run from the first edit
- ([[bugzilla:16376|bug 16376]]) Mention in deleteBatch.php and moveBatch.php maintenance scripts tha…
- ([[bugzilla:16507|bug 16507]]) Not setting “other time” on creation unprotection error removed
- ([[bugzilla:15427|bug 15427]]) Make monobook firstheading have an ID (instead of class) like modern
- ([[bugzilla:2242|bug 2242]]) Introduce expiry time for temporary passwords.
- ([[bugzilla:16560|bug 16560]]) Special:Random returns a page from ContentNamespaces, and no longer from NS_MAIN. Patch contributed by Lucas Garczewski.
- ([[bugzilla:16720|bug 16720]]) Transcluded Special:NewPages processes “/username=”. Patch submitted by Brent G.
- ([[bugzilla:16854|bug 16854]]) Provide explicit error when is omitted. Patch by Brad Jorsch.
- Track # of reviewed edits for users
- Track # of rollbacked edits
- Turn off userpage requirement
- ([[bugzilla:16894|bug 16894]]) Simplify URL after automatic flagging
- ([[bugzilla:16879|bug 16879]]) Add Link to help page on draft pages
- Use minimum max tally counts to allow future changes to be easier (less likely to need to re-run this)
- Tweak promote values
- Enforce reviewedEdits param
- Remove sorbs check option
- reviewedEdits -> totalReviewedEdits
- Move up some of the fast checks
- Bump uniqueContentPages
- Add autopatrol of new pages to log
- MediaWiki:Protect-expiring needs to have date and time separated.
- Use user’s language for ‘protect-expiring’ message in Special:Protectedpages and Special:Protectedtitles, no need to use it as content as it will simply be shown to the user and nothing else
- removed $wgOut->setPagetitle( … ), already done in SpecialPage::execute()
- Modified paths:
- + id on Whatlinkshere for list for easier access
- Add new messages ‘movepage-moved-redirect’ and ‘movepage-moved-noredirect’ per http://www.mediawiki.org/wiki/Special:Code/MediaWiki/45288#c1135
- Expand ArticleRollbackComplete hook to include reverted rev