The way things have always been
The first thing my translation teacher told me is that you shouldn't write down a single word before having read the whole text twice. Then, when you have a good feel of the content, you should note down any difficult parts, research them thoroughly and only then start to translate.
The traditional localization process follows the same steps.Here are some sections from the Game Localization Handbook
No matter how small or large the project, translators need to have read or seen the content before they begin translation in order to gain a feel for the subject matter. You expect a novel or movie translator will have read/seen the work before they translate it, so why wouldn’t we expect to give context to the translators of a game (that is much more complicated with multiple story branches and text files with no logical order to them)?
Translators should keep a record of names and ideas as they play through the game content.
The translators should brainstorm together, breaking into specialized groups on larger titles where needed, then bringing the results back to the group.
All clear, no? Play the game, note down your ideas for terminology and characterizations, do some brainstorming and away you go.
If we want to visualize this, it would be a pyramid.
Post-gold localization pyramid
The base is context. Translators need to check every nook and cranny of the game and see each string in context before translating. Then, this experience is leveraged to craft names and characterizations. On top of this sits the product as a whole, its identity driven and shaped by the context and characterization underneath.
It's a process that starts from the single, smaller details and uses them to build the product. Like in a mosaic, the bigger picture emerges at the end, after each tile has been pieced together.
The elephant in the room
A solid system, built over decades of game translations and rooted on centuries of translation as a whole. One caveat: as the Game Localization handbook clearly says, it needs context to work.
If the title is still in production, then providing early builds and design docs may have to suffice until playable versions are available.Translators have to see the game. Yes you can give them some design documents, but that's just a temporary solution until you can give them the finished game.
Little problem: if you ask most game translators today, they will tell you that seeing any part of the game is more the exception than the rule.
Since I began my career in 2003 I have been involved with all kinds of publishers from Ubisoft to Square-Enix to Paradox. I cannot count more than a dozen projects where I could access the game.
An increasing number of projects now starts with some character sheets and design documents, but the majority of projects is still carried completely in the dark, with no reference at all besides the source text and maybe some descriptive string names like scene_1_dialogue_b and WEAPON_WAND.
Why? A brief tweet from @USSpeaking summarized it very well a couple of months ago
There are two models in game localisation - sim-ship localisation and post-gold localisation. #fact
The whole system above is based on the assumption that the game already "went gold", i.e. that it has already reached its final production stages and is ready to be released (or it will be soon). However, most games nowadays are published in simship.
Quoting the Game Localization Handbook again:
Releasing the localized versions simultaneously (sim-ship) with the source version is a goal most publishers and developers want to achieve with their game (...) If the localized versions are published simultaneously with the source language version in a well-publicized worldwide release, game sales will benefit tremendously.
From a publisher point of view, it's really a no brainer. Sales " benefit tremendously " from sim-ship? Then go for it, now!
So the wave starts rolling.
Developers, while they are busy crafting new and exciting game mechanics, now need to build a solid localization framework at the same time, injecting masses of localized materials and deal with the ensuing issues.
Localization managers and agencies now need to operate in a just-in-time manner, sending out words as soon as they are ready to dozens of translators, editors and then dubbers. Each step linked to the next, each delay jeopardizing the whole project.
When the wave hits our little freelance translation shore, it's a storm.
Localization in a sim-ship world
Let's sum up the odd situation most game translators find themselves in.
On one hand, translation theory and game localization experts constantly remind us that translation shouldn't begin before having seen the whole text and game.
On the other, the vast majority of modern projects always happen without ever getting a general view, with small batches of text and no access to the game. Why?
In order to have a better perspective, I discussed the matter with a friend of mine from the other side of the fence, responsible for the editing, testing and submission of several AAA titles in Europe.
Where's my script?
Two elements make it really hard to hand out a single, complete script to translators: the first one is time.
With AAA videogame development costing hundreds of thousands of dollars per month, you can't really blame shareholders for wanting the game on the shelves as soon as humanly possible.
This means that all game developers, from designers to writers, have a fixed shipping schedule and are constantly rushing to get their work done by then. The depressing truth is that game are never really "finished", they are just "released".
When translating a book, you can imagine the finished text sitting with the editor, being polished while the translation takes place.
Game development cannot afford such a pause. Having a finished script would mean waiting until about four weeks before the game hits the shelves. Unfortunately, that's exactly the time where games are submitted to first party publishers (Sony, Microsoft, Nintendo) and translation must be already in for their approval.
That's why smaller batches of text get sent out instead, shaped by the localization coordinator. He is the person that, with an eye on the shareholder deadlines, forces developers to hand over their text (usually before they are ready to do so) and pushes it to translators.
Based on his strength, this can happen chapter by chapter, or in more chaotic ways. (Incidentally, with the introduction of string-by-string systems like LocDirect, the future seems to go towards smaller and more fragmented text).
The second element that stops from handing out a "full script" is that the concept itself is increasingly inapplicable for videogame texts.
Sure, games take cues from all sorts of linear documents like films, books, encyclopedias, technical manuals and so on, but their nature is substantially non linear and interactive and this is increasingly mirrored in their text structure.
Demanding to have it all as a linear script is a bit like asking for a printed copy of Facebook: very hard to prepare and so detached from the intended use to become almost counterproductive.
One practical example? If you think about it, until the PS2 era you would still have some separation between narrative and gameplay.
The game story was usually conveyed by cutscenes, pre-rendered movies placed between levels. As these required external vendors, both for rendering and for voicing (they commonly were the only part of the game to be dubbed) they had to be prepared in advance.
This meant that translators would get the whole story first, written as a linear script, and deal with the non-linear in-game only later.
That separation is substantially over. First, because cutscenes don't use pre-rendered movies anymore but are generated in real-time with the same graphical engine of the game. Second, because most games are fully dubbed anyway.
From a text perspective, the in-game script has swallowed the cutscenes, reducing what little linear structure we had to a mere element within the general non linear framework.
Where's my game?
Okay, if translators can't read the text before translation begins, why can't they at least see the game in order to have some context?
The most obvious reason is that there might be nothing to see yet. Although most modern titles rely on some licensed or pre-built graphics engine, they are still far from the standardization of desktop applications. They remain cutting edge, experimental code and it's not uncommon for them to be completely unusable for a long part of their development.
After that, you must consider that running a modern game during development requires very advanced technical knowledge, a PC with a very specific set of background tools, an extremely expensive development console and the experience to set that particular test version into something resembling a flowing game.
Even the internal staff couldn't do it without the support of a specialized and exceptionally knowledgeable functionality QA department.
Setting up multiple translators across the globe with all of that technology and knowledge (some of which -starting from the game code itself- is a trade secret of the game company) is just not an option.
The only workable route to show the game during development would be in-house, flying people to the QA or marketing department but, despite the huge costs, benefits would be minimal.
On one hand, we saw before that when translation starts there isn't really much to see and, with all good will, developers can't really afford to stop and explain what's going on. On the other, this kind of in-house presence would substantially overlap with QA duties.
And, if most publishers rely on freelancers for their translations, let's not forget that they usually have an in-house department for language quality assurance.
The friendly neighborhood QA department
Language QA is usually associated with two vital roles. The first one, of course, is catching typos and mistranslations. The second is ensuring that the translation, that might come from a non-gamer, is fit for its audience and purpose.
In a sim-ship environment, it takes a third role as the co-author of the text.
Under this scheme, the translators work in the dark, and quickly provide astonishing amounts of quality raw material. It's not expected for them to get everything right: after all, working with limited context forces them to make assumptions, and some of these will necessarily prove wrong.
QA then acts as their eyes on the game, knocking the rough edges off and ensuring that everything looks fine. Some companies even go to the point of drawing a line between the two roles, saying that translators "translate", focusing on the purely linguistic and textual level, while QA "localize", adapting the text so that it flows and moves correctly inside the game.
This relationship definitely requires a bit more investigation but, to close this already longish post, we can think three metaphors to describe it under different angles.
The first is police sketch artist and witness. The translator-artist draws a portrait using a few available elements, then the QA witness checks it and ensures that it really does look like the criminal. Together, they get an accurate portrait.
The second one is textile factory and tailor. The translator provides a large amount of fabric within the general specifications of the project, focusing on the overall quality and consistency. The QA-tailor then cuts and saws the different parts together, ensuring the quality of the details (which may have radically different requirements than the project as a whole).
The third one is the most technical, but also the most poetic. The translator is the film director, starting from the raw idea (the original text) and shaping it into rolls of filmed scenes. QA is the film editor that, eyes on the footage (translation), cuts and moves those scenes around to give them a clearer and more defined voice.
Weak metaphors aside, the truth is that this kind of collaboration is here to stay so, for best results, always remember to teamwork (and feel free to ask questions, Mr Translator!)