Lack of Context in Software: Why Is a Screenshot Essential?

Good translation calls for good understanding. In software translation, though, what is put in front of the translator is usually not a sentence but a single word torn from its context: “Open”, “Close”, “Home”. Is this word a button, a heading or a status message? That uncertainty is exactly what lack of context in software means.

Contents

Separating the code from the text is a gain that makes localisation possible, but it comes at a price: the text is cut off from the place where it is used. In this article we look at why the lack of context in software is unavoidable, at the errors it leads to, and at how the screenshot and the developer note close that gap.

Why is context lost?

Visible text in software is separated from the source code and held in source files (Jiménez-Crespo, 2024). These strings usually reach the translator as an unordered list; two consecutive lines can sit in completely different places in the interface. Because the translator does not see the text in the running product, every string has to be weighed up on its own.

This fragmentation is a natural consequence of translation memory and of the logic of segmentation. The text is divided into workable units, but that division divides the context as well. The translator often cannot tell how one string joins up with another, or which screen it appears on.

The result resembles what is called “collage translation”: the parts are translated one by one without anyone seeing the text as a whole. In software this is an unavoidable structural feature. The solution is not to do away with the fragmentation but to add the context back from outside.

How does a string without context go wrong?

The most classic examples of the lack of context are short words with more than one meaning. Words such as “All” or “Any” take different renderings from one product to the next; which translation is correct can be settled only by looking at where the word is used (Esselink, 2000). The same problem holds for Turkish.

The table below shows the typical error types that come out of the absence of context, and their causes.

Type of ambiguity	Example	Risk
Verb or noun?	“Ara”	Unclear whether it is a button (verb) or a heading (noun)
More than one meaning	“Home”	No telling whether it is the home page or a dwelling
String with a placeholder	“Yeni %s”	The type and number of the variable are unknown
Abbreviation	“Mon”	Unclear how many letters are needed in the target language

A button label needs a verb, a heading needs a noun. For a button that starts a task, for instance, “Başla” (a verb) is right in Turkish, whereas if the same word is a section heading a different form may be needed. Without context, that distinction is left to guesswork.

The role of the screenshot

The most practical way of closing the context gap is the screenshot. Cloud-based localisation tools (Transifex, Phrase and Smartling among them) offer the option of attaching a screenshot and a context note to every string. The translator then sees the string in the running interface, in its real place.

A screenshot solves three problems at once: it clarifies the meaning of the word, it settles its tone, and it shows how tight the available space is. The translator both chooses the right rendering and sees whether the text will fit in the box. This puts evidence where guesswork was.

Visual localisation tools (Alchemy Catalyst, Passolo) go further still: the translator previews the interface directly and edits the string in place. Whether it is a screenshot or a live preview, the principle is the same: seeing the text where it is used.

When the developer has to be consulted

A screenshot is not always enough. What value a placeholder will be filled with, or where a string will be inserted dynamically, is often something only the developer knows. In that situation the right thing to do is to ask rather than to guess (Savourel, 2001).

In a two-variable string such as “%s to %s”, for example, it is unclear whether the variables will be day names, file locations or numbers. The translation of the preposition between them depends on that value. Consulting the developer is the only reliable route in cases of this kind.

In a well-designed localisation process this channel of communication is opened from the start. On projects where the translator can put questions and the developer answers quickly, context-related errors drop markedly. As part of our software localisation services we make this feedback loop standard practice.

Steps for securing context

Managing the lack of context calls for discipline on the developer’s side as well as the translator’s. The sequence below heads off most context errors before they arise.

1. Give the source strings meaningful string identifiers and developer notes.
2. Attach a screenshot to every string where that is possible.
3. Flag short strings with more than one meaning separately.
4. Open a channel through which the translator can put questions to the developer.
5. Close ambiguities with answers, not with guesses.

The shared aim of these steps is not to leave the translator on their own. The richer the context provided, the more accurate the translation and the smaller the need for correction after delivery.

How do string identifiers carry context?

A screenshot may not always be to hand; in that case another instrument that carries context is the string identifier. Every piece of text in the source files is marked with a unique label, and that label often gives away the function of the text. An identifier with a meaningful name offers the translator a silent clue as to where and how the string is used.

If a string identifier makes clear that the string belongs to a button, for instance, the translator will cast that text as a verb; if it shows that it belongs to a heading, they will prefer the noun form. This small piece of information brings back much of the meaning that is lost in a list without context. Well-designed identifier names do not fully take the place of a screenshot, but they lighten its load.

It therefore raises the quality of localisation directly when developers give string identifiers meaningful labels instead of arbitrary numbers. When the identifier, the screenshot and the developer note come together, the context gap all but closes. The narrower the area in which the translator has to guess, the fewer the errors.

The cost of the lack of context in software

The lack of context in software is not merely a translation difficulty; it is a measurable cost item. When a string translated without context enters the product carrying the wrong meaning, the error comes to light only at the testing stage or through user feedback. At that point putting it right takes far more work than a simple question asked at the translation stage would have done.

This cost grows in proportion to the number of languages. When the same ambiguous string is sent out to dozens of languages without context, each language yields its own misreading and its own round of correction. A screenshot supplied at the outset, or a single context note, can prevent every one of those rounds.

Providing context is therefore not a luxury but a way of saving money. A small effort invested at the start of the process does away with a much larger correction bill at the end. Teams that take context seriously reach release with fewer items of feedback and in less time.

Other information that enriches context

The screenshot and the string identifier are the cornerstones of context, but they are not the only sources. A well-prepared translation package can carry extra metadata for each string: where the text is triggered, which character it belongs to, the greatest number of characters it can take. Details of this kind turn an abstract string into a concrete scene in the translator’s mind.

A short explanatory note added to a string, for example, makes clear whether that text is an error message or a message of congratulation. The tone changes completely with that information. In the same way, a character limit supplied along with the string lets the translator produce a rendering that fits at the first attempt.

When all this information comes together, the area the translator has to leave to guesswork falls almost to zero. The more channels context comes through, the safer the translation. A good localisation process rests context not on a single method but on several sources that complete one another.

The Türkiye context

Turkish is one of the languages most affected by the lack of context in software. Because the same root can take both noun and verb inflection in Turkish, it is hard to work out the function of a word in a string that has no context. “Ara” can be a verb on a button and a noun in a heading; without a screenshot, choosing the right form is left to guesswork.

The agglutinative structure of Turkish can also make it necessary to change the text around a placeholder according to the type and number of the variable. That turns context information from a mere convenience into a requirement for correct translation. The context note the developer supplies is reflected directly in quality on Turkish projects.

In the local market many software projects hand over their translation files as spreadsheets without context. Quick though this approach looks in the short term, it increases the number of correction rounds. Teams that supply context from the start move through the Turkish version with far fewer items of feedback. In interfaces dense with short labels that carry more than one meaning in particular, supplying screenshots and string identifiers raises Turkish quality directly; a translation done without that information usually needs a second round of review.

What does this mean for you?

When you have your software translated, what you give the translator determines directly what you get back. If you send a list of strings without context, even the best translator is forced to guess. Enriching the context is the cheapest way of bringing correction costs down from the outset.

1. Add the screenshots and the string identifiers to the translation package.
2. Note separately the strings that are dynamic or carry more than one meaning.
3. Set up a question-and-answer channel between translator and developer.
4. After the first delivery, review the context-related feedback as a batch.

If you are not sure how to set this process up, you can look through the localisation guides in our knowledge centre, or request a quote for your project and talk through how to proceed. A properly designed flow of context secures the translation from the very start.

Frequently asked questions

Why does a lack of context arise in software?

The text is translated in files separate from the code, as unordered strings. Because the translator does not see the string in the running interface, there is no telling in which sense the word is used.

Why does even a single word cause trouble?

Because the same word may be a button, a heading or a status message. A word without context, for example, can be translated wrongly before it has been established whether it is a verb or a noun.

How does a screenshot solve this problem?

It shows the translator where the string appears and in what function. The meaning, the length and the tone of the word are then settled correctly; evidence is put where guesswork was.

Does the developer have to be consulted?

In some cases, yes. If a screenshot is not enough, only the developer can clarify what value the placeholder will be filled with or where the string is used.

Sources

• Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge (Ch. 8).
• Esselink, B. (2000). A Practical Guide to Localization. John Benjamins.
• Savourel, Y. (2001). XML Internationalization and Localization. Sams.