Part 1. Comprehensive Kick-Off Meeting
Assessing the developer’s project and requirements.
There are a few main points to cover before localization gets started. The goal is to get certain key information for your own planning but also to provide an insight into the localization process so that when you start, you have the best possible foundation. Here’s an overview of this step:
- Requirements – getting an overview of the project and getting to know the developer.
- Localization Kit – materials for you and the translators.
- Script Preparation – considerations for the script prior to translation.
- Common Pitfalls and Other Considerations – things developers would rather know sooner.
1. Requirements: an overview of the project.
At this stage the point is to establish a high-level overview of the project and this typically happens around alpha or sometimes sooner. It affords you the opportunity to give an insight into the localization process, highlight common pitfalls and present options to the developer they might not know they have.
This is not an exhaustive list – and depending on what information you have going into a kick-off meeting it won’t be necessary to ask all of the following questions. In some cases, the developer won’t be able to provide an answer or only give estimates.
- What type of game is being localized?
- What languages are required?
- Will the project require localized voiceover (VO)?
- What is the current and projected:
- Onscreen text (OST) word count?
- Script line count and word count?
- Number of characters?
- Recording constraint (lip-sync, sound-sync, time-constraint, wild or a mix)?
- What is the target age rating and audience?
- Are any aspects of the project licensed? (Well-known brands or existing IP.)
- Does the project require any specialist knowledge? (Cars, military, medicine, IT etc.)
- Is a content management system (CMS) being used?
- What file types are being used for OST, subtitles and VO?
- Are there any drop-dead dates or hard deadlines? (Platform submission etc.)
- Is there a need for any localized demos prior to full release?
- Are there any materials outside of the game to be localized? (Downloads, websites, tutorials etc.)
- Who will be the main point of contact during localization? (Set up a weekly call.)
- What is the current schedule for the source (usually English) script recordings?
- What are the delivery specifications for the localized VO? (Mixing, naming and post-processing.)
2. Localization kit: things you want from the developer.
Prior to localization starting you will be responsible for preparing the localization kit. Some of these items are essential, some are nice to have, and others are just not available and you may have to create them yourself.
- The design document, project brief and concept documents.
- Screenshots or concept art for characters, items, weapons, vehicles and environments etc.
- Gameplay footage. Granularity is good; divide videos into levels or areas instead of one long video.
- Menu screenshots showing all the text used outside of gameplay.
- Casting documents for major characters and small descriptions for minor characters.
- Script with full context in chronological order – this is expanded upon in point 3 below.
- Studio recordings of the English actors.
- Cinematics or cut-scenes; even if they are still work-in-progress.
- Naming conventions – any legal terms, brand guidelines and platform terminology to follow.
- Glossaries – especially if you are working with existing IP that may already have been localized.
Translators are not necessarily going to spend the time going through all of these materials, but some will (especially if there is a budget for familiarization) and as a LPM you should know the game inside out to avoid spamming the developer with translator queries.
3. Script preparation: ensure there’s enough context for translators.
Scripts for games will vary from project to project. If a CMS is being used it should be doing some of the work below in guiding the developer to providing content in a structured way. If not, the questions below will help reduce a lot of the guesswork involved for translators and ensure the script provides enough context. How this data is presented within the script is largely down to what the developer feels comfortable with. It won’t be necessary to have all the below information in the script if it’s clarified in other documents such as the character biographies.
- Who is the person talking to?
- Is the person talking to one person or a group of people?
- What gender is the person talking and the person/group being spoken to?
- How are they talking to this person or group, is there a difference in social status or rank?
- What age is the person talking and the person/people being addressed?
- Where are they speaking – in a small room, outdoors, over the phone?
- Is the dialogue on-screen or off-screen (narration)?
- Is the VO divided into sections and subsections – in an easily recognizable chronological order?
- Is there a unique naming system for VO files and script lines?
- Is there a one to one relationship between script lines and audio filenames?
- What is the time-length of the audio file?
4. Common Pitfalls and other Considerations: this is half the battle.
As a LPM part of your role is to establish to what degree the developer is familiar with localization. Some developers have been here a number of times and are aware of these common issues – but for those that aren’t you should highlight each of these pitfalls to ensure you don’t have nasty surprises further down the line.
Images containing text
It’s easy for text embedded in images to be missed from the translation phase. Any text destined to be embedded in images should originate and be maintained in the main text file. When the text is locked it can be added to the images with each language on a separate layer. It is usually more convenient for the developer to ask the LPM to organize this. Recommendation; have one LSP do all images in all languages – just provide them with the text, images and fonts. This way you are much more likely to have consistent end results at a better price. Besides, some LSPs won’t necessarily have the right software or provide this service.
Fonts should be selected early enough to allow pre-checks for localized character support.
Two very common issues are missing glyphs and glyphs that do not render as desired (overlapping, shrunk or fubar) – and these usually only appear once your localized text is integrated and the game is being tested – resulting in a lot of unnecessary bugs. Recommendation; add a font line to the text file which is displayed on the main menu and check that all the glyphs are correctly showing in-game.
Here's an example of a line you can add to check glyphs for the majority of common game languages (Arabic and Chinese scripts excluded).
I’ll go into more details on fonts at a later date – but the goal should be to find a font that supports the aesthetics of the game but also supports as many scripts as possible. In reality you are likely to need a few fonts dependent on the number of languages you support – and while most fonts are fairly small in size Asian fonts can weigh in at 15 MB, or more, per style.
Here’s a table showing common game languages, their script and type:
French, Italian, German, Spanish, Dutch, Portuguese, Polish, Czech, Slovakian, Turkish, Danish, Finnish, Norwegian, Swedish, Brazilian Portuguese, Latin American Spanish,
Chinese – Simplified and Traditional
Chinese (Kanji), Kana
Hangul, Chinese (Hanja)
Latin, Chinese (Chu Nom)
*Arabic is a bidirectional language – it goes from right-to-left but mixing it with English text such as numbers and variables, which read left-to-right, may prove problematic. If a developer has not localized into Arabic before extra time should be set aside for investigating its implementation.
Support for Non-breakable space (NBSP.)
You are probably aware that in French there is always a space between the last word in a sentence and any two-part punctuation mark (; ! : ?). To stop that punctuation auto-wrapping onto a new line the text file will use a NBSP character. The developer should check that the NBSP is supported for use. True story – after I’d delivered the French translations to a developer he emailed me back 30 minutes later to say he’d “fixed it”. What does that mean? He removed all of those ‘erroneous’ spaces.
Test the asset integration pipeline.
I’ve lost count the amount of times that localization testers have been booked in to test a game only to find their language was missing from the build. This can be avoided by doing a dry run. I’ll expand on this point in a future article but essentially you can prevent this from happening by providing the developer with machine translations and dummy audio files for all languages. If the developer has time, trying to integrate these assets may flag some issues that weren’t previously known.
European languages may require gendered variants.
To ensure top quality localization the provision for gender variants should be considered; otherwise you might have a situation where a female protagonist is spoken to as if she were a man. Most European languages will need one or more alternative lines independent from the English to cover such situations. The number of alternatives for any given English line will vary per language and depends on the meaning/wording of the original sentence.
Depending on the type of game the variants can start to become complex. Consider a protagonist (male or female) who later on can choose a sidekick (male or female) – if any NPCs make comments towards the protagonist and sidekick some languages may need four lines instead of one (male/male, male/female, female/female, female/male).
Developers choose their own naming convention in these cases, but usually the original file name is kept and it takes on the role of a specific gender. In the example below, although the first example doesn’t have a suffix, it is male/male. The other lines would be needed in various languages. During runtime the appropriate line is selected, but if no suitable alternative is found the default line is used (the one without a suffix).
There are some extra considerations for this approach:
- Languages will no longer have the same amount of audio files. This will affect recording costs and testing time.
- If any of these lines are used in dialogue mixes it means having multiple mixes; depending on who is doing the mixing that can lead to a lot more work.
- LSPs will need to ensure they catch all possible variants – which might be difficult if they don’t have full context or access to the videos/game.
- LQA will need more time to check that the variants are triggering correctly – a debug option would help speed up that process.
Symbols or imagery should be checked for cultural suitability.
The Sign of the Horns is a common sight at rock concerts – but in a number of countries it means you have an unfaithful wife – I’ve seen this effect the artwork for a trophy in the past; which had to be re-done. In Arabic territories – references to religion, alcohol or nudity will need more considered checks. In practice, gathering up all the trophy icons, in-game billboards and prop textures and sending them off to be checked by natives will ensure you have no last-minute surprises.
Be aware that translations will sometimes be 30%-50% longer than English.
This usually becomes problematic in menus that have been built around the original English text. If you have a strict character count it may result in some scrappy abbreviations. The provision for scalable or scrolling text will grant more freedom to translators. If character limits exist this should be shown in the OST file.
Be wary of excessive text and audio stitching.
In order to save on repetition within the onscreen text or script file it's not uncommon to see lines that are separate but will ultimately be stitched together during runtime. For English this is no problem but depending on the grammar rules of any given language it may not work at all. In moderation I've never seen any problems with using stitching as long as translators are made aware of exactly which lines are going to be used together - problems can arise if the onscreen text or script file is not clear on how lines will work together. If translators can't make something work it may be in the developer's interest not to use stitching and have longer, complete sentences even if it means adding to the overall file size.
Confirm the format of the subtitles file and how translations are to be organized.
A robust subtitle system should ideally allow each language to operate independently from the English. So rather than have each language split over the same number of lines as the English – allow each language to use as many lines as needed and focus on the start and end times of each line. This will ensure localized subtitles match up with the localized VO in a more natural way.
If variables are being used in the text supply a list with details.
Onscreen text often contains one or several variables – it’s important that any variables are outlined so that translators understand what they will be replaced with during runtime. While translations should contain the exact type andnumber of variables to match the English, the order in which they are presented should be flexible to accommodate a difference in grammar rules.
Most of the world doesn’t use the imperial system of weights and measures.
“I’m just going for a 3.1 mile run, darling.” Said by no one, ever. America and Britain use the imperial system whilst the rest of the world (including Britain, again) use the metric system. This isn’t really an issue unless you are working on a project that is tracking the player in some way – like an exercise app. For instance, 4 miles should technically be expressed as 6.43738 km – but that doesn’t look very pretty does it? Just be aware that any references to gallons, ounces, pounds, pints, cups and quarts. etc. will need to be re-written/calculated so it makes sense to the user.
The kick-off meeting is your chance to bring to the forefront many issues associated with game localization - by presenting them early you can prevent them from become significant problems later on.
In part 2 I will go into details about the LPM's role when it comes to project familiarization.