Added a few new committers in the last week(ish):
Holger Motzkau - prolineserver - CiviCRM work
Benedikt Kämpgen - bkaempgen - Semantic MediaWiki, Selenium, Maps
James Alexander - jamesur - Fundraising
Ian Baker - raindrift - WMF employee
Welcome to everyone :)
Quick one for the tech folks: is there a known issue with printing at the
OTRS keeps getting comments that printing gets cut off after one page... I
searched bugzilla to no avail and am 99% certain this is a local computer
issue each time, but I wanted to check no one was aware of an issue ;)
I'm currently in the last stages of finishing a bot that will make
templates, userpages, talkpages on all Wikimedia wikis, this is done by the
Wikimedia API but I have a problem now and kind of need advice.
The bot will do the following:
bs.wiktionary.org User:GlobalEditBot --> check if the page exist
creating (+244). --> creating the page
Watchlist added --> Adding it to my watchlist
Retrieving watchlist for wiktionary:bs --> confirming its on it.
And it trows back this error:
Creating page [[wiktionary:bs:Korisnik:GlobalEditBot]] via API
Unknown Error. API Error code:ratelimited
Information:You've exceeded your rate limit. Please wait some time and try
What is the policy by Wikimedia for the API use, how much delay should I use
between the wiki's? Currently its 3 sec between every wiki's but that makes
me hit the limit. What is the adviced time?
Tomorrow (July 6th, Wednesday) at 2100UTC, I will hold a triage on IRC
of “easy” bugs. The purpose of this Triage will be to go through all
the bugs with this tag and make sure they're actually something that a
new MW developer could do.
We would like people who what to become involved with MediaWiki on the
development side to be able to use this keyword as a starting point, but
sometimes relatively intractable problem reports have been given this
There are currently about 25 of these bugs so we'll only have about 2
minutes per bug. If you are going to be involved in this triage, please
take a look at http://etherpad.wikimedia.org/BugTriage-2011-07 before
hand so we can keep up a good momentum. Feel free to update the
EtherPad before hand, but please don't remove items.
WHAT: IRC Triage of “easy” bugs
WHERE: #wikimedia-dev on freenode
WHEN: 2011 July 6, 2100UTC, conversion to local time at
I hope to see you there!
This document explains:
* why MediaWiki needs even better unit testing,
* what we're doing now
* and what we need to do next.
This is also a request for comments & commitments to make our testing
environment better. Suggestions:
* try to write more testable code, and start considering writing tests
* comment on Chad's RFC to help us get out of global hell:
* work on better code coverage and code change statistics
Please read and comment.
I wrote it with material and help from RobLa, Chad, Krinkle, and Hashar
Volunteer Development Coordinator
Just got this and 3 similar mails.
The thread and the revision number don't match.
> From: MediaWiki Mail <wiki(a)wikimedia.org>
> To: DieBuche <diebuche(a)gmail.com>
> Date: Tuesday, July 5, 2011 1:36:58 AM
> Subject: [MediaWiki r90678]: Revision status changed
> Στις 15-12-2010, ημέρα Τετ, και ώρα 15:57 -0500, ο/η Anthony έγραψε:
> > On Wed, Dec 15, 2010 at 3:30 PM, Ariel T. Glenn <ariel(a)wikimedia.org> wrote:
> > > We are interested in other mirrors of the dumps; see
> > >
> > > http://meta.wikimedia.org/wiki/Mirroring_Wikimedia_project_XML_dumps
> > On the talk page, it says "torrents are useful to save bandwidth,
> > which is not our problem". If bandwidth is not the problem, then what
> > *is* the problem?
> > If the problem is just to get someone to store the data on hard
> > drives, then it's a much easier problem than actually *hosting* that
> > data.
> We certainly want people to host it as well. It's not a matter of
> bandwidth but of protection: if someone can't get to our copy for
> whatever reason, another copy is accessible.
> Wikitech-l mailing list
The bugs are alive this weekend!
Here are a few that arrived on the scene since 1.17 was released that
are focused on the CLI tools:
maintenance script edit.php doesn't update link tables properly
Of this, Tim says:
It looks like there's no commit in Article::doEdit() after the
wfDoUpdates() call, and edit.php doesn't commit either, it just
Looks like an easy fix: just add the appropriate commits and test!
The next three are problems that Edward Z. Yang found with the
just-released CLI installer.
Install maintenance script needs to provide appropriate exit status
in ALL cases
Command line installer warning output broken
Installer should sanity check pre-existing tables
Since the CLI installer is my baby, I'll appreciate any help you can
provide in its defense. #29590 applies to more than just the CLI
installer, so by fixing it you'll may end up helping anyone using the
Dependencies break when mixing JS files and WikiModules, when
In the comments, Roan points to a related essay/comment he wrote in Code
Review. My favorite part is Roan's reaction to the code comment that
innocently claims “Document.write is synchronous, so this is called when
Roan's response? “Lies! document.write() is not synchronous, at least
not in Firefox 4.0.1, but I understand why it would appear to be.”
Even Roan is stumped in the end, though. “I'm not really sure how this
should be fixed” he says. But he does give you a couple of great ideas
to explore for fixing the problem. Check it out!
Happy hacking and, for the Americans, a happy 4th!