Continuing on from the Project Management 101 article, I promised I’d actually go into the translation process. The writing of this article was quite difficult, because there’s many interdependencies between sections and the ordering isn’t set in stone for all projects. What I detail in this article is a rough general sketch, and depending on specifics, things may differ significantly.

In writing this article, I’m making two deliberate choices in what I’m covering. First, I’m still coming from a mostly project management perspective, so I’m not going to discus things in much detail. Instead, the diagrams serve as a rough map to help PMs figure out what should be going on roughly when. Later, after Narcissu side 2nd is released, I’ll provide a much more specific explanation using that project as a case study, so I’ll stick to writing in general terms here.

Second, I’m leaving detailed discussion of topics like editing and translating for separate pieces. There’s just too much to write about those things.

The simplistic view

Above is the sketch of what most people seem to think the translation process is, this tends to be especially true for someone who wants to start a translation project on their own.

The Key on the bottom is a rough color coding that shows who’s supposed to be working on what. The “content guys” do the writing stuff, the “tech guys” do their tech stuff, and that’s about it.

There’s a number of interesting points to note about the graphic. First, it’s rather linear. Very little thought has been given to the question “what can be done while translating is going on.” Beginners also tend to just focus solely on the translating part as if that’s the biggest chunk of work.

The next thing that’s interesting is that “Edit” is in quotes. This is because to very many people, “editing” is this simple process of “fixing typos.” No, I’ve said this before about editors that’s proofreading. Editing is much more important and is an integral part of the translation process that provides vast script changing feedback.

Also, somewhat implied but also extremely common among people starting out is the notion that a translation “once through” is good enough. When really if it’s anything important, it takes multiple passes.

A bit closer to reality.

So here’s my rendition of what the translation process feels more like. The key is more enhanced now, with a color for “Everyone”. What the key is supposed to represent is the sorts of people who can do what sort of job. Content colors are mostly (but not exclusively) handled by people who work with text, Tech colors are mostly for people with strong technical expertise, and everyone means that everyone who has a moment of free time should be able to help out.

As you can see, the process is a long spider web. I’ve roughly color coded and organized everything with the notion of critical path analysis in mind. In general, the content path tends to take the longest, so they’re most likely to be on the critical path. However, there’s a number of dependencies along the way where a major delay can cascade down. That’s why I try to move as many jobs as possible off that path, and into a category where “everyone else” on the project can do productive work.

The translation side

All along the left side is the ‘translation track’ of the project. It consists of the majority of the work in a project, and will inevitably take the longest time. However, where it takes the longest time is different that what most beginners would believe.

The first step is the “Preliminary translation notes” step. This is when the translator first decides they’re going to translate a project, and is often alone, with no technical support or team to speak of. The first step to translating is to play through the game first (I’ve actually had people argue strongly against me on this point…). Along the way, it’d be a good idea to read things with an eye towards future translation. Note any things that will need to be researched later, keep an eye out for any repeated imagery or lines, start thinking about how you’ll be rendering how people speak, how text should sound, everything you can.

Some people start translating snippets into a text editor at this stage. While in my opinion you can’t do anything until you have the actual script dump in front of you, these snippets are useful for experimenting with tone and ideas. Either way, until you have a script dump, nothing can start.

Once translation does start on the scripts, the next important thing to do is figure out places to stop and take stock. Set some milestones, formally or informally, and use those to take a break and look back over your previous translations. These stop points are important because if they’re too far apart, no one has the mental stamina to look over the scripts critically. This is where the true editing process starts, not when the script is already done, but while it’s still evolving.

The bubble marked “Retranslation and editing” isn’t some joke. It’s quite literally retranslation. Face it, we’re amateurs with little practice, and we’re going to screw up if we so much as blink the wrong way. It’s part of the translator’s duty to realize this fact, and don’t take it for granted that the translation is right on the first pass. Countless times, I hear new translators go “my Japanese is bad, but I can translate and someone can edit after.” This essentially assumes they got it right the first time, when they can catch all sorts of insane mistakes in their own work if they bothered to look just one more time.

I have no proof, but it is my suspicion that projects that forever bog under “Editing” is actually trapped in the retranslation phase. It’s finally occurred to people that the first pass script is crap, and lots of work needs to be done. Except the translator might be long gone, or unwilling to rework their script since “it’s the editor’s job”, or editors just keep quitting because the text is impossible to work with for other reasons.

Either way, once a milestone is passed, life continues on with new scripts until the ‘final’ version is done. However, looking over ‘done’ scripts will inevitably unveil new errors and things that should be fixed. Keep that in mind going forward.

The technical side

The remaining 2/3rds of the diagram cover mostly technical considerations and smaller sub-tasks.

First, there’s the blue circles that cover hard technical aspects that I don’t know enough to go deeply into. These are the standard toolbox items of script dumper, script reinserter, archive dumper/inserter, and engine enhancements/details. All those are important and have come up in projects I’ve seen in one way or other.

What’s of most interest though is the green bubble “Opportunistic editing and proofing.” It comes after script insertion is possible, meaning you can put text into the game engine and play around. Most of this falls under stress testing the engine. However, it also provides an opportunity for people to make comments on translated scripts while they’re testing. Gasp! Doing two things at once!

The idea is simple, sure there are “editors” and “translators” who have lots of say in what goes in the script. However, anyone and everyone can play test the engine looking for bugs. While they’re at it, they can also look at pieces of the script. If they see anything wrong, a line that is unclear, a piece that just flat out sounds weird, or crazy typos, they should say something.

The end stuff

I’ve left much of the final process pieces vague, with just ‘beta testing’, ‘last minute changes’ and then ‘release’. Each of those can take some time on their own depending on the project, but that’s outside of the scope of this article I believe.

At this point, I’m not particularly sure what I want to write about next in this series. If readers happen to have questions or ideas, I’d be happy to entertain those. Otherwise, I’ll think of something eventually…