Code and Resource Separation: Why Does Software Text Live in a Separate File?

Every menu heading, every warning and every error message you read on a program’s screen actually lives in two separate places. On one side there is the code that runs the program; on the other, the resource file where that text is stored. The separation of code and resources is the fundamental architectural decision on which software localisation is built.

Contents

Without this separation, a separate program would have to be compiled for every language. Because of it, a single code base calls the text in the right language from outside at run time. The translator never touches the logic of the code; they work only with the file that holds the strings. The division of labour across the industry grows largely out of this boundary.

Below we explain how the separation is set up, what string IDs are for, which faults appear when the separation breaks down, and how the picture changes in open source software.

Software is not made of code alone

Say “software” and code is what comes to mind first. Yet the common definitions describe software as the whole set of programs, procedures and routines involved in running a computer system. Sommerville goes a step further: all the documentation and configuration data needed for those programs to work correctly are part of the software too (Sommerville 2010).

This broad definition matters for localisation. In a study that surveyed the existing definitions, the list of software components grows considerably longer: images, videos, audio files, configuration files, databases, fonts, mark-up files, user manuals and system documentation. Licence texts, copyright notices and patent notices belong to the same set.

Microsoft calls these two large sets the “code block” and the “data block”. Almost everything that happens on a localisation project happens in the data block. The translator does not change how the program runs; they prepare the text that the code will call at run time. This simple separation also determines who touches what.

Source code and object code: the two sides of the compiler

Source code is the human-readable code that developers work on. It is written in a programming language such as C++, Python, Java or PHP. It can be produced in a plain text editor, in a development environment (IDE) with visual programming features, or with software development kits. It also contains the comment lines developers leave for themselves and for the team.

Object code, by contrast, is the executable file produced when source code is passed through a compiler. The file with the .exe extension you download when you buy a program is the familiar example. While source code is written in a programming language, object code mostly consists of the binary numbers the machine understands and cannot be read directly.

This difference becomes visible at the testing stage. Quality specialists interact not with the source code but with the compiled object code. You can only confirm that the localised product runs, and that it sits on screen the way it should, in the compiled version. A similar arrangement applies in video games.

What matters for the localiser is the order in which the two layers come into play. Translation is done on the resource files before the build; the result appears only after the build. Any error introduced in the steps in between becomes visible only once an executable version exists. Setting time aside for testing is therefore not an option but a requirement.

How is code and resource separation set up? The satellite assembly architecture

Properly internationalised software separates the code from the assets the end user sees on screen. Text, images and videos are stored in separate files called “resources”. Instead of keeping separate source code and a separate build for each locale, the code is developed in a neutral form and tied to the external resource files by dynamic links.

This architecture is known as satellite assembly. The code reaches the resource it needs through a unique identifier. Where different locale versions exist, the code pulls the relevant text from the resource file of the target locale at run time. Adding a new language therefore means adding a new resource file, not writing a new program.

The greatest convenience this arrangement offers the translator is being able to work without touching the source code at all. In Dunne’s words, the real labour of software localisation is the translation of menu strings, dialogue boxes and string tables. If a problem arises during localisation or testing, correcting the code is the software engineer’s job.

Another benefit of the architecture lies on the maintenance side. Correcting a piece of text does not require the program to be rewritten; the line in the relevant resource file is updated and the product is built again. The same arrangement ensures that a change of style made in one language does not affect the others. Languages can move forward independently of one another.

String IDs and falling back to the default language

Every text string in a resource file has a unique identifier. That identifier may be a number or a textual label. While the program runs, a routine first determines the user’s locale, then finds the text matching this identifier in the file for that locale and prints it to the screen.

If no text is found for the identifier in the user’s language, the system falls back to the default language, which is usually English. This is the commonest cause of mixed-language screens. If a newly added string has not been translated yet, or if its identifier has changed, the user sees an English line in the middle of a Turkish menu.

A typical entry in a .po file makes this logic visible. A comment line pointing back to the source code, the msgid holding the text to be translated and the msgstr holding the translation sit side by side. The %s inside the text is a placeholder, while \n is an escape sequence that creates a line break; both are kept exactly as they are.

Identifiers are kept stable across versions for this reason. When a developer renames a label, the earlier translation of that string is technically treated as lost and has to be matched again from the translation memory. A rename that looks trivial can create dozens of lines of extra work in a multilingual product.

When the separation breaks down: text embedded in the code

Not every piece of software is developed to fit this architecture from the outset. In products written in a hurry, or built with a single market in mind, the text may be written straight into the code. String extraction tools then cannot see that text, it never enters the translation package, and it stays on screen in the source language. Putting it right is a development job, not a translation job.

A more insidious form of the same problem is a sentence assembled from fragments in the code. An order that looks natural for English does not hold in agglutinative languages or in languages with a different syntax. Problems of this kind are solved at the design stage, not at the testing stage.

1. Text that never appears in the translation package but shows up on screen.
2. The odd button label or warning left in the source language.
3. Strings with no context that read like half sentences.
4. Date, time and number formats that do not change with the language.

Reporting these symptoms early shortens the job. As you plan your localisation process, looking through the scope of our services will help you tell which work is translation and which is development.

In open source software the code is out in the open

In commercial software the code is protected by copyright and cannot be reached directly once it has been compiled. In free and open source software (FOSS) the situation is different. In these products the source code is published alongside the object code; users and developers can see it, copy it and change it. This is the clearest difference from commercial software.

For the translator this has a practical payoff: context. You can see in the repository which function an ambiguous string is called from. The GNU project classifies such software under different headings according to its copyright status.

Type	Use	Modification
Open source software	Unrestricted	Source code accessible
Copyleft software	Unrestricted	Derivative products bound by the same terms
Non-copyleft	Unrestricted	New restrictions may be added
Shareware	Time-limited	Fee or subscription once the period ends
Free software	Unrestricted	Licence permits modification
Freeware	Free of charge	Copyrighted; cannot be modified or sold

This classification also explains which products attract volunteer translation communities. In projects where the source code is open, translation contributions are usually gathered in the same repository and are visible to everyone. In a commercial product, translation moves through a closed supply chain, and context extends only as far as the client shares it.

The Türkiye context

Many software teams in Türkiye write their product in Turkish first and decide about exporting later. That sequence usually turns code and resource separation into a job done late. If the text is embedded in the code, the bill for the first export project owes more to redevelopment than to translation.

The features of Turkish raise the price of that delay. Because the language is agglutinative, sentences assembled fragment by fragment in the code usually break in Turkish; the form of a suffix changes according to the vowel before it. Concatenation logic that looks trouble-free for English produces inconsistent results when the output is Turkish.

Software built for the public sector carries one more layer. Accessibility and corporate identity requirements feed through into interface text, which makes keeping the strings in a separate file more necessary still. When the text sits apart, a terminology change requested by the institution is resolved in a single file.

What does this mean for you?

When you decide to have your software translated, the first question to ask is not price but architecture. If code and resource separation has been set up properly, the project moves predictably. If it has not, you will need to add a development item alongside the translation budget. Knowing this difference from the outset is the easiest way to keep the delivery date realistic.

1. Ask your development team in writing which file format the strings are kept in.
2. Send a sample resource file to the translation side in advance, so that format compatibility shows up early.
3. Have a scan for text embedded in the code carried out before translation starts.
4. Secure a commitment that string IDs will stay stable across versions.
5. Set aside time for a visual check with screenshots after the first delivery.

These steps may look like an added cost, but they are small next to the corrections that would otherwise follow. You can share the file format you have, request a quote and settle the scope with us.

Frequently asked questions

Does the translator touch the source code of the software?

Normally no. In properly internationalised software the translator works only with the strings in the resource files. If a change is needed in the code, the developer makes it.

If a string ID changes, is the translation lost?

The translation stays in the file, but the code can no longer call it. In most systems a string whose identifier has changed drops to the default language, usually English. This is why identifiers are kept stable.

Which files is code and resource separation done with?

It varies with the environment: .po and .pot files, .resx and .resw resource files, .properties for Java, framework-specific XML formats and XLIFF are the commonest.

Does being able to see the code in open source software help the translation?

Yes, in terms of context. You can see in the code which function a string is called from, and work out whether an ambiguous word is a menu heading or an error message.

Sources

• Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge, pp. 148–150.
• Sommerville, I. (2010). Software Engineering (9th edition). Addison-Wesley, p. 5.
• GNU gettext manual, “PO Files” section, gnu.org (online document).