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
Ref: <http://bugzilla.wikimedia.org/show_bug.cgi?id=1629>,
<http://de.wikipedia.org/wiki/Wikipedia:WikiProjekt_Usability/Test_Februar_2…>
>From the latter, we have
"Two users who started their first-time editing with a paragraph
instead of the whole page were not confused by the syntax. However,
they were faced with another problem: The location of the "Edit" links
seemed to relate them with the paragraph above, not the one below.
Therefore, when clicking the "Edit" link below "Geschichte", they
expected to see the heading "Geschichte" and its contents. . . .
"This expectation was not met, instead "Weblinks" appeared in the
editor window. They were confused, did not know what to do. Finally,
both participants deleted (!) the existing and valid text, and started
to add their own text."
We've known for well over a year now that this is a problem. I would
like to finally fix it. Specifically, I intend to remove the
editsection float style, so it's at the beginning of the section line,
to the left. The alternative is to have it as the German Wikipedia
does, with the section edit link on the right of the header; however,
this a) is kind of annoying as the link jumps around, and b) requires
a change to the document structure (admittedly just a reordering of
elements, but it may well break some fragile stuff regardless). It
does arguably look better, though, and that could be done instead
(opinions?). A comparison of the three styles is available at
<http://www.mediawiki.org/wiki/User:Simetrical/Edit_links_comparison>.
Before this goes into effect, it would be only courteous to inform
existing wikis about it and the reasons for doing it. I'll prepare a
little message and get someone with bots everywhere (Yurik?) to post
it on all the wikis' MediaWiki talk:Common.css pages, I think, before
I commit it, and so well before it goes live, along with instructions
on how to reverse it preemptively if desired.
Are there any objections to this?
On 31/08/2007, aaron(a)svn.wikimedia.org <aaron(a)svn.wikimedia.org> wrote:
> Revision: 25341
> Author: aaron
> Date: 2007-08-31 08:57:22 +0000 (Fri, 31 Aug 2007)
>
> Log Message:
> -----------
> *Call OutputPageBeforeHTML on preview (bug 7050)
The name of this hook implies that the OutputPage class should be
calling it, perhaps during the send() method, for all page views. If
that's not the case, then the hook ought to be deprecated in favour of
a more accurate name.
Rob Church
> Revision: 25083
> Author: raymond
> Date: 2007-08-23 10:52:51 +0000 (Thu, 23 Aug 2007)
>
> Log Message:
> -----------
> Fix for r25082. Access key for preferences changed to '9'.
> Access key ',' is already in use for the textarea of the edit form, but hard coded. Is there a special reason not to use the normal access key/tooltip mechanism?
> Thanks to WebBoy.
>
> Modified Paths:
> --------------
> trunk/phase3/languages/messages/MessagesEn.php
>
> Modified: trunk/phase3/languages/messages/MessagesEn.php
> ===================================================================
> --- trunk/phase3/languages/messages/MessagesEn.php 2007-08-23 09:34:33 UTC (rev 25082)
> +++ trunk/phase3/languages/messages/MessagesEn.php 2007-08-23 10:52:51 UTC (rev 25083)
> @@ -2241,7 +2241,7 @@
> 'accesskey-pt-anonuserpage' => '.', # don't translate or duplicate this message to other languages
> 'accesskey-pt-mytalk' => 'n', # don't translate or duplicate this message to other languages
> 'accesskey-pt-anontalk' => 'n', # don't translate or duplicate this message to other languages
> -'accesskey-pt-preferences' => ',', # don't translate or duplicate this message to other languages
> +'accesskey-pt-preferences' => '9', # don't translate or duplicate this message to other languages
> 'accesskey-pt-watchlist' => 'l', # don't translate or duplicate this message to other languages
> 'accesskey-pt-mycontris' => 'y', # don't translate or duplicate this message to other languages
> 'accesskey-pt-login' => 'o', # don't translate or duplicate this message to other languages
This breaks typing characters with Alt+numeric code, as you end up at
Special:Preferences. Please reassign a non-numeric character.
Follow-up: ',' was added on the previous revision (r25082), it didn't
have an accesskey before, which is bug 5206.
I would like to propose and gather support for incorporating a tool called
TiggerScript (see http://www.michaelpundit.com/tech/TiggerScript.htm) into
Wikipedia. TiggerScript is a Javascript app that allows the reader to instantly
toggle between table of contents and the current position in the article.
TiggerScript is incorporated into this article about it :) and into some other
articles on my website.
I believe that this user interface invention will significantly improve reading
comprehension of webpages, including in Wikipedia and other wikis run on
MediaWiki, and hence deserves widespread adoption to make the web a more
readable place. Incorporating TiggerScript into MediaWiki, as I explain in the
article, is very straightforward.
Please read the article, play around with TiggerScript, and tell me what you
think on the matter.
Best regards,
Michael
Hi List,
I develop extensions for MediaWiki at work. We are using IIS, PHP 5,
current MySQL, and MediaWiki version 1.8 (I believe). I have an
extension that is supposed to replace <accNumTag>SomeInfo</AccNumTag>
with a wiki table. It does this correctly, however, it seems to be
running through the extension on pages that do not contain the invoking
tag (accNumTag). This is severely slowing down the load of the edit
page.
I've added some print statements to figure out what is going on and it
seems that $input is getting a value even on pages that do not contain
<accNumTag>. I think if I understood how extensions are called better I
might be able to puzzle this out? Does anyone have any suggestions or
pointers to a good "how the parser hook works" page?
As far as I can see the code looks normal?
function wfAccChecker() {
global $wgParser;
$wgParser->setHook( "AccNumTag", "accChecker" );
}
function accChecker ($input, $argv) {
if (isset($input)&& !empty($input)) {
.
.
.
.
}
}
Thank you!
Courtney Christensen
On 8/30/07, brion(a)svn.wikimedia.org <brion(a)svn.wikimedia.org> wrote:
> Adds what seems to be a very purpose-specific extension into the core API:
It's not that purpose-specific.. the name in the code should perhaps
be changed. The purpose is to be able to declare a site as a remote
repository and have it work in the same way Commons does in the WMF
environment.
There were some issues with the code that Paa Kwesi committed, and
I've asked him to fix those.
> a) shortly before release
Perhaps it would be wiser to simply not include it in the release
branch if that is a problem?
> b) while apparently not implementing much of its interface
> c) with an interface that looks kind of strange to me
Could you be more specific here and make a list of things that you
think should be done before this can be in trunk?
--
Toward Peace, Love & Progress:
Erik
DISCLAIMER: This message does not represent an official position of
the Wikimedia Foundation or its Board of Trustees.
tstarling(a)svn.wikimedia.org schrieb:
> Revision: 25335
> Author: tstarling
> Date: 2007-08-31 02:51:23 +0000 (Fri, 31 Aug 2007)
>
...
> Elsewhere:
> * Made most images have a border=0 attribute, instead of just images on the image description page. Does not appear to adversely affect display at all, it was just convenient.
> Modified: trunk/phase3/includes/Linker.php
> ===================================================================
> --- trunk/phase3/includes/Linker.php 2007-08-31 02:30:14 UTC (rev 25334)
> +++ trunk/phase3/includes/Linker.php 2007-08-31 02:51:23 UTC (rev 25335)
> @@ -566,33 +566,13 @@
> - }
> - if ( isset( $fp['border'] ) ) {
> - $imgAttribs['class'] = "thumbborder";
> - }
It seems to me that this attribution is not added in another place, now
the image option [[Image:name.jpg|100px|border|text]] is broken :-(
Raymond.
An automated run of parserTests.php showed the following failures:
This is MediaWiki version 1.11alpha (r25338).
Reading tests from "maintenance/parserTests.txt"...
Reading tests from "extensions/Cite/citeParserTests.txt"...
Reading tests from "extensions/Poem/poemParserTests.txt"...
Reading tests from "extensions/LabeledSectionTransclusion/lstParserTests.txt"...
1 previously failing test(s) now PASSING! :)
* Fuzz testing: image with bogus manual thumbnail [Fixed between 30-Aug-2007 07:15:18, 1.11alpha (r25303) and 31-Aug-2007 07:15:36, 1.11alpha (r25338)]
1 previously passing test(s) now FAILING! :(
* <references> after <gallery> (bug 6164) [Introduced between 30-Aug-2007 07:15:18, 1.11alpha (r25303) and 31-Aug-2007 07:15:36, 1.11alpha (r25338)]
17 still FAILING test(s) :(
* URL-encoding in URL functions (single parameter) [Has never passed]
* URL-encoding in URL functions (multiple parameters) [Has never passed]
* Table security: embedded pipes (http://lists.wikimedia.org/mailman/htdig/wikitech-l/2006-April/022293.html) [Has never passed]
* Link containing double-single-quotes '' (bug 4598) [Has never passed]
* message transform: <noinclude> in transcluded template (bug 4926) [Has never passed]
* message transform: <onlyinclude> in transcluded template (bug 4926) [Has never passed]
* BUG 1887, part 2: A <math> with a thumbnail- math enabled [Has never passed]
* HTML bullet list, unclosed tags (bug 5497) [Has never passed]
* HTML ordered list, unclosed tags (bug 5497) [Has never passed]
* HTML nested bullet list, open tags (bug 5497) [Has never passed]
* HTML nested ordered list, open tags (bug 5497) [Has never passed]
* Inline HTML vs wiki block nesting [Has never passed]
* Mixing markup for italics and bold [Has never passed]
* dt/dd/dl test [Has never passed]
* Images with the "|" character in the comment [Has never passed]
* Parents of subpages, two levels up, without trailing slash or name. [Has never passed]
* Parents of subpages, two levels up, with lots of extra trailing slashes. [Has never passed]
Passed 526 of 544 tests (96.69%)... 18 tests failed!