On 10.10.2011, 2:04 Daniel wrote:
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).
If you can't trust your on-the-fly .php downloads, you can't trust localisations in other formats either: we have some messages with full HTML allowed, and default contents for JS messages can be used to screw up the wiki and steal everyone's passwords. Of course, it's less lethal than server-side php execution, but still an unacceptably dangerous attack vector.