Last modified: 2011-03-06 10:23:18 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 14473 - Sister project (interwiki) links should be stored in their own table
Sister project (interwiki) links should be stored in their own table
Product: MediaWiki
Classification: Unclassified
Database (Other open bugs)
All All
: Normal enhancement with 7 votes (vote)
: ---
Assigned To: Brion Vibber
: schema-change
: 15986 23195 (view as bug list)
Depends on:
Blocks: 23524 27888
  Show dependency treegraph
Reported: 2008-06-08 20:34 UTC by Danny B.
Modified: 2011-03-06 10:23 UTC (History)
7 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Danny B. 2008-06-08 20:34:25 UTC
We have all kind of links stored in db, but not sisterproject links. (Well, it's not the most correct word, because not only sister projects but other wikis and sites are linked with interwiki prefixes.)

These should be stored in database as well to provide better user friendliness of data mining, especially for broken link checking.
Comment 1 Daniel Kinzler 2008-06-08 20:38:41 UTC
I agree -- we have language links and even external links, but we don't have interwiki-links in the db. This is a bit annoying. And as suggested, checking for broken links to sister projects would be a prime application for this on wikimedia sites.
Comment 2 Alexandre Emsenhuber [IAlex] 2008-10-14 20:08:47 UTC
*** Bug 15986 has been marked as a duplicate of this bug. ***
Comment 3 Courtney 2008-10-14 20:17:58 UTC
Thanks, Alexandre!  I guess I didn't search the bug list as well as I thought, but I was looking for interwiki not sisterwiki :)
Here are my comments from 15986 so no one needs to follow that link:

The default behavior of links seems to be to add a link to a table:

But there is no table to store non-language interwiki links.

It would be really useful (to me anyway) to store interwiki links somehow, even
if they are stored inside of one of these other tables.

I think with the proper planning this could fix (or help fix) the following
bugs:  - store IW links as
metadata - IW what links here from
common - more general IW what
links here - local IW links made bold
Comment 4 Brion Vibber 2010-04-15 21:53:15 UTC
*** Bug 23195 has been marked as a duplicate of this bug. ***
Comment 5 Brion Vibber 2010-04-15 22:00:35 UTC
Assigning to myself; how did we manage to forget to do this for like 7 years?
Comment 6 Brion Vibber 2010-04-16 01:42:00 UTC
Fixed in r65104.

Added iwlinks table to track inline interwiki link usage.

Like langlinks, this stores the interwiki prefix (as iwl_prefix) and full page title (as iwl_title), attached to the page doing the liking (as iwl_from -> page_id).
Unlike langlinks, there can be multiple entries stored per interwiki prefix.

Updater to add the table confirmed on MySQL, untested on SQLite but should work.
Someone may still need to add and test a PostgreSQL updater.

Refactored makeWhereFrom2d() out of LinkBatch to Database so it could be re-used for the similar mapping for the interwiki links, which need a string prefix rather than an int namespace key.
Also cleaned it up internally to reuse existing code for building where clauses from arrays. (Tim & Domas -- if the previous more verbose code was there to reduce function call and array processing overhead on very large link lists, feel free to unroll it again if the difference is measurable. Just swap the var names around from the old LinkBatch code and escape the base key value if it's not an integer, it'll be functionally equivalent.)

Note You need to log in before you can comment on or make changes to this bug.