I recently set up a MediaWiki (http://server.bluewatersys.com/w90n740/)
and I need to extra the content from it and convert it into LaTeX
syntax for printed documentation. I have googled for a suitable OSS
solution but nothing was apparent.
I would prefer a script written in Python, but any recommendations
would be very welcome.
Do you know of anything suitable?
I've been informally mentoring André, Tiago, Diego, and César. They
are four students at Minho University who are currently working on a
project to improve DB2 database support in MediaWiki.
So far, they've:
- Fixed several outstanding issues with DB2 support involving
character encoding, Windows vs Linux, etc
- Added DB2 support to the new MediaWiki 1.17 Installer and Updater
- Put in the appropriate Updater sql patches to reflect database
schema changes since 1.14
MediaWiki already had some DB2 support, but it's been broken since
1.15 and never complete. As a result of their work, it's now possible
to successfully install MediaWiki on DB2 out of the box and to use the
core wiki features.
I'll shortly commit their first patch using my SVN account (leonsp).
I've taken some care to look over the code and make sure it abides by
the MediaWiki code guidelines.
Bug 24207 requests switching the math rendering preference default from its
current setting (which usually produces a nice PNG and occasionally produces
some kinda ugly HTML) to the "always render PNG" setting.
I'd actually propose dropping the rendering options entirely...
* "HTML if simple" and "if possible" produce *horrible* ugly output that
nobody likes, so people use hacks to force PNG rendering. Why not just
render to PNG?
* "MathML" mode is even *MORE* limited than "HTML if simple", making it
* nobody even knows what "Recommended for modern browsers" means, but it
seems to be somewhere in that "occasionally crappy HTML, usually PNG"
So we're left with only two sane choices:
* Always render PNG
* Leave it as TeX (for text browsers)
Text browsers will show the alt text on the images, which is... the TeX
code. So even this isn't actually needed for its stated purpose. (Hi
Jidanni! :) lynx should show the tex source when using the PNG mode.)
It's conceivable that a few folks really honestly prefer to see the latex
source in their graphical browsers (should at least do a quick stat check to
see if anybody uses it on purpose), but I wouldn't mind removing that
Fancier rendering like MathJax etc should be considered as a separate thing
(and implemented a bit differently to avoid parser cache fragmentation!), so
don't let future mode concerns worry y'all. Any thoughts on whether this
makes sense to do for 1.18 or 1.19?
I am starting this thread because Brion's revision r94289 reverted
r94289  stating "core schema change with no discussion" .
Bugs 21860  and 25312  advocate for the inclusion of a hash
column (either md5 or sha1) in the revision table. The primary use
case of this column will be to assist detecting reverts. I don't think
that data integrity is the primary reason for adding this column. The
huge advantage of having such a column is that it will not be longer
necessary to analyze full dumps to detect reverts, instead you can
look for reverts in the stub dump file by looking for the same hash
within a single page. The fact that there is a theoretical chance of a
collision is not very important IMHO, it would just mean that in very
rare cases in our research we would flag an edit being reverted while
it's not. The two bug reports contain quite long discussions and this
feature has also been discussed internally quite extensively but oddly
enough it hasn't happened yet on the mailinglist.
So let's have a discussion!
For a long time, we've been talking about migrating from Subversion to
Git. It's time to start getting more serious about it.
First: the need to do this. There is pretty broad acceptance that we
should move to a distributed version control system (DVCS). Our
current Subversion-based version control system has served us well,
but we're in need of a more suitable version control system for our
development effort. Our community is very distributed, with many
parallel efforts and needs to integrate many different feature
efforts. While we've developed lots of coping mechanisms, we sure
could use a system that's well suited to more fluid branching and
There has been resistance to this in the past, and there still may be
some resistance. However, I think we've worn everyone down. :)
Next: the selection of Git over other DVCSs. Over the past couple of
years, other systems have been mentioned (Bzr, Hg), but there hasn't
been any evidence (at least on this mailing list) for anything other
than mild support for the alternatives. As you might have seen, our
Ops folks have already moved to Git, and while they're right in the
middle of the tough part of the learning curve, they seem to be
adjusting just fine. The complaints seem to be of the "I really need
to get used to that" variety rather than the "why are we doing this
again?" variety. So, given the momentum that Git has, the ample
discussion we've had on the subject, and the fact that Ops is already
planning to support Git, this seems to be a settled question.
So now, the questions shift from "if?" to "when?" and "how?".
When? After some amount of arm twisting by Erik and Brion (*hugz*),
I've agreed to float a plan that has us making the migration by the
end of the year. This is completely contingent on our ability to get
1.19 deployed in a rapid fashion (which, if we can get through the
code review queue at our current rate, could be done in November).
Until we have a more fleshed out plan, though, "end of the year"
purely a guess, and subject to change (partly based on any ensuing
conversation after this mail). However, assuming we can clear the
technical hurdles, there's not any procedural issues I can see getting
in the way of a rapid transition.
How? Lots of unsorted pieces. There are still decisions we need to make:
* Code review tool: barring unforeseen complications, we're planning
to use Gerrit. We need to make sure it'll be a suitable replacement
for our existing tool
* How do we break up the repository? One big repo? Extensions each
get their own? We need to sort all of that out.
A draft plan is available here:
 ...or so I've read on Slashdot, so it must be true:
If you're interested in Wikimedia's infrastructure, or in making it
easier to develop MediaWiki and extensions, gadgets, and tools, please
come to the Wikimedia and MediaWiki hackathon happening 14-16 October in
New Orleans, Louisiana, USA.
We're getting together a wide variety of contributors -- including
tool, extension, and gadget writers -- to participate, give feedback,
test, and hack together.
At the event, MediaWiki developers and Wikimedia operations engineers
will be working on Wikimedia's gadgets/extensions/tools support,
authorization/authentication strategy, dev-ops virtualization, and
general training and hacking. And we'll improve and discuss the
Wikimedia Labs projects infrastructure
and other stuff that makes it easier for anyone to supercharge Wikimedia
The event is open to anyone who wants to come and contribute.
If you can make it to New Orleans, Louisiana, USA, 14-16 October 2011,
we'd love to have you. Please add your name to the attendees list:
(And please spread the word!)
Volunteer Development Coordinator
P.S. If the only way that you can come to this event is with financial
assistance, please let me know. I can't promise anything but I can at
least put in the request. (If you've already emailed me about that, no
need to repeat.)
On some of the Wikipedia sites, there are some messages near the top of
each page. These messages change every 10 or so seconds.
The problem is the number of lines in each of the changing messages is
not the same.
This causes the entire page to jerk up and down the screen every 10 or
so seconds. One might be reading many screenfulls below, but still the
page jerks up and down. I've never seen anything like that in the
history of WWW.
You might want to have a look at it, or forward my message to those who
are to blame.
Here's some stuff from 'view source' from nearby where the cause is.
document.writeln('<table width="100%" id="mw-dismissable-notice"><tr><td width="80%">'+siteNoticeValue+'</td>');
/* ]]> */
</script><table style="display: none;" id="mw-dismissable-notice" width="100%"><tbody><tr><td width="80%"><div id="localNotice"></div></td>
<table id="asn-dismissable-notice" style="background: none repeat scroll 0% 0% transparent;" width="100%"><tbody><tr><td><div style="display: block;" id="advancedSiteNotices">請參與<b><a href="/wiki/Wikipedia:%E6%8A%95%E7%A5%A8/%E5%90%84%E4%B8%BB%E9%A1%8C%E4%BD%9C%E5%93%81%E6%A0%BC%E5%BC%8F%E7%9A%84%E6%A8%99%E6%BA%96" title="Wikipedia:投票/各主題作品格式的標準">各主題作品格式的標準</a></b>的表決。</div></td><td>[<a href="#">關閉</a>]</td></tr></tbody></table></div>
<!-- /sitenotice -->
<!-- firstHeading -->
<h1 id="firstHeading" class="firstHeading"><div style="float: right;"></div>台南市公車</h1>
<!-- /firstHeading -->
<!-- bodyContent -->
<!-- tagline -->
<!-- /tagline -->
<!-- subtitle -->
<div id="contentSub" dir="ltr" lang="zh-tw">（重定向自<a href="/w/index.php?title=%E8%87%BA%E5%8D%97%E5%B8%82%E5%85%AC%E8%BB%8A&redirect=no" title="臺南市公車">臺南市公車</a>）</div>
<!-- /subtitle -->
<!-- jumpto -->
跳轉到: <a href="#mw-head">導覽</a>,
<!-- /jumpto -->
<!-- bodytext -->
<table class="infobox" style="width:
20em; font-size: 95%; text-align:
Support for 3D-rendered molecules on Wikipedia has been on the
wishlist since ... forever. This was never done due to security
I just found this site : http://alteredqualia.com/canvasmol/#Penicillin
only runs in the user's browser, Wikipedia servers are not at risk;
we'd probably have to check the code for potential XSS problems etc.,
browsers and, yes, old IE. But so what.
Any takers? Or should I give it a go?
Been some things floating around about this already, but I'm proud to announce Brighton Wikimedia Hackathon.
MediaWiki developers are going to meet in Brighton on the South East coast of the United Kingdom to hack anything to do with Wikimedia projects (mediawiki, toolserver, pywikipedia and various other things.) I've been putting this together for a while, with a lot of help from Roan, Reedy, Sumana and various others, and the date has now been confirmed for the 19th and 20th of November 2011 (unfortunatly, it clashes with WikiConference India). If you're intending to come, please add your name here, just so we can start getting an idea of how many people are coming:
I'll be adding more details as they become available, as well as a registration form.
-- Lewis Cawte