What Is Pseudo-Localisation? Finding Faults Before Translation

The cheapest way to find out whether an interface is ready for translation is to try it out before anyone has translated a word. Pseudo-localisation does exactly that: it replaces the original text with fake but realistic equivalents and shows you what becomes of the screen.

Contents

The definition can be summed up as follows: the automatic replacement of the original strings in a piece of software or an application with strings that represent the characters of the target languages and that have been lengthened by a set proportion (Schäler 2012, cited in Jiménez-Crespo 2024, p. 50). The aim is to see in advance what effect translation will have on the product.

For the party buying translation, this is more than a technical detail. Whether or not the test is run has a direct bearing on how many rounds of rework a project will need and on whether the delivery date holds.

What is pseudo-localisation and how does it work?

The method is simple. The text in the product’s source files is taken, transformed by a predefined algorithm and put back in place. The transformation usually does two things: it increases the length of the string and adds accents, or marks from other alphabets, to its characters.

The text that comes out is not a readable language, but it stays recognisable. On a button, a lengthened and marked-up version appears in place of “Kaydet”. That makes it clear at a glance which part of the screen overflows and which text is being cut off.

The second benefit of the test is that it exposes text which is not being translated. If something on the screen has not been transformed and sits there unchanged, that text is not in the source files but buried in the code. This is a finding that must be put right before translation begins.

The same logic is applied through invented languages known as “pseudo-languages”. These correspond to no real language; they are designed to test particular features such as right-to-left writing, accented characters or emoji support. A product’s robustness can therefore be measured even while the target language is still undecided.

The most practical thing about the test is that it requires no knowledge of any language. The person looking at the screen does not have to know German or Arabic; it is enough to see a truncated line of text, two buttons overlapping or a heading spilling out of its box. That turns the test into a job the product team can do directly.

Why is it done before the real translation?

In localisation, the cost of a fault multiplies according to the stage it is found at. In the waterfall model, if a problem surfaces after the process has moved on, the fix is both expensive and slow; the developers may already have gone on to something else (Jiménez-Crespo 2024, p. 57).

Pseudo-localisation pulls that risk forward. Screen overflows, truncated headings and broken alignments become visible before a single word has been translated. The correction is made at a point where the design is still flexible.

In commercial terms this means that instead of fixing the same fault separately in fifteen languages, you fix it once at source. As the number of languages grows, the return on this test rises not in a straight line but through a multiplier effect.

The test also puts the quotation process on firmer ground. With the findings in hand, the price you get from a supplier rests on measurement rather than guesswork, and the chance of a change of scope halfway through the project falls. What the engineering hours will come to also stops being an estimate and turns into a concrete line item.

Types of pseudo-language and what they test

Large development environments offer this test as a ready-made option. The pseudo-language types defined in Apple’s developer tools show clearly which problem is tested by which method (Jiménez-Crespo 2024, p. 50; Apple Developer documentation).

Pseudo-language	What it does	What it tests
Double length	Doubles the text	Whether boxes cope with growth
Right to left	Reverses the writing direction	Whether the interface can be mirrored
Accented	Adds accents to characters	Line height where letters grow taller
Emotional	Places emoji in the text	Whether symbols display correctly
Bounded string	Encloses the text in markers	Clipped and truncated text

Every row in the table in fact answers a separate question. Can your interface carry the text that will grow when it is translated into German? Can the layout be mirrored if an Arabic or Hebrew version is asked for? Put late, these questions have expensive answers.

Nor are the expansion rates chosen at random. On the benchmarks used in the industry, text can lengthen noticeably when English is translated into German, while in languages such as Japanese or Korean it can shrink (Eriksen 2019 data). The test imitates these differences.

Which problems does it catch?

The findings of the test usually fall under these headings:

1. Text that does not fit a box, a button or a menu.
2. Wording that has not been pulled out into the source file and is still buried in the code.
3. Sentences that are split into fragments, joined at run time and will break in translation.
4. Lines clipped by accented letters, and broken line spacing.
5. Symbols, arrows and alignments that do not flip in right-to-left writing.

The third item on this list is the most insidious. The fragments “Toplam” and “adet”, which look right in the source language, may call for a different order in Turkish once they are joined, and the translator cannot see the problem because they are looking at each fragment on its own.

Most of the findings are settled on the design side: a flexible layout instead of a fixed width, a shorter label instead of an abbreviation, a box that allows two lines instead of one. None of them is a translation decision; every one of them is a product decision.

Does responsive design make this test unnecessary?

Most sites and applications today are built with responsive design, which adjusts itself to the size of the screen. This approach solves a good part of the expansion and contraction problems that arise between writing systems (Jiménez-Crespo 2024, p. 49).

It is not always enough, though. A responsive layout manages width; it does not manage meaning or readability. When a three-word menu heading drops onto two lines there is technically nothing wrong, but the visual hierarchy breaks down and the user hesitates.

There are also components that have to stay at a fixed width: notification boxes, tables, chart labels, email templates. In these areas pseudo-localisation is still the fastest warning mechanism.

In short, responsive design does not take the place of the test; it reduces the number of faults the test will find. The two complement each other.

When and how often should the test be run?

The right moment for the first run is once the product design has settled but before the first translation order is placed. At that point interface changes are still cheap and all the findings can be gathered into a single round of fixes. Running the test after translation means doing the same work twice.

For products that release continuously, a one-off check is not enough. Because every release adds new screens and new text, it is better to tie the test into the build process and let it run automatically. A piece of text buried in newly added code is then caught before it reaches the production environment.

When setting the scope, it makes sense to give priority to the risky screens rather than to all of them. The payment flow, form validation warnings, notification text and email templates are both the most critical areas and the ones that overflow most often.

How the results are to be reported should also be settled at the outset. A simple table that keeps the screenshot, the identifier of the string concerned and the proposed fix together will cut the volume of correspondence between the developer and the language team noticeably.

Where do the limits of the test lie?

Pseudo-localisation measures technical robustness, not meaning. A wrong choice of term, an image that is unsuitable in the target market, a culturally wrong colour or symbol will not show up in this test. A separate cultural acceptability review is needed for those.

Nor does the test solve the context problem. Which screen a translator saw a string on, and whether a word is a heading or a button, still calls for separate information. Screenshots, or tools that make it possible to work in context, are used for this.

A supplier that offers pseudo-localisation on its own as a quality guarantee is therefore telling only half the story. The test is one item on the pre-localisation checklist; it is not the whole list.

One last limit has to do with expectations. The test imitates expansion rates on average values; in real translation some sentences can go well beyond that average. The result should therefore be read not as “no problems” but as “the known problems have been cleared”.

The Türkiye context

Turkish is one of the languages for which pseudo-localisation typically pays off. Because the language is agglutinative, a short English label can turn into a long inflected phrase in Turkish. “Clear filters” is two words, whereas “Filtreleri temizle” takes more space, and a narrow button will not carry it.

The characters peculiar to Turkish set a second test. The dotted and dotless “i” can give the wrong result when case is converted; the letters ğ, ş and ç change the line height in some typefaces. The accented pseudo-language brings these problems out quickly.

For software going out from Türkiye to markets abroad, the risk runs the other way. When a product is developed in Turkish and then translated into English the text shrinks and the screens look empty; when an Arabic version is asked for, the writing-direction problem takes the design right back to the beginning. It is worth running the test in both directions.

What does this mean for you?

Pseudo-localisation will not cut your translation budget directly, but it does lower the cost of the corrections and delays that surround translation. Following these steps when you place an order will make things easier:

1. Ask your development team for a pseudo-localisation run before translation starts.
2. Add the resulting screenshots to the localisation kit and share them with your supplier.
3. Put the text that turns out to be buried in the code on the list of jobs to be fixed.
4. Tell the translator in advance which fields have character limits.

You will find more material on preparing for localisation in our knowledge centre. If you would like us to assess with you whether your product is ready, you can share your file structure through our quotation page.

Frequently asked questions

Does pseudo-localisation take the place of translation?

No. The text it produces is not a readable language; its purpose is not to carry meaning but to test whether the interface stands up to different languages. The real translation process runs as normal after this test.

Who carries out this test?

Usually a developer or a localisation engineer, because the test works inside the source files and the build process. A translation agency can recommend that the test be run and can interpret the findings, but carrying it out mostly sits with the product team.

Is it needed for a small website too?

It can be applied on a smaller scale. Even on a site of a few pages, filling the text with samples lengthened by about thirty per cent and checking the screen will show most overflow problems in advance.

Which faults can pseudo-localisation not catch?

Those to do with meaning. A wrong choice of term, a culturally unsuitable image or wording that runs against the target market will not show up in this test. The test measures only technical and visual robustness.

Sources

Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge, pp. 49-50. · Schäler, R. (2012). “Localization”. Routledge Encyclopedia of Translation Studies. · Apple Developer, “Preparing Your Interface for Localization” documentation. · Eriksen (2019), compilation of text expansion rates.