Been a loooooooong while since I last posted a blog here.

Anyway, it's 2008 and I'm working full time for a year. The sad thing is, I have more free time working full time than I had working three full days a week plus five units a semester at uni.

So with my free time, I've been getting back into the scene, catching up various things (which involve playing Tsukihime a whole year and a bit after it was originally released >_<, and playing Fate/stay night). One of the major things I'm working on, however, is this little fickle thing we call 'QED'.

It's one of those weird acronyms that is out of sync with the words itself. It's an acronym for 'distributed quality enforcement', and also the codename of a fairly exciting tool that I'm developing for mirror moon. In a nutshell, it allows us to streamline the proofing/editing process by quite a lot. I'm estimating that it'll increase the ease of reporting errors in the text, as well as making the grue's (GRand Unifying Editor) job much easier.

Previously, we have tried a variety of different solutions for proofing, including Trac, flyspray and are currently using just a forum thread for it. Trac and flyspray was too complex for what we wanted, but granted, they were full on issue reporting applications. I happened to browse the forums one day and came across the forum thread with a day of UBW's proofing.

What I saw made me cringe: Each proofreader posted a few sentences of the original text that warranted a change and the proposed fix along with a reason (if needed). Then the master proofer (Message) would go through the posts and either agree or disagree with the change, and in the case of one that he can't decide (usually due to a translation styling thing), it goes to the grue (who happens to be TakaJun).

After all THAT, then the grue looks at the thread, decides whether to implement the fix or not, opens up the diff, looks for the line, then changes the line.

Repeat that by at least ten fixes per scene, around twenty scenes per day, then by however many proofers reported that change... it's a lot of boring and time-consuming work.

There are also a few downsides that further slow down the process. The master proofer doesn't easily have access to context (as it's generally the line that needs changing), and he has to go look for it, which further wastes time. Then, the grue might have to scroll all over the place to make sure the same line isn't reported twice, as one might have a better fix than the other.

I considered all this and decided that we needed a custom proofing solution.

So I made one.

QED began development on the 1st of December, coded in Ruby on Rails. It is fairly close to completion; I'm just implementing keyboard support for even faster proofing (thank you, Message, it is really a timesaver ;o).

Each script file counts as a Section, and they have many Blocks (think chunks of text). The Block contains a copy of the original text and all the English lines within that block. Each Line then has Fixes, which are proposed fixes to the original line. Each Fix has a reason and comments.

The proofer's general workflow is now:

1. Proofer sees a problem.
2. Proofer adds a fix.
3. Proofer moves on.
4. Proofer sees another problem, but this time, other proofers have suggested fixes.
5. Proofer can then vote on a fix, optionally comment on why, then continue.

And so on. This is already muchly improved compared to the old method already... no duplication of efforts (apart from more than one person proofing the same thing, but that's what we want).

Lets look at the master proofer workflow:

1. MP sees an unresolved line (marked with an orange number on the left).
2. MP looks at the list of fixes.
3. MP looks at the context, which is above and below the line in question.
4. MP optionally looks at the original text (which is shown by a toggle link).
5. MP makes decision based on intuition and votes.
6. MP clicks a button next to the decided fix.
7. MP moves on.

How much time did we just save there? A lot.

Now, lets look at the grue's workflow, which is really the above, plus this:

1. Grue makes sure everything is resolved by checking the stats at the top part of the page.
2. Grue clicks 'Download Diff', which depending on where he is, sends him a .txt in his chosen encoding or a zip file.

I'm pretty damn sure that saved a shitload of time there.

Plus, when keyboard shortcuts are done, things will be even faster. The whole thing also heavily uses AJAX to streamline the process even more. It also has versioning built in so we can see who made changes to what, and also revert if needed.

We will be using QED for HF, and I'm using it to report various bugs I've found in Fate as I'm playing along. QED also has project support, so we will be using this for future projects as well.

That rant was almost tooooooo long, but I hope you guys enjoyed a sneak peek into what goes on behind the scenes.

• chendo's blog
• Login or register to post comments