IMSLP Forums

Hi guys,

at present, only IMSLP bureaucrats have the ability to modify or export the table of interwiki values which is stored as a Mediawiki internal. There are myriad default options that most users would be unaware are there, for example besides the [[wikipedia:Page name]] method of linking to Wikipedia, there are similar shorthands for linking to Wikisource, Wikinews, MediaWiki, and Google. Links to choralwiki (aka CPDL) can be handled this way, avoiding the need to encode html links to correctly handle spaces, punctuation, and diacriticals. Basically any website that IMSLP has a large number of links to (e.g. Creative Commons, Piano Society, Amazon, The Mozart Tower, Sibley Music Library and various other libraries, etc) probably should have a matching Interwiki entry to facilitate easy linkage.

http://www.mediawiki.org/wiki/Extension:InterWiki

There is an extension to allow the Interwiki table to be accessed by means of a Special page, which has the advantages of (a) ordinary users being able to view what interwiki links can be made, and (b) allowing any user with elevated privileges (e.g. sysop as well as bureaucrat) to modify the Interwiki table.

http://www.mediawiki.org/wiki/Extension ... lInterwiki

The extension seems to have a long history of stability having been compatible with MediaWiki 1.6 and upward.

Regards, Philip

EDITED TO ADD: In fact, to the change Interwiki table requires direct SQL access to the server: not even the bureaucrats have that power.

pml wrote:[...] at present, only IMSLP bureaucrats have the ability to modify or export the table of interwiki values which is stored as a Mediawiki internal. [...]

Uh, I don't know about anyone else, but that went right over my head.

Mostly mine - but we can ask Peter, Leonard, and Feldmahler (The bureaucrats).
And that's why I wanted more of them

It is actually the first time I've heard of this beaurocratic power. I've always assumed that the only way to add interwiki links is through direct SQL access.

That said, my opinion would be that it is probably not worth the maintenance cost to have an interwiki link editor, especially since adding interwiki links should be very rare. But I can certainly change my mind if you can suggest interesting uses of interwiki links (do you have sites in mind that you would like to use interwiki on?).

All in all, don't expect this feature anytime soon (I'm busy as hell at the moment, and don't want to break anything on the site), but I can put it on my todo list if you convince me.

The main argument for using Interwiki links for regular "partner" sites is that website URLs occasionally change when a site gets redesigned or implements a new method of referring to its pages, and if external links are coded explicitly in each case on works pages all over the Wiki, then fixing broken links becomes unwieldy. For example, before CPDL went through its transition to new management, the main server cpdl.org was briefly replaced for a time by choralwiki.org. Hard-coded URLs in that instance broke; and the cpdl interwiki broke, but that's because its non-trivial to alter the interwiki table via SQL. This extension fixes that limitation, since it is simply a few clicks for an admin to modify any of the interwikis (and all edits are logged).

The other advantage is that links to external webpages with URLs including diacriticals and punctuation don't have to be encoded with lots of hexadecimal % codes; MediaWiki handles the conversion to a full correct URL.

There are some neat, template based solutions working around the issue already on IMSLP, e.g. the Amazon score template handles all of the links to various Amazon stores in one central location, and likewise the links to the Piano Society are handled by a template, however these are generally the exception, not the rule. And a lot of people still add Wikipedia links as [http://... ] without realising they can simply use [[wikipedia:...]].

For example, say the Sibley Music Library changed its URL or the path to its works pages slightly, would you really like to have to search out and fix every link to external pages? For efficiency the job would have to be done by a bot, which is something of a hammer to crack an egg. Templates or interwiki linking are a much more elegant and practical means of addressing these problems, in my opinion.

Regards, PML

Not opposing the proposal, but normally a serious website should never change its URLs without providing automatic redirects (HTTP 301 or 302) from the old URLs. I know that it occasionally happens, but unless there are very exceptional circumstances, that's just very bad management. It breaks all incoming links, personal bookmarks, messes up search engines, etc. Generally it's not the responsibility of a website to keep up with URL changes on other websites.

This is why we use the handle.net system for persistent urls to all Sibley digitized material (actually it applies to anything posted to the university's digital repository). In that way, when we switched software from DSpace to IR+, the persistent urls of the handle.net system remained the same, even though Internal urls changed (some people who had linked to the older urresearch.rochester.edu... urls could no longer find them). It's also what allows us to make links in our online catalog and OCLC (Worldcat), safe in the knowledge that we won't have to go back some day and change links to thousands of scores.

Hi Jim,

yes, I see your point, but as you said URLs based in the urresearch.rochester.edu domain changed when the library's web serving technology changed, and this is the sort of very long-term thing I'm talking about; in fact, the handle.net system commits the library to updating those URLs with the correct destination page if for any reason the target page's URL changes.

Leonard's point about automatic redirects is well made, but on occasion institutional changes aren't handled gracefully - or the redirects are only left behind temporarily, rather than permanently. The basic lesson here is ...it happens!

The proposal isn't to deal with other websites' management issues, it's to allow a manageable and consistent method for providing web links to external sites, rather than having a whole lot of ad hoc links requiring maintenance, as at present.

Regards, PML

pml wrote:Hi Jim,

yes, I see your point, but as you said URLs based in the urresearch.rochester.edu domain changed when the library's web serving technology changed, and this is the sort of very long-term thing I'm talking about; in fact, the handle.net system commits the library to updating those URLs with the correct destination page if for any reason the target page's URL changes.

Regards, PML

As I understand it, the handle.net system makes the necessary changes--all we have to do is alert them of the change (the single change of server name) and they do the rest. If you want, i'd be happy to find out more precisely how that works and what our developers had to do when we went through the recent change.