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?
On Fri, Jul 29, 2011 at 12:30 PM, Jay Ashworth <jra(a)baylink.com> wrote:
> More pointedly, is there a really *good* "Software Development Version
> Management HOWTO" anywhere at all? I've looked at the git book, and it
> just knocked me on my ass from the first chapter. I *almost* understand
> BZR... but I haven't seen a good 30,000ft explanation of any of them,
> written for people who are good programmers, but have never worked with
> one before.
I think this might be what you're looking for:
...though the information is a little dated. Then again, our version
control system is a little dated, so maybe this is just right (though
ignore pretty much everything said about CVS).
Regarding MediaWiki-specific information about branching and so on,
that's largely covered here:
...though that documentation could stand some improvement. (volunteers?)
Over the past couple days Roan Kattouw and I have been pushing out
changes to enable protocol-relative URL support. We've gotten to a
point where we think it is stable and working.
We've enabled this on test.wikipedia.org, and plan on running it for
two weeks before enabling it elsewhere. Please test if everything is
working properly, especially with regards to the API and bots. Report
bugs in bugzilla if any are found.
In light of recent discussions on this list about using branches and
not commit broken code, I'd like to ask for some advice.
Firstly, a little on me. I'm an amateur programmer, and more than a
bit rubbish at times (despite PHP being my strongest language). I've
submitted a number of patches to Bugzilla, prodded people on IRC, etc.
and they've been reviewed and accepted with minor changes. They've all
been small, easily readable patches for "paper cut" bugs so far.
More recently, I've been having a prod at some of the page protection
code. My goal currently is to make it possible to overlay different
editing restrictions e.g. to make it possible to have a temporary
"surge" in protection to +sysop without touching the underlying
+autoconfirmed. I've been having some success with the basic
operations, although it has required an additional pr_id column to be
added to page_restrictions and a couple of key changes. Obviously my
code would need substantial review when I'm done, particularly to
consider the many odd cases that come up when you've got 10 million
visitors and not just 1.
So, two questions:
* Should I write up my proposed changes for people to comment on? If
so, where? How should I publicise it? What sort of things should I
* Am I in danger of essentially creating one large patch which then
has to be commited all in one go? Should I try to avoid this? How?
Thanks all and apologies for some many questions,
Ask you may know, there will be an "Ask the Developers" panel at Wikimania.
However, there are no developers to ask, yet :) To make this work, we need a
few lead WMF developers on the stage, ready to answer questions. So please let
me know if you would be willing to do that, or tell me who I could ask to take
part in the panel.
In any case I want to invite all developers to be there at least in the
audience, so specific questions can be answered directly by someone working on
that topic. Originally, this sessions was planned as a "fish bowl" type
discussion on Danes' suggestion, which would remove the distinction between
panelists and audience. But since she won't be there and I don't have any
experience with that kind of thing, it's going to be a regular panel.
The session is scheduled in the block starting on 10:15 on Friday. Shortly
before that, Guillome has his "Wikimedia technical staff vs. the_World" -
perhaps we could arrange to combine or rather links these two events? Have the
"ask the devs" basically as the discussion round to "staff vs. world"? What do
See you in Haifa, hopefully for the Hacking Days already....
A draft schedule for the Haifa Hackathon has been published:
Some last details are being worked out. In particular, there are still
many slots for 5-minute lightning talks every hour. Many of the topics
listed under the "Topics" heading on that page can be subjects of
lightning talks, so if you can present it as a lightning, please add
it at the bottom.
See you in Haifa... in two days!!
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
“We're living in pieces,
I want to live in peace.” – T. Moore
Thanks, Sumana, for giving me this hint, that I now finally follow:
We have made available Selenium tests for Semantic MediaWiki (see email
AIFB, Karlsruhe Institute of Technology (KIT)
Phone: +49 721 608-47946
From: Benedikt Kämpgen [mailto:firstname.lastname@example.org]
Sent: Wednesday, July 20, 2011 2:14 AM
To: Semantic MediaWiki developers; Krzysztof Krzyżaniak
Subject: [SMW-devel] SMW Selenium system tests available
Semantic MediaWiki is now ready to be tested using Selenium, e.g., for
regression tests after code changes:
* We have uploaded one test suite with several test cases to
* We plan to upload more.
* For information of how to use the test suite, see our updated
documentation at .
* We rely on the Selenium Framework  recently provided by MediaWiki.
The Wikimedia Foundation has not yet decided, whether it will continuously
support this Selenium Framework. Still, we think Selenium system testing has
potential for two reasons:
* With Selenium IDE , it is very easy to create system tests, even for
less technically-skilled or SMW-experienced people.
* Also more complex Selenium system tests are possible, though in this case
writing PHP code will be needed.
We'd be happy to hear about your experiences.
AIFB, Karlsruhe Institute of Technology (KIT)
Phone: +49 721 608-47946