Development notes/Touhou Patch Center 2.0

Design goals
 So I was going through thpatch.net and the terrible state it's in right now, and it got me thinking about Touhou Patch Center 2.0 and the future thcrap GUI...  And then it hit me.  Those two, the GUI and Touhou Patch Center 2.0, should be *one and the same thing*.  Ultimately, the thcrap GUI should be more than just a configuration tool for patches - it should also provide a development environment to ease the creation of patches.  And Touhou Patch Center is... a development environment to ease the creation of patches.  (or rather, it should be, but currently fails miserably, as Kill-o-matic has been repeatedly pointing out)  How hard will this be for ya?  I have no idea. I have zero experience with writing web apps of any scale, really...  That must be pretty daunting ;~;  So basically I have to write a web app (urgh) that is also able to run off-line, with its output rendered by some browser engine?  And of course, it should feel snappy and responsive.  It Can Run Off-Line?  Sure. The only time this needs to access a remote server is when new patch data is pushed there.  And it needs to support both multi-user (for the "patch server farm" use case on Touhou Patch Center) and single-user (for local patch development) modes...  It'll basically be the server software to Touhou Patch Center, but you can also download it and run a "local server", or even set it up on your own VPS to offer your own Patch Center.  (To help your own group collaborate better, and to foster decentralization) <Toast> So I Don't Need To Use Github? <Nmlgc> That's the point, Toast. :) <Nazeo> Wait what <Nazeo> This would serve to be it's own storage space and streams down that way? <Nazeo> Should I start considering upgrading the space we have? <Nmlgc> That's the main point why we even need this - it replaces both GitHub and MediaWiki with functionality that is actually *useful* for patch creation. <Nmlgc> Nazeo, don't bother. It will use Git and therefore store patches in a more lightweight manner than a MediaWiki MySQL database ever will. <Nazeo> Ah, roger <Nmlgc> ... unless, of course, we don't manage to get this up and running *before* we run out of space on thpatch.net. <Nazeo> Just let me know! <Nmlgc> But right now, we still have ~10 GB left. <Nmlgc> Also, thcrap does not even know there is a wiki. <Nmlgc> And even with every other server, the communication is never bidirectional. <Nmlgc> In fact, that was one of the main design points of the whole files.js system. <Nmlgc> You shouldn't need to set up a specific server software that can "communicate", in the true sense of the word, with thcrap. <Nmlgc> And even Touhou Patch Center 2.0 will still not be that much of a "specific server software".
 * Instead of creating thcrap patch files from wiki pages, we go the other way round: User-friendly, editable representations of the patch data are created on demand from the patch data on the server, and wiki pages are eliminated entirely.
 * Stronger emphasis on editing the actual JSON patch data read by thcrap. In the absence of custom format handlers, an automatically validating JSON editor is the default method of editing.
 * Patches are directly kept in Git repositories on the server side, and all edits act on these:
 * As we don't want one commit per text box (as it is currently the case), edits are automatically pooled (think  after every key press) and committed whenever the editor wishes to do so
 * Every user gets their own thcrap repository.
 * Patches are fully owned by their creators, who can give write access (and administration rights) to other users.
 * Yes, initially, we were precisely against enforcing group hierarchies by default, as thpatch started out in a wiki tradition. However, time has shown that group-controlled repositories are indeed the only sane option. You don't want strangers to mess with your translation - you want them to fork your patch (or to be more correct, create a new patch depending on yours), and merge only what you would consider to be true errors.
 * Should work on both server and client sides:

Features

 * Multiple patch file views (e.g. to compare the original Japanese text with the English translation with the translation into another language)
 * Native dependency and patch stacking support. Only data that truly is unique to a patch is ever committed.
 * <tt>git blame</tt>-style reflection to show the originating patch and commit history for every JSON object in any final, stacked file.

Transition

 * Filter translation content out of the Touhou Patch Center MySQL database, replace every single revision with its scraped patch data, convert that to a Git repository, and spend one week branch-filtering and squashing everything into a concise history.
 * All language translations must designate a project leader to take over their respective patch into their repository. The languages that don't are moved into a <tt>Twitch Plays Pokémon reference - if you got a better idea, go ahead!</tt> repository.
 * <tt>helix</tt> is a special repository: It is publicly writable for all users (just like the original Touhou Patch Center) and any user can take over any patch and become its administrator. Therefore, it will be advertised as "the unmaintained junkyard" on the client side