Last modified: 2014-01-16 15:17:00 UTC
Rather than using interwiki.sql to populate the interwiki table, the installer should poll mediawiki.org's API for its interwiki table and populate the local interwiki table with those prefixes and URLs. If a connection isn't available, then interwiki.sql can be the fallback. The code to do this already exists in https://www.mediawiki.org/wiki/Extension:InterwikiMap If we don't have the installer do this, it should at least be a maintenance script.
Better, just pull the interwiki map from [[m:Interwiki map]], by stealing some code from rebuildInterwiki.php in WikimediaMaintenance. Or better still, we could write a script/bot that updates interwiki.sql in Gerrit with the contents of m:Interwiki map from time to time.
(In reply to comment #1) > Or better still, we could write a script/bot that updates interwiki.sql in > Gerrit with the contents of m:Interwiki map from time to time. Do you have an example of a script that does something similar? What level of access would be required to implement this? I assume that if someone without +2 were going to run the script, a +2 would be needed to approve each change? We still might want to have a maintenance script for use by wiki system administrators, since interwiki.sql would only be used at the time of the initial installation of MediaWiki.
(In reply to comment #2) > Do you have an example of a script that does something similar? I was thinking along the lines of l10n-bot. > We still might want to have a maintenance script for use by wiki system > administrators, since interwiki.sql would only be used at the time of the > initial installation of MediaWiki. If we were to do this we might need to add an extra column to the interwiki table to mark those entries added by the installer/maintenance script. Then when the maintenance script is run to update the table, it would be able to leave any manually-added entries untouched.
(In reply to comment #3) > If we were to do this we might need to add an extra column to the interwiki > table to mark those entries added by the installer/maintenance script. Then > when the maintenance script is run to update the table, it would be able to > leave any manually-added entries untouched. A few problems might arise. Suppose, say, Disinfopedia becomes Sourcewatch, but meta-wiki drags its feet changing the interwiki map. The local wiki doesn't feel like putting up with that, so it changes the interwiki table. The entry is now marked as manually changed, so it won't be reverted by the maintenance script. Then Sourcewatch becomes Exposetruth, and this time meta-wiki makes the change promptly. Because the entry is marked as manually changed, it won't be updated, and so outdated info remains in place on the local wiki. One possible solution is to have a serialized field indicating when the interwiki fields (URL, API URL, etc.) were updated. If, say, a URL is changed locally, then it could still be updated in accordance with a later change to the URL on meta-wiki's table, but it wouldn't revert back to an earlier version. If the local wiki is dead-set on having a different URL than what meta-wiki has, then it can set that date for, say, the year 3000 and the field would not be changed until then, no matter what meta-wiki does.
(In reply to comment #4) > The entry is > now marked as manually changed, so it won't be reverted by the maintenance > script. It's true. However I don't see any other way to overcome the difficulty of (a) allowing people to add their own additional interwikis and (b) allowing the script to remove dead interwikis that have been removed from the Meta map.
It can be done, but it would increase the complexity. One would need to either have a field indicating that the interwiki is dead, or have a table of dead interwikis. Either way, it would also be necessary to indicate WHEN the interwiki died; if it died after it was modified locally, then the interwiki should be removed. As always, this process can be overridden by putting a date very far in the future as the local modification date. If a site such as WikiApiary were used as the source of the interwiki map, a lot of other data could be provided by the API, since they specialize in providing more than the bare minimum. That data could include what wikis have died and when.
I think you should separate out having the installer use an up to date version of interwiki.sql (or pull from meta/whatever) and having the interwiki map be automatically updated (by update.php?) into separate bugs. Keep in mind that having mediawiki installed behind a corporate firewall is more common than one imagines, so a connection to the internet really should not be taken for granted.
(In reply to comment #7) > Keep in mind that having mediawiki installed behind a corporate firewall is > more common than one imagines, so a connection to the internet really should > not be taken for granted. Therefore, the suggestion in the second paragraph of comment 1 ("Or better still, we could write a script/bot that updates interwiki.sql in Gerrit with the contents of m:Interwiki map from time to time.") would be good to have as a fallback.
