Hi everyone,
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?
Kind Regards,
Hugo Vincent,
Bluewater Systems.
Hi,
today we came over 10k HTTP requests per second (even with inter-squid
traffic eliminated). Especially thanks to Mark and Tim, who've been
improving our caching, as well as doing lots of other work, and
achieved incredible results (while I was slacking). Really, thanks!
Domas
Hey,
I've put together an extension for rating articles if anyone is
interested. It's just a first version and hasn't been tested much, but
the details can be found here:
http://www.wikihow.com/WikiHow:RateArticle-Extension
You can see an example here on our development server:
http://wiki16.wikidiy.com/Get-a-Better-Deal-on-a-Home-Loan
(username password wikihow / wikihow2006) - scroll down to the bottom
of the page for the checkmarks.
I'd appreciate feedback if anyone has any. If someone wants to add
this to extensions in svn, that'd be great.
Thanks,
Travis
Anthere wrote:
> Hello Mike,
>
> Apologies, but it was unclear to me whether there is a wiki page set up
> for the 2007 hacking days.
> If there is no such page, can you set up one so that it is easier to
> follow plans and discuss programmes ?
>
> One feedback I had from hacking days 2006 was that it was necessary to
> have more cool time in small groups, and less "academic-type"
> presentations in front of 20 people. In short, they need not only a room
> with some presentations going on, but also a nice and cosy place to sit,
> with drinks etc...
Indeed there was a strong feeling that the hacking days were
overproduced last year, with too many outsiders, too heavy scheduling,
too many talks.
The hacking days are meant to be informal and, hopefully, productive. :)
Some really nice points did get made in the middle of it, but I and
others found the overall experience rather frustrating. In contrast, in
2005 we really weren't organized enough, and while there was good
socializing which helped build team spirit we didn't come out with much
directly productive.
My recommendation: don't invite too many people, don't have lots of
talks. Talks would be more appropriate for a tech track during Wikimania
proper.
A few small workshop-type sessions to let people strategize, socialize,
roadmap, experiment, and accept tasks to work on for the coming months
would be a lot nicer, and would better justify having a distinct
"hacking days" period before/after the main conference.
-- brion vibber (brion @ pobox.com)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In the previous discussion (about Special:Desysop), it was proposed to
merge the user rights pages (Special:Userrights, Special:Makesysop,
Special:Makebot, Special:GiveRollback, and now also Special:Desysop)
into the page Special:Userrights, using configuration settings. It seems
to be a good time to propose it:
I've merged these special pages to Special:Userrights using
configuration settings in
http://svn.wikimedia.org/viewvc/mediawiki/branches/rotem/userrights ,
which is an improved user rights page.
This proposed system adds the following features to Special:Userrights:
* Flexible configuration settings for a limited interface – for example,
you can allow bureaucrats to grant only these permissions and revoke
only those permissions, and allow the stewards to do everything.
* Checkboxes instead of lists, mainly because it's possible to disable
them separately while it's not possible in lists.
* Changing the permissions of remote users for stewards, controllable by
a permission ("userrights_remote"), like in the stewards interface of
Special:Makesysop.
* Log comment, to explain the change, like in Makebot.
You can either download and test it directly, or watch the following images:
http://img150.imageshack.us/my.php?image=mediawikinewuserrightsbureaucratsl…
The limited interface for bureaucrats, like it can be set in Wikimedia
sites.
http://img84.imageshack.us/my.php?image=mediawikinewuserrightsstewardsgg7.p…
The full interface for stewards, like it can be set in Wikimedia sites,
editing a remote user.
This change should deprecate Makesysop, Makebot, GiveRollback and
Desysop and make them implementable by using only configuration
settings. However, these extensions may be kept for old versions, and
for sites which were not updated. (There seems to be a compatibility
issue with Special:Makesysop because one of its core functions
(HTMLSelectGroups) was removed, but it can be defined in
SpecialMakesysop.php or SpecialMakesysop_body.php as a class function.)
Additional technical information may be found in
http://www.mediawiki.org/wiki/User:Rotemliss/User_rights_suggestion#How_to_…
. You can also read the other parts of the page, but it's a bit old and
not updated in some parts. You can also ask here about anything unclear.
What do you think about this implementation? Which changes should be
done? Do you think some features should be added, or dropped?
Thank you very much for the feedback.
- --
#define Name RotemLiss
#define Mail mail-AT-rotemliss-DOT-com
#define Site www.rotemliss.com
#define KeyFingerPrint 4AFD 8579 A449 4267 BED9 38E5 6EF8 5B1F EBDE 7AC0
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFE4b2abvhbH+veesARApwWAKCq1TGg1zVjTIjwDiH3f7AVe0sbGQCfV7hJ
NCU2Uwu1nrCv9ReNhVtaIxw=
=CBQh
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'm currently doing a test run of pulling migration data from the user
tables; the slow part currently seems to be getting the edit counts.
In a day or two I'll set up test.wikipedia.org for interactive migration
testing. This will allow people to try out the UI, and give a chance to
see how it looks so we can make sure the UI translations get done soon...
- -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFa/UawRnhpk1wk44RAon5AJ0Z3pDD6bFbYrT0d/eVz3N485rgggCbBooe
bb49EkzvY/6qZyze3BCTz6g=
=2Rya
-----END PGP SIGNATURE-----
We are a consumer web startup that's building a lot of really interesting
features on top of an existing wiki platform (Mediawiki is one of the five
we've narrowed it down to) and we're looking for a superstar developer with
wiki experience to join the team.
*We are a company:*
Who wants to use the power of Wiki to solve a big problem for consumers. Part
of our vision involves extending the functionality of one of the major wiki
platforms with innovative features that pose exciting technical challenges.
Be one of the first people to join a consumer web startup which could put a
lot of large companies out of business.
*You are someone who:*
- Is *scary smart* and someone we can *trust* will find the *right
answers* to hard problems you may have never solved before.
- Is *technically brilliant*, *versatile*, and* creative*.
- Your * teammates* love working with. You also have *friends* like
you who would *love* to *work with you* as we continue to grow.
- Will *passionately bust your ass* at the prospect of building
something that will revolutionize a $100B+ industry.
Specifically, we need someone who has a lot of valuable*
experience*building and extending the feature set of wiki platforms.
You also need experience designing and building highly-available and fault
tolerant *consumer web *applications with *performance*, *scalability*, *
stability*, and *security* in mind. This means you're very adept at:
- Building and extending the functionality of a wiki platform
- Database experience (optimizing SQL and writing software that uses
SQL to access databases)
- Distributed systems (hands-on experience preferred, academic
experience is OK)
- C/C++
- LAMP (PHP, Python, Perl)
Past experience with the following will make you even better able to
contribute to the team:
- Innovative approaches to UI design (AJAX, Flex/Actionscript/Flash)
- Designing and implementing production websites (HTML, CSS, XML,
Javascript, etc.)
- Database admin experience (setting up, maintaining and optimizing
Oracle, MySQL or PostgreSQL databases)
*You will:*
- Start with ideas, design products and features, architect a
technical solution, then build, test, and launch it.
- Help build and grow the engineering team as we expand over time. If
you also want to lead this team, that's in the cards, if you show us you
can.
*We will:*
- Be a group of the smartest, most trustworthy, passionate, and
interesting people you know.
- Make sure you have what you need to be happy and productive.
- Compensate you with a flexible mixture of cash and equity.
- Make great teammates united around a vision of how to solve some
pretty important problems for people.
Interested candidates should send your resume to
stealth.job(a)gmail.com<stealth_mode(a)gmail.com>with Wiki Guru in the
subject line.
Please also include in your email a summary of your past work with wiki
platforms (which ones you've worked with and what your contributions have
been to them).
On 29/11/06, MacGyverMagic/Mgm <macgyvermagic(a)gmail.com> wrote:
> We should probably still kill a lot of unsourced edits. Such a preload
> template is already in use at AFC and it is routinely ignored, but better to
> try and convince some people to follow it. It didn't solve the problem, but
> it cut back on problem cases slightly.
Yeah. The nice thing about a preload template is that it can guide new
editors without being a straightjacket on experienced ones - it's just
text in the edit box, after all.
Something like (off the top of my head):
'''{{PAGENAME}}''' is ... [one-sentence definition]. It is ...
==More detail==
[Put more detail about important aspects of {{PAGENAME}} here. Use
==section-name== around new sections.]
==References==
[List the sources you used in writing this article]
==External links==
[List the most important couple of external webpages on the subject.]
This shows people how to give us the useful content for a good stub
article without having to know all about editing wikitext and lovely
formatting.
wikitech-l - is it possible yet to do a preload when someone hits
'edit' on a red link? If so, what do we need for this to be switched
on for en:wp? It is likely time for such a thing.
- d.
On 29/11/06, 80686(a)svn.wikimedia.org <80686(a)svn.wikimedia.org> wrote:
> Revision: 18007
> Author: 80686
> Date: 2006-11-29 14:25:31 -0800 (Wed, 29 Nov 2006)
With all due respect, what kind of ridiculous username is that? How
are we supposed to link "80686" to a person in a quick manner? I see
"brion", I can think "Brion Vibber, don't argue with his code", I see
"tstarling", I know it's Tim.
"80686" might be a popular username, but we aren't dealing with a
bunch of children dancing about behind some wonderful label. We're
dealing with people who need to be a touch *more* accountable than the
damn wikis this is powering.
In addition, using a number is confusing. It could get mistaken for a
revision number or identifier of another form.
Rob Church
Dear Rob,
> With all due respect, what kind of ridiculous username is that? How
> are we supposed to link "80686" to a person in a quick manner? I see
> "brion", I can think "Brion Vibber, don't argue with his code", I see
> "tstarling", I know it's Tim.
well, it's me, as I'm known since 15 years in all kind of computing fields,
including Wikipedia, MediaWiki and the IRC channels.
Exactly like Brion (thanks) has introduced me in his mail.
> "80686" might be a popular username, but we aren't dealing with a
> bunch of children dancing about behind some wonderful label. We're
> dealing with people who need to be a touch *more* accountable than the
> damn wikis this is powering.
It is not propular, and that's the reason why I kept it since 15 years.
I don't know how young you are, but as learned IT specialists and studied
computer scientiest (applied computerscience in the field of internet
engineering) I don't see a problem here.
To be honest, I didn't find sponsors to pay people to create questioned
extensions and deal with them that they may be put under GPL to be pissed off
by you because of such a stupid thing like a username.
--
Regards
Manuel Schneider
Wikimedia CH - Verein zur Förderung Freien Wissens
Wikimedia CH - Association for the advancement of free knowledge
www.wikimedia.ch