Text Fragmentation in Localisation: Source Files and the Problem of Context

In the translation of a book the text flows from beginning to end. The translator has read the previous page, can see the next one and knows who is saying what to whom. In software, app and game projects the situation is the reverse. The text does not come to you as a whole but in pieces cut off from one another.

Contents

Text fragmentation in localisation is not a choice but a natural consequence of the way these products are made. As the source book states, the text assets in software or games do not have a linear structure that proceeds sentence by sentence; they are stored in source files or embedded in the code (Jiménez-Crespo 2024, p. 11).

This article looks at the origins of fragmentation, at the concept of the source file, at the difference between a string and a sentence, and at what loss of context means in practice. At the end we look at concrete ways of managing fragmentation rather than eliminating it.

Where does text fragmentation come from?

The translation process built for print publishing is known in the industry by the steps translate–edit–publish. This flow could not easily be applied to digital products, because the way these products were produced, developed and used was different (Jiménez-Crespo 2024, p. 11). At the centre of the difference lay the question of where the text physically sits.

In the early days, localisation engineers and developers extracted the text strings embedded in the programming code into separate text files. These files were sent to translators, and the translations that came back were put into the code and tested (Jiménez-Crespo 2024, p. 14). The text went into circulation torn away from its source.

The second factor is the way these products are used. The user does not read digital text from beginning to end; they interact with it and choose their own reading path. There is therefore no single “correct order” for the text. This shows that fragmentation is not merely a technical but a conceptual necessity.

The source file: the solution that organises fragmentation

Having texts embedded in the code caused problems for a long time. Every round of translation required developer intervention, and development and linguistic transfer waited on each other. As the source book relates, this arrangement was found to be impractical and two solutions were brought in (Jiménez-Crespo 2024, p. 14).

The first solution was to separate localisable texts, together with assets such as images containing embedded text, from the code and gather them in source files. The second was to plan localisation and internationalisation from the very beginning. Every localisation file format we use today is the legacy of those two decisions.

The source file does not eliminate fragmentation; it makes it orderly and manageable. The text is still in pieces, but each piece now has an identity, a key and usually a note. The fact that the localisation process can be audited rests on this.

Another gain from the separation is simultaneity. Because the text is separate from the code, translation can go forward while development continues. Releasing the same product in different regions at the same time, the practice known in the industry as simship, has become possible largely thanks to this structural separation.

String or sentence? The question of the unit

In localisation the unit of work is not the sentence but the string. A string is an independent piece of text displayed somewhere in the interface. A one-word button label and a three-sentence error message can each be a single string. The unit, in other words, is not grammatical but technical.

The practical consequence of this distinction is that one sentence may be split across more than one string. Two pieces that sit side by side in the interface sit far apart in the file as two separate lines. The translator sees them separately and can only guess at the relationship between them.

In a language such as Turkish, which is agglutinative and has flexible word order, this splitting has more serious consequences. A structure built up by suffixation in the source language may have to be built in a different order in the target language. The pieces can each be correct separately and broken once joined.

How does it differ from segmentation in CAT tools?

This subject is often confused with segmentation in translation memory tools. The two look similar, but they have different origins. Segmentation is the division of a running text into sentences by the tool; the software makes the decision and the segments can be merged if wanted. We deal with this subject separately in the relevant articles in our knowledge centre.

Fragmentation in localisation, by contrast, is in the text itself. Strings are separate because the architecture of the product requires it; they cannot be merged, because at runtime they are displayed in different places and under different conditions. The same string may appear as a heading on one screen and as a notification on another.

For this reason the problem of context in localisation cannot be solved by tool settings alone. It requires knowledge of the product architecture, of string reuse and of the flow between screens. The source book’s insistence that “the localiser is not simply a translator specialised in digital texts” points to precisely this.

Multimodal text: how wide is the unit really?

Here the source book makes an important criticism. In the industry’s common definitions the concept of “text” is understood reductively, as chains of words alone; whereas the multimodal relationship that makes up a coherent digital text takes in linguistic, visual, auditory and interactive elements together (Jiménez-Crespo 2024, p. 21).

On this view a game is a single, unified text conveying information through different channels: writing, sound, image, movement and haptic feedback produce meaning together. Working only from a list of strings means not seeing the greater part of that whole.

The table below compares the question that each different definition of the unit answers.

Unit	How wide?	Who uses it?	When is it enough?
String	A single piece of interface text	Developer, localisation engineer	In technical tracking and file management
Segment	Usually one sentence	Translator, translation memory tool	In text-heavy content
Screen	All the text in one interface view	Localiser, tester	In consistency and overflow checks
Multimodal text	Writing, sound, image and interaction together	The localisation team as a whole	In evaluating the user experience

The concrete cost of losing context

The first consequence of working without context is uncertainty. A string standing on its own may give no clue as to whether it is a heading, a button or a warning. The second consequence is inconsistency: the same concept is rendered differently on different screens. The third is overflow; the space the text will take up on screen cannot be predicted.

What these three problems have in common is that they appear not at the translation stage but at the testing stage. The cost therefore comes not out of the translation line but out of the correction and retesting line. On products with a high release tempo the cycle repeats with every release.

The book’s warning about the constraint of screen space comes in here. Localisation is limited by the size of the interactive screen on which the text is displayed, and that limit shapes translation decisions directly (Jiménez-Crespo 2024, p. 18).

How is fragmentation managed?

Eliminating fragmentation is not possible; the aim is to make it visible. The most effective method is to show the translator where each string appears. String notes containing a screenshot, the screen name, the character limit and a short explanation do this job.

The second method is visual tools. The source book states that tools such as Alchemy Catalyst and Passolo, along with some cloud solutions, allow the localiser to work in an environment where the result is seen directly. Whether elements fit within the screen space is thus checked during translation.

The third method is structural: not reusing the same string with different meanings. This habit, which saves a few bytes on the development side, creates an ambiguity on the translation side that cannot be resolved. The rule should be laid down from the outset when source files are prepared.

The fourth concerns process. If the localiser has access to a test environment where the product can be seen running, the greater part of context problems is solved while the translation is still being made. On most projects this access is technically easy, yet it is usually never even raised.

The Türkiye context

The agglutinative structure of Turkish makes working with fragmented text harder than it is in other languages. A structure split across two separate strings in English may have to be built by suffixation onto a single word in Turkish. In that case the string boundaries obstruct the natural structure of the target language.

The second problem is plural and case suffixes. In texts that depend on numbers, a structure built for the singular and plural forms of the source language does not match the Turkish use of the singular after a number. If the source file does not support that difference, the translation is grammatically strained.

The third is that Turkish is a relatively low-resource language. Machine translation support weakens markedly on short strings without context. String notes and screenshots therefore become a more critical input on Turkish projects than on pairs such as English–German.

What does this mean for you?

If you are on the buying side of translation, the quality of the file you hand over directly determines the quality of the result. On a project where only a list of strings is sent, the translator is left with nothing but guesswork. Providing extra context is not an extra cost but a saving on the cost of correction.

1. Add a short explanation field for each line in your string files.
2. Mark the fields that have a character limit in the file.
3. Deliver screenshots of the critical screens together with the translation package.
4. Prevent the same string being reused with different meanings.
5. Plan on-screen testing after translation as a separate stage.

These five points markedly reduce the number of correction rounds on most projects. If you would like support with preparing files, you can write to us through our contact page.

Frequently asked questions

Why does text sit in fragments in localisation?

The text assets in software and games do not have a linear structure that proceeds sentence by sentence. This content is either stored in source files or embedded directly in the programming code. Nor does the user read the text from beginning to end; they choose their own reading path. Fragmentation is the consequence of this way of producing and using the product.

What is a source file for?

In the early days texts were embedded in the code, so every round of translation required developer intervention. The solution was to separate localisable texts and images containing embedded text from the code and gather them in source files. Translation could then be carried out without bringing development to a halt.

Are a string and a sentence the same thing?

No. A string is an independent piece of text displayed somewhere in the interface; a one-word button label and a warning of several sentences can each be a single string. A sentence is a grammatical unit, whereas a string is a technical one. The same sentence may be split across more than one string.

How can loss of context be reduced?

The most effective method is to show the translator where each string appears. String notes containing a screenshot, the screen name, the character limit and a short explanation do this job. In the industry, visual tools such as Alchemy Catalyst and Passolo, along with some cloud solutions, make it possible to work while seeing the result directly on screen.

Sources

• Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge, pp. 8, 11, 14, 18, 21.
• Pérez González, L. (2019). On multimodal text and the production of meaning, as cited in Jiménez-Crespo (2024).
• Unicode CLDR and plural rules documentation, a reference source for differences in plural forms across languages.