Text Expansion in Software: Why Doesn’t the Translation Fit the Interface?

When a software interface is translated from English into Turkish, the first problem is usually not one of meaning but one of space. A button label that fits comfortably in the source text spills outside the box in translation, or half of it is cut off. This phenomenon is called text expansion, and it explains why even a well-designed product can look broken once it has been localised.

Contents

Text expansion is an engineering and design problem, independent of translation quality. Even when the translator picks the right word, the nature of the target language may call for more characters than the source language. This article takes up where expansion comes from, how it breaks the interface, and how it is managed on the development side and the translation side alike.

What is text expansion and why does it happen?

Text expansion is a string taking up more room when it is carried over into another language. The most basic feature of software localisation is the separation of code from visible text (Jiménez-Crespo, 2024); that separation, however, is no guarantee that the length of the translated text will not strain the design. Because English is the language of development and of coding, interfaces are usually drawn to the length of the English text.

The most important rule of expansion is that the shorter the text, the greater the proportional expansion. Single-word labels such as “OK” or “New” can grow to two or three times their length in the target language. In long help paragraphs the ratio drops, because within the structure of a sentence the excesses balance one another out.

The source of expansion is mostly the structure of the language: compound words, inflectional endings, gender and number agreement, long equivalents. Expansion is therefore not random but a predictable tendency tied to the language pair. The localisation team has to allow for it from the outset.

Which elements expand, and by how much?

The level of risk from expansion varies with the type of element. The table below summarises the expansion tendency of interface elements in qualitative terms. The aim here is not to give exact ratios but to show which element is the more fragile.

Element type	Expansion tendency	Typical risk
Single-word button or label	Very high	Text being cut off, not fitting the button
Menu and tab heading	High	Overflow of the menu width
Error and notification message	Medium	The dialogue box growing
Help paragraph	Low	More scrolling required

German with its compound words, Russian with its inflectional structure and Finnish with its long words frequently run markedly longer than English. Agglutinative structure creates a similar pressure for Turkish as well; when several suffixes attach to a single word root, a label can come out longer than expected.

How does expansion break the interface?

The errors reported most often in the localisation quality assurance (LQA) process arise from precisely this: clipped text, overlapping elements and overflowing strings. As Torres del Rey (2022) points out, even visual tools provide separate checking functions to catch these errors.

Clipping is the most dangerous of them, because the user may not notice that text is missing. When a button reading “Save and Close” appears as “Save and Cl…”, its function becomes unclear. Overlap, for its part, makes two labels unreadable. Fixed-width dialogue boxes magnify these problems.

The problem is not merely aesthetic; it affects usability directly. If the user cannot work out which button to press, the product’s credibility suffers. Expansion should therefore be treated not as a cosmetic defect noticed after delivery but as a requirement to be designed for from the start.

Adjusting boxes with visual tools

Visual localisation tools (such as Alchemy Catalyst, Passolo and Lingobit) come into play at this point. They allow the translated interface to be previewed and the box dimensions to be adjusted directly. The translator or the localisation engineer can widen a button or reposition a label while translating.

Cloud-based tools (Transifex, Phrase, Smartling) often do not offer a WYSIWYG preview; instead they make it possible to attach screenshots and context notes. That too lets the translator see the string in place, and so reduces the risk of expansion. Both approaches serve the same purpose: seeing the text in place.

The way to settle expansion for good, though, is to use a responsive layout and automatically resizing components at the internationalisation stage. If the code has that flexibility, the interface adapts itself even when the translation runs long.

Managing length on the translation side

Not all of the expansion can be solved by design; part of the work falls to the translator. In fields with a character limit the translator uses condensation (a shorter but equivalent rendering) and, where necessary, approved abbreviation. The aim is to fit the text within the limit while preserving the meaning.

The work follows these steps:

1. Read the context of the string and its character limit, if there is one.
2. Produce a natural and complete rendering, then measure its length.
3. If the limit is exceeded, condense without damaging the meaning.
4. If you have to, fall back only on accepted abbreviations.
5. In doubtful cases, ask the developer whether the field can be widened.

This process is a standard part of the work we carry out under our software localisation services. It is worth remembering that abbreviation is the last resort and that the first solution is always flexible design.

Seeing it early through pseudo-localisation

The most effective way of not leaving text expansion to delivery day is pseudo-localisation. In this method, strings are artificially lengthened and padded with special characters at the development stage, while there is still no real translation. The team can then see in the real interface which button will overflow and which label will be clipped, before translation has begun at all.

The strength of pseudo-localisation is that it brings the problem out at the right time. When a design flaw is found during development, the code is easily corrected; when the same flaw is found after translation has been completed for hundreds of languages, correcting it costs far more. Mature localisation processes therefore adopt pseudo-localisation as a pre-check step.

The technique brings out early not only length but other risks as well, such as right-to-left languages and special characters. A team that has once seen text expansion at its true scale builds the interface more flexibly from the start. Pseudo-localisation, in other words, does not solve the problem, but by making it visible it allows it to be solved cheaply.

Expansion is really a design decision

The way to defeat text expansion for good runs through seeing it as a design problem rather than a translation problem. An interface that uses a responsive layout, automatically resizing components and dynamic alignment at the internationalisation stage adapts itself even when the translation runs long. This approach removes the need to make manual corrections separately for every language.

Fixed-width boxes, fixed-position labels and screens drawn pixel by pixel are the greatest enemy of expansion. A layout once locked to English produces a new problem in every new language. Components that grow with the space available and stretch with the number of lines, by contrast, can carry dozens of languages on a single design.

Expansion decisions are therefore taken at the design desk, long before translation begins. If the designer asks “what happens if this text doubles in length?” while drawing a button, the work of the translator and the engineer is made easier from the outset. A well-internationalised interface is the soundest ground there is for keeping localisation invisible.

Preparing the source text for expansion

Managing text expansion is the responsibility not only of the target language but of the source text as well. The shorter and more economical the source strings are written, the smaller the chance of the translation exceeding the limit. Needlessly long labels, ornate wording and repetition grow further still in the target language and strain the interface.

Another important point is to avoid assembling strings piece by piece. Placing two separate texts side by side at run time may work in English, but in other languages it produces unreadable results because the syntax breaks down. Translating each sentence as a complete unit keeps both the meaning and the length under control.

The last leg of preparing the source is to set character limits at the outset and pass them on to the translator. If it is stated in advance how many characters a field can carry at most, the translator produces a rendering that fits on the very first pass. Translation done without that information leads to later rounds of compression and to a loss of quality.

The Türkiye context

Turkish creates a pressure of its own where text expansion is concerned. Agglutinative structure lengthens short labels in cases where several suffixes pile onto a single root: a word such as “Ayarlar” may be no longer than its English equivalent, but inflected forms such as “Bildirimlerinizi” or “Kaydedilenler” can cause trouble in narrow spaces.

A font layer is added on top of that. If the Turkish characters ç, ğ, ı, İ, ö, ş and ü are not embedded correctly in every font, expansion and character corruption appear at the same time. This is why teams preparing a product for the Turkish market need to test the interface text on a real device, with the real font.

In the local market most projects run from English into Turkish. Expansion in that direction is generally moderate, though its effect grows on narrow mobile screens. Planning length management from the outset when localising into Turkish is far cheaper than corrections made after the event.

What does this mean for you?

If you are taking your product into Turkish or into other languages, you should see text expansion not as a surprise but as a cost item you can plan for. Planning early is far more economical than wrestling with an interface that looks broken on launch day.

1. Design the interface with a responsive layout rather than a fixed width.
2. Mark the fields that have a character limit before translation begins.
3. Provide the translator with screenshots and context notes.
4. Run a visual test on a real device before delivery.

Most of these steps are taken before translation, at the design desk. If you are not sure how to proceed, you can look through the localisation resources in our knowledge centre, and for a specific project you can consult us and request a quote. Our aim is not to sell but to help you set the work up properly before delivery.

Frequently asked questions

What exactly is text expansion?

It is a source text taking up more characters when it is translated into another language. Short interface labels are the elements that expand most; in long paragraphs the ratio drops.

Which languages expand more than English?

Languages such as German, Russian and Finnish generally run markedly longer. In Turkish, agglutinative structure can make short labels come out longer than expected.

Is the expansion problem solved by translation?

Partly. The translator can help with abbreviation and condensation, but the real solution is designing the interface flexibly and making the boxes resizable.

How do we see text expansion before delivery?

Through pseudo-localisation and visual localisation tools. These lengthen strings artificially and bring out the elements that overflow or are clipped on screen while development is still under way.

Sources

• Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge (Ch. 8).
• Esselink, B. (2000). A Practical Guide to Localization. John Benjamins.
• Torres del Rey, J. (2022). “Machines and Technology” chapter, localisation tools and QA functions.