For games, there’s usually a link on the IF Archive to the relevant IFDB page, e.g. on Index: if-archive/games/glulx.
For the software-related files, e.g. at Index: if-archive/mapping-tools, it might make sense to have a link to the relevant IFWiki page. It would be a way of documenting the archive without overcomplicating the archive itself, and a good use for the wiki which has a database and infobox structure for software.
I wonder how this could work, and whether it’s something that would be considered useful and feasible.
Maybe an archive field could contain what the wiki page is called or should be called – then whether it exists on the wiki would affect how it is displayed on the archive page (either as a link to the page, or to the wiki form that would create the page).
Hm. Let me explain the ifarchive index system. It’s pretty simplistic. The entire site is static HTML. Every time it’s updated, someone (usually David) runs a script to regenerate the index files.
Each directory has an Index text file (e.g. http://ifarchive.org/if-archive/games/agt/Index). This contains a list of directory entries, and some entries have a tuid: line. That gets turned directly into an IFDB link. So it’s easy to imagine adding an ifwiki: line that gets turned into an IFWiki link.
The problem is that there’s no automated system for adding new metadata. I added the first batch of tuid: lines a couple of years ago, and I guess David has been adding them by hand ever since. I don’t want to say “Hey, now it’s also your job to add the ifwiki: lines.” Still less update them every time a new wiki page is added.
If this was to work, it would have to be an automated process based on data sourced from IFWiki. Maybe a CSV file which associated an IFWiki path (https://www.ifwiki.org/Violet) with an IFArchive URL (https://ifarchive.org/if-archive/games/zcode/Violet.zblorb). Then an Archive script could import that periodically.
It’s not a one-to-one mapping, so there’s details to work out here.
My initial reaction was that it wouldn’t be that hard to add the ifwiki: line, as there aren’t that many software pages on the wiki, and that I wouldn’t mind doing it.
But, thinking aloud, the wiki software page could have a separate Archive field for the IF Archive URL. This would be useful in any event (for the infobox), and many pages already link to the archive. Then a wiki query could make a CSV file available containing archive path / wiki page name / wiki path.
It might be possible for one wiki page to be linked to from multiple archive files (i.e. for a wiki page to have a list of archive links) but I don’t think one archive file would need to link to multiple wiki pages (i.e. we could ensure that only one page links to each archive link).
Could you expand on this a little, in case I’ve missed something?
I’ve tried this out on the dev server and it works all right. Each wiki page can have multiple archive links. I could provide you with an ifwiki.org URL for an automatically generated CSV file.
That would be cool. And, I think, probably necessary if this going to work well.
If this is going to be automated (and agree it should be) then every wiki page that links to an archive page/file should have a reciprocal link.
This is an example where it would be good to have archive directory pages (not just files) linking to the relevant wiki page or pages. Some wiki pages might link to some individual Adventure ports too, but I doubt all the archive files would be mentioned on the wiki (so they’d not all get wiki links added on the archive page).
The results were far too big to put here as forum replies, but here is a list of IFWiki pages linking to the IF Archive - there are 2363 rows. Some wiki pages have multiple archive links (and some archive links appear on multiple pages). Let me know if you anything else would be useful. I’ll delete the list from the wiki after a while as it won’t be of interest in future.
I notice that there’s a few entries that don’t link to the wiki properly. “ADRIFT_tutorials” on the first page is a category page, I think, which snuck into the page list.
Yes I never thought of adding the namespace to the query, so links to pages in the Category or User (or any other non-main) namespace show up as red links. It would be easy to fix the query. But hopefully the list gives a useful overview anyway. If you were to use something like this list then maybe we should ignore some of those pages anyway.