Translators, editors, and localization testers all need context.

This is a guest post from Jennifer O’Donnell who shares tips for game developers to have a better understanding how localization works and what to look at. Here is a very useful document: the loclization kit, or loc kit.

High Quality Localization? Help Loc Help You!

Too long, didn’t read, the more context and background information you can provide your localization team, the smoother the localization will go and the better it will be!

Provide your localization team with familiarization materials, a localization kit, style guide, give them a platform to ask questions, and include notes in your text files.

Too many developers throw the text file at their chosen localization agency and expect the final text to come back perfect. You’d be surprised at how hard it is to understand the direction, vision, and other in-game factors just from the text alone. Translators, editors, and localization testers all need context.

Ideally, the best way to provide context to the people translating your game is to let them play the game first. But maybe the game isn’t finished yet or you can’t provide a playable ROM for some reason. What do you do then?

If you can’t provide a playable ROM then there are other options to provide context and ensure the best quality localization of your game.

Other Familiarization Materials

If you can’t provide a game ROM for familiarization then perhaps you can record a play through of the game (as much as you can) to send to translators?

Or maybe there’s something else that would be useful for them? Previous games in the series? A TV show or novel the game is based on, perhaps? These help give translators an idea of the world-feel and the characterizations.

If a previous installment was already translated then it helps them get a good idea of language, tone, and terminology. Which is especially important for consistency.

Note: Ideally any familiarization period should be paid for hourly. This is valuable time the translators can spend getting a feel for the world and start mapping out important information needed for accurate localization.

Localization Kit

This. Is. A. Must.

Even if you’re able to provide your localizers with a ROM or another form of familiarization, providing a localization kit is invaluable. It takes a lot of work to create* but will guarantee a higher quality translation. It may even benefit the development team!

*If you have up-to-date, accurate, and detailed design documents then a localization kit shouldn’t take up much additional work.

You might think this information is obvious to you but if the translator doesn’t understand the context of the text they’re translating, then misunderstandings and translation errors may arise.

German, for example, changes depending on who is talking to who and what their relationship is. Korean also changes depending on whether the person they’re talking to is older or younger than them. French, Spanish, and Italian will change depending on the gender of the character/creature/object.

So making it clear if a note from a minor character called “Cook” was written by a female cook or male cook, in their 20s or 50s, could make a huge difference in how the text is translated.

Your localization kit should include:
(You can download a Localization Kit Template here: Localization_Kit_Template.)

General Information

• Title of the game. (Believe it or not translators aren’t always told this.)
• The target audience.
• Official game website and/or game wikis.
• Platform(s) in which the game will be released (to be aware of which terminology to use)
• PEGI if known already (to decide the tone and also know if coarse language is ok)

Story

• Summary of plot and chapters/sections.
• Mechanics (could also be genre of the game, is it candy match game, a hidden object game, simulation, RPG…

Characters

• Character profiles including picture, name, age, gender, description, personality, biography, rank/status. (Including minor characters and NPCs.)
• Notes on how you want the characters to be portrayed. (Added to profiles would be helpful.) E.g “Character X talks like grumpy old man.” “Character Y is smart but writes like a child.”
• Notes on how each character talks. (If they use coarse or polite language, if they speak with an accent, or vocal tics, etc.)

Creatures

• List of animals/creatures/monsters including pictures, gender, description, references.
• Notes on how they speak (if they speak.)
• Notes of evolutions and differences between similar creatures.

Objects

• List of items, weapons, vehicles, etc., including images, brief description and explanation of relevant information. (Especially if these are unique to your)

Systems

• List of spells, moves, attacks, etc. including description of what these do. Videos of these in action if possible.
• Clear diagram or table of game’s mechanics and short explanation of systems.
  g How do your “upgrading” systems work? What verbs do you use for each system? Characters, items, weapons, pets, etc. can all “level-up”, “advance”, or “upgrade” in different ways.

Other

• Additional notes if an item/person/name/description is a reference to something else, either to something in your game’s universe or to popular culture.

Creating a loc kit will benefit your game in a number of ways.

Even if you don’t refer to, say, a monster’s gender in the original text, this might invaluable information for the translator, so creating one just for localization purposes would help.

Pictures and video of items, creatures, etc. helps the translators come up with creative naming solutions, rather than play it safe with dull direct translations. Understanding where names come from, the creative process behind a creature name, is gold to mirror that same effect in localized versions.

Providing this information before translation begins will also mean you’ll be bothered a lot less by the localization project manager. Otherwise you can expect a lot of time to be wasting with back-and-forth clarrifications on the above information.

A day spent putting this information together in advance will save you weeks of implementation and reimplementation later on.

Organize Strings and Provide Context in IDs

You’d be surprised by the number of a times a translator is given a file with a list of seemingly random string IDs and no idea how it fits into the rest of the game. Please do not put your strings in alphabetical order!

At least providing strings in a logical order (e.g by chapter, items, names, etc.) and making it clear where these strings appear in the overall scheme of the game can really help!

Useful information to include in string IDs:

• Type of UI (button, header, etc.,)

If you do have an unclear string names, be aware that translators also won’t know your ID system. They would have no idea if a line from scene_1510 said by character X10500 should use masculine or feminine language. If you do assign code numbers to certain characters or scenes, provide that information to the translators so they can tell what type of text they’re working on, and where it fits with the rest of the game.

If you can organise your string IDs clearly with chapter numbers and what type of string it is (e.g ch1_2_jane_003 or item_description) that would be incredibly helpful to everyone, not just the translators!

Dev Comments in Text Files

Whether you do this as you write your source text, or after you’re done, adding notes can be invaluable to translators.

What kind of comments should you include?

• Who the speaker is and who they’re talking to (including the number of addressees.) (Even if you think this is obvious.)
• What the speaker is feeling/what you want them to convey. (Think about the types of notes you’d provide to voice actors.)
• If the line referencing something. (Either something else in-game or some cultural reference/joke?)
• Where the text is used. (Even if you think this is obvious.)
• The character and line limits for the string. (Very important for good translations that fit!)

Translation text files can sometimes be lists of 20 cases of the word “no” but without comments to give context it’s hard to tell whether “no” or some other word in the target language would be more appropriate for the situation.

Do not remove these repeated words either! As mentioned, these might need translating differently depending on the context. (E.g. The button prompt “Push” will vary in other languages depending on whether you “push a button” or “push a cart”.) So if you remove repetitions to reduce translation costs and reuse the same text for different locations, you might introduce errors.

Take this menu, for example. One of the options was “Resume” as in “resume playing the game,” but the translator (for whatever reason) misinterpreted this line and translated it to “Resume” as in “a document used for job applications that lists one’s career.” You’d have thought the context would be obvious, but clearly not.

Character and line limits can impact a translation greatly. Not knowing the limits a line has can risk text overflow or unnecessary and unnatural short-hands. Knowing the limits ultimately saves time and money when it comes to the localization QA.

Provide a Style Guide

If possible a style guide for each language would be ideal. But at least the style guide you used for the source language will help the translators shape the style for the localizations.

A style guide should include the following:

• Punctuation
• Capitalization
• Abbreviations
• Characterizations of speech/text in different locations
• Tags and variables (and what they mean)
• Gender when referring to players

Keep terms in your dictionary consistant with how you want them to appear in the game. If a term should be lower case, write it out as lower case.

A style guide is particularly important because if you have multiple translators on a project then they might use inconsistant formatting. Interrobangs, quotation marks, hyphens, capitalization, em dashes or en dashes, are inconsistently used between writers. A style guide and glossary helps keep the text consistant.

See “Style up your game: All you need to know about Style Guides” by Lucile Davilov for more detailed example and style guide template.

A Group Q&A System

Sometimes you may have missed something in the localization kit or comments, or something is confusing or unclear even with those explanations. In times like these, you’ll probably get an email from the localization PM with a long list of questions. (Or you should, if they’re a good PM!)

Having a Q&A system (ideally online and not via Excel file, please!) that the entire localization and dev team can access will be incredibly helpful! If everyone related to text/audio/scenario etc. can access it then that means everyone can help answer questions, rather than one poor manager. (Unless you have a localization manager in-house who fields these questions to the correct people.) It also means questions are answered quickly, which will speed localization up too.

It would be even better if you use a system that allows you to share files and post images.

This more direct dev/localization interaction can be beneficial because if the translators are confused, then there’s a chance your players will be too! Translators are great at finding errors and inconsistencies in the original text. (Which can happen, we’re all human.)

Why Bother With All This?

The translators can just guess this all based on the text, right? No.

Unlike comics, game translation is often done without images. And unlike novels, game translation is often done without descriptions for scenes. The stories in games are often not linear either. They might have branching paths and the plot told through side dialogue and files.

More often than not, game translators have to wade through thousands of strings of translation before they get an idea of the overall context for the characters and story. A lack of understanding of the overall story can often result in inconsistencies, confusing dialogue or system descriptions, and requires hours of re-tracing steps and changing earlier translations to fix everything.

It also saves hours of your time answering context queries, as well as money from extra hours spent changing and checking changes during localization QA.

Providing all this information right from the start, even if you’re not asked for it, can save hours of your time and your localizers’ time. Which also means saving you money without you even realizing it.

But beyond money, all this information willl allow the localizations of your game to be more true to the original. The PMs, translators, editors, and localization QA staff will have a clear vision and understanding of your game’s spirit.