What Is Digital Text? Three Ways Screen Text Differs from Print

When you buy translation you assume you are holding a single, whole document: a fixed text with a clear beginning, middle and end. On your website, in your mobile app or in your SaaS dashboard, that is not the case. What the user sees on screen is usually made up of fragments gathered from a content repository at that very moment.

Contents

Digital text is the concept that names precisely this difference. Most of the problems that arise in localisation come from carrying an understanding of translation suited to print onto the screen. The translator renders the string in front of them correctly; the user sees an inconsistent whole on screen. Both are right; the fault lies in the design of the process.

This article sets out the three points where digital text departs from print, and how those differences show up in your translation budget, your support workload and your conversion rate.

Where does digital text depart from print?

Digital text is a whole that is read on screen and that the user can act upon. In print, the order of the pages does not change. In digital text, the order is built by the user’s clicks. Right at the start of the translation process, this difference determines how the files will be split and what the translator will actually see.

The literature defines digital text as an interactive digital object that is developed coherently as a unit and presented to the user as a unit (Jiménez-Crespo 2013). The critical word in that definition is unit. The user perceives your product as one thing; you, meanwhile, have it translated across hundreds of separate files.

Pym’s plainer definition arrives at the same place: a text is anything distributed as a unit (Pym 2004, p. 17). Your store page, your app and your notification copy are a single text in the user’s eyes. Any difference of style between them appears as a single flaw, and as your brand’s flaw.

Interaction: text is now a field of action

Text on screen offers the user possibilities for action; the literature calls these action possibilities, or, to use the original term, affordances (Gibson 1977). Reading a news page, you expect to click a link, to open an embedded video, to share the content. Those expectations are part of the text and have to be preserved in translation.

The problem usually surfaces here: while the button label is being translated, the action itself is overlooked. When a one-word string is rendered as a page heading rather than an action, the user cannot tell what will happen. Hesitation before clicking grows, the basket abandonment rate rises, and your support team fields the same question over and over.

In interactive text, a translation decision determines not only meaning but also the user’s next move. That is why renderings that are grammatically correct yet functionally empty are a real cost item in digital text translation. Measuring it does not take an A/B test; looking at the support records is usually enough.

An affordance is not built with words alone. A change of cursor, a colour darkening, a shadow under a button all carry the same message. Translation must not disturb this visual layer. If a long Turkish rendering pushes a button onto two lines, the user is slow to notice that there is an action there, and that is a measurable loss.

Multilinearity: every user reads a different text

The second defining feature of digital texts is that they are not linear. They may have no clear beginning or end. The user follows a path of their own choosing among links and actions. Two visits to the same e-commerce site can produce different texts, depending on user preferences and past behaviour.

The effect on translation is direct. Once a sentence fragment enters the translation memory with a single rendering, it is reused in three separate contexts. A phrase that sits well in a promotion box jars in an error message. A heading that looks short on a product card overflows in a filter menu.

The remedy is to stop using the same string everywhere and to move context information into the source file. On the developer side, that means adding a comment field to the string identifiers. When that field is left empty, the cost appears not at the translation stage but after release.

Collective production: no single person writes the text

The third feature is that digital texts are written and localised by communities rather than by individuals. One measurement showed that the English version of the American Centers for Disease Control site held more than two hundred and forty-four thousand pages, while its Spanish local version was left with one thousand eight hundred and thirty-four (Jiménez-Crespo and Tercedor 2021).

The same study found dialect features belonging to different countries in the pages of the local version. In other words, translators from different countries produced the text and no single line of style was established. The picture in large software projects is similar: the translation memory of a Microsoft operating system released in 2000 held more than three hundred and thirty thousand segments.

Your own scale may not be anything like that large. But if three freelance translators, one agency and two marketing specialists are touching the same product, you will have the same problem. Consistency does not arise on its own; it is built with a style guide, a term list and a single point of approval.

Blind localisation: the price of a string without context

In localisation, the file in the translator’s hands is often not a text but a heap of strings in random order. The literature calls this way of working blind localisation (Dietz 2006; O’Hagan and Mangiron 2014, p. 119). In workflows of this kind, the notion of the document is said to disappear entirely (Macklovitch and Russell 2000, p. 140).

The classic example is one-word strings. When the English string open arrives without a context note, it can be either an adjective or a verb. In Turkish the distinction is sharper still: depending on the situation, the same string is translated as Aç or as Açık. The wrong choice is the difference between the user opening a box and the user reading a status.

The same problem shows up in decisions about numbers, dates and levels of politeness. If translators do not know who they are addressing, they will strike a formal tone in one part of the interface and a familiar one in another. The user reads that not as a stylistic choice but as carelessness.

The most galling thing about blind localisation is that the error is invisible at the translation stage. The file is delivered, checked and approved. The problem emerges only when the product reaches a real user. At that point the cost of putting it right is not just a translation fee but the cost of shipping a new release.

How does macro level representation rescue translation quality?

The antidote to lost context is to build a mental map of the product as a whole before translation begins. The literature calls this macro level representation. If translators know which section they are in and what that section is for, they have a chance of interpreting even a context-free string correctly.

In practice that means three concrete steps: adding screenshots to the translation package, opening an account for the translator in the test environment, and sharing a map of the product’s sections as a single-page document. All three are a day’s work, and they wipe out a good share of the revision rounds before they begin.

Knowledge of genre does the same job. Because an experienced localiser recognises the genre of the product being worked on, they know in advance which patterns are expected in which section. Working with teams that specialise by product genre therefore saves more than a cheap hourly rate does.

Four common errors in digital text translation

The table below summarises the four problems we meet most often in digital text translation, how each looks from the user’s side and how to prevent it. All four come from the process; none has anything to do with the translator’s command of language.

Problem	What the user sees	Prevention
String without context	A word on the button reporting a status instead of an action	Screenshot and usage note
Fragmented style	The same function called by three different names	Term list and a single point of approval
Incomplete scope	The link is in the menu, but the page it opens is in the source language	Fixing the scope decision in writing
Broken interaction	A translated link does not reach its target	Link testing before release

Putting these four headings on a pre-release checklist is the cheapest way to measure translation quality. If you want to build a detailed quality framework, see the localisation quality articles in our knowledge centre.

The Türkiye context

Turkish is an agglutinative language and its verb stands at the end of the sentence. That creates a direct problem in interfaces that split strings and then join them back together. Combinations of fragments that read naturally in English produce inverted or broken sentences in Turkish. Having the text translated as whole sentences rather than in pieces is usually the only way out.

Turkish renderings are also usually longer than the source text. The risk of overflow is high on narrow buttons and in mobile views. Teams that leave no character allowance at the design stage pay for it later in rounds of shortening.

Another common practice in the local market is to have only the shop window pages of a site translated, leaving the help, returns and privacy sections in the source language. The user has no trouble up to the moment of purchase; the trouble appears at exactly the step that calls for trust.

What does this mean for you?

When you have your product translated, what you are buying is not words but the consistency of the user experience. So when you compare prices, look not only at the unit rate but at the method for supplying context. The sequence below can be applied on a first project by most teams.

Draw up a map of your product’s sections on a single page and add it to the translation package.
Next to one-word strings, write whether they are an action or a status.
Open an account for the translator in the test environment; ask for at least one round of in-context review.
Fix in writing which sections will be translated, and do not leave the scope half done.
Put link, date and currency checks on the pre-release list.

If you would like to discuss which of these steps matters most for your product, you can send us your scope through our quotation form. For digital text, prices quoted without working out the scope almost always fall short.

Frequently asked questions

What is the basic difference between digital text and print?

Print is fixed and linear; its beginning, middle and end are set. Digital text is interactive, its order is built by the user and it is usually assembled from a content repository on the spot. The translation process therefore proceeds piece by piece as well.

What does blind localisation mean?

It is translating strings in random order without knowing where they appear on screen. The literature describes this state of affairs as the disappearance of the notion of the document. The result is usually renderings that are grammatically right but functionally wrong.

What is the most practical way to give a translator context?

Adding a screenshot and a short usage note to the string list is the quickest solution. If you can, open an account for the translator in the test environment; seeing the text in place removes most of the corrections that would otherwise come later.

Why are the versions of the same product in different languages not the same size?

In most organisations the scope decision varies by language. One public health site was measured as having more than two hundred and forty-four thousand pages in its English version while its Spanish version was left with under two thousand. Sections left out appear to the user as a broken whole.

Sources

Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge, pp. 122–128.
Pym, A. (2004). The Moving Text: Localization, Translation, and Distribution. John Benjamins, p. 17.
Nielsen, J. and Loranger, H. (2006). Prioritizing Web Usability. New Riders.