Text Types in Games: Interface, Dialogue, Quest and Story Layers

Localising a game is not a matter of translating a single text file from beginning to end. Text types in games are sharply distinct from one another: a button in a menu and a long monologue by the main character will not take the same approach. One answers to a constraint of space, the other to register.

Contents

Jiménez-Crespo divides the assets localised in games into four groups: in-game text that appears on screen, audio and cinematic assets, art assets carrying text, and accompanying documentation. This distinction is not academic decoration; each group has its own file format, its own constraints and its own delivery process.

This article takes the layers one at a time. The aim is for the buyer of translation to see how many separate work items sit behind the sentence “I am having my game translated”. For the wider picture you can also look at the localisation articles in our knowledge centre.

Why are text types in games handled separately?

Games are not linear texts. Everything that appears on screen consists of independent strings called up in different orders according to what the player does. As the book points out, most of these strings “carry no clear meaning outside the context of the game” (Pettini 2022, cited in Jiménez-Crespo 2024, p. 210).

This is why the lines in a file cannot all be read with the same eye. One line may be a button label, the next an error message, the third something a character shouts in the middle of a battle. A string whose type is unknown gets translated in the wrong tone and at the wrong length.

Separating the layers also determines the budget. The difference between the “box and docs” level, where only the menus and the documentation are translated, and full localisation is essentially a matter of which text types are included in the job. The scope decision cannot be taken until the layers have been named.

Interface text: the shortest layer with the tightest constraints

Installation screens, menus, buttons, commands, status bars and HUD elements fall into this group. The book says these texts have to be “short, clear and precise”, because they carry the user’s interaction with the system directly (Jiménez-Crespo 2024, pp. 214–215).

The real problem here is length. Turkish renderings are usually longer than the English source; “Save” is two characters while “Kaydet” is six. When the character limit is exceeded the text either overflows or is cut off. Either one leaves the interface unusable.

Interface strings are the layer that most resembles software localisation. Variables, plural forms and escape sequences are concentrated here. Because of that resemblance, experienced software translators usually enter game projects through this layer.

There is one more detail: platform terminology. The book notes that platform holders do not allow games that fail to follow their own terminology rules to be published (Bernal-Merino 2015, cited in Jiménez-Crespo 2024, p. 211). The names of the buttons on a controller, or account terms, are not words the translator is free to choose; they are taken from the platform’s glossary.

Dialogue lines: spoken language committed to writing

Dialogue is the source for both the subtitles and the voice recording. The book underlines an interesting point: in games the subtitle text and the dubbing text are usually one and the same, whereas in film and television the two come clearly apart (Jiménez-Crespo 2024, pp. 212–213).

Using a single text this way can reduce the readability of the subtitles. A long line written for voice recording turns into a subtitle that will not fit on two lines of the screen. In the dialogue layer, then, speakability and readability have to be watched at the same time.

Dialogue also carries character voice. A guard’s rough speech, a merchant’s ingratiating manner, a child’s vocabulary all have to be preserved in translation. To make that possible, the translator needs to be given a character list and a summary of the script.

Dialogue strings are held in spreadsheets, and every line has a string ID. The book shows audio units listed together with their ID names and the name of the actor who will record them (Jiménez-Crespo 2024, p. 215). Dialogue, in other words, reaches the translator not as a script but as a data table broken into pieces.

Quest, combat and system messages: strings with variables

Quest texts, combat messages and status notifications are short but very numerous. The typical examples given in the book take the form “You have %d lives left” or “You have %d gold coins” (Jiménez-Crespo 2024, p. 210). The variable is not translated; it is preserved.

In Turkish these strings raise a problem of suffix agreement. The form of the suffix that follows a number can change, and gender and possessive suffixes can shift along with the variable as well. The safest solution is usually to rebuild the structure so that the variable sits in a position within the sentence where it takes no suffix.

The book also gives examples of conditional structures: “Why, hello there <IF_MALE>handsome boy<ELSE>pretty girl<ENDIF>!” (IGDA 2021, cited in Jiménez-Crespo 2024, p. 218). If these tagged structures are broken in translation, the game either shows the wrong text or crashes.

Narrative and story text: the domain of creative translation

Some games carry narrative on the scale of a novel. The book notes that sagas such as Final Fantasy contain very large narrative sections (Jiménez-Crespo 2024, p. 215). Ubisoft’s Child of Light is an extreme example in which the text is written in rhyme.

In this layer the criterion is not fidelity but experience. The concept of “playability” that the book uses foregrounds translation serving the player’s overall experience rather than adhering word for word to the source text (Mangiron and O’Hagan 2006, cited in p. 208).

Narrative text also creates the names of weapons, abilities and characters. These have to go into the term list and stay consistent across the whole game. The same sword appearing under two different names on two different screens is a classic error, one the book lists under the heading of “internal inconsistency”.

If the game is tied to the universe of a film, a novel or a comic, the job grows tighter still. The book gives the example of the Harry Potter games having to agree with the renderings of spells and names in the existing book translations (Jiménez-Crespo 2024, p. 208). In the narrative layer the translator is bound not only to the source text but to the established Turkish of that universe.

Text inside graphics and accompanying documentation

Maps, signs, graffiti and warning boards are graphics that carry text. The book calls these “textual graphics” and notes that they can be translated directly when they are supplied as layered files (Jiménez-Crespo 2024, p. 215).

If there is no layered file, the translator only lists the visible text; the developer or the art team applies it. These graphics can carry a space limit in pixels too. Long Turkish renderings should therefore be checked at an early stage.

Accompanying documentation is a world of its own: user manuals, store descriptions, promotional sites, help content and the end user agreement. The book stresses that these texts are more creative and less standardised than software documentation, because they are expected to match the atmosphere of the game (Jiménez-Crespo 2024, p. 215).

This group includes legal texts as well. The end user licence agreement should not come from the same hand as the promotional copy: one persuades, the other creates obligations. The level at which only the packaging and the documentation are translated is called “box and docs” localisation in the book; it is still a preferred option in some smaller markets today.

Constraints and priorities by layer

The table below offers a practical framework for separating the text types on a game project. Asking for this breakdown when you request a quote heads off most of the scope arguments that would otherwise come later.

Text type	Main constraint	Translation priority
Interface and menu	Character or pixel limit	Clarity and consistency
Dialogue	Timing and readability	Character voice
Quest and system message	Integrity of variables and tags	Technical accuracy
Narrative	Consistency of register	Creative transfer
Text inside graphics	Visual space	Brevity
Documentation and store copy	Marketing tone	Persuasion and accuracy

Every row in the table can be priced as a separate delivery item. On some projects only the first three rows are translated; on others, all of them. The decision follows from expectations in the target market and from the budget.

The Türkiye context

Turkish raises two structural difficulties in game text. The first is its agglutinative structure: in strings containing variables, suffix agreement arrives on the translator’s desk as a problem never once considered in the English source. The second is text expansion; a shortage of space in the interface is a common sight in Turkish.

Demand for Turkish localisation in Türkiye has risen visibly in recent years. Player communities run campaigns for major titles that have no Turkish support, and some studios answer that demand with post-release updates. This shows that Turkish is now a language that comes after the first-wave languages on most projects but is firmly on the agenda.

The picture we see most often in practice is this: the menus and the interface are put into Turkish, subtitles are added, and the voice recording stays in English. This is the typical Türkiye counterpart of the book’s discussion of “localisation levels”. Which layer gets translated is a commercial decision, not a linguistic one.

What does this mean for you?

If you are buying game translation, breaking the job into layers rather than describing it as a single item makes both the price and the quality predictable. The sequence below summarises what to do before requesting a quote.

Export the text assets and tag which layer each string belongs to.
Mark the fields that carry a character limit in a separate column; where there is no limit, write that down too.
Give the translator the list of variables, placeholders and conditional tags in advance.
Prepare a localisation kit made up of the character list, a summary of the script and screenshots.
If there is to be voice recording, deliver the dialogue layer separately, and plan the subtitle version with room for shortening.
Approve the term list before the first delivery and use the same list across every layer.

These six steps carry the difference between text types in games into the contract. A file with a clearly defined scope reduces both the translator’s questions and the number of bugs at the testing stage. If you are not sure which layers your project contains, you can look at the localisation headings on our services page or share your file through the quote form.

Frequently asked questions

How many main groups do text types in games fall into?

The common classification uses four: in-game text that appears on screen, audio and cinematic assets, art assets containing text, and accompanying documentation. Interface, dialogue, quest and narrative texts are sub-layers of the first group.

Why are interface text and narrative text not translated the same way?

Interface text has to be short, clear and unambiguous, and it usually carries a character limit. Narrative text, on the other hand, carries register, rhythm and character voice. Clarity comes first in one, creative transfer in the other.

How are game strings containing variables translated?

Variables (such as %d and %s) and placeholders are kept exactly as they are and not translated. Because suffix agreement can cause trouble in Turkish, rebuilding the structure is usually safer than leaving the variable in the middle of the sentence.

Is text embedded in graphics translated as well?

Graphics that carry text, such as maps, signs and warning boards, can be translated directly if they are supplied as layered files. If they are not layered, the translator supplies the visible text separately and the art team applies it.

References

Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge, pp. 208–219.
O’Hagan, M. & Mangiron, C. (2014). Game Localization: Translating for the Global Digital Entertainment Industry. John Benjamins.
IGDA Localization SIG (2021). Best Practices for Game Localization.