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
This pops up every so often at www.mediawiki.org, particularly in relation
to the public domain help pages that we are trying to compile.
What is the correct license for screenshots of MediaWiki? Are we able to
distribute them along with the PD help pages (when we get to that stage)?
Currently they are variously tagged as GFDL, PD, (c) WMF and possibly
others.
Are there any considerations that may cause some screenshots to be under one
license and some under another? E.g. if the screenshot includes the MW logo
or certain interface text does it affect how it can be licensed? What about
the different skins?
It would be good to have this question answered officially, once and for
all.
- Mark Clements (HappyDog)
I was trying to parse the Wikipedia dumps but unfortunately I find the XML
file that can be downloaded a little hard to parse. I was wondering if there
is a neat way to extract:
1. The article title
2. The article content ( without links to articles
in other languages, external links and so on )
3. The category.
Also I find that there are a large number of tools that allow one to convert
plain text to media wiki text. What if I want to go the other way and
extract information exactly the way it appears on the wikipedia site.
Harish
An automated run of parserTests.php showed the following failures:
This is MediaWiki version 1.10alpha (r19199).
Reading tests from "maintenance/parserTests.txt"...
Reading tests from "extensions/Cite/citeParserTests.txt"...
Reading tests from "extensions/Poem/poemParserTests.txt"...
19 still FAILING test(s) :(
* TODO: Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html)
* TODO: Link containing double-single-quotes '' (bug 4598)
* TODO: message transform: <noinclude> in transcluded template (bug 4926)
* TODO: message transform: <onlyinclude> in transcluded template (bug 4926)
* BUG 1887, part 2: A <math> with a thumbnail- math enabled
* TODO: HTML bullet list, unclosed tags (bug 5497)
* TODO: HTML ordered list, unclosed tags (bug 5497)
* TODO: HTML nested bullet list, open tags (bug 5497)
* TODO: HTML nested ordered list, open tags (bug 5497)
* TODO: Parsing optional HTML elements (Bug 6171)
* TODO: Inline HTML vs wiki block nesting
* TODO: Mixing markup for italics and bold
* TODO: 5 quotes, code coverage +1 line
* TODO: dt/dd/dl test
* TODO: Images with the "|" character in the comment
* TODO: Parents of subpages, two levels up, without trailing slash or name.
* TODO: Parents of subpages, two levels up, with lots of extra trailing slashes.
* TODO: Don't fall for the self-closing div
* TODO: Always escape literal '>' in output, not just after '<'
Passed 484 of 503 tests (96.22%)... FAILED!
Note: The following topic is not about namespace names and not about names of
special pages.
Vanilla Mediawiki UI strings contain hardcoded localised link targets. For
example have a look at MediaWiki:Blockedtext (if you want to get all (?)
affected messages grep for {{ns:project}} in the sources). Well again in
monolingual wikis no problem. These linked pages are supposed to exist but
now consider a multilingual wiki...
For example "Project:Administrateur" is linked in MediaWiki:Blockedtext/fr
from vanilla Mediawiki. Imagine using someone French in a wiki with a
non-french default language which is commonly the case in multilingual wikis
such as Wikimedia Commons (note: French is just an example this holds for
every of the zillions of languages supported by Mediawiki). So UI messages
were created with monolingual wikis in mind and never considering simultanous
usage of different languages.
So in vanilla Mediawiki please do not hardcode any wiki page in message
strings.
Well how to localise embedded link targets in the future?
Use a mechanism that points to mediawiki namespace pages that define these
link targets (like the mediawiki namespace pages defined by
MediaWiki:Sidebar). A possible syntax could be done with
{{subst:Mediawiki:PAGENAME}} templates (however this syntax has some problems
as this would need to expand to a given sub page and would need to check if
that sub page exists and fall back to default if not). Another possible
syntax could be the use of named variables such as $MediaWiki:PAGENAME in
interface strings.
Arnomane
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)