Digital Products and Accessibility 6 August 2026
Error Message Translation: Text That Does Not Leave the User Stranded
An error message is the text a user reads at their most anxious moment. Translated vaguely or too technically, it leaves them on a screen with no way out.
Error message translation is the localisation of the text a user reads at the moment something has gone wrong. They read it when a transaction will not complete, a form will not send or the connection has dropped. The error message is the interface at its most tense, and for exactly that reason its translation calls for a different kind of attention from other text.
Contents
A badly translated error message leaves the user on a screen with no way out. Not understanding what has happened, they abandon the task: if it is a purchase, they leave the basket; if it is an application, they break off halfway. In this article we look at which layer of communication an error message belongs to, the rules of a good message, and the traps most often fallen into in translation.
Which layer does an error message belong to?
Two communication processes run at once in a digital product. One is the human-to-human communication between the company and the user; the other is the interaction between the user and the device. Error messages belong to that second layer, to the communication the user has with the machine. Seeing this distinction is the first step towards getting the tone right.
The example given in the source book is clear: a social network may address its users in a warm, informal voice while the error notices of the same application take a more technical tone. If the translator mixes these two voices up, either the error message turns out too flippant or the welcome text too cold. Every layer has a tone of its own.
The translator therefore needs to know which layer the string in front of them belongs to. Is the string addressing the user, or reporting the state of the system? That question settles both the choice of words and the level of politeness. A translation made without knowing the layer usually lands on the wrong tone.
The three rules of a good error message
One of the best-known heuristic evaluation principles in the usability field deals with error messages directly. Under this principle, error messages should be written in plain language without using code, should state the problem precisely and should propose a constructive solution. Three rules: intelligible language, an exact diagnosis, a suggestion that points the way.
| Weak error message | Error message that points the way |
|---|---|
| Error 0x24 | Could not connect, please check your internet connection |
| Invalid input | Enter the date in DD.MM.YYYY format |
| Something went wrong | The file is too large, you can upload 10 MB at most |
As the table shows, the difference emerges in whether or not the user knows what to do. The messages in the left-hand column say that there is a problem but offer no solution. Those in the right-hand column show both the problem and the next step. Translation is the key to preserving that difference, or to creating it.
Preventing an error beats messaging about it
The best error message is the one that never appears. The usability principles hold that something is more valuable still than a good error notice: a design that prevents the problem in the first place. Removing error-prone situations, or warning the user before they act, is better than showing an error afterwards.
This principle bears on translation as well. A hint text that explains in advance how a field is to be filled in is more useful than an error message that appears afterwards. The localiser has to translate not only the errors but also these helper texts that prevent them, and to do so accurately and clearly.
The language of preventive text also has to do with making the state of the system visible. The user should know at every moment what is going on: is the upload still running, has it been saved, is a field missing? Translating these status notices is what keeps the user from feeling lost.
Tone and code in error message translation
The commonest mistake made in translating error messages is carrying the technical language of the source across untouched. The system should speak the user’s language, addressing them in familiar words rather than in system-oriented terms. Leaving an error code or a technical abbreviation untranslated leaves the user facing a language they do not know.
Tone matters at least as much as wording. An error message should not blame the user or leave them feeling alone in the middle of a problem. Rather than saying they have entered something wrong, it is more constructive to show the expected format. In Turkish this starts with choosing the right verb mood and the right level of politeness.
This balance calls for technical accuracy and a human tone at the same time. The message has to be clear enough without being cold, short enough without being incomplete. A good error message translation stands exactly between those two extremes.
Error text with placeholders and variables
Error messages often contain variables: file size, time remaining, field name. These variables are embedded in the code with placeholders, and their positions must not be touched in translation. Where the placeholder sits may change with the sentence structure of Turkish, so the sentence has to be built to read correctly wherever the variable falls.
The agglutinative structure of Turkish poses a particular difficulty here. The suffix that follows a variable can change according to the value of that variable; where one pattern suffices in English, the sentence may have to be rebuilt in Turkish. A translation that ignores the placeholder produces a broken sentence on screen.
Error message translation therefore demands technical awareness as much as grammar. The translator has to picture how the string will be assembled at run time. Otherwise the user meets a warning that is grammatically broken or whose meaning has slipped.
Format errors: date, name, telephone
The error messages encountered most often arise from format mismatches. After the user submits a form, the system may report that the date or the surname format is wrong. Yet these formats vary from culture to culture: the order of a date, the layout of a telephone number and the split between forename and surname differ from country to country.
Localisation does not stop at translating these error messages; it adapts the expected format to the local user as well. A field that expects day-month-year in the source product should be presented to the target user in the order they are used to. The message has to ask for something the user can actually do.
This is an instance of matching the rules of the real world. The system should follow the formats the user knows and a logical order. Translating format errors therefore requires not only language but a knowledge of local habits.
Error message translation and the loss of context
The greatest translation difficulty with error messages is that they arrive cut off from their context. The translator usually sees the string without knowing which screen it will appear on or which action it will follow. The same word can be a warning in one place and a confirmation in another. A translator who does not know the context picks the wrong tone or the wrong meaning.
The way to reduce this problem is context notes that accompany the string. Localisation files can carry fields explaining when and in what circumstances a string appears. For getting an error message right, these notes are often more valuable than the words themselves.
Where the notes are absent, the translator has to build a mental map of the product as a whole. Guessing which flow an error message belongs to should be tested at the quality control stage. That way the errors caused by the loss of context are caught before they reach the user. When this testing stage is skipped, a message that looks right but appears on the wrong screen can catch the user out at an unexpected moment.
The Türkiye context
In Türkiye users run into error messages constantly in banking, e-Devlet and e-commerce applications. Most of these messages were translated from a foreign product, so they are either too technical or never quite settled into Turkish. The result is that the user gives up before completing the transaction, or rings customer services. Yet most of these messages describe simple situations the user could resolve alone; the problem lies not in the information but in the fact that it is not presented in intelligible Turkish. A good translation turns these messages from an obstacle into a helper.
The agglutinative structure and free word order of Turkish call for particular care in error messages that contain variables. Date, identity number and telephone formats are also specific to Türkiye, and a form needs to expect these formats as the local user writes them. A well-translated error message lets the user solve a problem on their own and lightens the support load. In the projects we run from our single office in Kızılay we see it too: a clear Turkish error notice often heads off a phone call or an abandoned transaction, which is why error text should be seen as a quiet investment that brings costs down.
What does this mean for you?
The error messages in your product are usually the texts that receive the least attention and affect the user the most. Translated well, they help quietly; translated badly, they can end a transaction outright. It is worth treating error text not as a detail at the edge of the design but as a tense yet decisive stop on the user’s journey.
- Bring error messages into the scope of the translation as a separate item.
- Have a context note added for each message, stating which screen it appears on.
- Adapt the expected date and number formats to the local user.
- Have the messages tested within the real flow.
To work out which of these steps is the priority for you, take a look at our translation services, and for an assessment tailored to your project you can request a quotation. A good error message translation leaves the user beside the solution rather than in the middle of a problem. This lifts both user satisfaction and the completion rate of transactions directly, an often overlooked detail with a high return. Put another way, a small amount of effort spent on error messages saves time for your users and for your support team alike.
Frequently asked questions
Why does an error message need a translation of its own kind?
Error messages are the text a user reads at the moment they meet a problem. A vague or technical translation leaves them with no way out, so it has to be clear and point the way forward.
What does a good error message contain?
A good error message is written in plain language, states the problem precisely and proposes a constructive solution; it uses wording the user can understand rather than code.
Are an error message and interface text the same thing?
No. An error message belongs to the interaction between the user and the system and usually has a more technical tone; that tone should be preserved in translation but made intelligible.
Why do error messages lose their context in translation?
Error messages usually reach the translator as separate strings, with no indication of which screen they will appear on, and that raises the risk of the wrong tone and the wrong meaning.
Sources
- Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge (Chs. 6/7).
- Nielsen, J. (2020). Heuristic evaluation principles for usability.
- ISO 9241-11, definition of usability.