On 9 October 2011 22:33, Niklas Laxström <[email protected]> wrote:
> On 9 October 2011 21:52, Daniel Friesen <[email protected]> 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 _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
