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-----
Hi,
I tried to find some info about storing Java applets on the Wikimedia
servers, and was not very successful. Maybe somebody here can help me out.
From what I understand, applet/jar files are not welcome on the
servers, because there is no valid/convincing use case. However,
thinking about an interactive "lab session" for Wikiversity, and seems
to me a Java applet would be the best fit for what one would look for.
Actually, there are some GPL sourced applets for physics demos out
there, that show the possible usefulness of those for Wikiversity, eg.
look at
http://galileoandeinstein.phys.virginia.edu/more_stuff/Applets/ProjectileMo….
Anybody want to chime in on this? Maybe there is a better way to
implement an interactive page like that, and I just have not found it, yet.
Andreas =:-)
Hello,
At en wikipedia, I clicked edit on Talk:British Isles (terminology)
and received this message:
--
User is blocked
Your user name or IP address has been blocked from editing.
You were blocked by Pathoschild for the following reason (see our
blocking policy):
Autoblocked because your IP address has been recently used by
"Ilikesheeeeeeeeeeep". The reason given for Ilikesheeeeeeeeeeep's
block is: "Violation of the Username policy (too long, confusing,
Your IP address is 72.14.192.5.
...etc.
--
This was obviously some kind of database fart because it disappeared
when I tried again, and because that IP address isn't close to mine :)
Anyway, just thought I'd mention it.
Steve
Hi Julien,
One more patch for the suggestion searching, this time to add experimental "autocomplete" searching.
It works like this:
* If there is only one matching result, then the rest of the search term is automatically filed in.
* If the top two searches agree on the next X letters, then the next X letters are automatically filled in.
In both cases, any automatically filled in text is kept highlighted / selected. This way, the user can either:
* Press the right arrow key if the autocomplete is correct (thus accepting the autocomplete).
* Or keep typing normally, thus overwriting the highlighted autocomplete.
In other words, you shouldn't in theory lose anything from the autocomplete, but you may well gain (in that we can be lazier because
of it). For example, you can specify the word "australia", and instead of the usual 9 key presses, you can do it with 4 ("au", right
arrow, "a"); "Los Angeles Aqueduct" instead of the usual 20 key presses is just 9 ("los a" + right arrow + " aq"); and so forth.
Patch (against 0.2) is here: http://files.nickj.org/MediaWiki/WSuggest-js-autocomplete-diff.txt
Currently there are two known problems with the autocomplete functionality (hence the 'experimental' status):
* The main one is if the user types fast, the highlighting/selection will stuff up. For example, if you type "new" quickly, then it
autocompletes to "new York" (which is fine), but the " York" bit is not highlighted (which is definitely not fine). I'm currently
not sure why this happens (maybe a race condition between the sequential query requests?) - but if anyone knows how to prevent this,
please sing out and/or send patches!
* Gets redirects wrong (fills in too much detail). For example if the user types "formula we" it will autocomplete to "Formula
Weight → Atomic mass", which simply won't work. It's possible to have the JavaScript search for " → " and stop any string
at that point, but it feels a bit ugly, so I have omitted that. Might it be slightly neater to have sendRes return 5 fields instead
of 4? E.g. "sendRes(query, res, freqs, urls, redirectTargets)", where the new "redirectTargets" field would be an array that
contained a NULL/empty entry when there was no redirect, or the redirect target when it was a redirect? That way 'res' could contain
just the article's name, and the redirect target functionality could be kept in a logically separate field.
All the best,
Nick.
I have taken a look at render.ml and have written a patch that will
enable the use of the PNG-rendering program dvipng. This would reduce
load on the server, and also enable full-alpha transparency (but I
havent included that yet, IE has problems with full-alpha PNGs).
There is already a patch somewhere, but in this attempt I have tried to
make sure that the old dvips->convert renderer is used in the case
dvipng fails (or indeed, is not present on the system). Unfortunately I
do not have a server to test it on. Does anyone want to try it?
The patch is small, so I suppose there is no real harm in including it here.
/Jan-Åke
Index: render.ml
===================================================================
--- render.ml (revision 16007)
+++ render.ml (working copy)
@@ -2,6 +2,10 @@
let cmd_latex tmpprefix = "latex " ^ tmpprefix ^ ".tex >/dev/null"
(* Putting -transparent white in converts arguments will sort-of give you transperancy *)
let cmd_convert tmpprefix finalpath = "convert -quality 100 -density 120 " ^ tmpprefix ^ ".ps " ^ finalpath ^ " >/dev/null 2>/dev/null"
+(* Putting -bg Transparent in dvipng's arguments will give full-alpha transparency *)
+(* Note that IE have problems with such PNGs and need an additional javascript snippet *)
+(* Putting -bg transparent in dvipng's arguments will give binary transparency *)
+let cmd_dvipng tmpprefix finalpath = "dvipng -gamma 1.5 -D 120 -T tight --strict " ^ tmpprefix ^ ".dvi -o " ^ finalpath ^ " >/dev/null 2>/dev/null"
exception ExternalCommandFailure of string
@@ -25,9 +29,11 @@
close_out f;
if Util.run_in_other_directory tmppath (cmd_latex tmpprefix0) != 0
then (unlink_all (); raise (ExternalCommandFailure "latex"))
- else if (Sys.command (cmd_dvips tmpprefix) != 0)
+ else if (Sys.command (cmd_dvipng tmpprefix (finalpath^"/"^md5^".png")) != 0)
+ then (if (Sys.command (cmd_dvips tmpprefix) != 0)
then (unlink_all (); raise (ExternalCommandFailure "dvips"))
else if (Sys.command (cmd_convert tmpprefix (finalpath^"/"^md5^".png")) != 0)
then (unlink_all (); raise (ExternalCommandFailure "convert"))
+ else unlink_all ())
else unlink_all ()
end
Hi All,
I am wondering how difficult it would be to use wiki with Sybase ASE. Has
anyone attempted this with any amount of success? I'm willing to work on
this with others who may be interested. I've downloaded mediawiki 1.6.8 (due
to PHP4) and just starting to look around.
Thanks,
Mark
Most developers have specialisations -- some of us hate UI design and love
DB performance optimisation, others don't know any PHP but can speak
HTML/CSS like a second language. This is a problem for writing features for
an open source web app -- the nature of the work is cross-disciplinary, but
the culture encourages individual effort. The result of this is that
developers are placed under pressure to learn a huge skill set, and that can
be a disincentive to participation.
I have an idea for a feature, and I was wondering if anyone might want to
collaborate on it. The idea is to display, in a box in the edit window,
information about who else has the same edit window open. For example, it
could display each username, along with the amount of time they have been
idle and the edit summary they have typed if any. The box will periodically
refresh itself, say once every 10 seconds. At the same time as fetching
updated data, the client sends back information about how long the user has
been idle and so on.
An optional subfeature would be allow the user to remove themselves from the
box voluntarily, e.g. to signal that they have no interest in actually
saving the article and that they are just looking at the source.
There are three different skill sets which are required to make this feature:
Person 1: User interface design
Person 2: Client-side programming
Person 3: Server-side programming
The tasks can be roughly divided as follows:
Person 1: Make a mockup of the user interface by taking the HTML of an edit
page from MediaWiki and adding a box with the required information. Edit the
HTML and the CSS. PHP or JavaScript knowledge is not required, although some
JS knowledge may be desirable to allow them to demonstrate any necessary
show/hide buttons and popups.
Person 2: Write the JavaScript. Monitor the edit window and send the
information I have described to the server. To update the info box, write a
model server response with a text editor, save it as a static file. Have the
JS load the model response and update the box in response. Deliver a
request/response format specification.
Person 3: Write the PHP. Implement the AJAX handler using the specification
from Person 2. Implement an internationalised user interface based on the
mockup delivered by Person 1.
I can probably be Person 3, but I don't think I can handle the other two
tasks as well. Any volunteers? Anyone know anyone who might be interested?
-- Tim Starling
