Game Localisation: Text, Audio and Cultural Adaptation

Game localisation is one of the most layered services in the translation industry. It is best thought of not as a single line item but as a package whose parts can be switched on and off independently of one another: text, audio, graphics, cultural adaptation and testing.

Contents

That structure works in a studio’s favour. When the budget is tight, you begin with some of the layers, measure how the market responds and then go deeper. Doing so, though, means knowing what each layer delivers and what it costs.

Below we take the layers, the options for localisation depth, the technical difficulties specific to Turkish and the timing decisions in turn.

What layers make up game localisation?

The layers are ordered by the relationship the user has with the game. The outermost layer is the store page; the innermost layer is gameplay itself.

Layer	Content	Typical delivery format
Marketing	Store description, promotional copy, screenshot captions	Text file, image
Interface	Menus, settings, error messages, tutorials	String file
Narrative	Dialogue, quest text, item descriptions	String file, table
Audio	Voice-over, subtitles, sound effect text	Audio file, time-coded text
Legal	Terms of use, age rating notices	Document

This breakdown is the quickest way to pin down scope when you ask for a quote. The sentence “I want my game translated into Turkish” can mean five different projects in the table.

The layers also stand in a sequence. The marketing layer can be published on its own; the narrative layer is meaningless without the interface layer; and the audio layer cannot begin until the narrative text is final. That dependency gives studios who want to split the budget into stages a natural road map.

Localisation depth: box, partial, full

Three levels of depth are in common use across the industry, and each of them serves a different purpose.

The first level covers the marketing layer alone: the store page, the promotional copy and the user manual are put into Turkish, while the game itself stays in the source language. It costs little and is used to gauge the market’s interest.

The second level adds the interface and narrative layers; the audio remains in the source language and the dialogue is delivered through subtitles. It brings the greater part of the game experience into Turkish, and for most independent studios this is the most sensible balance.

The third level takes in voice-over as well. It raises the cost noticeably, because a studio, voice actors, a director and sound engineering are added to the translation. It is the choice in genres where the narrative is central and in productions addressing a broad audience.

The text layer: variables, context and character limits

Game text sits somewhere between software strings and literary writing. It carries technical constraints and stylistic expectations at the same time.

Variables come first among the technical constraints. A player name, an item name, a number or a place name is dropped into the sentence at run time. In Turkish this creates a suffix agreement problem: the suffix has to change according to the last vowel of the word being inserted. A suffix fixed in the code appears to the player as a broken sentence. The solution is usually to rebuild the sentence or to move the variable to a position the suffix does not reach.

The second constraint is context. In a string file, dialogue is ordered by the layout of the code rather than by the order of the conversation. A translation made without knowing who is speaking to whom, and in what mood, comes out technically correct but inconsistent in characterisation. That is why sharing a character guide and scene information is decisive for quality.

The third constraint is space. Interface text has to fit into fixed-width boxes. The agglutinative structure of Turkish cuts both ways here: some expressions become shorter, but when the suffix chains grow the text overflows. Stating character limits in the string file prevents a great deal of later correction.

The audio layer: voice-over and timing

Voice-over is the most visible layer of localisation and also the most constrained. The text is not free here; it is tied to duration and sometimes to lip movement.

The duration constraint appears in two forms. In cut scenes the line has to end in step with the animation on screen. For lines heard during gameplay, the length of the audio file is usually held within a fixed range; otherwise the sounds overlap. The translator then has to manage length while preserving meaning.

The order of the process matters as well. Translation comes first, then the adaptation stage fits the text to the available time, and the recording is made after that. Changes made during the recording have to be written back into the text; otherwise the subtitles and the audio will not match.

Last comes file management. Every line is a separate audio file, and the naming scheme of those files maps onto the code. A single mistake in naming makes the wrong line play in the game, so an automated matching check is run before delivery.

Cultural adaptation and legal limits

Cultural adaptation is the body of decisions that keeps a game intelligible and lawful in the target market. It is confused with censorship, yet its purpose is to preserve the experience, not to restrict it.

The elements adapted most often are jokes, wordplay, references and units of measurement. A reference peculiar to the source culture says nothing to the player when it is translated literally; in that case an equivalent reference is built. The decision has to be taken jointly by the translator and the studio, because it affects the tone of the brand.

Legal limits, for their part, vary from market to market. Violence, gambling elements, the use of symbols and age rating notices are subject to the regulations of the target country. This assessment is the responsibility of the publisher rather than the translation provider; the localisation team can nevertheless report risky elements at an early stage.

A third heading is in-app purchase text. Price display, currency format and refund terms have to comply with the rules of the target market; this is a configuration job, not a text translation job.

Cost items: where does the budget come from?

A game localisation budget is not made up of a single item. When you compare quotes, seeing which items are included tells you more than the total figure does.

On the text side there are two items: translation and revision. In narrative-heavy games a second round of review is all but compulsory, because consistency of characterisation can only be checked once the whole text has been seen. If that round is not included in the quote, the price is low but the risk is high.

The items on the audio side are more varied: adaptation, casting, studio time, direction, post-recording editing and file delivery. Most of these depend on studio hours rather than on the number of lines; the better the text is prepared, the shorter the time spent in the studio.

The third group is the technical items: preparing the string files, adjusting the fonts, reproducing the text inside graphics, and testing. These items usually look small, but in unprepared projects they account for a significant share of the total. To compare items, you can use the definitions on our pricing page as a yardstick.

Testing and timing

In game localisation, testing is not an optional step. Text that looks right in the string file may overflow on screen, appear in the wrong scene or come adrift from its context, and this can only be noticed by playing the game.

There are two kinds of test. Linguistic testing looks at translation quality and consistency. Functional testing looks at whether Turkish characters are displayed correctly, at how the text boxes behave, and at whether the language is preserved through the save and load flow.

In terms of timing, both extremes are risky. If localisation is run at the same time as development, the texts change often and the same work is done over and over. If it is left entirely to the end, no time remains for testing and the errors reach release. Common practice is to start once the text flow is largely settled and to plan at least one full round of testing before the release date.

The Türkiye context

In terms of game localisation, Türkiye is a two-way market: it is both the destination for foreign productions localised into Turkish and the source for domestic studios opening up abroad. In the second group the problem met most often is that the game was developed as a monolingual product from the start; because the texts are embedded in the code, the first localisation project turns into an internationalisation project.

On the language side, the clearest difficulty is suffix agreement. In inventory and quest text, item names are used as variables; the pattern “%s aldınız” (“you have received %s”) calls for different suffixes in Turkish depending on the item name. The solution to this problem is usually to design patterns that require no suffix, such as “Alınan eşya: kılıç” (“item received: sword”).

On the technical side, the choice of font stands out. The custom fonts used in games do not always contain the Turkish letters; if the characters ğ, ş, ı and İ are missing, the screen shows an empty box or a garbled shape. Checking the font is the first technical check that has to be made before localisation begins.

What does this mean for you?

If you are thinking about bringing your game into Turkish, you do not have to make the decision all at once. The layered structure allows you to divide the risk.

Confirm that your font covers the Turkish letters; this is the first and cheapest check.
Make sure the texts can be exported as a string file; if they cannot, solve that first.
Begin with the marketing layer and measure interest through the store page.
Prepare a character guide and a term list as you move to the interface and narrative layers.
Take the voice-over decision after you have seen the figures for the subtitled version.
Set aside room in the schedule for at least one full round of testing before the release date.

This order spreads the budget across stages and leaves room to turn back at each one. If you share the text volume and file format of your game, we can draw up a scope layer by layer: ask for a quote or look through the scope of our services.

Frequently asked questions

Do I have to localise my game completely?

Not necessarily. Beginning with the store page and the promotional copy alone, moving to the interface and text layer once interest has been measured, and going on to voice-over after that is a common and low-risk route.

When is voice-over necessary?

In genres where the narrative is at the centre of the gameplay, and in segments where the target audience is not used to reading subtitles. In action-heavy games, the fact that the player cannot take their eyes off the screen also brings voice-over to the fore.

When should localisation start?

Once the text flow is largely settled, but far enough ahead of the release date. Localisation run at the same time as development costs more because the texts change often; left entirely to the end, it leaves no time for testing.

Is cultural adaptation censorship?

No. Cultural adaptation is the body of decisions that keeps content intelligible and lawful in the target market. Sometimes a visual element changes, sometimes a joke is rewritten; the aim is to preserve the experience.

Sources

Pietrzak, P. & Kornacki, M. (2021). Using CAT Tools in Freelance Translation. Routledge, pp. 16–18.
O’Hagan, M. & Mangiron, C. (2013). Game Localization: Translating for the Global Digital Entertainment Industry. John Benjamins, pp. 87–140.
Bernal-Merino, M. Á. (2015). Translation and Localisation in Video Games. Routledge, pp. 105–150.
Unicode Consortium, CLDR – language and locale data.