So, this is yet more noodling wishlist stuff I've been thinking about
for MediaWiki which I wanted to throw up for discussion.
Here's my problem. Let's say I'm reading a Wikitravel article about
Venice because I intend to go there. I want to print out the article
or download it to my PDA. Now, a trip to Venice is going to require
more than just the Venice city guide. I should also know about the
Italian language, the money used in Italy, visa requirements, and
perhaps about the region around Venice.
It would be possible to include all that information on the same page,
but since there are hundreds of cities in Italy, each needing the same
info, it would get unwieldy pretty quickly. For Wikitravel, we keep
country-wide info in the country page, phrasebooks in another page,
and so on. So, it would be nice if, when I choose to print the
[[Venice]] article, the Wikitravel software would suggest that I also
print out [[Italy]] and [[Veneto]] (the region Venice is in) and
[[Italian phrasebook]], which I could optionally do.
The question is then: how would the software know that these articles
are related at all? It could try to follow the links in the article,
but those might point to very loosely-related articles (say, there
might be some text pointing out that Venice has canals much like
[[Amsterdam]]). It also gets redundant saying that if you're in an
Italian city, you're in [[Italy]] and you should check out our
[[Italian phrasebook]] and by the way [[Italy]] is part of [[Europe]]
and...
There are other options, though. Metadata systems often declare
relationships between individual items. For example, the <LINK> tag in
HTML specifies sibling and parent page relationships. Dublin Core has
a "Relation" specifier that can specify "Is Part Of" and "References"
relationships, among others.
We have a system for tagging related articles in MediaWiki already --
interlanguage links. What I propose is that this system get expanded
to include metadata links to other articles in the same MediaWiki
system. For example, I could declare that [[Venice]] is-part-of
[[Veneto]], which in turn is-part-of [[Italy]]. I could also point out
that [[Italy]] is-related-to the [[Italian phrasebook]].
Now, my automatic suggestion tool only needs to navigate these
relationships instead of all the visible links in the page. The
related articles could also appear on the Web rendering in the same
way interlanguage links do -- so that I don't have to interrupt the
prose in the article to give "See also" style links.
I haven't developed this idea out fully, so I don't have a really good
syntax suggestion. I think the best I can come up with is something
like the interlanguage links, such as:
* [[meta:is-part-of:Veneto]] (for the Venice page)
* [[meta:has-part:Venice]] (for the Veneto page)
* [[meta:is-part-of:Italy]] (for the Veneto page)
* [[meta:related:Italian phrasebook]] (for the Italy page)
These would be kind of abstract, but usable on any MediaWiki
system. For example, it'd also work for showing that [[History of
Canada]] is somehow a part of the article on [[Canada]]. We could
probably just borrow the applicable Dublin Core names (minus stuff
about versioning and replacing, which don't seem that applicable for
MediaWiki articles).
It would also be nice to have article relationships specific to the
MediaWiki installation, like, for Wikitravel:
* [[meta:phrasebook:Italian phrasebook]]
* [[meta:country:Italy]]
* [[meta:region:Veneto]]
...where each installation could configure how to render the
metatags. It might even be possible to fit the interwiki pages into
this more general scheme.
Anyways, this is something I'd like to get into doing for MediaWiki,
since it's kind of important for us on Wikitravel. Any ideas,
comments, precedents, suggestions?
Thanks,
~ESP
--
Evan Prodromou <evan(a)wikitravel.org>
Wikitravel - http://www.wikitravel.org/
The free, complete, up-to-date and reliable world-wide travel guide
I've packaged up the current state of the stable branch from CVS and
put out a new release. There are a number of fixes and changes from the
20030829 release, so please do read the release notes!
Release notes and download:
https://sourceforge.net/project/shownotes.php?release_id=196082
Updating should be fairly straightforward: if you used the install.php
script, copy in your LocalSettings.php and AdminSettings.php and run
update.php, otherwise copy things to the destination directory manually
and run the SQL updaters noted in the release notes.
-- brion vibber (brion @ pobox.com)
So, the main reason I'm writing to this list because I want to see if
it's a discussion list or just for announcements. I think Brion said
it should be used for discussion of the MediaWiki software, not
wikitech-l.
But, to make this post something better than just the word "test", I
figure I should ask a question. Here goes:
It seems on Wikipedia that there are really only a few idioms that are
mainly used for adding images: left-float, right-float, centered, and
interpolated into text. Considering that these are all done with some
hairy HTML markup, I'm wondering if it wouldn't make sense to add some
Wiki markup for these standard items.
Has anyone done proposals for doing this? Something like, I dunno:
[[Image:left:name_of_image|alt text|caption]]
[[Image:right:name_of_image|alt text|caption]]
[[Image:center:name_of_image|alt text|caption]]
[[Image:name_of_image|alt text|caption]]
...where the alt text and caption are optional?
I haven't taken much of a look at the Wiki markup rendering stuff, but
I figure that whatever renders [[Image:]] links right now could
probably be altered to handle syntax like the above.
Any ideas? Different syntax? I might start whacking on this, and
submit a patch.
~ESP
--
Evan Prodromou <evan(a)wikitravel.org>
Wikitravel - http://www.wikitravel.org/
The free, complete, up-to-date and reliable world-wide travel guide
On Nov 3, 2003, at 14:52, Freerk Ohling wrote:
> Hello wikitech-l,
>
> I am trying to install the mediawiki-20030829.tar.gz on my
> webspace as a readonly mirror of the german cur database.
> I already got it managed to insert the 92MB mysqldump
> of the german cur_table into my mysql database.
>
> But I can't install the mediawiki. I do have a webspace packet
> with 200mb space, PHP 4.2.1, Apache 1.3.23 and MySQL
> 3.23.51-log on Linux 2.4.9-31 RedHat7.2. I also have phpMyAdmin
> 2.5.1 (but the mediawiki INSTALL file says: Recommended versions
> are: Apache 1.3.27 or later; MySQL 4.0.13 or later; PHP 4.3.2 or
> later.)
-snip-
(If you haven't already, you may wish to sign up for the mediawiki-l
mailing list, we're hoping to split setup help and release
announcements off from the day-to-day running-of-Wikipedia and active
development stuff here in wikitech-l.)
You may have trouble with that old a PHP, some things may need to be
replaced with older equivalents.
It should be possible to set it up generally, but not with the install
script.
All the *.php files from includes/ and languages/ (or at least, just he
languages/ files you need) need to go into a single install directory,
for simplicity this may be the place where you put wiki.phtml and
LocalSettings.php.
To create the database... first, in phpMyAdmin rename the existing
'cur' table to something else, say 'cur2', for the meantime. Now, in
phpMyAdmin you should have the option to run a sequence of sql
commands. I forget if there's a script upload option or if you just
have to paste in, but take maintenance/tables.sql and
maintenance/indexes.sql and execute all the commands in them; this
creates the table layout.
Now, get rid of the newly created 'cur' table and rename 'cur2' back to
'cur'.
If everything's set up right, you now should be able to browse pages.
Some features won't work (whatlinkshere, recentchangeslinked, nothing
yet in recentchanges, search won't work) and without the link tables
it'll be slightly less efficient loading pages, as it has to check the
existence of every linked page individually. "In theory" if you put the
'maintenance' subdirectory in there, and you've got an
AdminSettings.php, you can run the maintenance/rebuild-all.php script.
It may be buggy and may not work at all, be warned, and you really
_really_ shouldn't leave the maintenance scripts web-accessible.
-- brion vibber (brion @ pobox.com)