The other reason, like I said, is to have the site be in different languages, which BML already supports, but not as well as I'd like. I did it with FreeVote.com, where we had 11 languages.
But I want kick-ass internationalization with LiveJournal. I've started designing the DB schema and strategy for translating everything on the site. At this point there are 3 main areas:
1) BML files
2) the FAQ
3) certain journals (namely,


BML files are easy. I've done it in the past. We'll redistribute the en_generic language with the code, but 'ljcom' CVS will also contain 'en_livejournal' and tons of other languages, starting with German, which some friends here in Germany are going to work on.
We've also been talking to a number of people about making it easy for Europeans to pay... we did a name search for LiveJournal over the whole EU, then we're registering the name, and we're getting a bank account that people can pay with their EC Konto Karte or whatever.
The FAQ translation will require a little DB change. But not so bad.
The journal translation plan is this:


So we have 3 areas (and possible more) to translate, but varying ways to update stuff. That sucks... it should be VERY easy for translators, with a single place to go. And all text needs to be versioned. And changes in the master language (en_US or en_livejournal) need to be able to marked with a strength:
0 = typo/grammar change (don't flag translations as bad at all)
1 = minor change (translator should be able to see difference and decide whether to reword or not)
2 = major change (translation is considered stale and needs update)
So I've designed the tables and MultiLang API to be very abstract and totally separate from LiveJournal and BML. lj-bml-init.pl will register plugins so MultiLang knows about new domain types: like journals and the FAQ (which have special publishing logic). The BML support will work the opposite.... the MultiLang tables keep track of when a domain+language pair is last updated, and a new bmlp.cfg option exists named "MultiLangRefreshInterval" which checks every n seconds if a language is updated, and if so, pulls ONLY the new translations and saves them on disk in a DBM file, which is tied to a hash, which the _ML tags access. Scoping is as such: (_ML foo _ML) is file-local (internally, filename and delimiter prepended) and (_ML [scope].foo _ML) specifies the scope, or global if no scope.
Much ramble, but the point is that all parts of the site should be translatable, and it should be easy (consistent) for translators.
Yet, I don't want to force this interface on everybody, so editing news entries will still be possible with the client, and as such with editing the FAQ with the /admin/ interface, but those will call MultiLang functions which touch the translation so translators can see the difference. (I'll modify the pages to let users specify level)
All this requires UTF-8, which Avva just sent me the last part of. So I'll work on final testing of that soon here, then translation project can go full speed.
The end.