An automated run of parserTests.php showed the following failures:
This is MediaWiki version 1.9alpha (r18949).
Reading tests from "/home/brion/src/wiki/phase3/maintenance/parserTests.txt"...
Running test TODO: Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html)... FAILED!
Running test TODO: Link containing double-single-quotes '' (bug 4598)... FAILED!
Running test TODO: message transform: <noinclude> in transcluded template (bug 4926)... FAILED!
Running test TODO: message transform: <onlyinclude> in transcluded template (bug 4926)... FAILED!
Running test BUG 1887, part 2: A <math> with a thumbnail- math enabled... FAILED!
Running test Basic section headings... FAILED!
Running test Section headings with TOC... FAILED!
Running test Handling of sections up to level 6 and beyond... FAILED!
Running test Resolving duplicate section names... FAILED!
Running test Template with sections, __NOTOC__... FAILED!
Running test __NOEDITSECTION__ keyword... FAILED!
Running test Link inside a section heading... FAILED!
Running test TODO: HTML bullet list, unclosed tags (bug 5497)... FAILED!
Running test TODO: HTML ordered list, unclosed tags (bug 5497)... FAILED!
Running test TODO: HTML nested bullet list, open tags (bug 5497)... FAILED!
Running test TODO: HTML nested ordered list, open tags (bug 5497)... FAILED!
Running test Fuzz testing: Parser14... FAILED!
Running test Fuzz testing: Parser14-table... FAILED!
Running test TODO: Parsing optional HTML elements (Bug 6171)... FAILED!
Running test TODO: Inline HTML vs wiki block nesting... FAILED!
Running test TODO: Mixing markup for italics and bold... FAILED!
Running test TODO: 5 quotes, code coverage +1 line... FAILED!
Running test TODO: dt/dd/dl test... FAILED!
Running test TODO: Images with the "|" character in the comment... FAILED!
Running test TODO: Parents of subpages, two levels up, without trailing slash or name.... FAILED!
Running test TODO: Parents of subpages, two levels up, with lots of extra trailing slashes.... FAILED!
Running test TODO: Don't fall for the self-closing div... FAILED!
Running test TODO: Always escape literal '>' in output, not just after '<'... FAILED!
Running test Inclusion of !userCanEdit() content... FAILED!
Running test Out-of-order TOC heading levels... FAILED!
Running test -{}- tags within headlines (within html for parserConvert())... FAILED!
Reading tests from "/home/brion/src/wiki/phase3/extensions/Cite/citeParserTests.txt"...
Reading tests from "/home/brion/src/wiki/phase3/extensions/Poem/poemParserTests.txt"...
8 previously failing test(s) now PASSING! :)
* Thumbnail image caption with a free URL
* BUG 1887: A ISBN with a thumbnail
* BUG 1887: A RFC with a thumbnail
* BUG 1887: A mailto link with a thumbnail
* BUG 1887: A <math> with a thumbnail- we don't render math in the parsertests by default,
so math is not stripped and turns up as escaped <math> tags.
* Image caption containing another image
* Bug 3090: External links other than http: in image captions
* Fuzz testing: image with bogus manual thumbnail
3 new PASSING test(s) :)
* Transclusion of default MediaWiki message
* Transclusion of nonexistent MediaWiki message
* Raw output of variant escape tags (R flag)
12 previously passing test(s) now FAILING! :(
* Basic section headings
* Section headings with TOC
* Handling of sections up to level 6 and beyond
* Resolving duplicate section names
* Template with sections, __NOTOC__
* __NOEDITSECTION__ keyword
* Link inside a section heading
* Fuzz testing: Parser14
* Fuzz testing: Parser14-table
* Inclusion of !userCanEdit() content
* Out-of-order TOC heading levels
* -{}- tags within headlines (within html for parserConvert())
Passed 470 of 501 tests (93.81%)... FAILED!
At 17:49 +0000 7/1/07, Virgil Ierubino wrote:
>To follow up some of the replies:
>
>I'm not suggesting WYSIWYG. I don't like Wysiwyg personnally, I think it
>makes content editing more difficult and less clear.
>
>My point in its simplest form was that there ARE ways of doing VERY funky
>stuff. And I don't mean flashing animations, I mean stuff that actually
>makes MediaWiki run better, be easier to use, attract more users, etc.
>
>Compatibility isn't that much of an issue because:
>* The features can be opt-in via user preferences (could even be as simple
>as selecting one of 3 modes, or something)
>* This kind of funky stuff IS actually very stable, and can even detect the
>browser it's being viewed in and turn itself off.
>* Most people CAN run it without problems.
>
>For the Somalians without Dell Dimensions, (interesting example!) there's
>always the normal Wikipedia (before turning on these options), CDs, DVDs and
>Print Encyclopedias.
Well, I am user in the UK and I have mobile phone. I often edit
Mediawiki based wikis on the phone. Just basic stuff.
>If lack of developers and money is the only problem then why not be more
>WIKI about it?
Money pays for servers. Developers work for nothing.
>Call to the Wikimedian community for volunteer coders to help
>improve MediaWiki. Of course this is a lot more complex than I make it
>sound, but the point is that somewhere out there will be a professional AJAX
>coder willing to code free for Wikimedia. I know that if I knew the
>language, I'd do it.
AJAX? Are you serious? Most of these interfaces are way beyond what
Wikipedia calls for.
I have had one request from a wiki I run for a local history group -
a spell checker. Everything else they like (the group had TWiki
experience from another project).
Anyway, like somebody else, feel free to contribute...
--
Gordo (an amateur)
http://www.loopzilla.org/
On 07/01/07, Gordon Joly <gordon.joly(a)pobox.com> wrote:
> >My point in its simplest form was that there ARE ways of doing VERY funky
> >stuff. And I don't mean flashing animations, I mean stuff that actually
> >makes MediaWiki run better, be easier to use, attract more users, etc.
Nobody is adverse to implementing any AJAX in MediaWiki where it will
be genuinely useful. As an example, Simetrical recently committed some
code adapted from a patch which makes it possible to watch/unwatch
pages using AJAX. It's very neat, works superbly and is a nice little
time-saver. Pending some minor tweaking, it will probably make it
live.
> >Compatibility isn't that much of an issue because:
Compatibility is always an issue. Absolutely always.
> >If lack of developers and money is the only problem then why not be more
> >WIKI about it?
It's not a lack of developers or a lack of cash, although more of both
is always better.
> Money pays for servers. Developers work for nothing.
We have two paid developers.
> >Call to the Wikimedian community for volunteer coders to help
> >improve MediaWiki. Of course this is a lot more complex than I make it
> >sound, but the point is that somewhere out there will be a professional AJAX
> >coder willing to code free for Wikimedia. I know that if I knew the
> >language, I'd do it.
There is an established process for improving MediaWiki. We also have
most of the AJAX framework in place.
Rob Church
The current localisation system has a number of undesirable properties:
* Start from a cold cache is extremely slow, taking from 20 seconds to
several minutes.
* The database is preloaded with hundreds of default messages, causing:
* Slow installation, to the point where web installation is entirely
impossible on some resource-limited shared web hosts without commenting
out the message cache section
* Excessive disk usage and slow backups on sites with large numbers of
near-empty wikis
* The message cache can exceed the 1MB limit of MemCached, causing total
failure
* The performance of the message cache degrades when some of the keys are
large
I spent a fair bit of time pondering how to fix this, but I think it was
Rotem who finally suggested the obvious solution: don't have pages for
default messages.
The only reason for preloading the MediaWiki namespace was to provide
admnis with model text upon which they could base their translations. This
justification has long since disappeared, since action=edit, action=view
and Special:Allmessages are now all capable of drawing default message
text from the message files if the articles do not exist.
So here's what I've done in my working copy, soon to be committed:
* Removed InitialiseMessages.inc and rebuildMessages.php
* During upgrade, delete all pages in the MediaWiki namespace which were
last modified by "MediaWiki default".
* Reoptimised the message cache for the sparse MediaWiki namespace.
The main message cache (i.e. the $wgDBname:messages key) will now be a
faithful representation of the contents of the MediaWiki namespace,
instead of (as it previously was) a representation of the contents of all
messages. If a page does not exist, it will not have a message cache key.
To solve the performance problems of having a small number of large items,
any page which is larger than some threshold (10KB by default) will only
have a placeholder stored in the main message cache, instead of the
complete page text. The full contents of these items are stored separately
in the cache.
-- Tim Starling
Hi Everyone,
I would like to request for some usage and participation statistics from
Wikipedia. I am a student from Singapore working on my thesis on online
knowledge sharing and contribution with a particular focus on Singapore.
Wikipedia is a shining example of online knowledge sharing and
collaboration. I would like to know the amount of traffic to Wikipedia from
Singapore (can be filtered by IP), and what is the percentage of lurkers vs
contributors. If possible, I would like such statistics for a few more
notable countries for comparison.
I have obtained some statistics (http://www.nedworks.org/~mark/reqstats/)
from an administrator, but i don't understand the notations and i think it's
only general statistics, not sorted by physical location.
My purpose is to back my hypothesis that users from Singapore and generally
Asia, contribute less by metrics of the ration of lurkers against
contributors/wikipedians. My thesis aims to analyse such a situation and
suggest recommendations.
I hope this request is not too much of a hassle. I am a honours student in
Communications and Media from the National Unviersity of Singapore (
www.nus.edu.sg). I can also be contacted at junde(a)nus.edu.sg
Thank You & Regards,
Yu Junde
--Xaosflux wrote:
> Seems like {{delete|I created this page by mistake}} would suffice
> there?
... We're not in the business of providing individual examples and
counter-examples. Suffice to say there is no good reason *not* to support
signatures in templates - and people do use signatures in templates - so we
should support it.
Andrew Garrett
(Werdna)
Can MediaWiki use a - instead of | in the default signature? The bar
breaks templates (like http://en.wikipedia.org/wiki/Template:mirror)
when people sign inside.
Matthew Flaschen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Virgil Ierubino wrote:
> Why is MediaWiki so low-tech? [snip]
I'm sure this kind of response will spark righteous indignation on the
part of every developer who has a clue on what's going on underneath
MediaWiki's hood. Plus, lack of AJAX does not mean "low-tech", which you
have so insinuated.
Furthermore, you've mixed up AJAX (which, while slow in coming, is being
implemented when appropriate) and inline-WYSIWYG editing (which poses
immense technical challenges due to the legacy baggage of our wikitext
format). If you want to see "state-of-the-art" MediaWiki work, please
check out: http://wikiwyg.net/
<http://demo.wikiwyg.net/wikiwyg/demo/standalone/>
Finally, the trouble of maintaining accessibility is probably the last
of our concerns. We don't /have/ the more advanced features implemented
in a stable manner yet, this is *open source*
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFn997qTO+fYacSNoRAlRqAJ9DMQSI7XfCgp+wEI83Ix46GYAA9ACeN+9i
8Mn0nxqYyzZkp4PL8fXZ4lE=
=UKcI
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Note that this was crossposted to wikimedia.foundation.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFn+AoqTO+fYacSNoRAiJ1AJ9P8bmOI2fzYF+i28DK4zOSUs5lgQCfStp1
56X27cHfGv6gyixbPIS8FXA=
=Ue+b
-----END PGP SIGNATURE-----