How to Translate a Game 1/3 : The Process

Translating a video game sounds simple enough. There are some words, you replace them with other words, and you have a translated game, right?

This high level overview covers the basic requirements for translating any videogame. Using my own game as an example, I will cover what it takes to get started, how to prepare, prioritize, and how to implement translations. This is the first in a 3-part series aimed at small and medium sized games, and while every detail may not apply to your project, you will still find useful information here, to help get your next game translated.

Early on in the development of my tiny roguelike, Torgar’s Quest, I knew it would be translated into several languages. I knew, because I was lucky enough to work with people from all over the world, several of whom had already asked if they could translate it. In other words, I got lucky and had awesome co-workers. If you need help finding translators for your game, I recommend using social media, reddit, etc. to get fans on board – that is, if hiring a professional service is not in your budget.

There is nothing wrong with crowdsourcing your translations – for small teams this might be the best approach, as it lessens the cost while also has potential to help build an audience in the process. But if you’re a studio with a medium sized or larger project, I do recommend using a professional service, just because they provide more than just translations – they typically have tools and experience from working on similar projects, and can help you avoid common mistakes. None of which you are guaranteed to get with crowdsourced work.

Since the game was published, I have received some feedback from fans who were happy it was available in their language. Furthermore, Torgar’s Quest sales, however pitiful the may be overall, do show better performance in the markets the game was localized for. That’s what it’s all about!

Define the scope

Whether your game supports 2 languages or 20, the technical setup will be more or less the same. You will need to separate out all strings from your source code, and load those using ID-references to match the correct assets, and finally display that depending on the user’s language settings. There are UI design challenges involved with mixing left-to-right and right-to-left text, as well as other language specific issues to be aware of, so the sooner you know which languages are to be supported, the faster you can accommodate any such specifics.

On Torgar: I limited the translations to left-to-right, Latin based alphabets, to make my own life easier from a design POV. I focused on the traditional main languages: French, Italian, German and Spanish (FIGS), with Danish thrown in since it’s my native language, and I could do it myself. I did have an offer to add Russian, but did not have sufficient time to implement and test the required extra fonts, so I chose to exclude it at launch.

Familiarization and Workflow

Once the content is separated out, translators need access to the source material as well as any relevant design documents, concept artwork, screenshots and test builds you can provide. This helps them build a glossary, and provides context for the content they are translating. Practical workflows for handing assets back and forth must also be established and communicated. I also recommend providing a way for translators to communicate with each other, as well as someone from the design/production team. This helps clarify terminology and avoid contextual misunderstandings.

On Torgar: The text was delivered in Excel format (more on that in part 2), translators had access to test builds, and we used email and a Facebook group to communicate. Next time, I would probably use a Slack board, Confluence and a CAT tool of some kind.

Editing and Quality Assurance

It is important to budget enough time for the translators to not only do the work, but also iterate on it, just like a designer iterates on artwork. This should be done in conjunction with localization QA, where most issues are uncovered. If you can, always use fresh eyes to perform QA on translations in-game. In a perfect world, you will have 2 translators per language (so they can proof read each other), and as many QA testers. For most games however, this is not an option and compromises must be made.

On Torgar: I did not have the luxury of having separate QA testers, so the translators did most of it themselves. In a couple of cases, I happened to have access to additional interested parties, and got some extra QA this way. Handling each language on an individual basis like that is yet another way things can get messy. Knowing it would go down like this, I gave the translators plenty of time to test their work. On bigger projects where you pay someone to do the work, there are other messes to worry about, but the progress is faster and more consistent. I had to rely on donated time, and people willing to work for a game key and credit, so I took what I could get and made the most of it.

Final Testing and Triage

Once the game is fully translated, a full final test pass should be run in every supported language. Sometimes, getting full coverage can be challenging due to release schedules and marketing commitments. In those cases, you will need to prioritize what to cover. However, ignore this phase entirely at your own peril! It almost always happens, that something breaks and will need to be fixed.

A typical scenario might go something like: Two weeks before launch, a UI change to the mini-map means there is now less room for the planned subtitles. These will now need to be retimed to fit a smaller space, as rescaling the fonts make the subtitles illegible. That means inserting new time codes where it makes sense linguistically – a job for the translators, which then has to be verified in-game.

When triaging issues I recommend this 20/80 approach: focus on the 20% of the content users will see 80% of the time. Typically, this starts with UI elements in-game and main menus. Work on those strings this sprint, then repeat the evaluation next sprint, defining the most important 20% of the remaining content, and focusing on that. Repeat the cycle until you run out of time, and you will get the most coverage where it really matters. Got time to cover the top 20% more than once? Perfect!

On Torgar: There wasn’t much time for final testing, and since translators would mostly do their own QA, it was tempting to rationalize the entire phase away as a waste of time. Nevertheless, several issues were found, including missing special characters and a couple of truncated strings.

Coming soon
Part 2 is about splitting and setting up the content, deciding on a way to implement the strings, and then building the Excel spreadsheet that would become the backbone tool of the process.
Part 3 is a guide to implementing a similar approach using Gamemaker Studio 2, including an example project.

The Art of Elimination

Sometimes projects get too big, deadlines get too close, creative disagreements happen, or for some other reason you’re either stuck, falling behind schedule, or both. In my experience, this often happens when projects become too bloated with half-cocked ideas and unfinished features. To solve the problem you must invoke a dark art, namely the art of elimination.

I love the expression “kill your darlings”. In three words, it perfectly captures what this is all about. We tend to look at our ideas as darlings, loved little entities to nurture and grow. We take pride in them, boast about them and even build things around them with the help of others. But most ideas are not as good as they seemed, when they first appeared in your head.

There is a reason why the painter sketches before creating the final piece, the writer produces several drafts, the director does alternative takes, the game dev makes hundreds of builds; all of this in pursuit of perfection. What is also true is that in nearly every project using an iterative approach, those last few iterations are about cutting the fat to focus on what is important.

This can be agonizing. I witnessed a film director barricade himself in the editing room for two days, because his film was 6 minutes too long for the short film competition he was entering. He looked like hell at the end of it, and the film did not win the competition, but he got it done and submitted on time. At the end of the day, getting it done is the first building block for actually shipping something.

Here is how I approach the art of elimination in any creative project.

First, focus on the high level. What is the story we are telling here? What are the top priorities we want to convey? Keeping this list short is very important. One or two items is ideal, and you shouldn’t go beyond four.

Secondly, split your project into parts. If it’s a novel, split it into story arcs or subplots. If it’s a game, split it by quests, meta-game or whatever makes sense. The idea is to have an overview of the logical building blocks that make up your project. Chances are, you already have that in some form.

Once the project is split into parts, it becomes much easier to see which parts take up the most space. Compare this to the list of priorities, and evaluate how they connect. How does each part further the priorities? If you find that something is non-essential to the priorities, it makes a good candidate for getting cut. Note that “space” in this context can refer to anything from playtime in a game to how much mental focus a reader spends on it in a novel – while not necessarily a specific number of words or minutes, these are good data points to use as indicators.

Identify the best candidates for cutting. If none are found, you are probably not looking hard enough. But if I take your word for it, the next step then is to dive deeper into each of the parts you have identified, and find individual components within these parts that might be axed, combined or reduced. This will invariably lead to more fine editing and polish, but likely also an overall tighter result, without outright reducing the number of parts.

Doing this may sound simple, but choosing what to cut can be extremely difficult. If there are several contributors, and you are left to make the decision, it is likely that someone will disagree with or be upset by your call. However, there is no point blaming the editor, producer, or whomever is enforcing the limitations causing the cuts (in my experience, a looming marketing deadline and launch commitments are the most common causes for cutting things at the last minute). It just happens.

Killing your darlings can suck, but it can also be liberating and open your eyes in a different way, to the story you are telling or experience you are building. It enhances the focus of your top priorities, which tends to also increase the impact on and retention of the target audience by making your story clearer and easier to understand. Editing is your friend.

One thing to watch out for when cutting content, is that sometimes what may seem non-essential in one context (say, the main plot line) can be essential in another context (like world building). Make sure you examine your project from multiple angles.

Don’t be afraid to cut boldly to see what happens. You can always save a backup without the changes, and restore if you think it was too drastic. If you have to kill your darlings, you may as well have fun doing it. Good luck!

Game in a Day: Procformer Infinite

Procformer Infinite
I like to set challenges for myself. Self-imposed, often timed challenges is a great way to learn new things, or experiment with different ideas. I find that it’s a great way to learn new concepts or test theories you might have; set yourself a challenge, and try to overcome it.

So, on a lazy Sunday, instead of playing video games, I challenged myself to make a platform game myself. Right away, I knew I wanted it to have an infinite number of procedurally generated levels, so you could never run out of new challenges. To make it more difficult for myself, I was not allowed to use any third party artwork or sound, everything had to be made for this challenge (no using scraps from the personal archives), and to top it off, I only allowed myself one day to complete it.That was pretty much my entire Sunday, but worth every second of it.

The screenshot is from the resulting game – Procformer Infinite – which you can play yourself, right here!

Challenge completed. Next! Perhaps improving or expanding the game with more features and obstacles? You never know what might happen on any given Sunday.