Evan Prodromou wrote:
Holy crap, that's a lot of work.
For the task at hand, I don't think it is. The to-do-list is just very detailed.
What about just tagging articles in cur and old with a language code ('en', 'fr', 'akk'), and putting them all in one big database?
How would that lead to a single log-in? And all the user IDs for the edits would be wrong. You'd have to renumber all of them, both in cur and old, as well as in user. And then, how to unify the user table? Just add'em as they come? Half a dozen "Magnus Manske" users in the user table? You'd have to merge them somehow. Wait - that's my proposal... ;-)
Users' interface language (the navitorial stuff) is determined by their browser settings.
We can do that already without changing anything in the database. But IMHO that'd be a bad idea. Better, in my proposed new user database, let the user *choose* the interface language.
That doesn't solve the problem for other wikis (-tionary, -books), but it does cut down on a lot of differences. Also, it makes interwiki links a lot easier to detect and fix.
Well, my proposal *would* solve the problem for wiktionary/wikibooks. And I already had an interwiki management demo running once, with separate databases. The main point with interwiki links is to get them out of the article source and into a decent table. It would make sense to generate a single table for all interwiki links, granted. It could reside in the same database as my new user table. Which is exactly what I proposed about a year ago...
Magnus