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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
MediaWiki 1.6.4 is a maintenance bug fix release, which rolls up some fixes to
additional minor problems and localization updates to the Spring 2006 quarterly
snapshot.
* Further improvements to Hebrew localisation
* (bug 5544) Fix redirect arrow in Special:Listredirects for right-to-left
languages
* Replace "doubleredirectsarrow" with a content language check that picks
the appropriate arrow
* Remove live debugging hack which caused errors with certain database names
* (bug 5510) Warning produced when using {{SUBPAGENAME}} in some namespaces
* (bug 5548) Improvements to Indonesian localisation [patch: Ivan Lanin]
* (bug 5403) Fix Special:Newpages RSS/Atom feeds
* (bug 3359) Add hooks on completion of file upload
* (bug 5184) CSS misapplied to elements in Special:Allmessages due to
conflicting anchor identifiers
* (bug 5519) Allow sidebar cache to be disabled; disable it by default.
* Add $wgReservedUsernames configuration directive to block account creation/use
* (bug 5576) Remove debugging hack in session check
* (bug 5181) Update "nogomatch" for Slovak
* (bug 5594) Id translation up to '# Login and logout pages' section
* (bug 5536) Use content language for editing help link
* Minor improvements to English language files
* Improvements to German localisation files
* (bug 5628) Translations for MessagesHr.php
* (bug 5595, 5644) Localisation for Bosnian language (bs)
* (bug 5592) Actions are logged with the default language for the
wiki, not the language of the user performing the operation.
* (bug 5646) Compare for identical types in wfElement()
* Fix for concurrency problem in job queue (image description page invalidation)
* (bug 5497) regeression in HTML normalization in 1.6 (unclosed <li>,<dd>,<dt>)
* (bug 5709) Allow customisation of separator for categories
* (bug 4834) Fix XHTML output when using $wgMaxTocLevel
* Improvements to update scripts; print out the version, check for superuser
credentials before attempting a connection, and produce a friendlier error if
the connection fails
* (bug 5005): Fix XHTML <gallery> output.
* (bug 5315) "Expires: -1" HTTP header made strictly valid (using 1970 date).
* (bug 4825): note in DefaultSettings.php about 'profiling' table creation
* Remove unneeded extra whitespace at top of Special:Categories
* Rewrite reassignEdits script to be more efficient; support optional updates to
recent changes table; add reporting and silent modes
* Updated initStats maintenance script
* (bug 5723) Don't count pages linked to from the MediaWiki namespace as "wanted"
* (bug 5789) Treat "loginreqpagetext" as wikitext
* (bug 5796) We require MySQL >=4.0.14
Full release notes:
http://svn.wikimedia.org/viewvc/mediawiki/tags/REL1_6_4/phase3/RELEASE-NOTEShttp://svn.wikimedia.org/viewvc/mediawiki/tags/REL1_6_4/phase3/HISTORY
Download:
http://prdownloads.sourceforge.net/wikipedia/mediawiki-1.6.4.tar.gz
MD5 checksum:
3afc13074e29db9083fb73435e5e7371 mediawiki-1.6.4.tar.gz
Before asking for help, try the FAQ:
http://www.mediawiki.org/wiki/FAQ
Low-traffic release announcements mailing list:
(Please subscribe to receive announcements of security updates.)
http://mail.wikimedia.org/mailman/listinfo/mediawiki-announce
Wiki admin help mailing list:
http://mail.wikimedia.org/mailman/listinfo/mediawiki-l
Bug report system:
http://bugzilla.wikimedia.org/
Play "stump the developers" live on IRC:
#mediawiki on irc.freenode.net
- -- brion vibber (brion @ pobox.com)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEV8sJwRnhpk1wk44RAkmoAKC6egTg4YhnXbPSn9BhbjiSC3a8OgCgsL1T
SwVYtN4ftr3BBgBUsQWlgXw=
=HNzm
-----END PGP SIGNATURE-----
Hi, we have a strange behaviour on the nap wikipedia. Strange enough the
categories don't work well - the first one works - the others not ... hmmm
http://nap.wikipedia.org/wiki/Acerno
The categories are inserted like this:
[[category:giugrafia]]
[[category:Comune d<nowiki>''</nowiki>a Campania]]
[[category:Comune d<nowiki>''</nowiki>a pruvincia 'e Salierno]]
now we tried the following:
changed the category to Categoria, Category, categoria
took out the nowiki-tag
The only thing that works is take out the '' + the nowiki tag - so we
get a category, but the resulting spelling is then plain wrong. It
worked well up to the last version of the Mediawiki software ... so
something must have been changed there.
One thing I just tried out: also wiki-links do not work anymore - this
means we cannot create correct pages anymore since <nowiki> does not
seem to be allowed within a wiki link. This means problems with
nap.wikipedia, but not only: also wiktionary will have (maybe already
has) problems with this (we have approx. 3000 Neapolitan words (if I am
right) in the Italian wiktionary - some of these probably use the '')
Could someone please look into this?
Thank you!
Best, Sabine
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
I've searched the archives for the past several months, and cannot find
the status of this project, other than a busy fellow saying that it was
the top priority in February. Anybody know?
Several of us on the English Wiktionary are trying to resolve an issue
and we could use some advice.
(This is my frist post to this list, so apologies if I restate the
obvious.)
What's the best way to rig it up so that when you interlink to [[Foo]]
on a caseful Wiki project, where "Foo" does not exist but "foo" does,
to give the user a convenient shortcut to [[foo]]?
Background: unlike most Mediawiki projects, the English Wiktionary
honors case in the first character of article titles . (That is, I
assume it has $wgCapitalLinks set to false.) This can cause problems
with links to Wiktionary from other Mediawiki projects, and from the
outside world (such as Wiktionary mirrors), since those incoming links
are often to the capitalized version of a word, on the assumption that
Wiktionary works like Wikipedia. (As, in fact, it once did.)
Even since it switched over to casefulness, Wiktionary has evidently
been trying to "solve" this problem by having an explicit, capitalized
redirect in place for every lower-case entry. But that's clearly a huge
nuisance and waste of time.
Instead, some of us have been thinking it Would Be Nice if we could
adjust the behavior on a missing page ("broken link") slightly. Instead
of saying "Wiktionary does not have an entry for this word yet", in the
case where Wiktionary does have an alternate-case version of the word,
perhaps it should display an explicit "Did you mean?" link right up
front (along with but ahead of the other search and create options).
There are probably several ways of approaching this. I've already
implemented one way, but I'm curious as to this list's opinion of the
most appropriate approach.
1. I added some code (in a test wiki) to getContent() in Article.php
to optionally display "Did you mean ___?" before displaying
'noarticletext', in the case where an alternate-case version does
exist. In some ways this is the right approach, but it's awkward,
because it has to prepend its text to the 'noarticletext'
boilerplate. Someone editing MediaWiki:noarticletext would
reasonably expect to see the "Did you mean?" text there,
and might want to integrate it with the rest of the boilerplate,
but wouldn't be able to.
2. It might also be possible to implement the test and optional text
right there in 'noarticletext', using the new in-line conditional
expressions. (But I'm not sure they're quite powerful enough.)
3. Arguably, this is a problem that doesn't need solving, and the
typical, already-existing "You can search for this article in
Wiktionary" link should suffice.
4. Arguably, this is a problem that does need solving, but in an even
more general case, whenever there are other kinds of near matches,
that aren't appropriate to handle with redirects or with the
automatic case mapping that happens when $wgCapitalLinks is on.
(Someone might ask, "Why provide an interactive question and a link;
why not just quietly redirect?" But that defeats the purpose of being
caseful and makes it difficult or impossible to create a second entry
with the other case. If you're going to redirect in this case, you
might as well turn on $wgCapitalLinks and be done with it.)
Another way of thinking of this is that the proposed "Did you mean?"
question is a little like a disambiguation page, in a case where user
confirmation is required (i.e. in cases where a more implicit Wiki
redirect or 302 redirect is not appropriate).
For all I know this issue has been discussed already and some consensus
reached. But does anyone have any advice or suggestions? Thanks.
Hi all,
Others must have noticed this - is this a recognised issue?
Basically: Given some article whose title is in title case (eg, Lyon
Metro), you can type the lower case version in the go/search box, and
still get there. However, if you link to [[lyon metro]] in an article,
it will show up as a red link.
This has the effect that it's actually difficult to create the article
*other* than going through the redlink - if you try and type in the
name, you get silently redirected.
Would it be wrong to be redirected towards the other cased version
instead of having a redlink?
Steve
Hi,
An increasing number of wiki pages use the
{{Mapit-AUS-suburbscale|long=151.21459|lat=-33.87531}}
Type notation to indicate the page relates to a specific location.
Where would I go to request that this information is also embedded into a
meta tag for the page e.g.
<meta name="ICBM" content="-33.87531,151.21459" />
So capable browsers/search engines can use this information more
semantically ?
Cheers,
Neil
Hi,
I have a small patch (2k lines) at http://p.defau.lt/?
Jnc0Y1AY0hc0SNOhmFtzSw
that eliminates most of require_once() calls and uses require() in
__autoload() handler.
Generally it makes things faster, as less require_once means less stat
(), as well as that might be more APC-friendly.
As well as some refactoring was needed, I could introduce lots of bugs.
And break extensions of course.
As included source is executed at function scope, rather than file
scope, various other issues could arise - like missing global
declarations, etc.
So, please send your comments ;-)
Domas