On 11-10-09 02:48 PM, Happy Melon wrote: > 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! That IS what we're discussing. We're also discussing how ridiculous it is to be using executable files for our output format. Using .php as our output format means that whatever out-of-band download we use to separate i18n from the repository could be a vector to inject php from. If we drop php and go to some other format, then that part of the issue goes away. Nikerabbit also points out that leaving the repo behind also means we don't have to care about what the output format looks like anymore (likely part of the reason why it's still php).
>> > 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. The foundation's vision has little to do with our development process. Whether i18n is inside our version control or some other place it'll still be inside the release tarballs. And really, OLOC (OLPC?) running full MediaWiki? I thought that plan was zim based or something. > --HM ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
