In the next few days, some of them may be presenting their debriefings for their individual projects on our development journal; indeed, Edward has started us off strong with his very insightful analysis of what happened over the course of his project. I will be attempting to do something very similar in this five-part series of Mentor’s Debriefings, but with a somewhat different focus. As Edward has led us off quite well, I have chosen to start with his project first.

Theory and Praxis

The target piece that we chose for Edward was 向日の夢, a short visual novel that was released in 2002 by Treasures. At first it seemed like a good fit, as it met the following criteria:

• Engine Familiarity: this piece was based on NScripter, which is a visual novel scripting engine that is intimately familiar to us. All the tools we required to effectively localize this game were already available to us — indeed, we were the ones who had created some of said tools in the past. This made this piece an immediately-attractive target. It should come as no surprise that this was one of the two criteria that I did not end up gravely misjudging.
• Length: this piece’s script weighed in at 15KB, about a fourth of which consisted of scripting commands. In my perspective, this is a very short script — it is one that, at average speed, I could have translated and translated well in no more than an hour. Fortunately, it is true that in the grand scheme of things, a 15KB script is on the rather small side of things. Unfortunately, it turned out that my usage of my own translation speed and accuracy as a metric for those I was a fundamentally bad idea, and that depending on how those 15KB were written, a translator might have a very hard time indeed with them.
• Written Complexity: length aside, during my preapproval read of this script, I found that it had a relatively simple narrative voices that switched off at the beginning of every new chapter of the story. Furthermore, I found that while there was a moderate level of slang and street language in the piece, there was enough context established in the various narrative flows that a beginning translator might have some difficulties, but he should in the end be able to grasp at where, so to speak, the narrator is going. Therefore I initially chose to take a more hands-off approach, to see what he would come up with on his own. This ended up being a complete miscalculation on my part — not only did Edward struggle with many of the words that I had written off as simple, he also ended up having a very difficult time establishing what, exactly, the narrative flows were doing at any given time. As a result, and because I initially refused to intervene deeply, he found himself reading a story that was qualitatively very different from the one that was actually being told.
• Production Value: this visual novel boasts particularly high production value in graphical content, especially for a free amateur visual novel built in 2002. I distinctly recall that this particular criterion drew a lot of attention during the preliminary phases of al|together 2006 — at one point, no fewer than three translators including Edward himself wanted to do this piece. It will probably come as no surprise that this was the other of the two criteria that I did not end up gravely misjudging.
• Lines of Communication: while not a facet of the piece itself, this is still an important criterion to bring up. Edward and I have worked together for two years now, executing project after project successfully. Our lines of communication are strong and open at any time, and of all people he would not feel embarrassed to come to me for help if need be. This gave me confidence that he would ask a lot of questions, and that he would listen intently to what I had to say. And while he did ask a lot of questions — and I gave a lot of answers — there arose some misunderstandings in our discourse that would come back to haunt us in the final days of this project.

What Went Right

• The preproduction phase went very smoothly. Edward did jump right into the script, and asked questions at what I felt were a pretty good clip. The questions he asked were mainly of a technical nature — how does this phrase work, what is this word, what is this extra sound doing here.
• The release engineering phase was both fast and efficient, a product of our long association with each other.
• The final product was well-done, and both the accuracy and the artistry of the translation meet our internal standards.

What Went Wrong

• I severely misjudged Edward’s abilities as a translator, and thus I left him to figure things out when I probably should have not. As a result, there grew to be many inaccuracies in his initial translation that I probably could have helped avoid by checking up on him more regularly.
• This piece was actually a lot more technically difficult than I had thought. It has no less than four different narrators, all of whom use the first-person voice — this in and of itself gives ample reason for a novice translator to become easily confused. Furthermore, while the language used does tend toward the simple, this simplicity is deceptive — there are many subtle contextual clues that, if missed out, could have — and did — lead to disastrously incorrect readings of sentences, paragraphs, and even entire chapters of the work.
• I waited until Edward had a completely translated script before I began looking through it. This resulted in a wastage of about four days that I could have spent looking through and commenting on his translation — and this possibly could have helped us nip many of the above problems in the bud.

Object Lessons

• The mentor needs to take a far more active role in the translator’s work.
• In conjunction with the above, the translator must confer with the mentor far more often than he wishes to. Do not take our silence as approval! It is best to nip problems in the bud before they grow into a script that needs to be entirely retranslated by the mentor two days before the final deadline.
• If you have a mentor, ask questions about everything. This means submitting every single line you translate if that is necessary.
• Err on the side of absolute caution. Submit even lines that you think you have absolutely nailed down for approval.
• The only thing worse than a translator who asks for only a little help is a translator who asks for no help at all.
• Treat the piece as a unified whole, not as individual paragraphs and sentences. Each word only makes sense within its parent sentence. Each sentence only makes sense within its parent paragraph. Each paragraph only makes sense within its parent chapter. Each chapter only makes sense within its parent work. If you, as a translator, ignore this at any point in time, you have already failed.
• If you do not understand the comment blocks the original author has written, translate them first, before anything else. This will give you much-needed insight as to what the author was thinking, and how the author chose to organize his or her script.
• As a translator, it is not your duty to write the piece that you think the author should have written. It is your duty to translate the piece that the author actually wrote. This means making sure that you have as close a bond — direct or indirect — to the author as you can. Read the original words. Contact the original author if you can. Try as best you can to understand not only what the author did write, but the way that the author would write if he were a native speaker of English.

Conclusion

Was this project worth it? From my perspective, it most definitely was. Both Edward and I learned a lot, I think, about both the nature of translation and the nature of mentorship. And while it was not always a pleasant experience, it was interesting work, and our final localization stands on its own merits. Should Edward attempt another localization in the future, I would be honored to serve as his mentor again, and we will most certainly remember the insights and the hard lessons we have been taught by this project.

During the month of the festival, I kept a brief log of my progress, so I thought this might be interesting to post, to show what goes on behind the scenes of the game translation process. As well, it’s worth discussing some of the lessons learned from all this.

Mukou no Yume schedule

7/18: Preflight check. Got Mukou running happily in ONScripter via redirecting filenames to data/ with a search-and-replace and pulling out the cursor0.bmp. Identified graphics needing translation and set them aside.

7/19: Day 1 of read-through. Hit line 43/276 of actual Japanese lines. Imported com01-07 to Photoshop for later (dead simple) editing.

7/20: Day 2 of read-through. Hit line 74/276 (+31 for the day). Also worked on [insani project] today, so not a full day of translation.

7/21: Day 3 of read-through. Hit line 112/276 (+38 for the day). Some [insani project] as well. Seem to be averaging about one gp32 question per 20 lines or so.

7/22: Day 4 of read-through. Hit line 155/276 (+43 for the day). Fewer questions today and a decent pace, with a couple of good working periods through the day. Past the halfway point.

7/23: Day 5 of read-through. Hit line 186/276 (+31 for the day), and fiddled with the title graphic a bit. Also worked on True Tears some but generally wasn’t too into translation.

7/24: Took a break from Mukou. Worked on True Tears a bit, but the day was mostly a waste.

7/25: Mukou break continues, with some more serious True Tears effort.

7/26: Mukou break continues, but finished True Tears graphics and went to QC release on it.

7/27: Day 6 of read-through. Hit line 209/276 (+23 for the day). Main effort for the day was a sekai entry, though.

7/28: Day 7 of read-through. Hit line 276/276 (+67 for the day), finishing the initial pass after being trapped on campus by storms until late. Script up from 19K original to 68K including romaji and annotations.

7/29: Took a break from Mukou to QC True Tears.

7/30: Mukou break continues, but finished up True Tears QC and graphic revisions, and pushed out the release.

7/31: Took a break from everything, feeling wiped from staying up to 4:00am to finish True Tears.

8/1: Break from everything continues, with a full day at SIGGRAPH.

8/2: Day 1 of translation. Did a half-hearted attempt at 20 lines or so, but couldn’t get a good sense of tone or level of literalness versus colloquialness required, so work mostly redone the next day.

8/3: Day 2 of translation. Real translation pass begins, actually inserting English into playable script. Up to line 26/276.

8/4: Day 3 of translation. Up to line 52/276 (+26 for the day). Pace is a bit slower than I’d like, mainly due to lack of huge working periods. T minus 2 weeks.

8/5: Took a break from Mukou, although I did glance at the next section a bit. Main task for the day was [non-insani project].

8/6: Break continues. Main task of the day was moving preparations.

8/7: Break continues. More moving stuff.

8/8: Break continues. Moving stuff, car repair, [non-insani project].

8/9: Day 4 of translation. Up to line 64/276 (+12 for the day).

8/10: Day 5 of translation. Up to line 75/276 (+11 for the day). My translation pace is really starting to suck.

8/11: Nada, back to moving preparations and phone tag. Gotta get a ton done this weekend when I know nobody will be calling me. T minus 1 week.

8/12: Day 6 of translation. Up to line 118/276 (+43 for the day). Good pace, and got through some tricky passages.

8/13: Day 7 of translation. Up to line 136/276 (+18 for the day). Spent a lot of time in moving crap. Lack of progress is getting critical. Also did QC for At Summer’s End.

8/14: Day 8 of translation. Up to line 178/276 (+42 for the day). Two decent working periods, plus a full round of moving chores: busy day.

8/15: Day 9 of translation. Up to line 216/276 (+38 for the day). Got an early start and did 25 lines before lunch, but did moving junk in the afternoon, and the evening was killed with [non-insani project], as well as QC on OMGWTFOTL and Adagio. Really busy day.

8/16: Day 10 of translation. Finished translation pass at line 276/276 (+60 for the day). Script up to 90K from 19K original. Did some minor wording cleanups and then handed off to gp32 for critique. Edited the ending credit graphics, and the title graphic too. Attempted to email RAIL for official permission, but both his known addresses bounced, so giving up on that. T minus 2 days, and probably in good shape.

8/17: Day 1 of post-production. Did OS X custom icons. Corrected some pagination and script problems, as well as tweaks to ending credits. gp32 begins editing and retranslates a significant fraction of the text due to some large contextual blunders on my part. Translated the Readme file and handed it off to gp32 for editing.

8/18: Day 2 of post-production. Final editing pass of gp32’s new script, mainly fixing punctuation style and pagination/centering issues. QC build of full OS X installer. Readme revised by gp32. Some minor tweaks, then tri-platform builds. QC of Panda Samurai. RELEASE!

Analysis

I estimate that I spent somewhere around 80 hours on this game throughout the month of the festival — though only 20 working days — averaging about 5-10 lines/hour for each of two translation passes, plus time spent in miscellaneous graphics work, editing, and release engineering. This is the rate of someone who has awful Japanese skills, by the way. Note that gp32 essentially redid the same amount of work in one evening during his translation review.

Lesson one: a good translator is not just 25% faster, or has 15% fewer errors than a poor translator. A good translator is orders of magnitude faster and produces qualitatively better work.

My translation of the game was riddled with small errors, of course. What I didn’t expect, however, was the gaping contextual holes… I had misread entire passages as referring to different characters completely, got confused on who said what line, and messed up the passage of time horribly. It is not an exaggeration to say that the translation I initially produced is a qualitatively different game than the one which was originally written and eventually released.

Lesson two: if you have the opportunity, get a better translator to give you a quick synopsis of the game before you start work. A bad hypothesis about, say, who the narrator actually is during a given passage will warp your interpretation down to the grammatical level and produce a lot of confusion. Note that Japanese depends a lot on comparatively subtle contextual clues to make up for the lack of explicit pronouns, and a novice translator may not pick up on them properly.

However, visual novels have some extra elements that can help a lot, specifically the audiovisual information in the game. Is the script ambiguous about whether a character is male or female? Look at their picture! Are you unclear whether a scene change has taken place or not? Listen to the background music!

Lesson three: don’t just work from the script, treat the entire game as a whole as your translation source. I, unfortunately, failed to do this in a number of cases… I played the game initially, then almost ignored it again until I was ready to test my translated script. Bad idea. The first playthough showed me a number of “Oh of course” revelations, and there were more to pick up on if I’d been attentive enough.

Was all of this worthwhile? I’m not sure… the resulting release certainly is, and I hope people will enjoy playing it. But I don’t think I learned as much as I thought I would about translation: the number of errors was just too great for me to be able to discuss, correct, and learn from each one. In that sense I bit off more than I could actually chew for al|together this year, I think.

Moreover, you need to be able to recognize the common algorithms just from their compressed data alone, so when you’re staring at hex dumps, you will know how to proceed. In today’s installment, we’ll go through some of the most popular formats, how they work, and how you can recognize them “in the wild”.

First of all, note that this task is in theory quite hard. The ideal compression algorithm produces data that is essentially indistinguishable from random noise (which counterintuitively contains the highest density of information). Fortunately, games have two additional requirements: to be able to access data quickly, and to be programmed by normal coders as opposed to Ph.D. computer scientists.

Both of these requirements means games typically use either industry-standard formats or relatively simple, quick algorithms that anyone can code from a book. The former often include extra identifying information we can spot, and the latter compress data poorly enough that it looks like “compressed data” instead of looking like random noise.

zlib

Let’s start with the industry standard, zlib. This is an open-source compression library which implements the classic ‘deflate’ algorithm used in .zip and .gz files. It’s pretty fast and pretty decent, and since it’s already written and completely free, it gets used all over the place, including in game archives.

How can you recognize it? 0×78 0×9C. The first two bytes of a standard zlib-compressed chunk of data will be those two bytes, which specify the default settings of the algorithm (’deflate’ with 32KB buffer, default compression level). Alternately, you will often see 0×78 0xDA, which is the same except using the maximum compression level. If you see those two bytes at the start of where you expect a file to be, rejoice, since you’ve just solved a big mystery with next to zero effort.

Decoding this format is also pretty easy, since virtually every modern language will have a zlib library for it. In C, you want to just link against libz and call:

#include <zlib.h>
uncompress(new_buffer, &new_size, comp_buffer, comp_size);

Be sure to allocate enough memory for your expanded data: hopefully the archive index will have already provided you with the original file size. The function will return a status code and additionally update new_size with the amount of data that was uncompressed.

In Python, dealing with zlib is just embarrassingly easy:

new_data = comp_data.decode('zlib')

One of the built-in string-encoding methods (like ASCII, UTF8, Shift-JIS, etc.) is just zlib encoding, so if you have your data as a string you can just expand it like that. Alternately you can import zlib and use more direct function calls for extra control.

Compressing data is just as easy, with the compress() function in C — or compress2() if you want to specify the compression level — and the encode(’zlib’) string method in Python (or zlib library calls).

I don’t want to say much about the inner workings of the deflate algorithm, since that really doesn’t come up very often: you can safely treat it like a black box. However, there is one extra facet I’ve run across: the Adler32 checksum. This is a very simple 32-bit checksum algorithm (like CRC32) which is included in the zlib library, and therefore gets also used by games a bit. Additionally, the zlib format specifies that an Adler checksum is appended to the end of a compressed file for error-checking purposes.

However, some games twist their zlib implementation slightly by either leaving off the checksum (in favor of using their own elsewhere in the archive) or moving it into the archive index instead. This will cause the zlib uncompress call to return an error, even though it actually uncompressed the data successfully.

So, a word to the wise: if you’re sure that the game is using zlib but you keep getting errors when you try to expand the data, look for this case. You may have to do a little twiddling of the compressed data to add the expected checksum at the end, or just ignore the zlib error codes and continue as normal.

Run-length compression

This is the simplest kind of home-grown compression you’re likely to run across. It shows up in image compression a lot, sometimes as part of a larger sequence of processing. Basically the idea is to start with a sequence of bytes and chunk them up whenever you run across a repeated value:

  31 92 24 24 24 24 24 C5 00 00
= 31 92 5*24 C5 2*00

Exactly how you represent the chunked-up data varies a bit from algorithm to algorithm, depending on what you expect the sequences to look like.

Escape byte. You might designate a byte, say 0xFF as a flag for designating a run of repeated bytes, and follow it by a count and a value. So the above data would be:

  31 92 FF 05 24 C5 FF 02 00
= 31 92 5*24 C5 2*00

If the flag byte actually appears in your data, you have to unescape it by, say, having a length of 0 in the next byte.

Repeated bytes. Here you just start running through your data normally, and whenever you have two bytes in a row that are the same, you replace all the rest of them (the third and thereafter) with a count byte:

  31 92 24 24 03 C5 00 00 00
= 31 92 24 24 3*24 C5 00 00 0*00

If you don’t have a third repeated value, you’ll need to waste a byte to give a count of 0.

Alternating types. Here you assume that your data alternates between runs of raw values and runs of repeated bytes, and prepend length counts to each type:

  02 31 92 05 24 01 C5 02 00
= 2 (31 92), 5*24, 1 (C5), 2*00

Naturally, if you have two repeated runs in a row, you’ll have to waste a byte to insert a 0-length raw sequence between them. A special case of this I’ve run across is when you expect to have long runs of zero in particular instead of any random byte, so you just alternate between runs of zeroes (with just a bare count value) and runs of raw data.

Note, of course, that there is some subtlety which can be involved depending on the variant you run across. For instance, it’s often the case that pairs of bytes aren’t efficient to encode, so they’re just treated as raw data. Also, rather than giving lengths themselves, sometimes you encode, say, length-3, if length values of 0, 1, and 2 aren’t ever needed. In some cases you might also run across multi-byte length values (controlled, say, by the high bit in the first length byte).

For images, you may have pixels instead of bytes which are the fundamental unit of repetition. In that case, even two RGB pixels in a row which are the same can be successfully compressed.

In any event, how do you recognize this format? The general principle is that all of these variations have to fall back on including raw bytes in the file a lot, so you want to try to look for those identifiable sequences (RGB triplets in image formats are good to key off of) interspersed with control codes. It’s often helpful to have an uncompressed version of an image to compare against, which you can recover from a screenshot or from snooping the game’s memory in a debugger (a topic for later articles).

LZSS

One step up from run-length encoding is to be able to do something useful with whole sequences of data that are repeated instead of single bytes. Here, the algorithm keeps track of the data it’s already seen, and if some chunk is repeated, it just encodes a back-reference to that section of the file instead:

  I love compression.  This is compressed!
= I love compression.  This [is ][compress]ed!
= I love compression.  This [3,-3][8,-22]ed!

The bracketed sections indicate runs of characters that have been seen before, so you just give a length and a backwards offset for where to copy them from. A lot of compression algorithms, zlib included, are based on this general principle, but one version that seems to crop up a lot is LZSS.

The special feature of this format is how it controls switching between raw bytes and back-references. It uses one bit in a control byte to determine this, often a 1 for a raw byte and a 0 for a back-reference sequence. So one control byte will determine the interpretation of the next 8 pieces:

  I love compression.  This [3,-3][8,-22]ed!
= FF "I love c" FF "ompressi" FF "on.  Thi" 73 "s " 03 03 08 16 "ed!"

The 0xFF control bytes just say “8 raw bytes follow”, and the 0×73 byte is binary 01110011: reading from least-significant bit, that’s 2 raw bytes, 2 back-references, and then 3 raw bytes.

Recognizing this format in the wild rests on the control bytes, and you can spot it most easily in script files. If you see text which looks liFFke this,FF with reFFadable tFFext plus some junk characters in every 9th byte, you’re dealing with LZSS. You can also spot this in image formats, since the natural rhythm of RGB triplets will get interrupted by the control bytes.

Note that the farther in the file you go, the harder this gets to recognize, since the proportion of back-references tends to climb once the algorithm has a larger dictionary of previously-seen data to draw upon.

The major hassle with this format is the nature of the back-references. There are a lot of subtle variants of this. One of the most popular ones uses a 4096-byte sliding window, and encodes back-references as a 12-bit offset in the window and a 4-bit length. However, is the length the real length or length-3? Is the offset relative to the current position, or is it an array offset in a separate 4096-byte ring buffer? Is the control byte read most- or least-significant bit first? I’ve even run across an example where there were several different back-reference formats: a 1-byte one for short runs in a small window, a 2-byte one for medium-length runs in a decent window, and a 3-byte one for large runs over a huge window. You will just need to experiment a little bit to see exactly what the particular game is doing, unfortunately.

One subtle point is that you may be allowed to specify a back-reference which overlaps with data you haven’t seen yet. By that I mean a length larger than the negative offset involved:

  This is freeeeeeeaky!
= This [is ]fre[eeeeee]aky!
= This [3,-3]fre[6,-1]aky!

The [6,-1] back-reference works because you are copying the bytes one at a time: first you copy the second ‘e’ from the first, and now you can copy the third ‘e’ from the second, etc. Be aware of this subtlety when you implement your own algorithms, since (a) this can preclude you from doing certain types of memory copying or string slicing, (b) not all games will be able to understand this type of reference, so don’t encode that way unless you know yours can.

Huffman encoding

From one point of view, this is easier than other algorithms since it only works on single bytes (or symbols, in general) at a time, but it’s also more tricky since the compressed data is a bitstream rather than being easy-to-digest bytes and control codes.

It works by figuring out the frequencies of all the bytes in a file, and encoding the more common ones with fewer than 8 bits, and the less common ones with more than 8, so you end up with a smaller file on average. This is very closely related to concepts of entropy, since each symbol generally gets encoded with a number of bits equal to its own entropy (as determined by its frequency).

Let’s be specific. Consider the string “abracadabra”. The letter breakdown is:

a : 5/11  ~ 1.14 bits
b : 2/11  ~ 2.46 bits
c : 1/11  ~ 3.46 bits
d : 1/11  ~ 3.46 bits
r : 2/11  ~ 2.46 bits

Where I’ve given the number of bits of entropy each frequency corresponds to (i.e. if you have a 25% chance of having a certain letter, it has a 2-bit entropy since you need to give one of 4 values, say 00, to specify it out of the other 75% of possibilities: 01, 10, 11). Unfortunately we can’t use fractional bits, so we may have to round up or down from these theoretical values.

How do we choose the right codes? Well, the best way is to build up a tree, starting from the least-likely values. That is, we treat, say, “c or d” as a single symbol with a frequency of 2/11, and say that if we get that far we know we can just spend one extra bit to figure out whether we mean c or d:

a : 5
0=c + 1=d : 2
b : 2
r : 2

Then we continue doing the same thing. At each step we combine the two least-weight items together, adding one bit to the front of their codes as we go. In the case of ties, we pick the ones with shorter already-assigned codes, or alphabetically first values:

a : 5
0=b + 1=r : 4
0=c + 1=d : 2

00=b + 01=r + 10=c + 11=d : 6
a : 5

000=b + 001=r + 010=c + 011=d + 1=a : 11

So the codes we end up with are:

a : 1
b : 000
c : 010
d : 011
r : 001

You will notice an excellent property of these codes: they are not ambiguous. That is, you don’t have 1 for ‘a’ and 100 for ‘b’… as soon as you hit that first 1, you know you can stop and go on to the next symbol without needing to read any more. Therefore, “abracadabra” just gets encoded as:

a  b   r  a  c  a  d  a  b   r  a
1 000 001 1 010 1 011 1 000 001 1
= 10000011 01010111 00000110
=    83       57       06

We’ve compressed 88 bits (11 bytes) down to 23 bits (just under 3 bytes). Almost always the bits are packed most- to least-significant in a byte.

One subtlety is the exact method of tree creation, which assigns the codes. The method described above is “canonical”, but sometimes games will use their own idiosynchratic methods which you will have to match exactly to avoid getting garbage.

How do you recognize this in a data file? Well, the decompressor needs to know the codes, and the easiest way to specify this is to give it the frequencies (or more easily, the bit weights) of the values so it can construct its own tree.

Therefore, the compressed data will usually start with, say, a 256-element table of bit weights. So if you see 256 bytes of 05 06 08 07 0C 0B 06 — values that are around 8 plus or minus a few — followed by horrendous random junk, you’re probably looking at Huffman encoding.

Sometimes instead of bit weights you’ll have the actual frequency counts instead, which might need to have a multi-byte encoding scheme if they’re above 256. In that case, you’re mainly looking for a few hundred bytes of “stuff” followed by a sharp transition to much more random data.

Other algorithms

Needless to say, the algorithms covered here are not the full range of compression formats out there. I’ll just briefly mention some others in case you run across them, though I haven’t really seen them in the wild.

Arithmetic encoding. This is vaguely related to Huffman encoding, in that you are working strictly with single bytes (or symbols) and trying to stuff the most frequent ones into fewer bits. However, instead of being restricted to an integral number of bits for each one, here you are allowed to be fractional on average.

This works by breaking up the numerical interval [0,1) into subranges corresponding to each symbol: the more common symbols correspond to larger ranges, in proportion to their frequency. You start with [0,1), and the first byte resticts you to the subrange for that symbol. Then the second byte restricts you to a sub-subrange, the third byte a sub-sub-range, etc. Your final encoded data is any single numerical value inside the tiny range you end up in: just pick the number in that range you can represent in the least number of bits as a binary fractional value.

Needless to say there are some good tricks for implementing this without using ludicrously-high-precision math, but I won’t go into that.

LZ77 (Lempel-Ziv ’77)

This is the core of the zlib deflate algorithm, but you’ll sometimes see variants outside of that standard, so it’s useful to know a little about. It’s basically a combination of standard back-references as in LZSS, plus Huffman encoding. You just treat the back-reference command “copy 8 bytes” as a special symbol, like a byte value of 256+8=264.

Then, with this mix of raw data bytes and back-reference symbols, you run it through a Huffman encoding to get the final compressed output. Typically you will do something different with the back-reference offsets: either leave them as raw data, or encode them in their own separate Huffman table.

LZW (Lempel-Ziv-Welch)

When taught correctly, this is an algorithm with a mind-blowing twist at the end. As it runs through the file, it builds up an incremental dictionary of previously-seen strings and outputs codes corresponding to the dictionary entries. And then, at the end, when you start to wonder how to encode this big dictionary so the decompressor can use it to make sense of the codes, you just throw the dictionary away. Cute.

Of course it turns out that things are cleverly designed so that the decompressor can build up an identical dictionary as it goes along, so there’s no problem. This algorithm was patent-encumbered for a while, so it didn’t get as widely adopted as it might otherwise have been, but you might start seeing more of it these days.

Conclusion

I’ve focused here on lossless general-purpose compression: the sorts of things that are done to data at the archive level. There is also a stage below this, where data can be compressed before even being put into the archive: making raw images into JPEGs, PNGs, or other compressed image formats, and converting sounds to MP3s, OGGs, and so forth. In many cases those compression steps are just a lossy approximation to the original data, which is okay for graphics and sounds but bad for other files.

In a later installment, I’ll be tackling image formats in particular in more detail, since you will tend to run across custom ones a lot, some of which include image-specific processing steps (like, say, subtracting pixels from their neighbors) which wouldn’t make a lot of sense in a more general-purpose compression algorithm. Encryption is another later topic, since sometimes that will keep you from being able to recognize compressed data for what it is.

And naturally, if you’ve run across other general compression algorithms used in games you’ve looked at, please mention them in the comments, since I don’t pretend to have investigated all the games out there… I’m still being surprised all the time.

So today we’re going to run through some quick code prototyping to create some suitable tools for dealing with the archives. My intention is to make this as simple and straightforward as possible, so if you come out of this installment saying, “You mean that’s all I have to write to hack a game?!” then… mission accomplished.

What language should we use? Ordinarily I work in C, but I want to get something out of this series too, so instead we’re going to use Python, which is a bit of a learning experience for me as well. The main advantages of this are:

• Cross-platform. It’s available for Windows, Linux, and Mac OS, and it unifies some inherent differences like directory-path separators.
• Good mix of levels. There are flexible high-level data structures, like hash-table dictionaries and function continuations, as well as decent low-level bit manipulations.
• Intuitive syntax. Python is almost like executable pseudocode, so if you know virtually any other language, you should be able to read it without trouble.
• Interactive mode. If you want to, you can just type in commands one by one and have them execute immediately. This is great for avoiding a slow edit-recompile-test step during prototyping.

The main disadvantage, unfortunately, is speed. Python just can’t compare to C or other to-the-metal compiled languages for serious bit-crunching. For our purposes this isn’t very important yet, and when it becomes an issue there’s actually some pretty good Python/C interface features available for us to mix and match code when we need to.

So, if you’re on Mac OS X, you probably have Python already. If you’re on Linux, you either have it or can grab a package for your distribution without much trouble. If you’re on Windows, there’s an installer for you too. Grab a copy and follow along!

What sorts of routines will we need to get started? Well, let’s review the archive format we determined last time:

1. Signature string PackOnly
2. 56 bytes of zeroes
3. 8-byte little-endian file count
4. 144-byte file entry records consisting of:
   1. 128-byte filename, zero-terminated
   2. 8-byte little-endian file offset (from beginning of archive)
   3. 8-byte little-endian file size
5. The files, uncompressed and unencrypted, at their offsets.

So it looks like we’ll need routines to:

• Read/write integers of specific lengths and endianness
• Read/write zero-terminated strings
• Check signatures and known runs of zeroes

No sweat! These sorts of utility routines will come in handy from here on out, so once we write them we can use them for subsequent games as well. Let’s attack the integers for example:

def read_unsigned(infile, size = 4, endian = LITTLE_ENDIAN) :
   result = long(0)
   for i in xrange(size) :
      temp = long(ord(infile.read(1)))
      if endian == LITTLE_ENDIAN :
         result |= (temp << (8*i))
      elif endian == BIG_ENDIAN :
         result = (result << 8) | temp
   return result

Depending on your background, this code snippet is either completely trivial or completely confusing. Basically, it’s just reading one byte at a time from a file, and shifting those bits to the proper numerical value to build up a multi-byte number, depending on whether the bytes are ordered least-significant-digit-first (little endian), or most-significant-digit-first (big endian).

The rest of the stuff we’ll need is similar, and honestly not really worth discussing in detail. I’ve helpfully put together a quick package of utility routines which you can download as insani.py and use if you like.

Now we get on to the meat of the problem, reading and writing the archive!

We can basically just run through our archive specification above and turn it into code. First the signature and header:

from insani import *
arcfile = open('cg.pd','rb')
assert_string(arcfile,'PackOnly',ERROR_ABORT)
assert_zeroes(arcfile,56,ERROR_WARNING)
numfiles = read_unsigned(arcfile,LONG_LENGTH)
print 'Extracting %d files...' % numfiles

Here I’m using the assert_string() and assert_zeroes() utility routines from insani.py to check for the file signature and the zeroes we expect. The LONG_LENGTH constant is just 8, the length of our integer, and little-endianness is implied as the default value.

The major thing to make note of here is error-checking. I don’t mean “normal” error-checking like making sure the file opened properly or that you have enough memory to read an 8-byte integer, etc. That’s kind of silly for a prototype tool: we don’t care a whole lot if it crashes when the file can’t be read, as that’s sort of the behavior we want.

No, I mean, error-checking our assumptions about the archive. You see, we could have just skipped the first 64 bytes of the file entirely and jumped right to that numfiles read statement. That’s the only information we actually need, right? Why are we bothering to check the signature, or check those zeroes?

We’re doing that because we’re still testing our understanding of the file… we’ve only really looked at a small percentage of one archive file from one game. Are those 56 zeroes really useless? Always? We’re just not sure. So if the tool runs across something that it doesn’t expect — i.e. that we don’t expect — then we want to know about it, and either abort for “now I’m totally confused” cases or at least print a warning for less critical discrepancies so we can inspect the situation more carefully and revise the tool.

Okay, enough about that. Just trust me: build in the extra logic to check your assumptions rather than always jumping to the known-important info. Now on to reading the index:

print 'Reading archive index...'
entries = []
for i in xrange(numfiles) :
   filename = read_string(arcfile)
   assert_zeroes(arcfile,128-len(filename)-1)
   position = read_unsigned(arcfile,LONG_LENGTH)
   size = read_unsigned(arcfile,LONG_LENGTH)
   entries.append( (filename, position, size) )
assert_zeroes(arcfile,144*(16384-numfiles),ERROR_WARNING)

Here we’re using some Python magic to make our lives easier. After reading the filename, position, and size, we just collect the three variables together into a “tuple” denoted by the extra parentheses, and push that onto the end of our entries linked list. Doing the same thing in C would be a bit more complicated, but here it’s almost pseudocode. Again, notice the assertion statements: every single byte of this file is getting examined, and either its data is being used or its status as uninteresting is being checked.

Now, we complete the process, and actually write out the files, and do a little clean-up:

for (filename, position, size) in entries :
   print 'Extracting %s (%d bytes) from offset 0x%X' % \
    (filename, size, position)
   outfile=open(filename,'wb')
   assert (arcfile.tell() == position)
   outfile.write( arcfile.read(size) )
   outfile.close()
assert (arcfile.read(1) == '')
arcfile.close()

The loop structure is another nice bit of Python: we can just iterate through our entries list trivially, pulling off a whole tuple at a time and using those variables again. Instead of the assert statement, we could have just done a arcfile.seek(position) command to jump to the offset we know we want, but here we’re still testing our knowledge of the archive format: are the files stored in order, with no gaps between them like we think? And after all the files, are we really at the end of the archive, or is there more data we’ve neglected?

If we’ve done everything correctly, there shouldn’t be any surprises. So let’s try it. You can download crosschannel-extract1.py if you like, but I’d recommend you implement your own, or at least type it in to get a feel for the language:

% python crosschannel-extract1.py
Extracting 545 files...
Reading archive index...
Extracting bgcc0000e.png (8370 bytes) from offset 0x240048
Extracting bgcc0023.png (538382 bytes) from offset 0x2420FA
...
Extracting TCYM0005c.png (156881 bytes) from offset 0x566E1B4

Seems to have worked, and all of the PNG files are viewable in your favorite image editor. Ummm, although a few of them are NSFW, by the way. ^^;

The proof-of-concept extraction works. Now we can improve things just a little bit, since that hard-coded archive filename certainly sucks. The revised version is crosschannel-extract2.py, which adds some routines from the Python operating-system interface libraries to read parameters from the command line and allow us to extract files to a new subdirectory, etc. I’ve also tweaked the error-checking a little bit, to allow for out-of-order files if we ever run across them, as well as aborting early if we find a position or file size that is “obviously” wrong. Have a look if you like, though it’s not really vital to the thrust of this article.

What we really should be doing is rebuilding the archive now! No sweat. We can just take our code, and adapt it pretty easily to the opposite case. First we need to collect info about the files we want to repack, from a subdirectory name passed on the command line:

import sys, os
from insani import *

dirname = sys.argv[1]
rawnames = os.listdir(dirname)

numfiles = 0
position = 144*16384+72
entries = []
for filename in rawnames :
   fullpath = os.path.join(dirname,filename)
   if os.path.isfile(fullpath) :  # Skip any subdirectories
      numfiles += 1
      size = os.stat(fullpath).st_size
      entries.append( (filename, fullpath, position, size) )
      position += size;

While we do this we can compute the ultimate position of each file based on the file sizes and the known sizes of the header and the index. Next we can write those out:

print 'Packing %d files...' % numfiles
arcfile = open(sys.argv[2],'wb')
arcfile.write('PackOnly')
write_zeroes(arcfile,56)
write_unsigned(arcfile,numfiles,LONG_LENGTH)

print 'Writing archive index...'
for (filename, fullpath, position, size) in entries :
   write_string(arcfile,filename)
   write_zeroes(arcfile,128-len(filename)-1)
   write_unsigned(arcfile,position,LONG_LENGTH)
   write_unsigned(arcfile,size,LONG_LENGTH)
write_zeroes(arcfile,144*(16384-numfiles))

This is actually kind of easier, since we don’t need to check anything: we are just writing exactly what we know… no uncertainty. You’ll also notice how closely the structure maps to our initial archive description: it’s good to have utility routines so that you can take care of each item in your spec with just a line or two of code. And now we write the files themselves:

for (filename, fullpath, position, size) in entries :
   print 'Packing %s (%d bytes) at offset 0x%X' % \
    (filename, size, position)
   assert (arcfile.tell() == position)
   infile = open(fullpath,'rb')
   arcfile.write(infile.read(size))
   infile.close()
arcfile.close()

Here we’re doing a little bit of sanity-checking with the assert statement, but really that’s just a “stupid programmer” check rather than anything else: if we’ve written everything correctly, that assertion will always be true, regardless of the archive format details. That’s one of the classic uses of an abort-if-false assert statement: to quickly check something which cannot possibly be wrong when the program is operating correctly.

You can grab crosschannel-repack1.py if you like, but again I’d encourage you to write your own. Let’s test:

% python crosschannel-repack1.py temp temp.pd
Packing 545 files...
Writing archive index...
Packing bgcc0000a.png (408458 bytes) at offset 0x240048
Packing bgcc0000b.png (436171 bytes) at offset 0x2A3BD2
...
Packing xiconp.png (2399 bytes) at offset 0x5693D26

The gold standard of a successful tool is to be able to extract and repack an archive to a bit-perfect replica of the original. Have we succeeded?

% diff cg.pd temp.pd
Binary files cg.pd and temp.pd differ

Urgh, no. Well, it’s kind of to be expected… the files aren’t getting packed in the same order, since our repackaged archive gets its directory list in alphabetical order, whereas the original archive is more random. Does that matter? We’re not sure.

The silver standard of a successful tool is to be able to extract its own archives successfully. So we extract, repack, and then extract again and make sure the first extraction is identical to the second.

% python crosschannel-extract2.py temp.pd temp2
Extracting 545 files...
...
% diff -r temp temp2

And that works. Okay, so our extraction and repacking tools are internally compatible. Are they compatible with the game, though?

Here is one helpful trick of the trade. The first time you test a rebuilt archive, change nothing. Just extract the game’s own archive, repack it, and see if the game still runs. This way you can see whether, for instance, the game has an MD5 checksum for the archive stored in the executable, or whether you’re missing something about the archive format. Once you pass this hurdle, then you can start changing files and inserting English and so forth.

To make a long story short, that works. There thankfully doesn’t seem to be any checksum weirdness going on, or features of the archive we haven’t fully reproduced (the file ordering could have mattered, after all).

The next step is to try altering something. How about the main title screen graphic? That happens to be x0000.png, so we can just drop in our own 640×480 PNG file, rebuild the archive, and see what happens…

The extra colored rectangle is part of the main menu highlighting system. Looks like we’re doing pretty well… most of the UI resources are just stored as PNGs, so our translator and graphic editor ought to be able to make over this game’s interface with these tools, no problem.

But wait… what about the game script!

% python crosschannel_extract2.py script.pd script
Expected "PackOnly" at position 0x0 but saw "PackPlus".
Aborting!
Traceback (most recent call last):
...

PackPlus?! Uh-oh. But now the wisdom of our error-checking is somewhat revealed… we know immediately that something weird is going on in the script archive, rather than extracting garbage and trying to make sense of it at some later step. Let’s fall back on our hex editor and take a look.

Well, it looks pretty normal, actually. All the zeroes are still there; there’s what looks like a file-count, and filenames, positions, and sizes. If you scroll down you’ll see nothing but zeroes out to offset 0×240048, just like before. So the entire header and index is the same, apart from the file signature itself. Is this a complete no-op?

Ah, but look at the files themselves:

This is kind of weird. The bytes aren’t random-looking — there are long strings of constant values — so it’s probably not really compressed or encrypted. There’s also a high proportion of large values, above 0×80, which is unusual.

So we’re probably looking at some sort of basic “encryption” here, the ever-popular XOR/add-with-a-constant-byte algorithm, suitable for protecting your files from your six-year-old sister… assuming she doesn’t code, anyway.

We could just guess the answer… and in fact if you guess you’ll get it right. But you know what, I’m lazy, so I’m just going to brute-force this with some quick code.

arcfile=open('script.pd','rb')
arcfile.seek(0x240076)
data=arcfile.read(16)
outfile=open('bruteforce.dat','wb')
for i in xrange(256) :
   for temp in data :
      outfile.write(chr(ord(temp) ^ i))
   for temp in data :
      outfile.write(chr((ord(temp) + i) & 0x00FF))
outfile.close()
arcfile.close()

I’m just reading in 16 bytes of data (chosen to match my hex-editor width) at an interesting-looking offset, XORing and adding all possible byte values to that string, and writing it out to a file to examine. Scanning through this 8KB file by eye takes like 10 seconds, and we find:

Wow, recognizable text, at the very end of the file… always in the last place you look. So this corresponds to an XOR by 0xFF, or just flipping all the bits in the file, which is precisely what you might have guessed anyway. My point here is really that when you’re not sure, don’t be afraid to do a little experimentation… writing the above code snippet and scanning through some possibilities is the work of 5 minutes, tops, whereas you can easily bang your head against some unknown simple encryption for hours or days if you’re not feeling sufficiently clever sometimes.

Now we can update our extraction tool to account for this. It’s a pretty easy modification to the header code:

signature = arcfile.read(8)
if signature == 'PackOnly' :
   xorbyte = 0
elif signature == 'PackPlus' :
   xorbyte = 0x00FF
else :
   print 'Unknown file signature %s, aborting.' % \
    escape_string(signature)
   sys.exit(0)

and to the file-reading code:

   data = array('B',arcfile.read(size))
   if xorbyte != 0 :
      for i in xrange(len(data)) :
         data[i] ^= xorbyte
   outfile.write(data.tostring())

This part is slightly confusing if you’re not familiar with Python. The standard Python string is an immutable data type, so you can’t just XOR all the bytes without making a zillion new copies of the string. Instead we read it into a mutable unsigned-byte array. You’ll need to add a from array import array line at the top of your file to allow this too, since the array module isn’t part of the core language. The new version is crosschannel-extract3.py.

% python crosschannel-extract3.py script.pd script
Extracting 54 files...
Reading archive index...
Extracting adstart.dsf (236 bytes) from offset 0x240048
Extracting cca0001.dsf (934 bytes) from offset 0x240134
...
Extracting cca0011c.dsf (6674 bytes) from offset 0x297376

Looks like we’re in business. The extracted scripts open normally in a text editor, using Shift-JIS character encoding. With a little snooping around, we can see that the file cca0001.dsf is the start of the main game script. A little editing, a quick repack (we don’t even need to bother with PackPlus when we make our own archive), and presto!

Note that I have skipped over some complexity in that last step, doing things like word-wrapping the line manually and making sure that the game engine gets CR-LF line breaks as opposed to just LF. There’s more weirdness lurking there too… I don’t mean to imply that the script format is trivial, merely that it’s now open to further experimentation beyond the scope of this article.

Where to go from here? As a homework assignment, you should try experimenting with this code, or even better writing your own in your language of choice. And how about those 2.3MB of zeroes in the archive format… will the engine object if you take that out and start file storage right after the index to save space? Can you write a routine which will word-wrap the script automatically when packing it into an archive? How about the kanji in the window title bar? What other problems will you run across in trying to do a full translation of this title?

But for now, this is all that I plan to use Cross+Channel for… we’ve cracked it wide open, and there’s not a huge amount more to learn here. This is a legitimate accomplishment, because this is a real game that’s on the market and that people would like to translate. However, it’s also a very simple example. The archive had no compression and minimal encryption; the graphics files were a standard format; the script files are plaintext; and there was no integrity checking in the game or need to touch the executable at all.

Any or all of these characteristics could have meant a lot of work for us if they went the other way. So, in the next few installments, I’ll be picking other games to give good examples of more complicated situations, focusing on one of these areas at a time. Feel free to suggest games that you would like to see covered, though there’s no guarantee I’ll know anything about them, of course. Heh.

Greetings in haste. I was surprised to see how quickly you responded to my last letter, and I was gratified to see that you were putting many, many thoughts on paper. This is wonderful — you are beginning to develop, no doubt, a sense of your place as a translator, and by some of the often-pointed questions you ask I see that you are beginning to come to your own conclusions about the validity of what you are doing and saying — and also what I am doing and saying. Since you have asked these questions of me, though, let us spend some time talking about the issues they raise.

You did not like the implication of my go analogy, did you? I am not surprised. Why shouldn’t, after all, a translation strive to be better than the piece it is translating? Why should the translation team not strive to “win” every single time, with every single opportunity it gets? These are worthy questions, and it is clear to me that your motivation in asking these questions is because you want your translations to be well-regarded by your audience. That is by no means an ignoble goal — after all, as you yourself state many times over, it seems strange to create a translation that nobody else reads.

Perhaps, then, we should first talk about what “winning” and “losing” mean. We both accept, I am hoping, that at some point there exists no concrete way to measure a translation against the original work. Certainly, one could create some kind of weighting system based on, say, the number of typographical errors present in each work, or along similar lines. But at the core, these systems — while they certainly help, often greatly, in your task of making sure that your translation has as few egregious errors as possible — they do not help us at all in our task of gauging whether a translation lives up to the standards — high or low as they might be — that the original work sets. But we may as well start there, as the case of spelling and typographical errors is a simple one; it does not offer up the significantly thornier issues that we begin to encounter when we speak of “entirely rewriting” a translation, reordering segments and chapters (which some professional translators are known to do — Jay Rubin’s excellent translation of The Wind-Up Bird Chronicle by Haruki Murakami does just that, for instance), or even cutting out segments that existed in the original altogether.

So, is it necessary to try to duplicate misspellings and typographical errors? Here, our duty is clear: if those misspellings were intentional, by all means yes. But if not, then you should consider the following before proceeding:

• Is the misspelling even a misspelling? I have often seen translators who claim that words were misspelled, or kanji were mistyped, when the reality of the situation was quite different. You must avoid this at all costs; therefore, if you find what seems to you to be a misspelling or a typographical error as you are translating, then unless you are 100% sure that it is a misspelling or typographical error that you have found, then it would behoove you to seek counsel from other, preferably more experienced, translators.
• If the word is misspelled, then why? Again, ask yourself if there is any possible way this misspelling could have been intentional. Was the author trying to make some kind of pun? Was he attempting to emphasize a certain character’s level of learning (or lack thereof)? Is there any dialect or regional aphorism that the author was utilizing here? Finally, is your knowledge base sturdy enough that you can definitively answer all of these questions?
• Is this a known misspelling? This question is probably unanswerable in most cases, unless the piece you are translating is sufficiently well-known (unlikely) or unless you have direct access to the original writers (even more unlikely). If one of the above conditions is met, though, your job becomes much easier. There is a line in the doujin visual novel 月姫 that has a very famous typographical error that turns a は into a を; thus rendering a line that should have gone something to the point of “you are the murderer” into something to the point of “you going the murderer” (omission of ‘to be’ intentional) when translated literally. This line, in fact, has even been parodied in an episode of the anime ぱにぽにだっしゅ！ to, no-doubt, hilarious effect. In any case, this would be a case in which our role is clear-cut: don’t try to model that misspelling in translation. It would be fair, and even fun, to provide a translator’s note about that line, explaining that there was such a misspellling in the original. On the other hand, even a casual player of Final Fantasy IV is probably quite aware that the line “you spoony bard” does not appear in any way, shape, or form in the original Japanese. The phrase was, at the time, a product of Nintendo censorship and Ted Wollesley’s own quirks. However, it has since then taken a life of its own, and has found its way into every authorized translation of the work into English since. And can you blame it?
• What exactly is being translated, anyway? As we both well know, most people will write IM’s differently than they would write formal letters. It also goes without saying that a minor typographical error that would be acceptable in an introductory-level college composition course would be entirely unacceptable in a UN resolution or an opinion by the Supreme Court. In other words, there are some situations in which it is most honest to model the misspellings you find, and others in which it is entirely unacceptable. If you ever find yourself in the rather-unenviable position of having to translate a ream of internet forum posts, you may well decide to model every misspelling you find — and I would applaud you for it. But clearly, in most formal or production writing — and visual novel scripts are certainly productions, if not necessarily formal — unintentional misspellings should not be modeled at all.

Is it “winning” against the original to correct a misspelling, though? I would argue that it is most definitely not. It is most certainly a tangible improvement in production value when you correct an unintentional misspelling — but at the same time, you have made no significant change in the various meanings that the original piece conveys. For that matter, should your correction of a misspelling cause a significant change as above, you should be on your guard, and be doubly careful that you did not miss something that the author did deliberately. In all cases of formal writing, going from “teh” to “the” will not make any change in the original meaning of a sentence. However, it is possible — if vanishingly — that going from “an” to “and” might cause some significant change in a sentence, depending on how said sentence is structured. This is when you should be worried; this is when you should double- and triple-check your accuracy.

How about たん, ちゃん, さん, 様, 先生, and all those other honorifics that we have come to know and love? What do we do about those, and how — if at all — do we localize these? This one is an ambiguous issue, as there are indeed official localizations of pieces that include every single honorific intact (many localized manga on the bookshelves of your local bookstore do this), and there are likewise official localizations of pieces that strip every single honorific out (all known localizations of Haruki Murakami’s work do this). I have certainly done translations that fall on both ends of the spectrum — and below I present a rough algorithm (if it can even be called that) that I use when deciding what to do with these fascinating articles of Japanese grammar and culture:

• Start out by assuming that you will strip all the honorifics out. I am well aware that, in the end, you might go the opposite way — but by doing things this way, by assuming that you are going to be taking the harder of the two paths, you force yourself to think longer and harder about each decision you are making. Additionally, it strikes me that it is impossible for a translator to see what a piece would have read like without honorifics if he has not actually attempted to translate the piece without them. So try it! Try your hardest to model the implicated relationships that the honorifics function to indicate. And if you find yourself in an untenable situation, then you’ve just proven to yourself that either (a) you do not have the skill to translate the target piece properly without honorifics, or (b) the honorifics carry some meaning to them that cannot be modeled accurately, and absolutely cannot be done without. You may at this point wish to seek consensus.
• For pieces that utilize high school as their primary setting, there is precedent. Indeed, most pieces of this kind — from To Heart to 天使のいなに１２月 to True Tears to Kanon to … you get the point — heavily feature the use of honorifics to model changing relationships between individuals. For instance, when a girl stops referring to the protagonist as くん and starts referring to him by さん or even without honorific at all, that crystallizes the relationship between the two characters as that of lovers. It is relatively difficult to capture this transition in English, as in Western culture we all generally refer to each other by first name, even when we might not know each other that well. Jay Rubin, in his translation of Haruki Murakami’s Norwegian Wood, makes a valiant attempt to model this without using honorifics by having Midori, a girl that the protagonist meets in college, refer to him by his last name alone at first (where the original had a くん at the end). This does not strike me as the best choice in the world, as in Western culture we usually refer to people we dislike solely by last name. Additionally, it seems even more distant for Midori to call the protagonist “Mr. Watanabe”, although the くん at the end can cary that meaning. I honestly do not know what the best solution would have been in this case, as I have immense respect for Mr. Rubin’s work, and I do not think he would have made this decision without due reason. But my gut tells me that I would probably have used honorifics throughout the piece if I were the one translating it.
• What is the focus of the piece? There are many storylines in which the developing relationships between the characters may be secondary to the rest of the plot. In the case of the doujin visual novels Narcissu and 常世の星空, the characters are indeed strong and interesting, but the focuses are arguably elsewhere — in Narcissu there is the overhanging pall of terminal illness, and in 常世の星空 the relationship between Kouya and Mikoto — while very interesting — has less to do with the way the piece reads than the internal thought processes and ethical frameworks of Kouya himself. This was why, for me, the decision to not use honorifics in these two pieces was an easy one. On the other hand, in the case of the doujin visual novel 夏の日のレザナンス or the commercial ADV 月は東に日は西に 〜Operation Sanctuary〜 the relationships between character are the main — and sole, as some people might put it — points of the pieces. It also helps that both visual novels utilize school as their primary (in the case of はにはに, only) setting. This is why it became relatively easy for me to decide to use honorifics when translating those two pieces.
• End by asking whether the audience will accept the use of honorifics. In the case of manga, where the target audience is very well-defined, the answer is more than likely yes. In the case of more “serious” literature, as in the case of Kenzaburo Oe or Haruki Murakami, the answer will more than likely be no. As a budding translator of visual novels, you are more than likely quite aware of the fact that our target audience — for better or for worse — seems to overlap more with the demographic that corresponds to manga readers than the demographic that corresponds to readers of “serious” literature. However, you are not allowed to use this as a crutch! The answer to the question I posed — will the target audience accept the use of honorifics — is only useful to you if the answer is “no”, in which case your decision and your conscience are both largely clear. If the answer is “yes”, that does not give you a free hand to use all the honorifics you want, whenever you want. On the contrary, I ask you to show all possible moderation in this case — to assume, as I indicated in the first bullet of my algorithm, that the answer is “no” to begin with and to work from there. That way, if you decide at the end of the day that you must use honorifics — and there are so many valid reasons to do so! — then you have a very good reason that you can, if necessary, publicly disclaim.

So are we “winning” or “losing” by choosing to keep or leave out honorifics? While we are certainly on somewhat more dangerous grounds than we were with the case of misspellings, I still maintain that no, this is still more of a sideways move if a move at all. To begin with, the English language has no honorific system in the sense that the Japanese language does, just as the Japanese language has none of the complicated temporal relationship tenses that the English language has. In a vacuum, it makes little sense to simply take cultural and grammatical constructs that do not apply across languages and stick them into one’s translation, hoping that the audience will “get it”. However, I am well aware that we are not in a vacuum, and that sometimes it is inevitable that we will need to resort to the use of honorifics. Just make sure that you have a very good reason — articulated and written out — if and when you make that decision. It strikes me that with honorifics, it is possible to “lose” if one is not careful, but not to “win”. The best you can possibly hope for is some kind of tie, and even that is not certain. So tread carefully, and let us leave it at that.

Now let us turn our attention to aphorisms and set phrases. We are beginning now to tread into the realm of alterations where the potential exists to significantly alter the intended meaning of sentences being translated if the translator is not careful, and where concrete rules become scarce as the daylight star on a heavily-overcast day. Not to say that the sun does not exist on such days — certainly, it exists, and we do not freeze to death thanks to its warmth — but we cannot see it with our own two eyes. Guiding principles at this level quickly become much like that — they must be felt rather than seen or strictly documented. Therefore, let us go through a series of examples, and perhaps they will help you in coming to your own conclusions about what you should do.

• 一石二鳥: This is the simplest case, where the aphorism in question is directly translatable — this is, after all, “one stone two birds”, and in direct translation “to kill two birds with one stone”. This is almost invariably the only correct translation for this phrase, as it not only depicts the “literal” truth of the words, it also translates the meaning behind the words quite well. You would be blessed if all your translations went this way. However, note also that there are aphorisms like 一挙両全 (’one means two ends’) and 一挙両得 (’one means two profits’) that essentially mean the same as “to kill two birds with one stone” — but depending on context, it may or may not be appropriate to translate these phrases as such. We will get to some cases where it is not appropriate in a later bullet point.
• J’ai bien d’autres chats à fouetter: Here we have a French aphorism that, literally translated, means “I have so many other cats to whip”. The first thing you might think is wait, to whip?! followed by oh, this probably means something along the lines of “I’ve got other things to do”. And you’d be correct on both counts — this phrase indeed means “I’ve got other things to do” or “There are other things on my mind”, and I’m not quite sure why anyone would whip a poor cat to begin with. We do have a set phrase in English that means something a lot like it: “I’ve got other fish to fry”. But is it appropriate to use that phrase? Yes, and no, and depending on the piece, mainly yes or mainly no. When used in isolation by a character, without any other reference to cats or whips or the Marquis de Sade, then in all likelihood, yes, you could get away with using “I’ve got other fish to fry”. But in the case of a piece like L’Œuvre du Sixième Jour by Marie Noël (which I have translated into English here), the phrase pops up in the middle of a canine account of the Creation. Suddenly, the reasoning behind the use of “cat” becomes obvious, and even laugh-out-loud funny, and just as suddenly you have become charged with finding some alternative phrasing that keeps the word “cat” in there somehow. Your options here are (a) to translate the phrase “literally”, and include a long translator’s note about it, (b) to find or create some analogous phrase that uses cats, and leaves it at that, or (c) to find and create some analogous phrase that uses cats, and include a long translator’s note about it. All three of the above are equally valid options, but I would encourage you to try (b) or (c) before having to resort to (a). What should draw your attention is that there is no (d) simply use the phrase “I’ve got other fish to fry”. That is because that option, in a sea of equally valid options, is probably the least valid for the reasons outlined above. I must hasten to admit that I originally ended up with the unwieldy “I have other cats to chase” — which I realize was not necessarily the best possible choice. But it was a good choice, and I had (and still have!) a clear justification for it, even after I’d come up with a localization that I like a lot better.
• 虫の息, 虫の声: In a certain visual novel, there comes a point where the protagonist asks his childhood friend how she made out on the national board exams — and she replies that her national rank was the year in which the 大化の改新 (the Taika Reformation) occurred, multiplied by 10. Our intrepid hero immediately recites the mnemonic 虫の息 (むしのいき, or 641), which happens to be completely wrong; the correct schoolyard mnemonic for the Taika Reformation is 虫の声 (むしのこえ, or 645). In other words, she wasn’t 6410th place, but 6450th. Ba-dum-bum, thank you, thank you, I’ll be here all night. Laughing (or wincing) aside, this provides an interesting challenge for the translator — how best to localize this? Obviously, one cannot just leave these mnemonics as-is — for the audience, they have no context at all, and one can hardly expect that most of your readers will be so well-versed in Japanese history. It is equally dissatisfying to simply leave a long translator’s note and walk away — for then we have destroyed the (bad) humor that is integral to the scene. So, then, what to do? The way I originally translated this was (brace yourself) by using l33tspeak. Yes, you heard me right. 6rass 4nt 1nhales and 6rass 4nt 5peaks, to be exact. Along with, of course, a translator’s note explaining what this nonsense was all about. If I had to do it again, though, I am not sure that I would have gone with that route; instead, I think I might have found a mnemonic that resonates more with the target audience, and done number manipulations to match. One might, for instance, take the rhyme “In 1492, Columbus sailed the ocean blue”, having the protagonist misquote it as “In 1419, Columbus sailed the ocean green”. Then, by having the girl say that it was the year that Columbus went on his voyage, plus 5000, we have essentially duplicated the bad joke for anyone who was educated in the public school system of the United States of America. It is not an exact duplication by any means, and there are some senses in which our original translation is “better” — after all, it does match up more closely to the original Japanese, and it doesn’t make all the sense in the world that Japanese schoolchildren would learn about dates important to the history of the United States of America. But the original translation is already “losing”, so to speak, and my feeling is that this kind of localization would improve its position somewhat. And of course, the addition of a translator’s note remains a fine idea.
• 直死の魔眼: This is a term made famous by TYPE-MOON’s seminal visual novel, 月姫. It is also one of many neologisms that Nasu Kinoko employs in his writing, for the supposed purpose of extensive immersion in the world inside Nasu Kinoko’s head. It is not up to me to say whether or not he succeeds — obviously, to many people, he does — but I will point this term out because it is typical of the kind of writing that this writer employs. Literally, this is something like “direct death magical eyeball” — and this is why there are some who translate it as “Mystic Eyes of Death Perception”. However, there also exists a pun in that first compound — 直死 is read as ちょくし, which also happens to be the reading for the words 勅使, 勅旨, and 直視. The first two both mean something along the lines of “imperial messenger, imperial order, imperial will”. It is possible that there is something of that meaning in the phrase, as the power of 直死の魔眼 is indeed incredibly commanding. But on a more basic level, the pun with 直視 — which means “to look at something directly, to look something straight in the eye” — is obvious, and that should definitely be modeled. To be fair, a phrase like “Mystic Eyes of Death Perception” does that, in a way — there is a pun with “Depth Perception” there. But this is tenuous, and we have taken a short, 5-character phrase and turned it into a 22-character one. While the number of syllables in each — 6 as opposed to 8 — does not differ much, in written and spoken terms “Mystic Eyes of Death Perception” seems to me to be somewhat unwieldy. I must stress that I still find this a good, serviceable translation — it is just not the one that I would choose. Rather, taking all of the above into account, I would go with a phrase like, perhaps, “Dead Center Sight” — which certainly models the 直死/直視 pun better than “death perception/depth perception” does. I freely admit that this translation has problems of its own, but my conscience is also clear when I say that I find this to ring more true to me than any other translation of this phrase that I’ve seen.

Do we even have to ask the “are we winning or losing” question anymore? I should hope not. I hope that it is becoming apparent to you that there is no way that a translator — no matter how gifted — can “win” against the original meanings and subtleties of any piece in its original language. We can most certainly “lose” — the cases and examples I have presented to you thus far are only the tip of the iceberg of dangers, and for that matter all it takes is a strictly “literal” translation to ensure that you have lost before you have even begun. And I promise that we will continue to talk about some of the more (and less) common pitfalls on other days. But for now, I can stand by this: that I struggle with the realization that there is no such thing as a perfect translation every day — and that I find a certain kind of joy in the knowledge that what I seek is so far beyond my grasp. This discipline is only worth it for the journey, for the things that you learn about the spaces between words and the spaces within your own heart as you travel along. While for each production process there will be a definite beginning and a definite end, for you the path flows on forever, and it should have no ending. Not while there is still the will to translate within you.

We should at this point make one thing clear — when I speak of “winning” and “losing”, I am not speaking of production value at all. While it is unlikely that a translation that has low production value will strive to be true to the original at all times, it is indeed possible. While it is unlikely that a translation that has high production value will deviate from the original in significant ways, it is indeed possible (see Working Designs). No, what I am concerned about is the integrity of the translation, and through it the integrity of the translator — not the coordinator, not the editors, not the QC staff, not the release engineers — the translator. I am interested in you and you alone, as you struggle with the bridge between two languages, and not in anyone else on your team. They are your concern, and they are not mine.

What do I mean by this? Simply that it takes a certain kind of hubris to state that you can make the original piece better, that you can “win” against it. I do not doubt that there are bad writers in Japanese — indeed, there will be unaccomplished writers no matter what language it is that you choose to translate. If you were the assigned editor for one of these writers, if you had full sanction to correct their errors, if it was your job to suggest improvements that the writers could follow up on, then by all means it would be your place to try to better the writers’ pieces — in close cooperation with the writers themselves, of course. But we occupy a different place. Like it or not, a single cease-and-desist letter can take away all the fruits of our labors on a project. We occupy a gray zone of both legality and ethical authority, in this respect; while we can debate on the ethical validity of international copyright law as it stands, there exists no doubt that currently, according to international copyright law, what we do is illegal. Likewise, while it is entirely possible that the translator who is working on a piece might be a much better writer than the original author, there is little to no ethical justification to give the translator a free hand in reshaping the piece as he wishes — unless the original author agrees. This is why I maintain that there is no “winning” to talk about here; for most part, we will not have such significant contact with the original creators such that they can know of and approve of (or shoot down) our changes.

This, of course, raises another argument: if what we are doing is illegal anyway, then why not go all out? Why not adapt things as we see fit, the (admittedly-unknown) wishes of the original creators be damned? My response to this is that it seems to me that this attitude is one that has lost a great deal of integrity, legal status aside. It is entirely possible to have a translation that has a great deal of integrity that is also completely illegal; William Tyndale’s unsanctioned English translation of the Holy Bible is thought to be one such case. True, he burned at the stake for it in 1535. But it does not change the fact that the Tyndale Bible is to this day thought to be a very solid translation of those scriptures. And it does not change the fact that in 1539, there arose an authorized English translation of the Bible that was largely based on Tyndale’s work and that was distributed to every parish in the land. Indeed, that version of the bible we call the King James Version is largely based off Tyndale’s work.

But William Tyndale never tried to “improve” the Bible. He knew that it was not his place. He had integrity on his side, even though all the forces of legality were arrayed against him.

While the things we translate do not claim to be “true” or “holy”, I implore you to take heed of this warning: it is not our place to make “improvements” based on our understanding of the original language (or lack thereof) and to declare that we’ve “won”. When we do that, or when we complain that the original author obviously did not care about his work, or when we point at misspellings that are not misspellings as evidence that the piece we are translating was an unloved stepchild of a distracted mind, then we have lost all integrity as translators.

And when we have lost that, we have lost everything. What discerning mind, then, could read our works and not doubt the sincerity of our efforts? How could we defend the changes we have made in our translations if we are simultaneously denigrating the original work? How are we any better than the much-reviled Carl Macek, who once took three different anime series, amalgamated them into one, and called the badly-dubbed result Robotech?

And this is what I mean when I say we have no right to “win” or “lose”. We tread a dangerous path, and tipping too much in any one direction — be it toward attempting to duplicate every single Japanese grammatical structure there is in English and filling your resultant translation with translator’s notes for every single word on the page, or be it toward writing your own script based loosely on the concepts found in the original and calling it a faithful translation of the original — has all the potential of leading us into disaster. This is not to say that we are not allowed to radically alter a piece — just that grounds for doing so are much rarer than you might think, and that you should have a very exact justification for why you are doing what you are doing when you do it. Let the original writing be your guide. Most of all, listen — listen closely, more closely than anyone before has listened — to the voices of the piece. Spend time with the piece, nurture it, take it with you to work or play, keep it in your head, let it sing, and listen, and listen, and listen. This again leads me to point out how intimately you must know the original language for such a condition to be true — for even the best translators will be forced to leave something inimitable to the piece out as they translate. For the time that you have it, the piece your translating is your charge; it deserves your love and your advocacy. If you do not speak up for the piece, then no one can. And if you cannot find it in you to defend the piece with all your heart, even given its flaws, then I implore you to find that love within you, to nurture it, and to give it voice.

That’s right. When you translate, you should translate for yourself, for the sake of the piece, and for no other person. The more internal your reasons are, the better; ignore the target audience, ignore the naysayers, ignore those who would “support” you, and most of all ignore the little voice in the back of your head that whispers “I can do better” to you. You do not know that. None of us do. Only translate, for your own reasons, and when those reasons are no longer valid, then declare your work done and walk away — release or no release. Did I not say it before? No one can help you. Unless you can ask yourself, in the still of night, when all seems lost, whether you must translate and reply with a clear “I must” that finds its source in no other place than your own heart, then it is much better that you do other things that interest you more. This hobby will only drain you of all the energy you have otherwise. And I have no problem conceding the fact that there are far more interesting hobbies out there, should one be inclined to do them.

With that, I must leave you for now. I have a large project that will come due in the following two weeks, and I must dedicate my energies to that. But know that I have all the love and respect in the world for you as you labor in the darkness, alongside me, toward a prize that cannot ever be attained by any mortal mind, and that I look forward to conversing with you in the future. Until then, I remain

Faithfully yours,

Seung Park
Lead Translator
insani.org

It has been some time since our last correspondence, and I hope this letter finds you well. You say that you have spent a good deal of time reading through the piece that you hope to translate, and for this I applaud you. All the time you spend in this lonely task, straining to see and hear all that which is most unseeable and unhearable about a piece, will prove its own reward. For there is no art save that which is found in solitude, no goodness in translation save that which you find in yourself. I know you will smile at this, and say to yourself, knowingly, condescendingly, that there is a target audience, and that translations are made for the purpose of being read.

In a sense, you are right.

I trust that it is in this sense that you have sent me some of your preliminary translations. I thank you for this faith — I enjoyed reading them over, and indeed the words of explanation you sent highlight very well for me some of the inadequacies in your current translation style. I cannot give you specific criticism, not at this time, but if you want my opinion, if you were not speaking in jest when you asked me to be as harsh as I could, I can tell you this: at the moment, you have no style and no form. You argue stubbornly, to the death, that “this is what the author wrote” without knowing, really knowing, whether that is a true statement or not. You speak to others about being “literal” as opposed to being “loose”, when you have not the wisdom or the right to offer up such criticisms. And I beg of you, for your own good and for the good of everyone else, to stop. You cannot help anyone. And likewise, no one can help you. No one. For in this art, we are all equally wrong — and we are none of us right. Not the bountiful polyglot, not the astute English major, not the silver-tongued native speaker of Japanese, not the illustrious professor of linguistics, not me, and certainly not you. All we have are our words, and when we use those words to vivisect the works of other people instead of to strengthen them, we do them — and more importantly, ourselves — a grave disservice.

Then why should you listen to me? Why, indeed, do you write me letters, and why do you say you await a reply? At the simplest level, you come to me seeking my advice — and that is something I am willing to give you, in abundance. Am I right? Am I wrong? I do not know. All I know is that these are the lessons I have learned, and this is the way my translation circle works. Perhaps, when you have successfully released as many translations as we have, you might have a significantly different opinion of what it is to be a translator. I do not doubt that. And I do not seek to question the validity of the conclusions that your future self will no doubt come to about the nature of these production processes, about the nature of translation, and even about what happens to both you and the piece you are translating as you translate. All of us change; all of us have footfalls that whisper on the concrete bones of the cities to which we are given only to forget that we might ever have existed at all. But here and now, I am me and you are you — and so I beseech you to listen.

So you have completed your initial read, and you are getting down to the often-unpleasant business of assigning your team members their tasks. This, then, is as good a time as any to talk about the makeup of your team. As I wrote before, insani is in essence a two-man team: one translator and one hacker. Edward is, in fact, writing an excellent series of articles about the mechanics of eroge hacking that your programming staff may wish to read at some point. However, the roles we play are diverse, and I will list them here (other than the programming role — I shall leave Edward to cover that) in somewhat greater detail than I did the last time around:

• The Coordinator: On many translation teams I have seen, this person is not a translator at all; in fact, in the romhacking circles, this person is almost invariably a hacker. In the anime fansub circles, this person might not actually do anything at all. Regardless, there is one property — and only one property — that a good coordinator must have. That is: he must understand the role of every single person on the team, including himself. And in order to be truly respected, he must be willing to lead from the front, charging into the fray before everyone else, blazing a path for others to follow. That is why, in the amateur visual novel localization community, the coordinator should usually be the lead translator. The coordinator has the final say on all team decisions, makes the timetables for milestones and releases, works intensively with all members of the team in order to ensure that they are making their deadlines. Furthermore, it falls to him to arbitrate and resolve team disputes, and to make sure that troublesome members of the team are either dealt with or shown the door if necessary. Should anything in the production process or the final release go wrong, it ultimately falls on him to shoulder the blame. Should anything in the production process or the final release go right, he cannot take any of the praise at all. This is a serious job, it may not be taken lightly, and the ideal coordinator must out of all members of the team know the most about the nature of both translation and the production process. Which means that: if you have no knowledge of Japanese other than what you “learned” from anime, if you have no knowledge of translation other than your derision at the much-maligned introduction to Zero Wing, if you have no ability other than that of an “editor” (read: a glorified cheerleader), then you have no business in this position.
• The Translator(s): It goes without saying that any translation project that exists should have at least one translator. However, if there is more than one, then there are additional issues of differing skill levels and translation consistency to deal with. Fortunately or unfortunately, just as in any other field, it is very difficult to put a number or a logical measure to the “skill” of any given translator. I have worked with translators, for instance, who might be brilliant when they are made to translate legal contracts from one language to another, but fail miserably when asked to translate literature. I know of others who can translate medical documents well enough even given the fact that they have no M.D. at the end of their names, and I know of M.D.’s who might know more than one language, and yet who make miserable translators altogether. But ideally, in your team your translators will be of fairly clear-cut skill levels. In this case, the translator of the greatest skill and experience should become the lead, and on his shoulders should rest the final creative control over the resultant translation. Practice the art and craft of pair translation — when there is one proficient translator and one who is still in the stages of learning, every single line translated should become a teaching point. And practice the art and craft of working under strict deadlines as set by the coordinator — for this, too, is an integral part of any production process.
• The Graphics Staff: These people are recruited to do what is essentially grunt work, and they most likely know this. If they do not, your coordinator needs to disabuse these people of their illusions. Graphics editing is hard, monotonous work, and it is most often a thankless job. The volume and difficulty of graphics to edit will vary per project, but in some projects we’ve tackled (see Majipuri) the configuration menus alone were enough to give our graphics editor (see Edward Keyes) grand mal tonic-clonic seizures. People who make good web graphics, by the way, do not always make good graphics editors for our purposes; ideally, you want someone who can make every single deadline you throw at him, someone who can faithfully duplicate sometimes-garish visual effects that appear in the original Japanese game — not someone who can build a pretty webpage.
• The Editors: These people are among the most unimportant components of a translation team. If they are among the most important, or if they play a major role in how your final translation reads, then your translators are at best clueless, and at worst dangerously flawed. The problem I have seen is this: most “editors” are drawn from English majors, self-described masters of English, creative writers who have only ever “published” in obscure blogs, and the list just goes on. Their one defining characteristic is that they do not understand Japanese very well (if you are lucky, not at all — then they cannot argue with you) and they understand English only slightly better. If that is the case, it becomes very difficult for an editor to truly “edit” a translation without introducing at best blatant — for in that case it can be easily fixed — or at worst insidious — for in that case it may hide undetected even by the time of release — amounts of meaning skew. No, a truly good editor must be at least as or even more skilled at Japanese than the original translators in order to be any good — and if that is the case, then that editor should probably have been translating the piece from the very beginning. I am aware that there are some people who advocate the practice of a translator and an editor working in close cooperation with each other — while this is well and good in theory, in practice I have not seen it working so well. If the translator has a hard time expressing the concepts and the wordings of the original work into English, then adding an editor into the mix — even one who goes over every single line with this translator — will not help you one bit. I only list this category of team members because most translation teams seem to have editors; insani does not work with any.
• The Quality Control Team: These hardy souls are as important as editors are unimportant. Prospective Quality Control staff should have the willingness to play a piece over and over and over, and should have an obsession over documentation, a keen eye for grammar and for that mysterious quality that we call “rightness”, and a willingness to write up their findings early and often. They will no doubt dislike the piece by the time release time comes around — if they do not, they are probably not doing their jobs, or they are far more tolerant of tedium than I am. Something perhaps unique to our circle is the fact that most of our quality control staff are well-qualified translators themselves — and so we sometimes term our QC period a “peer review” period as well. Truly, we seek the judgment of those we consider our peers — and there are not many of those we are willing to accord this title in this community. The reason is simple: your Quality Control staff are the last people to lay eyes on your translation before it hits the general public. Make sure that they are people you respect. Make them count.
• The Release Engineers: These people are responsible for packaging the finalized translations into installer builds for each of the operating systems you are planning on supporting, and have final say over the final deadline for release. The release engineer may call a complete halt to the release process if he believes that there are sufficient flaws in the process, or he may choose to delay release for a set period of time. For this reason, your release engineers above all must have a high degree of professionalism and integrity, and must be willing to face down the rest of the team if that is what is required for a good release. This is why, most often, the coordinator has a high amount of contact with — or even is — the release engineering team.
• The Fans: Do not forget these people. They constitute the silent member of your team, whether you like it or not.

In any team, you will find “tacticians”, and you will find “strategists”. While this is a gross overgeneralization, in brief, “tacticians” are adept in the achievement of self-contained, goal-driven objectives, and “strategists” are those who see the big picture, and assign these objectives to the tacticians under their command. Having one without the other is potentially fatal — a pure tactician is akin to a one-centimeter-squared 1200dpi display, and a pure strategist is akin to a 30-inch LCD that has a display resolution of 320×240. You must have both — and as the leader of your translation group, you must be both.

I leave you with this: in the game of go, it is generally not possible for there to be a tie game. However, in some cases — usually, ones where black is given a handicap to start — there is no komi that makes a tie game impossible. This has to do with the fact that usually, black (which is the first to move) is given a 4.5 stone penalty in order to theoretically make up for the advantage it has by going first; if black is weaker, and has to be given a handicap, then it makes no sense then to have a komi against it. In any case, let us imagine the case where players of equivalent skill are playing, have agreed to no handicap, and have also agreed to no komi (that is to say, black is at an effective 4.5 stone advantage). Certainly, in this case, if white should win, then white is probably the better player. If white should win all the time, then white is more than likely the better player.

But if white should force a tie all the time, then white is beyond the shadow of a doubt the better player.

The original author is playing black.

You are playing white.

You have no right to win or lose.

That leaves you with one choice.

Until next time, I remain

Yours,

Seung Park
Lead Translator
insani.org

[ As told by Stop-Dog to his little brothers ]

As soon as the Dog was created, he licked the hand of God and God patted him on the head.

“What do you desire, Dog?”

“Oh, Good Lord, I want to live with You, in Heaven, on the doormat maybe.”

“Oh, heavens, no!” God exclaimed. “I have no need of a dog, as I have not yet created thieves.”

“When will You create them, Lord?”

“Never. I am tired. It has been five days that I have worked, and it is time for me to rest. You are done, Dog, you, my best creation, my masterpiece. I had better stop now. It is not good when an artist presumes to try to go beyond his inspiration. If I continue to create, I am very capable of failing in my efforts. Go, Dog! Go quickly and find your place on the Earth. Go and be happy.”

The Dog let out a profound sigh.

“What should I do on the Earth, Lord?”

“Eat, drink, increase and multiply.”

The Dog sighed again, in utter desolation.

“What more do you need?”

“You, Lord, my Master! Will You not come to live on the Earth as well?”

“No!” said God, “No, Dog! I assure you. I cannot at all come to live on Earth just to keep you company. I have too many other cats that need skinning. The heavens, the angels, the stars … I assure you, they’re quite the bother.”

Then the Dog lowered his head and began to leave.

But he came back:

“Oh! Perhaps, Good Lord, just perhaps, there might be a kind of master of your type?”

“No,” replied the Good Lord, “there is none.”

The Dog made himself very small, very low, and then begged with all his heart:

“If you wished to, Good Lord God … you could make it possible …”

“No, it is impossible,” the Good Lord answered, “I have done what I have done. My work is complete. I will never create a being better than you. If I try to create another one today, I swear on my mighty right hand that it will end up a failure.”

“O Good Lord God,” the Dog cried out, “it does not matter how much a failure he is if I can follow him wherever he goes and lie next to him when he goes to sleep.”

Then the Good Lord was astonished at having created a creature so good, and then he said to the Dog:

“Go, may it be done according to your heart.”

And, returning to his workshop, he created Man.

–

P.S. — Man, naturally, was a failure. The Good Lord had said so. But the Dog is very content!

FIN

The young man sat almost in spite of himself. He was so little used to talking about what he loved that soon enough, a veritable deluge of words flooded from his mouth, as if some dike in his soul had broken at last.

He recounted everything: the addresses, the candle, the melodic phrases, the harsh light … and the other listened to him without saying a single word.

–And that is why I wanted to buy that lamp, he concluded. But my means are so far from the price that you are asking …

–Which instrument do you play? the old man wanted to know.

–None. But I hear them all in my head.

–And what do you compose?

–Oh … a few things here and there … some sonatas … and perhaps … someday … a symphony.

–I like music very much, the old man said. Whistle for me something from one of your sonatas, from the one that you like the most.

The young man began whistling, just as asked. It was a curious spectacle indeed: for he arose from his seat and began wandering through the shop crowded with antiques, whistling all the while. and as for the old man, he remained comfortably installed in a wing chair, his eyes closed all the while.

–That isn’t bad at all, he said when the young man was finished.

–Oh … well, maybe, the young man replied.

–Have you no confidence in yourself?

–Sometimes … and not very much.

–And have you gone to see a publisher?

–Oh, no! I couldn’t dare! The stuff I write isn’t really in style, and I will get laughed at!

The old man took up the lamp and stroked it in an almost loving fashion.

–It is true that the brass is a bit tarnished, he murmured, as if he were talking to himself. It could use some polishing …

He quickly raised his head and looked the young man straight in the eye.

–Have you ever heard a story regarding a lamp, and what happened when that lamp was polished? he asked tartly.

–Um, no, sir.

–You mean to tell me that you have never heard the story of Aladdin and his magic lamp?

–No, really, I never have.

The old man went to a shelf, plucked a book from it without effort, and then turned without any difficulty at all to the page that he was looking for.

–The Tales of the Arabian Nights, he said. Within them, we find the story of Aladdin and his magic lamp. I will not tell you the entire story from beginning to end, as if I did that we would be here all night. Aladdin’s father was a tailor by the name of Mustafa …

–My father was not a tailor, the young man said with a pout.

–This Aladdin had been behaving so badly by the time he was only fifteen, the old man continued with some severity, that he caused no end of hardship to his father. It is even said that his father’s eternal embarrassment at his never being able to turn his son to gainful work caused him a sickness so obstinate that he died from it after the course of several months.

–I assure you that I am not like that, interrupted the young man. See … I … I never knew my parents …

–Good … good … let us get back to our story of the lamp, then … ah, here we are … “there was once a magic lamp that was so powerful that even tyrants and emperors in their far-off thrones trembled and desired its power.”

–The young man wondered to himself what in the world this old man was getting at; he was of a mind to take to his heels and bolt from this shop that was resembling more and more, by the second, the inner sanctum of a magus.

But a curious kind of authority, emanating from that old man, kept him from doing so.

–In short, the old man continued, the lamp found its way into Aladdin’s hands, who was completely ignorant of its awesome powers. Aladdin’s mother took that lamp, and looked at it carefully. “It is quite dirty,” she said to her son, “and if we clean it a bit, it will have a bit more value to us, no doubt.” She took some water and some fine sand, but barely had she begun to clean the lamp that an awe-inspiring djinni of gigantic height appeared before her. Then it thundered: “What is your command? I — I and all the other slaves of the lamp — am here to obey, your slave, the slave of all who possess the lamp.”

The old man stopped here, closed the book, and placed it before himself.

–And it was all true, what the genie said, he concluded. In the end, the lamp gave everything to Aladdin: happiness, riches, love …

The twilight had begun entering into the room, and the old man lit the oil lamp. It was a beautiful, firm flame that allowed room for the friendly and favorable shadows that now danced about the walls.

–Fine, the young man finally said, but that lamp isn’t Aladdin’s lamp …

–What do you know, the old man countered. It is only faith that saves … take the lamp, take it with you …

–But I do not have …

–Polish it gently every time you wish to create something great, something of beauty … you will succeed … you will make money … and you will come back to me to pay me for the lamp.

The young man could scarce believe his ears. Nevertheless, he stood, took up the lamp, and held it in his arms …

–I do not know how to thank you.

–It is nothing. But make sure you take good care of that lamp …

The young man cradled the lamp under his coat, protecting it as if it were his very own child.

He did not know how best to say goodbye to the old man, but the old man seemed to have quite forgotten that he had ever been there. He had closed his eyes and seemed to all the world to be deep in sleep.

The young man exited the shop with all the haste and delicacy of a thief and went back home as fast as his feet could take him.

But in the end, the lamp sat at his table, he lit it, and his apartment was bathed in a gentle light.

He took a rag and gently polished the tarnished brass. No genie — not good, not evil — came from the lamp. If anything, the lamp just seemed happy to have been cleaner than it had been in some time.

The young man finally threw himself into writing his grand symphony, grasping at the phrases that often crossed his mind like flashes of lightning, but that he had never been able to capture in flight.

And now, here they were, taking form, as his symphony!

He polished the lamp now, the ironic smile of that first day gone, because he knew well that the lamp had aided him just as the other lamp had aided the Aladdin of old …

One day, he took his finished symphony to a well-known publisher.

–Come back here in three days, the editor told him. At 5:00PM …

–I work until six, sir …

–Then come here at six-thirty …

Those were the longest three days in his life. He did not write anything, not one more note, and he would gaze at the lamp for hours at a time, struck with the thought that the yellow flame carried madness and madness alone in its wake.

The final day, he went to that antiques store, and saw the old man reading as he sat comfortably on a period armchair. He had all the air of a magus who was consulting his grimoires, and the young man did not have the courage to face him.

The great day finally arrived, and precisely at 6:30PM, the editor received him with cordiality and respect.

–That which you have created is excellent, young man …