On 9 October 2011 22:33, Niklas Laxström niklas.laxstrom@gmail.com wrote:
On 9 October 2011 21:52, Daniel Friesen lists@nadir-seen-fire.com wrote:
On 11-10-09 11:20 AM, Platonides wrote:
What I've been thinking isn't so much putting translations in another repo, or even TWN doing any commits anywhere at all. Frankly the whole idea of TWN reading and writing .php files has felt completely messed up to me anyways. Sure our canonical message forms can be in .php, but having the semi-automated system we use to translate to every other language we support output php files feels like a relic of a time before it existed and a band-aid hack just to make it possible for TWN to do translations back then.
Huge +1. I would sincerely welcome a move away from PHP-based i18n files. Having data in executable format is just stupid imho.
I don't really see how changing the format is going to have any impact by itself. Whether PHP, XML, a hand-rolled data format or anything else, it still doesn't play nicely with version control. Fundamentally we want to make changes to content in a version-controlled project, and we want everyone to have the latest versions of those changes; but we don't want the version history *of the i18n content* mixed in with the version history of the rest of the project. The solution to that issue is obvious and has nothing to do with the file format: if you don't want your changes showing up in the version history of your repository, make your changes outside the repository!
I'd like to make TWN the proper source for all the translations. Rather than TWN spitting out php for non-en, we have a proper generated output format for translations, and MediaWiki uses that instead of .php for our translations. Instead of TWN having to make this a commit somewhere, I think we should pull those translations right from TWN once we need them.
I'm not sure I want to add that burden to TWN right now. It's just single vserver with no uptime guarantees. I'm not opposed to the idea though - having efficient l10n update in the core, enabled by default, providing always up-to-date translations and perhaps also loading new languages on demand[1] would soo awesome. But like I said, that would need some serious effort to code and to make stable and secure content distribution channel. Any volunteers? :)
This would seem something of a slap in the face to anyone running an 'unplugged' wiki (on an intranet or low-connectivity area); *especially* one using a language other than English. I doubt this would play very happily with the Foundation's vision of bringing offline content to, for instance, rural Africa. Not all MediaWiki installations run on a webserver permanently hooked into the internet; some of them run from a USB stick plugged into an OLOC laptop in the middle of the middle of nowhere.
--HM