Case 3. Localizing Chinese games into Russian

Description:

A Chinese online game publisher is looking to localize a game. The deadlines are tight, the company has three contractors, the source content was written in English by Chinese speakers, there’s no time for testing, and there are no reference texts in Chinese. Prioritizing the deadline, the translations are handed to three different suppliers, with employees on staff tapped to handle the editing. Only one company suggests using a single software tool to ensure consistency and naming one of the three contractors responsible for complying with existing terminology and managing translation memories. For a variety of reasons, including the lack of time, the decision is made to just go with the existing options.

Result:

All three companies get the job done on time, though the quality level is poor. And since editing and compiling the texts needs to happen yesterday, there’s no time to figure out which companies performed better or worse. Only one of them gets any feedback. Which, you ask? The one that asked for it, of course. And from what that contractor can tell, the problems that were pointed out are all in sections of the translation handled by the other two.

Building processes within the localization department

Besides setting goals, it’s important to keep a tight grip on translation quality. The best way to do that, in addition to randomization, is to institute a triple-blind system: the people being checked don’t know which part of their work will be checked, the testers don’t know whose work they’re checking, and the specialist processing the results doesn’t know who was checking who. Localization or linguistic testing is the simplest way to find and eliminate errors in the real world.

There are two rules for making sure evaluations are objective:

The translation and testing teams are equidistant from the developer — if the translation is done by an external contractor, the testing should be as well. The translation and testing teams should be separate units with their own independent processes and staff. Translators shouldn’t moonlight as testers, and vice versa. That goes for both salaried and external teams.

Linguistic testing is a critical element of the localization process. Even experienced game translators sometimes don’t get the context or haven’t read the supporting documentation. Alternatively, a Chinese font might have been used for kanji in the game engine instead of a Japanese font, or tags might have been just stuck in due to a software quirk. Whatever the case, the outcome can be problematic. And that’s easier to catch when you’re playing through the game, making it important to have testers in place rather than dumping the issues on your players.

When it comes to a well-oiled localization process, the manager working for the developer needs a contractor to handle game translation and testing. That’s generally two separate companies, though there are some cases where a single supplier with mutually independent teams can take on both sides.

If you have multiple contractors localizing a single project, it’s going to be almost impossible to maintain a uniform style throughout. There are going to be different kinds and quantities of issues in the resulting texts as well.

The same is true of cases where you’re working with a single contractor, only they have more than three translators on the same project. That forces you to hire two or more editors who will have different linguistic styles and mistake profiles.

Just like in Brooks’ The Mythical Man-Month, linear expansion in the number of people working on a problem doesn’t exactly net you a similarly linear reduction in the project time frame. It can even start pushing deadlines back once you hit a certain number.

But what do you do when deadlines are tight? That’s when it comes in handy to have a single glossary and a general translation memory that have to be steadily updated. And while either the developer’s localization manager or one of the contractors can take responsibility for doing that, it does need to be just one person. That will cut down on errors, though it won’t eliminate them.

And so the perfect translation is handled by one translator and one editor working within reasonable deadlines. That’s about 10,000 words a week.

Case 4. Maximum automation for localization

Description:

Company Y uses GitHub for file storage, its translation resources are stored in a separate repository. Crowdin automates the localization process by uploading modified strings to the project for translation. Once the translation is done and confirmed by the localization manager, the text is uploaded to the same repository with a language tag. After that, it’s automatically incorporated into the build that’s sent off for testing. The process leverages the API for multiple solutions, the company’s own platform, and a single manager.

Result:

That workflow delivers the translation and testing of updates at record speed regardless of their size, and it’s suited to work both with freelancers and organizations. It saves the company money, too.

On the other hand, maintaining operability means regularly updating the software on your own and testing out any new functionality to make sure it fits into the process. Managing and upgrading the flow is a job for a professional localization manager, someone who knows all the nuances of every piece of software involved. And that weakness in the chain shows up when they quit, take maternity leave, or have to move on for any other reason. Finding someone to take their place can be nearly impossible (see “Assembling the team”).

Automating processes within the localization department

Below you’ll find a simplified visualization of the localization process pulled from our Culturalization Guide.

Unlike the similar layout in Nikolai Bondarenko’s article, ours is much simpler. Today’s companies leverage automation to launch translations into all languages at the same time (the same goes for testing).

We can break the automated localization process down into four segments:

Automating text import and export. For example, there are Unity extensions that import texts directly to Google Docs. Automating the localization process. There’s special translation software available for that, both server- and cloud-based. We use memoQ, Trados, Smartcat, and Crowdin depending on the client’s needs and the kind of job we’re being asked to do. Automating the link between text uploading/downloading and setting localization objectives. This tends to be the most challenging part, as game development is anything but standardized, and the range of solutions different companies use for the various dev stages can be expansive. Still, their API and ready-made cloud solutions can be leveraged to automate the localization process fairly quickly. Automating testing. It depends on the platform and other particulars, but localization testers generally go with one of the bug tracking systems out there. Jira, to take one example, is our go-to option.

To learn more about automating the localization process, check out the recordings of talks given by localization managers from Wrike and Xsolla, at LocKit, the conference we host.

But the simplest and best way is to have your localization contractor integrate you into the processes they already have in place. Serious companies will offer multiple ways to make that happen, giving you the strengths and weaknesses of each.

And of course, if you don’t have a task management system on your end, and you’re just sending game texts back and forth using a network drive, don’t expect to find a silver bullet that will solve all your problems.

5. Working with contractors