Localisation 6 August 2026
Resource File Extraction: How Is Text Separated from Code in Localisation?
The first condition of localisation is that the text be separated from the code. In a product where no resource file extraction has been done, the translation process needs engineering support at every step and the cost becomes impossible to predict.
Most localisation projects lose the enthusiasm of their first day at the same point: the file to be sent to the translator simply cannot be produced. The texts are scattered through the code, some of them sit in the database and some are buried inside images. Resource file extraction exists precisely to remove this problem.
Contents
In the literature the process is known as “externalisation”, and it means separating the code from the localisable assets (Jiménez-Crespo 2024, p. 48). All language-dependent elements, including text, images and video, are held in separate files, while the code is written so that it belongs to no language at all.
This article explains what the process is, what costs arise when it is skipped, and which questions you should be asking as the party buying translation. The subject looks technical, but you see its result directly in your budget.
What is resource file extraction?
Resource file extraction means separating every expression the user sees on screen from the logic of the program. Phrases such as “Save”, “Your password must be at least eight characters” and “Your order has been received” do not sit inside the code between quotation marks; they are stored in a separate file, each matched to an ID number.
While the program runs, it reads the relevant file according to the user’s language and puts the text in place. Adding a new language therefore means adding a new file rather than changing the code. The same approach is applied in the same way to every language, the development language included.
In practice, extraction covers more than text. Date and time formats, currency display, sorting rules, units of measurement and language-dependent images are separated out on the same logic. When these are fixed inside the code, every new market creates a separate piece of development work.
The quality of the extraction determines the speed of every stage that follows. In a product that has been fully extracted, the translation process comes down to an exchange of files; in one that has been extracted only partly, every round demands new engineering hours.
Satellite assembly: neutral code, separate resources
The established name for this architecture is the satellite assembly. At the centre sits code that runs independently of language; around it stand separate resource files for each language, and these are attached to the centre at run time (Jiménez-Crespo 2024, p. 48). The visual image behind the structure is a planet with its satellites around it.
From a business point of view the most important consequence of this structure is that adding a new language puts no part of the product’s core at risk. A correction made to the Turkish version does not break the English version, because the two live in separate files.
The second consequence is speed. Correcting a mistake in a piece of text may not require you to release the whole product again; in most cases updating the relevant resource file is enough. That provides valuable flexibility, particularly in regulatory texts and campaign announcements.
The third consequence is scalability. Going from five languages to twenty is a proportionate increase in cost in a product whose architecture has been set up correctly. If the architecture is wrong, the same move turns into a rewriting project that grows out of all proportion.
Which assets are extracted?
A localisable asset is not just interface text. The table below summarises where the various kinds of content in a typical digital product are held and how each of them enters the translation process.
| Asset type | Where it is held | How it enters translation |
|---|---|---|
| Interface texts | Resource files by language | Directly, by ID number |
| Help and support content | Content management system | Connector or export |
| Legal texts | Separate document repository | Usually by hand, with legal approval |
| Images containing text | Design files | Through the layered original file |
| Audio and video | Media library | Through the subtitling or voice-over workflow |
The last two rows of the table are forgotten in most projects. Once the writing inside an image has been flattened into a plain picture file, it can no longer be extracted; a designer has to step in for each language. Keeping the layered original files is therefore a cheap insurance policy.
Legal texts call for separate attention as well. They are less a matter of translation than of rewriting in line with local legislation, and they should be marked as a separate set during extraction.
There is one more group that is easily left off the list: the texts the system sends to the user. Order confirmation emails, text messages, app notifications and the descriptions attached to error codes are usually held somewhere else, so they never make it onto the extraction list. Because users see them as part of the product, this is where a half-finished localisation is noticed most.
What happens if extraction is not done?
The symptoms of incomplete extraction look surprisingly similar from project to project:
- Some screens in the released version are still in the source language.
- Every small text correction requires a software update.
- The same expression is translated differently in different places, because it has never been gathered into a single list.
- The word count does not add up; a gap opens between the quote and the invoice.
- In the next release a good part of the work is done all over again.
What all these symptoms lead to is unpredictability. Costs cannot be estimated, delivery dates slip and quality fluctuates. The problem shows up in the translation, but its source lies in the preparation stage.
Putting it right has a cost of its own, but that cost is paid only once. The engineering days spent moving the texts into resource files pay for themselves in the second or third language.
File formats and exchange standards
Extracted content is held in different formats depending on the platform. On the web side, JSON and XML based structures are widespread; in mobile applications the platform’s own resource file format is used. What they have in common is that the text is matched to an identifier and stands outside the code.
As these files enter the translation process they are usually converted into a common exchange format. The industry has standards developed for this purpose, and almost every translation tool reads them (Jiménez-Crespo 2024, pp. 66-67). Using a standard means your content stays portable when you change supplier.
From your point of view the critical question is not the name of the format. If the answer to “if I hand these files to another supplier, will they be able to open them?” is yes, the architecture is sound. If the answer is no, a dependency has been created.
The same logic applies to the translation memory and the term list. Being able to export those in standard formats too makes any future move easier.
Who does this work, and how long does it take?
Extraction sits on the development side. In small projects the developer who wrote the product takes it on; in large ones the specialist known as the localisation engineer does. This is the only party with the authority to change the code, and it is also the party that fixes the technical faults reported by the translation team (Jiménez-Crespo 2024, pp. 62-63).
The translation agency’s role is to identify and report. On receiving the files, a good supplier flags up the texts that are missing, the sentence patterns that have been concatenated and the technical values that should not be translated, and reports them back to you. For the development team that feedback amounts to a ready-made list of things to do.
The time it takes depends less on the size of the product than on how well ordered it is. In a product built correctly from the start, extraction is a matter of a few hours of exporting. Done retrospectively, the work involves combing through the screens and moving each piece of text across one by one, so it can stretch over days.
It is therefore sounder to think of the cost of extraction as part of the product development budget rather than the translation budget. It is paid once and used in every language.
The context problem of extracted text
Separating text from code has a side effect: the translator now sees the sentences cut off from the screen they belong to. A word such as “Open” standing on its own gives no clue whether it is a button, a menu heading or a piece of status information.
There are two ways round this problem. The first is to add explanatory notes to the resource files; in well-prepared files each string is accompanied by a short note explaining what it is for. The second is visual localisation tools, which show the text on the real screen (Jiménez-Crespo 2024, pp. 60-61).
The price of working without context is guesswork. In the literature the situation is described as localisation done without sight of the context turning into an error-prone exercise in guessing. In a language such as Turkish, where the suffix structure is sensitive to context, that risk grows larger still.
The practical answer is simple: do not leave the comment fields empty when the extraction is done, and include screenshots in the kit where you can. This removes most of the correction rounds that would otherwise follow.
The Türkiye context
A large share of the software developed in Türkiye is first designed for Turkish alone. The texts are written straight into the code, because no second language is considered at the outset. When the decision to export is taken, the first job is not translation but retrospective resource file extraction.
The structure of Turkish makes that job harder still. In an agglutinative language, splitting a sentence into pieces and joining them at run time usually gives a broken result; the pattern “3 ürün eklendi” calls for different endings depending on the number and the case. Patterns of this kind have to be extracted as complete sentences from the start.
On screens that involve personal data, extraction takes on a compliance dimension as well. Privacy notices and explicit consent statements are written within the KVKK framework; managing them as a separate group is safer than keeping them in the same set as the interface texts.
What does this mean for you?
Resource file extraction is a preparation question you need to have answered before you buy translation. The following steps speed the process up:
- Ask your development team for a list of all the texts that appear on screen, in a single file.
- Flag the expressions that appear on screen but not on the list, and add them to the correction list.
- Archive the layered original files of any images containing text.
- Confirm that the files can be exported in a standard format.
We set out which file formats we work with and how we organise the process on our translation services page. If you would like us to check whether the files you have are ready for translation, you can send us a sample file from our quote page.
Frequently asked questions
Is resource file extraction the translation agency’s job?
No, this work sits on the development side. A translation agency can identify the gaps and report them, and can even pick some files apart by hand; but separating the text from the code permanently is the product team’s responsibility.
If the text has not been separated from the code, can it still be translated?
It can, but it becomes expensive and fragile. A code file has to be opened for every piece of text, every correction requires a new build, and the same work is repeated from scratch in the next release. Apart from small one-off jobs it is not sustainable.
Which file format should be preferred?
The platform of the product decides that. What matters is not the name of the format but whether translation tools can read it and keep the code intact. For exchange, standards such as XLIFF are widely used.
Can the writing inside images be extracted too?
Not directly. That is why the layered original files of images containing text should be kept, or the writing should be separated from the image and placed on top of it as a text layer. Otherwise the image has to be produced again for every language.
Sources
Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge, pp. 47-48, 60-61, 66-67. · Dunne, K. J. (2014). “Localization”. Routledge Handbook of Translation Studies. · OASIS, XLIFF 1.2 documentation.
This article is for general information only and is not legal advice.