GLOC Game Localization 24/7

We might say that video-game translators are the foot soldiers of game localization. Together with QA, they live it in their smallest detail, but often miss the general perspective and motives behind their effort.
To bring us that perspective, today we are joined by Christoffer Nilsson, CEO at LocalizeDirect, whose goal is precisely to capture those motives and needs and serve them through a seamless client-server solution.

Hi Christoffer, thank you very much for accepting this interview! Can you tell us a bit about you and the career path that lead you to LocalizeDirect?

In the early 1990’s I started one of the first game developers in Sweden so I’ve been heavily involved in most areas of game production. For the last decade it’s been mostly running game development studios but in my heart I still consider myself a programmer I’ve always been a “process person” and found game localization fascinating as it spans across so many different skills and professions – this is also what makes it difficult. I realized that from a development  perspective there was no reason to deal with localization as an afterthought – as was the norm. So together with two game industry veterans I founded Localize Direct and we set out to create tools that would allow localization to be an integral part of development.

For those who aren’t familiar with it, could you summarize what LocalizeDirect is and what it does?

LocDirect is a system that manages all loc-data in a project. This includes images and audio files as well as text. It allows developers to create text strings which can then go straight into the game in production as well as making them available for translation. As translations are added to the system they are automatically validated and imported into the game. The system has a version control system that tracks strings on an individual basis as well as tracking all dependencies. As everything is automated and tracked there’s little or no “overhead” associated with each translation batch – so in theory it allows a game to be translated string per string as they are created. However, in practice strings are still translated in batches albeit they can be as small or as big as you decide is suitable to the project. We also kept the system flexible by adding support for translation export and import so that translators can use whatever translation tool they prefer.

Based on your experience, what are the main needs and priorities of developers regarding localization?

When I developed games, the publisher would normally manage the translations. After passing our strings over to the publisher we totally lost insight into what was going on. So having progress visibility is very important as developers usually have milestones targets to be met where “fully localized version” will loom. Other control issues include keeping on top of string changes and data validation. Import of localized text can and often will break the code. In most cases translations are carried out fairly late in the development process, say when the game is feature complete – this is also the time the development team will start getting feedback and gameplay tweaking is going on. It’s also close to the end of the project and many teams will be in crunch mode at this time – dealing with localization issues at this point can be stressful and painful. As with all development, it’s cheaper to fix something early on rather than later. So finding out that you needed to tag thousands of dialogue strings with the genus of the listener is better done whilst the strings are created rather than in a mad rush at the end of the project.

* Have insight into the full process and be able to track progress
* At an early point make sure that all the necessary data is created and that the product is “world” ready
* Have flexibility to be able to change strings until very late stage in the dev process (like 30 min prior to submission )and get the updated translations into the game very quickly
* High quality translations that will enhance the gaming experience for their audiences

And what are those of publishers?

Publishers often have a localization department that manages the translation, audio and loc QA processes. They need to juggle all their projects so need to be on top of the individual requirement of each game – how many strings? What languages? How many dialogues? What are the time constraints? What about subtitles? Etc etc. So they need to educate the developer to provide them with the correct information. They also need to be able to send all the localized data back to the developer in a format that the developer can use. On the actual translation/QA effort they would be looking for high quality, timely and good value propositions.

Your company website strongly recommends a “parallel” model, where localization happens during development and translators collaborate directly through a shared online interface. In your experience, what are the main benefits of this scheme for developers and publishers?
It allows the developer to deal with any eventual localization issues early on when there’s more time and options available. As a game is created, all new functions are tested by the development team as they are added, localized versions can also benefit from this testing. Having the localized versions up to date during development also means you can release a fully localized trade show demo, beta release or hand out fully localized review code. But most importantly the team don’t get hit by localization at the end of the project phase when stress levels are peaking.

Your company also provides translation services. What are the main benefits for translators?
Traditionally translators are handed over all the strings in a project when the game is almost finished. In a large game this can amount to hundreds of thousands even a million words. Now the development team is sitting waiting for their strings and needed them back translated yesterday. This in combination with the highly seasonable release schedule of games will create high peaks where translators have too much to do and other slow down periods. Rather than getting a full bucket of “strings” thrown at you, the translators will get strings in smaller batches throughout the development period so there’s less stress. The translators workload will be smoothed out during a longer period. As the game is already “hooked” up with LocDirect – if translators are given game code they can see and review the translations in the game. Another benefit is that, if given access, translators can view translations of other languages as they are entered into the system so this provides yet another reference point.

Under the “parallel” translation model, translators need to be available every day, but for variable amounts of text (even none). What kind of arrangement is used to make this financially viable?
It really needn’t be every day. By working in batches you can agree that periodically they will have a batch of text that will need translation. The amount will be determined closer to the time. This would be the case for one project. If however you are working on multiple projects as we do, then there are usually a number of batches each day that need addressing. The system is also used by publishers that have their own in-house translators.

Working repeatedly on very small batches doesn’t lead to inconsistencies? Can translators request a string update if new elements make a previous translation unviable?
LocDirect allows the developer to organize their strings in folders and also to control which strings are ready for translations. Normally we’d group together strings that belong as they are part of the same folder and translate them within the same batch. So rather than sentence by sentence strings are translated in chapters. Still, it is entirely up to whoever is managing the project how to structure it. I understand that only having a piece available at a time and not be able to see the full scope can be challenging from a translators perspective. To help minimize this we’ve added communication functions so that translators quickly can ask questions and they get routed to the right person at the developer straight away. Translators also continue to have visibility into the project as it grows and can edit previous translations and have full access to all strings including the folder structure that provides additional context.

With LocalizeDirect, translation happens directly inside the program interface. In terms of functionality, how would you say it compares with a translation suite like LocStudio, Trados or memoQ in terms of translation memories and QA systems? If they prefer, translators can export string and translation memories and carry on their translation and QA in such tools?
LocDirect is still a “young” tool and there’s lots left to do. Our initial focus has been on the process flow of the strings. This is also why we have opted to support export and import of translations so that translators can work in whatever system they prefer. Learning from the translators we are working with, many use the internal LocDirect editor for smaller batches but use other translation tools for larger amounts of words. We’re currently working on adding support for terms and translation memory as it makes sense to have them centralized and available to all loc stakeholders. We’ll continue to stick with the idea that translators should be free to use whatever tool they want. We’re very excited about the XLIFF format  which will play a large part in LocDirect going forwards.

In their best practices, the IGDA Locsig states that “translators need to have read or seen the content before they begin translation” and recommends “a minimum of 3 days of playing the game and reading background documentation”
However, if localization starts early on, the game will be unplayable and the script incomplete or still in draft form. In your experience, sharing design documents and other reference materials can suffice?
I agree that it would be wonderful if all translators were given preview code and was paid to play the game for 3 days but in reality this does not often happen. Publishers and developers are reluctant to give out game code before release and in many cases translators don’t have the development hardware needed to run a development version of a console game. So instead translators have to rely on experience and other context materials like design documents and pictures. We advise developers to start using LocDirect from the start of their project to create and organize their strings. As you mention it doesn’t make sense to start translating early on in pre-production, rather most LocDirect translation efforts are kicked off during the last half of the production phase.

In one (very impressive!) promo, we see in-game text being updated and displayed in real-time using LocalizeDirect
Do you think that a similar system, coupled with streaming technologies à la OnLive or Gaikai, could be used on day to allow remote testing and in-game reference? Do you think that technology and stake holders are both ready for this (at least in the mobile/social arena)?

I think there’s a huge gain to be made during the QA phase by allowing testers to be able to fix a localization text error straight away as soon as they find it. Normally they play the game, find a faulty text, file a bug describing the problem and pass that on to the developer who then need to track down the text, change it, build a new version and upload it to the testing facilities. Once the new build is available the tester needs to install it, and play through the game to the same spot where they found the faulty string and verify that it actually has been fixed. This process normally takes 24 hours or a couple of days. Instead, if the game is activated to update its strings during runtime (via the LocDirect API) the tester would find a faulty string, look it up in the LocDirect client, change it, immediately see the text change in the game and if it looks ok that is all there is to it. Some clever publishers are already doing this.

I think similar setups to OnLive and Gaikai would be great ways of allowing loc stakeholders access to the running code and remove the stigma attached to sending out actual code. I do hope we’re ready for a change – haven’t we passed around xls sheets long enough?

Again, a great thank you to Christoffer Nilsson for his time and kindness. For more information about LocalizeDirect, please visit the official website http://www.localizedirect.com or to arrange a meeting at the GDC 2012 contact Michael Souto at ms@localizedirect.com

And you? Have you been involved in a project with LocDirect? How do you see the future of videogame localization? Leave a comment to share your views.