forking wikis

I wish wikis were less collaborative! I wish they were more like software projects, where if one wants to modify anything, one gets one’s own copy and does anything at all to it.

No, I’m not really saying that there should be fewer centralised places of communal effort, these things are great… I just want a good way to branch and modify non-code content.

A cross between the Internet Archive’s system for uploading content into their collections, and Github’s user-centric arrangement.

The problem seems to often come back to the formats that things are in. It’s easy in the text-only code world; but wiki’s each have their own markup…

I wondered about the use of MediaWiki, and pulling in remote articles (periodic synchronisation), but of course there’s no merging in that idea, so it doesn’t work. It’s what Printable WeRelate does, but I’m yet to quite figure out how that’s going to deal with local additions to the data (probably, pages will be quite separate, with links only going from the local-only content to the remote-sync’d stuff; because we can’t modify the remote articles locally, and links in them when they’re elsewhere wouldn’t make sense).

So, there’s no solution: I’ll stick to centralised editing and storage, but carry on pulling backups (huzza to Wikiteam).

Better sync’ing for Printable WeRelate

Printable WeRelate now will synchronize all ‘starting-points’ pages (i.e. any page with a <printablewerelate> element), rather than being required to have just a single page listed on the command-line. This means that a cron job just needs to call sync.php at some interval (maybe nightly? of course, at some unusual number of minutes past the hour), and everything will be brought up to date.

This change is now available on the test site.

I’m now working on the display of the data within the wiki. Including the addition of a notice (maybe just a template call: something like {{WeRelate page}}) to the effect that “this is a copy of a page from WeRelate.org and should not be edited. All changes should be made at [url].” to send people back to WeRelate. Probably also actually prevent the editing of the synchronized pages.

Printable WeRelate

Last year I wrote a little script for producing GraphViz graphs, and LaTeX books, from werelate.org family history data. I’ve been tweaking it a bit now and then, and using it for my mum’s genealogical research. It works, but the more I want to do with it the more I think it needs a good ground-up refactoring. So, I’ve set to work turning it into a MediaWiki extension, so I can use an installation of MediaWiki as the cache (instead of text files), and update this installation in a separate operation to the tree-generation stuff. (I found that I was playing around with regenerating things more often that I wanted to be waiting for downloading modified data, and it was set to check for modifications if it’d been longer than a day since the last check…) The other big advantage of sync’ing into a local MW is that I’ll have a complete, working, backup of all our data.

The basic idea is that the ancestor and descentant lists, which define the starting points for the tree traversal, will be defined in normal wiki pages, and both the syncronisation and the tree-generation processes will read these and do what they need to do.

I’m setting up a test wiki at http://test.archives.org.au, if anyone’s interested.