Good Wikitech-l Folk,
I write in the hopes of getting some input or ideas about an extension I've written that attempted to solve a particular maintenance and navigation problem I think I have. I most interested in whether it's anything like The MediaWiki Way of doing things.
My problem: I have a lot of documents with a fairly straight-forward a priori order (these are digitized notebooks and papers of family memorabilia), where lots is hundreds of individual page-sides. I wanted a couple of things:
To put them in a wiki to allow for them to be viewed, commented on, linked, &c.
To lay down the original order the page-sides occured.
Sure, my audience is going to come along and add other connections, but this is the first path they can start with.
One way I could have done this was to have each page contain a link to the next and previous pages explicitly. Straihghtforward, and fairly easy to have a bot go through and programmatically add the links. But this approach also struck me as a maintenance problem: suppose I got something wrong the first automation, and wrong in a tedious way to fix? Suppose new information comes along later than makes us want to re-arrange this order? Suppose I don't want to just write a bot to do this for me?
If, on the other hand, instead of explicit links, something like MediaWiki's Categories were added to each page, something that placed the specific page in a broader context through code, then that would be preferable. Categories, though, didn't quite answer, they are really for grouping things that have some trait in common together, not for sequencing many things.
Suppose one page in the wiki contained a map of some other pages? If I included a tag in a page that refered to some map page, then my extension could look up the map, find the context of the referring page, and print out suitable navigation links.
Some crufting around later, Nav.php was born: at a little sandbox mediawiki 1.5.4 at http://www.nigelk.org/wiksand/index.php?title=Nav_Map_Demonstration, find a couple of demonstrations of this Nav.php extension I've written.
Is there a built-in or better way of trying to solve this problem I think I have? Would it be thought of differently by the mediawiki developers here? Is this kind of lashup of interest to anyone? Is my php completely horrible? Any thoughts or inputs, either here on the list or in discussion at that sandbox above, is appreciated.
Respectfully submitted, Nigel Kerr nigelk@nigelk.org
G'day all
We've had a merge glitch on English Wikipedia I think, see
http://en.wikipedia.org/wiki/Talk:Montreal_Expos#Improper_merge_of_histories
for the story.
I can't be sure just how serious it is. I'd decided that the histories couldn't be merged because of overlap, but another admin has done it. Unfortunately I didn't take a copy of the histories, I was waiting for comments before taking any action so I didn't think it was necessary at that stage. As you'll see, the other admin is doubtful that there was significant overlap.
How difficult is it to recover the histories of "Montreal Expos" and "Montréal Expos" from the last backup before 09:34, 28 December 2005, so we can see the exact problem (and even if there is one)?
All I think I need at this stage is the two lists of edits, to manually see what the problems might be. But all suggestions of how to proceed are welcome.
Andrew Alder aka user:andrewa
On 12/29/05, Andrew Alder andrewa@alder.ws wrote:
I can't be sure just how serious it is. I'd decided that the histories couldn't be merged because of overlap, but another admin has done it. Unfortunately I didn't take a copy of the histories, I was waiting for comments before taking any action so I didn't think it was necessary at that stage. As you'll see, the other admin is doubtful that there was significant overlap.
How difficult is it to recover the histories of "Montreal Expos" and "Montréal Expos" from the last backup before 09:34, 28 December 2005, so we can see the exact problem (and even if there is one)?
All I think I need at this stage is the two lists of edits, to manually see what the problems might be. But all suggestions of how to proceed are welcome.
Hi Andrew
This problem can be solved without developers' help -- if you can identify which revision goes with which article. This should be fairly easy, because the text will be in bold on the first line. If you then undelete all revisions of the Montréal Expos article, you can move them back to their rightful place. Then undelete all the other revisions at Montreal Expos, and revert the redirect that will be pointing to Montréal Expos.
The articles will then be as they were before.
Yours, Sam
-- Sam
nigel kerr" nigelk@nigelk.org wrote in message news:43B33F44.5090905@nigelk.org... [snip]
Some crufting around later, Nav.php was born: at a little sandbox mediawiki 1.5.4 at http://www.nigelk.org/wiksand/index.php?title=Nav_Map_Demonstration, find a couple of demonstrations of this Nav.php extension I've written. Is there a built-in or better way of trying to solve this problem I think I have? Would it be thought of differently by the mediawiki developers here? Is this kind of lashup of interest to anyone? Is my php completely horrible? Any thoughts or inputs, either here on the list or in discussion at that sandbox above, is appreciated.
Looks interesting: stick a page up on meta so we can discuss it more easily :-)
Phil Boswell wrote:
Looks interesting: stick a page up on meta so we can discuss it more easily :-)
done: http://meta.wikimedia.org/wiki/User:Nigelk/Nav
to see the thing in action without installing it, do see http://www.nigelk.org/wiksand/index.php?title=Nav_Map_Demonstration.
cheers, Nigel
-----BEGIN PGP SIGNED MESSAGE-----
Moin,
On Thursday 29 December 2005 15:45, nigel kerr wrote:
Phil Boswell wrote:
Looks interesting: stick a page up on meta so we can discuss it more easily
:-)
done: http://meta.wikimedia.org/wiki/User:Nigelk/Nav
to see the thing in action without installing it, do see http://www.nigelk.org/wiksand/index.php?title=Nav_Map_Demonstration.
Sounds very interesting for well, slide shows (don't kill me!).
Two things missing: * the Nav Map should have links to the pages in question instead of being just a list. * the very first page (like in the outline) should have a "next page" link.
Best wishes,
Tels
- -- Signed on Thu Dec 29 18:05:17 2005 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email.
"One man in a thousand is a leader of men, the other 999 follow women" -- Groucho Marx
Tels wrote:
Sounds very interesting for well, slide shows (don't kill me!).
okay, i won't kill you. seriously, though, slide-shows are indeed a worthwhile usage here, if you want to lead readers through a sequence of things at least in a given a priori way.
Two things missing:
- the Nav Map should have links to the pages in question instead of being
just a list.
i had been taking a cue from MediaWiki:Sidebar here, and just including the page names as data to be used, not links. this does make it easier to parse through the list looking for a page, one doesn't have to clear the link-structure out of the way first. what advantages can you see from doing as you suggest?
- the very first page (like in the outline) should have a "next page"
link.
so, like, to get one started, you're saying? probably pretty easy.
some parameters or further work that would be probably helpful to be able to apply it to a variety of situations:
* style information for the links and for the toc box
* controls for what links to show when ("put a 'next page' on the TOC page"...)
* localized messages for whatever language the user prefers
* it's possible for a single content page to be in more than one nav map, so a way to distinguish the nav links for the different maps ("Vacation Pictures: Prev - Up - Next" and then "Embarrassing Pictures: Prev - Up - Next" could both apply to that one picture from the summer at the beach...)
Ryan Lane wrote:
One thing though: When clicking next, and going to a page that hasn't been created yet, it would be nice if the "Previous - Up - Next" dialog didn't dissapear.
from what i understand, this means either:
1. calling all the pages in the nav map into existence at map-creation time
2. checking all maps for a given non-existent page when you come across it and inserting the links even if there's no text
or am i mis-understanding the suggestion?
cheers, nigel
-----BEGIN PGP SIGNED MESSAGE-----
Moin,
On Thursday 29 December 2005 19:42, nigel kerr wrote:
Tels wrote:
Sounds very interesting for well, slide shows (don't kill me!).
okay, i won't kill you. seriously, though, slide-shows are indeed a worthwhile usage here, if you want to lead readers through a sequence of things at least in a given a priori way.
I was partly joking, but I indeed constructed a slideshow on one wiki for a presentation, because that seemed much easier for me to edit than using any other program.
And adding manually "next page, last page" links became tedious :)
Two things missing:
- the Nav Map should have links to the pages in question instead of
being just a list.
i had been taking a cue from MediaWiki:Sidebar here, and just including the page names as data to be used, not links. this does make it easier to parse through the list looking for a page, one doesn't have to clear the link-structure out of the way first. what advantages can you see from doing as you suggest?
Well, to have an overview with clickable links? Hm, I see, you already get these on the first page. But my very first instinct was to try to click any of the headlines to go there.
I think having a human-parsable (with links) and machine-parsable (easier format) page might be worthwhile. Maybe add an XML or whatever output.
(I can even see that this gets turned into a graph automatically....*cough*)
- the very first page (like in the outline) should have a "next page"
link.
so, like, to get one started, you're saying? probably pretty easy.
some parameters or further work that would be probably helpful to be able to apply it to a variety of situations:
* style information for the links and for the toc box * controls for what links to show when ("put a 'next page' on theTOC page"...)
* localized messages for whatever language the user prefers * it's possible for a single content page to be in more than onenav map, so a way to distinguish the nav links for the different maps ("Vacation Pictures: Prev - Up - Next" and then "Embarrassing Pictures: Prev - Up - Next" could both apply to that one picture from the summer at the beach...)
:-)
Best wishes,
Tels
- -- Signed on Thu Dec 29 19:40:47 2005 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email.
"A Thaum is the basic unit of magical strength. It has been universally established as the amount of magic needed to create one small white pigeon or three normal-sized billiard balls." -- Terry Pratchett
This is a cool extension for my needs so I'm jumping in. :) Hope no one minds...
nigel kerr wrote:
i had been taking a cue from MediaWiki:Sidebar here, and just including the page names as data to be used, not links. this does make it easier to parse through the list looking for a page, one doesn't have to clear the link-structure out of the way first. what advantages can you see from doing as you suggest?
Consistency, it's very confusing to run into this unlinked page. But an XML list that showed up as a TOC or something when viewed would solve this nicely. Or maybe just a link to the real TOC page?
- the very first page (like in the outline) should have a "next page"
link.
so, like, to get one started, you're saying? probably pretty easy.
some parameters or further work that would be probably helpful to be able to apply it to a variety of situations:
* style information for the links and for the toc box * controls for what links to show when ("put a 'next page' on theTOC page"...)
* localized messages for whatever language the user prefers
All of these things would be awesome.
* it's possible for a single content page to be in more than onenav map, so a way to distinguish the nav links for the different maps ("Vacation Pictures: Prev - Up - Next" and then "Embarrassing Pictures: Prev - Up - Next" could both apply to that one picture from the summer at the beach...)
This would be really, really good, too. See comment below for more thoughts on this.
Ryan Lane wrote:
One thing though: When clicking next, and going to a page that hasn't been created yet, it would be nice if the "Previous - Up - Next" dialog didn't dissapear.
from what i understand, this means either:
- calling all the pages in the nav map into existence at map-creation
time
- checking all maps for a given non-existent page when you come
across it and inserting the links even if there's no text
I think a third option might be to hook into the Article render and generate prev/next/up links for all navs the page is in at start and end of page. That depends on the details of rendering non-existant pages, I imagine, but it would be the best choice. Also means no ugly link crud in the page text itself!
Great work so far, I hope this extension matures quickly. :)
Regards, Ben Garney Torque Technologies Director GarageGames.Com, Inc.
good wikitech-l folk,
after perhaps more lying about on holiday than was quite healthy, i've put together a new version of this NavMap extension.
http://meta.wikimedia.org/wiki/User:Nigelk/Nav
the links to the demo have the most recent version installed. thanks to all who commented here or en Meta. the changes:
* php4 compatibility (i'd been wandering along blissfully ignorant of php4 vs php5 issues...) * some of the appearnce of the extension have some more options * a battery of unit-tests for the features as i went (what do folks here do for testing/unit-testing?) and attendant robustness
but it remains much as it was in terms of basic functionality.
i heartily solicit and welcome feedback and observations. my next step is to write a SpecialPage that can concatenate pages in the navmap together (inspired by the wikibooks comments i've received).
cheers, nigel
nigel kerr <nigelk@...> writes:
Is there a built-in or better way of trying to solve this problem I think I have? Would it be thought of differently by the mediawiki developers here? Is this kind of lashup of interest to anyone? Is my php completely horrible? Any thoughts or inputs, either here on the list or in discussion at that sandbox above, is appreciated.
This is pretty neat. Seems like a good way to organize a book or a very long tutorial/how-to. One thing though: When clicking next, and going to a page that hasn't been created yet, it would be nice if the "Previous - Up - Next" dialog didn't dissapear.
V/r,
Ryan Lane
wikitech-l@lists.wikimedia.org