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:

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.

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.

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.

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).

!"#$£¢µ¿¡%&'()*+,-./01234 56789:;<=>?@^_`[\]~{}™©
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnop
qrstuvwxyzÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖØÙÚÛÜŸÝþÞ
ߊŒàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýÿšœężış
ＡＢＣＤＥＦＧＨＩＪＫＬＭＮＯＰＱＲＳＴＵＶＷＸＹＺａｂｃｄｅｆｇｈｉｊｋｌｍｎｏｐ
ｑｒｓｔｕｖｗｘｙｚぁあぃいぅうぇえぉおかがきぎくぐけげこごさざしじすずせぜそぞただ
ちぢっつづてでとどなにぬねのはばぱひびぴふぶぷへべぺほぼぽまみむめもゃやゅゆょよらり
るれろゎわゐゑをんァアィイゥウェエォオカガキギクグケゲコゴサザシジスズセゼソゾタダチ
ヂッツヅテデトドナニヌネノハバパヒビピフブプヘベペホボポマミムメモャヤュユョヨラリル
レロヮワヰヱヲンヴヵヶΑΒΓΔΕΖΗΘΙΚΛΜΝΞΟΠΡΣΤΥΦΧΨΩαβγδεζη
θικλμνξοπρστυφχψωАБВГДЕЁЖЗИЙКЛМНОПРСТУФХЦЧ
ШЩЪЫЬЭЮЯабвгдеёжзийклмнопрстуфхцчшщъыьэюя─

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:

*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:

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.

In Summary

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.

Next Time

In part 2 I will go into details about the LPM's role when it comes to project familiarization.