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
-----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-----
is there some variable to be able to input raw php into the edit box??
for example,
I have the raw html variable enabled...
and <html></html> seem to work fine
I have tried..
<html><?php echo "hello"; ?></html>
but does not seem to do the trick...
Any ideas?
thank you
A few months ago the ability was added to limit IP blocks to allow
logged-in contributions to continue. This allowed finer-grained blocking
of troublemakers on shared IPs (schools, AOL etc).
There's some suggestion to make this the default mode. I wanted to
announce this ahead of time since it will change what happens when
admins make a block without manually clicking something extra.
If there's no serious objection, we'll go ahead and change this in a few
days.
-- brion vibber (brion @ pobox.com)
I'm user:Graham87 on the english wikipedia. I use a screen reader called JAWS from Freedom Scientific at:
www.freedomscientific.com
It is the most popular Windows screen reader at the moment.
My problem is that it appears that the edit link has become part of the title of each section created with wiki markup. This problem
is compounded when using quick navigation keys to navigate between sections; in this case, JAWS will stop reading a heading title
when it encounters a link. Therefore, each heading title will be read as either "left bracket" or "edit" when I navigate between
editable sections on a MediaWiki page. I tested this with JAWS 5.1 and 6.0, which aren't the most recent versions but are still
widely used and the problem appears on both of them. I am using Windows XP with IE 6 (Firefox only works well with the latest
versions of JAWS). The headings were working fine late last night my time (about 15:30 UTC on 21 October).
I would like this fixed as soon as possible so only the section title is spoken when navigating through headings.
Thanks,
Graham
Pretty soon, likely within the next week, I'll be moving all
accesskeys and tooltips out of Monobook.js and implement them
server-side. This may affect personal scripts that implement custom
accesskeys; they'll have to be revised a bit to find the elements
themselves rather than relying on their presence in the "ta" array,
but it shouldn't be difficult. Sites that have modified Monobook.js
should not have their global changes affected by this directly,
although they may have to rework them when the id's are changed.
The tooltip for any given element that has a tooltip will be stored in
a message "tooltip-x", where x is the element's HTML id, and can be
modified as usual by sysops. The accesskey, likewise, will be stored
in a message "accesskey-x".
For developers: currently this is in a branch, branches/simetrical/.
Help converting over the language files would be greatly appreciated
(via commits or, for non-devs, patches), but I'll do it myself if
necessary. I'll make this concurrent with reworking the id's/classes,
just for simplicity.
Hi,
We've had some complaints off and on about diffs taking a long time.
This happens at random times, doesn't happen often and clears itself
up after awhile. When this happens, the load on the Apache servers
seem low and the database seems ok.
We did seem to have this problem if users had the Google toolbar
installed a few months ago, but it appears that the problem is back
and unrelated.
I wonder if the job queue has anything to do with it, sometimes it
get's up to over 10,000 on us, but usually is at 0. I haven't been
able to check what it's at when users experience this problem.
Does anyone have any ideas on how to debug, or what the possible
causes might be? We're still running 1.6.7.
Thanks,
Travis
Virgil Ierubino wrote:
> I would really like to see a function like this developed into MediaWiki,
> either an an extension or into a new version. Put simply, one should be able
> to perform searches, limiting the field of search to articles in a given
> category. The reasons why this would be useful are probably obvious. If not
> - the simplest one is just that categories split articles into topics - and
> this would allow a user to search in a given topic.
>
> I see two ways of enacting this, and I think both should be looked into.
> Firstly, an "advanced search" option, which I think is not as favourable.
> Secondly, and this is what I think would really be good, a search box
> automatically appears on a category page.
>
> Alternatively, when one is viewing a category page, the normal search box
> (on the left) acquires a check box - "search in this category".
>
> Additionally, a further checkbox could be interesting: "also search
> subcategories".
>
> I can't imagine this would be too difficult to implement, but would
> certainly be very useful and would make more use of the categorisation
> system in MediaWiki.
Category search could be implemented fairly easily using Lucene fields. But
I think the results would be counterintuitive unless subcategories were
included by default, and that's rather more difficult to implement. A
top-level category in Wikipedia does not contain a collection of articles on
that topic, it contains a list of subcategories and a few miscellaneous
articles.
To implement subcategory search, MW could recursively load parent categories
on page save, and put them in a "parent category" lucene field. Circular
reference detection and resource limits would have to be in place.
-- Tim Starling
