An automated run of parserTests.php showed the following failures:
Running test BUG 361: URL within URL, not bracketed... FAILED!
Running test External links: invalid character... FAILED!
Running test Bug 2702: Mismatched <i> and <a> tags are invalid... FAILED!
Running test A table with no data.... FAILED!
Running test A table with nothing but a caption... FAILED!
Running test Link containing "#<" and "#>" % as a hex sequences... FAILED!
Running test Magic links: PMID incorrectly converts space to underscore... FAILED!
Running test Template with thumb image (wiht link in description)... FAILED!
Running test Link to image page... FAILED!
Running test BUG 1887: A ISBN with a thumbnail... FAILED!
Running test BUG 1887: A <math> with a thumbnail... FAILED!
Running test BUG 561: {{/Subpage}}... FAILED!
Running test Simple category... FAILED!
Running test Section headings with TOC... FAILED!
Running test Media link with nasty text... FAILED!
Running test Bug 2095: link with pipe and three closing brackets... FAILED!
Running test Sanitizer: Validating the contents of the id attribute (bug 4515)... FAILED!
Passed 268 of 285 tests (94.04%) FAILED!
I'm working on a (clearly :-) non-WMF project using MediaWiki, and I've
tripped over something that I can't figure out how to do using the
templating language.
Several things I've seen in various WP templates suggest there are many
thing about that part of the parser that I don't understand (and can't
locate doco for), but if there's a better list than this on which to
ask, please let me know.
And so, to the problem:
I'm trying to use MW as a database.
I just wanted to get out of the way up front that I realize that's the
problem here. :-)
I have a template ("A").
This template is instantiated on many pages ("A"->"B", "A"->"C", "A"->"D").
Those pages are in turn transcluded onto other pages:
"A"->"B"->"E"
"A"->"B"->"F"
"A"->"B"->"G"
"A"->"C"->"H"
"A"->"C"->"I"
"A"->"C"->"J"
"A"->"D"->"K"
"A"->"D"->"L"
What I'm trying to accomplish is to include a link on "A" that, when
the user is looking at "I" will permit them to edit "C".
I had been hoping that I could include the PAGENAMEE magic word in the
template ("A") as part of an HTTP edit link, but alas, PAGENAMEE (and
presumably all the other magic words that pertain to pages) bind so
late in the parse chain that they point to "I" in that situation.
In a situation like this, is there any reasonable way to grab the name
of "C" from inside the code of "A"? Something with subst:, maybe?
The actual pages are
A: http://tbkinfo.net/wiki/index.php/Template:Infobox_Show
C: http://tbkinfo.net/wiki/index.php/O%27Maddy%27s_House
I: http://tbkinfo.net/wiki/index.php/O%27Maddy%27s
Cheers,
-- jra
--
Jay R. Ashworth jra(a)baylink.com
Designer Baylink RFC 2100
Ashworth & Associates The Things I Think '87 e24
St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274
A: No.
Q: Should I include quotations after my message body?
An automated run of parserTests.php showed the following failures:
Running test BUG 361: URL within URL, not bracketed... FAILED!
Running test External links: invalid character... FAILED!
Running test Bug 2702: Mismatched <i> and <a> tags are invalid... FAILED!
Running test A table with no data.... FAILED!
Running test A table with nothing but a caption... FAILED!
Running test Link containing "#<" and "#>" % as a hex sequences... FAILED!
Running test Magic links: PMID incorrectly converts space to underscore... FAILED!
Running test Template with thumb image (wiht link in description)... FAILED!
Running test Link to image page... FAILED!
Running test BUG 1887: A ISBN with a thumbnail... FAILED!
Running test BUG 1887: A <math> with a thumbnail... FAILED!
Running test BUG 561: {{/Subpage}}... FAILED!
Running test Simple category... FAILED!
Running test Section headings with TOC... FAILED!
Running test Media link with nasty text... FAILED!
Running test Bug 2095: link with pipe and three closing brackets... FAILED!
Running test Sanitizer: Validating the contents of the id attribute (bug 4515)... FAILED!
Passed 268 of 285 tests (94.04%) FAILED!
Since the old extension seems dormant/not working, and I didn't know about it
when I started mine :-), here is a new one:
http://www.schwen.de/wiki/GMap
This extension lets you embed an arbitrary amount of fully interactive Google
Maps objects into your wikipages. The mapcontrols appear when you move the
mouse over the map, and disappear when you leave it. A helper widget is
available wich outputs current coordinates and zoom-level on click, making it
easy to choose a map locaton to display.
It currently works in Konqueror and Firefox (Windows and Linux). I'm not so
sure about IE, maybe someone can point me in the right direction. I plan on
adding markers. If you remember my dynamap extension, it is undergoing a
complete rewrite.
Cheers,
Daniel
--
http://en.wikipedia.org/wiki/User:Dschwenhttp://de.wikipedia.org/wiki/User:Dschwenhttp://commons.wikipedia.org/wiki/User:Dschwenhttp://meta.wikipedia.org/wiki/User:Dschwen
The other day the Vietnamese Wikipedia community found a
Vietnamese-language search engine, Viet99 <http://www.viet99.com/wiki/>,
that is direct-loading the entirety of vi:, as evidenced by the
up-to-datednesss of
<http://www.viet99.com/wiki/?title=Special:Recentchanges> -- compare to
<http://vi.wikipedia.org/wiki/Special:Recentchanges>.
The website uses <http://www.vacilando.org/index.php?x=7065>, a
direct-loading PHP script. The author of that script maintains a
poorly-behaved Wikipedia mirror at
<http://www.vacilando.org/index.php?title=Main_Page>. Unlike the
Vacilando mirror, though, Viet99 removes the script-provided references
to GFDL and slap on their own Google-provided advertising and copyright
statement: "Copyright 2005, Viet99. All rights reserved." They did keep
the part of the script that provides an edit link back to the real wiki,
but that's about it. Viet99 doesn't make it clear that the Wikipedia
content isn't actually their own work, and they make no effort to
explain what Wikipedia is; the only explanation is what we added at the
bottom of our main page to make sure that no Viet99 users get
misinformed about Wikipedia.
My understanding is that this is a violation of Wikipedia's terms of use
and the GFDL, and that they should be blocked. We could find no contact
information on their website, and a whois search revealed (presumably)
their host, A Theory <http://a-theory.com/>. I posted a message to IRC
and this mailing list the day we found out about this issue, but the IRC
message got ignored (probably the wrong time of day), and my previous
e-mail never made it through to the list.
Please consider blocking this direct-loader, because it's just adding to
Wikimedia's bandwidth for Viet99's own profit.
--
Minh Nguyen <mxn(a)zoomtown.com>
AIM: trycom2000; Jabber: mxn(a)myjabber.net; Blog: http://mxn.f2o.org/
Is there some way to write a working template that does what I'd like
it to do with this (nonworking) code?
As of [{{<includeonly>subst:</includeonly>FULLPAGENAME|oldid={{REVISIONID}}}}
this edit], this article uses content from {{{source}}}.
This is from [[Template:GFDLSource]]
As you can see, I'm trying to automatically stamp the article with a
link to the current revision.
I've got no idea what I need to unblock for this to work :-( Try again
until you get a different IP address?
I've cc'ed this to the technical list for their consideration. This
user is on AOL and is blocked from creating an account, but we don't
have enough information for me to work out which autoblock is causing
the problem and undo it.
- d.
On 20/02/06, WARDCOLIN6(a)aol.com <WARDCOLIN6(a)aol.com> wrote:
> When I tried to create an account in order to logon, I was told that I had already opened ten accounts and was blocked from creating any more.
An enhanced version of the C++ diff extension, wikidiff2, is now running on both clusters. It now
does character-level diffs on Chinese, Japanese and Thai, so it produces much better results than
the PHP diff algorithm, in a much shorter time to boot. Chinese had an ad-hoc segmentation scheme
based on inserting a space between every character before the diff, then removing the spaces
afterwards, but unfortunately that left spaces all over the place where there shouldn't have been
spaces. Anyway, it's fixed now.
We're still calling dl() every time a diff is needed, and I'm still waiting for profiling results on
the effect of that. The performance of the algorithm is quite good though, on our opterons, it can
diff 2MB (each side) of the most pathological input text I've yet been able to devise in 5.2
seconds, and it does it with only about 15MB of memory.
-- Tim Starling