Although not well-tested and I'm pretty sure incomplete, we currently have basic support for tracking which language for each article record. However, we don't do that for the rest of the Wikipedia-based records (ie, User, and Revision.

This seems a little tricky, since we can't use the pageid as primary key if we're storing users, revisions and articles from different wikis in the same database. I guess we have to switch to using a primary key that combines the language with the local pageid? And for users, maybe we can rely on a globalid, although there are some logistics to work out for finding out what those global ids are for existing users.

Compound keys get nasty, you inevitably find yourself exploding them and stuff. What about introducing an autoincrement dashboard-local primary key and including wiki and wiki page_id as regular columns? We can include a multi key on the discrete fields to improve the occasional reverse query, still.

That would work, probably. (I think?) But it'll be a lot of work, and a lot of careful testing, to clean up all the places that currently depend on ids matching Wikipedia's records. For revisions, we'll also need to be careful about implementing ordering whenever do queries and expect id-order to match up with date-order.

I've worked pretty hard to separate organize and refactor the code that interacts with Wikipedia's API and the wmflabs replica database, but the assumption of ids matching Wikipedia I've mostly taken for granted, so I'm not sure where all that assumption sneaks in outside of the Importer libraries.

Just noting that the simple matching IDs thing is being overturned regardless of how we proceed... If you think it's easier, we could make the schema changes I suggested but refer to rows using the multikey on wiki+wiki page id rather than the integer primary key. Having primary key be a calculated value seems like trouble to me, same with making monotonicity assumptions about the primary keys also having a date ordering. What about solving the latter problem by ordering by a timestamp column on revisions?

We have the timestamp column on Revision. It's just noticing all the places where we didn't order by date explicitly because we didn't need to.