Interwiki integration

This page is for proposing and discussing interwiki integration ideas. These ideas seek to fix the following bugs, while also enabling more interconnection among the wikis of the wikisphere as a whole, in ways not contemplated by these bugs:

Create wikispaces and langspaces
Combine all local wikis into one big wikifarm, with a single database containing wikispace and langspace fields, in addition to the existing namespace fields, in the appropriate tables. All configuration settings will need to be unified for the one big wikifarm, which might require changing some of them to arrays in order to maintain customizability of individual wikis. Pages would be accessible as follows, without the need for external links:

This will enable both "absolute" addresses (e.g. http://wikimedia.org/wiki/wikipedia:en:Portal:Geography ) and "relative addresses" (e.g. http://en.wikipedia.org/Portal:Geography ). Users would not necessarily need to type in the full page title (including wikispace and langspace); if the user is on, say, enwiki and types in Portal:Geography, the software will assume he means wikipedia:en:Portal:Geography.

Implementation
Make necessary changes to dozens/hundreds of core and extension files. E.g. parameters will need to be added to many functions, and new variables will need to be added to many class objects. Many aspects of the user interface, including special pages and the API, will need to be revised to make use of the new fields. Add the following database fields, and implement the associated functionality to make use of them:

Advantages

 * Allow for integrated watchlists, integrated RecentChanges, interwiki page existence detection, etc.
 * Allow one database query to be run on the entire wiki farm without the need to UNION or JOIN a bunch of different databases.

Disadvantages

 * Less ability to run isolated tests on small wikis without risking crashing the entire wikifarm?
 * Could be hard to implement, requiring hundreds of changes to the core and extensions.
 * Efficiency issues due to difficulty/impossibility of dividing the wiki farm among different servers if there is just one big glob of data, rather than each wiki being a separate glob.
 * Already-established wiki farms would have a more complex process of merging data, similar to the issues involved with shared databases. Collisions involving some data, such as page titless, could be resolved by disambiguating through the wikispace and langspace fields. But it would be necessary to resolve collisions in primary keys, user names, etc.


 * This might be done by establishing prioritization of wikis &mdash; e.g. if an enwiki user has the same username as a frwiki, and enwiki is the higher-priority wiki, then the frwiki user could be required to change his username to one that has not already been taken. Or the user with the longer-established account could have priority.

Create central database/website as clearinghouse for interwiki data sharing
Create a central database/website as a clearinghouse for interwiki data sharing. Have local wikis retrieve data from it (e.g. for producing interwiki watchlists, recentchanges, and existence-detecting links) via the backend, and allow remote wikis to either (1) pull data from it or (2) subscribe to a service in which the clearinghouse website will periodically push updates to those remote wikis via their APIs. This could combine well with the previous idea to create wikispaces and langspace.

Advantages

 * Be itself, might be easier to implement than creating wikispaces and langspaces, since aside from the clearinghouse implementation code, it would only require creating extensions that link into existing hooks.

Disadvantages

 * By itself, might not be as elegant or efficient a solution as creating wikispaces and langspaces.