CCing wikidata.

I don't think this is a good approach. We shouldn't be breaking API just because there is a new under-the-hood feature (wikibase). From the API client's perspective, it should work as before, plus there should be an extra flag notifying if the sitelink is stored in wikidata or locally. Sitelinks might be the first, but not the last change - e.g. categories, etc.

As for the implementation, it seems the hook approach might not satisfy all the usage scenarios:

* Given a set of pages (pageset), give all the sitelinks (possibly filtered with a set of wanted languages). Rendering page for the UI would use this approach with just one page.
langbacklinks - get a list of pages linking to a site.
* filtering based on having/not having specific langlink for other modules. E.g. list all pages that have/don't have a link to a site X.
* alllanglinks (not yet implemented, but might be to match corresponding allcategories, ...) - list all existing langlinks in the site.

We could debate the need of some of these scenarios, but I feel that we shouldn't be breaking existing API.

On Thu, Apr 25, 2013 at 2:24 PM, Brad Jorsch <> wrote:
Language links added by Wikidata are currently stored in the parser
cache and in the langlinks table in the database, which means they
work the same as in-page langlinks but also that the page must be
reparsed if these wikidata langlinks change. The Wikidata team has
proposed to remove the necessity for the page reparse, at the cost of
changing the behavior of the API with regard to langlinks.

Gerrit change 59997[1] (still in review) will make the following
behavioral changes:
* action=parse will return only the in-page langlinks by default.
Inclusion of Wikidata langlinks may be requested using a new
* list=allpages with apfilterlanglinks will only consider in-page langlinks.
* list=langbacklinks will only consider in-page langlinks.
* prop=langlinks will only list in-page langlinks.

Gerrit change 60034[2] (still in review) will make the following
behavioral changes:
* prop=langlinks will have a new parameter to request inclusion of the
Wikidata langlinks in the result.

A future change, not coded yet, will allow for Wikidata to flag its
langlinks in various ways. For example, it could indicate which of the
other-language articles are Featured Articles.

At this time, it seems likely that the first change will make it into
1.22wmf3.[3] The timing of the second and third changes are less


Brad Jorsch
Software Engineer
Wikimedia Foundation

Mediawiki-api-announce mailing list