2011/3/22 Gerard Meijssen gerard.meijssen@gmail.com:
The notion that it has to be MediaWiki core and or its extensions first is absurd when you consider that it is what we use to run one of the biggest websites of the world. We rely on the continued support for our production process. The daily process provided by LocalisationUpdate is such a production process. When the continuity of production processes is not a prime priority, something is fundamentally wrong.
There seems to be this misconception with the TranslateWiki people that using Git automatically means that integrating localization updates will somehow be more difficult. This is not the case. In fact, it won't even be appreciably different from the way we currently handle localization updates in SVN.
While Git *supports* the workflow of pushing freshly written code to some branch and merging it into trunk after it has been reviewed, it does not *require* it. It's trivial to set things up so that TWN can commit and push their localization updates directly into trunk, without a need for review or merging or whatever. Having LocalisationUpdate continue to pull those updates from trunk and apply them to the live site is equally trivial.
The only thing that may be different, depending on what our workflow ends up being, is that messages that have been added in some branch that hasn't been merged to trunk yet will not automatically be picked up by TWN for translation. This is technically already the case, but branches aren't very common at this time and will likely become more common with Git. If we end up with a first-review-then-merge-to-trunk workflow, messages wouldn't be available for translation on TWN until after the commits that introduced them have been reviewed and merged to trunk, so TWN will be behind the curve a little bit. But I'm not convinced that's necessarily bad: it'll hopefully prevent poorly organized or poorly translatable messages from making their way into trunk, thereby making sure translators never even see those.
Roan Kattouw (Catrope)