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