Types of Localisation Testing: Linguistic, Functional, Cosmetic, Cultural and Accessibility

When the translation is finished, most businesses think the job is done. In localisation, though, the stage that really decides the outcome begins after that. The text is placed into the product and put to the test in the form the user will see; localisation testing is precisely the name of that test.

Contents

The literature in the field describes this stage not as a single check but as a set of complementary types of testing: review, re-integration, functional testing, cosmetic testing, cultural acceptance and user experience testing, and accessibility testing (Jiménez-Crespo 2024, p. 56).

Below we set out what question each of these types answers, who carries it out and what happens when it is skipped. When you are assessing a quote, asking which of these headings are included in the scope turns a conversation about quality into something concrete.

Why is localisation testing a separate stage?

Translation is done on a file; the product runs on a screen. The distance between the two is greater than it looks. A sentence that looks flawless in the file may not fit inside its box on screen, and a correctly translated warning may appear on the wrong screen.

The second reason is that errors do not come from a single source. Some of the problems found at this stage arise not from the translation but from the way the files were placed, from text left over from an older version, or from the code itself. The job of testing is to find the fault and to work out who should put it right.

The table below summarises the main types of testing and the question each of them answers.

Type of testing	Question it answers	Who usually does it
Linguistic testing	Is the text correct and consistent on screen?	Language team
Functional testing	Does everything work?	Testing specialist, engineer
Cosmetic testing	Has the appearance broken?	Testing specialist, designer
Cultural acceptance testing	Does it feel natural in the target market?	In-country reviewer
Accessibility testing	Can everyone use it?	Specialist or automated tool

Integration: putting the text back into the product

Before anything can be tested, the localised content has to be put back into the product. Source files are updated, uploaded to the content management system or sent to the repository. The step looks technical, but its outcome reaches the user directly.

The most common problem during placement is a mismatch. When a piece of text is matched to the wrong identifier, a completely correct translation appears in a completely wrong place. Errors of this kind are found not by reading the file but by opening the product.

The second common problem is character corruption. When a file is saved with the wrong encoding, Turkish letters turn into broken symbols. It has largely been solved today, but it is still met with on projects that work with older systems.

Integration should therefore be counted not as something before testing but as its starting point. No check made without the content being placed shows the real state of the product.

Placement also has a version dimension. If the source text has been updated while translation was under way, the content that goes back in may not match the latest state of the product. Keeping a record of which version was worked on allows mismatches of this kind to be resolved quickly.

Linguistic testing

Linguistic testing reads the text inside the product. The aim is less to catch spelling mistakes than to check whether the wording that appears on screen suits its context. This is also the stage at which you make sure the same function is called by the same name on different screens.

The most productive output of this test is inconsistencies in terminology. The words “account”, “membership” and “profile”, each of which looks right on its own in the file, leave the user hesitating when they end up side by side on the same screen. The problem is only noticed once you see the whole.

Linguistic testing also brings untranslated text to light. A button left on screen in the source language is usually not a gap in the translation but a gap in the extraction, and the finding is passed on to the developer side.

This work does not take the place of the proofreading done on the file; it completes it. Proofreading looks at the text itself, linguistic testing at where the text sits.

Who does the linguistic testing matters too. When the person who translated the text looks at their own work a second time, they tend to carry the same blind spot over. A check by a language specialist seeing the screen for the first time produces far more findings in the same amount of time.

Functional testing

In functional testing, all functions, interactive components and links are checked, and the localised version is confirmed to work correctly (Jiménez-Crespo 2024, p. 56). It calls for no knowledge of the language, yet it is one of the most critical tests there is.

Functions break during localisation more often than people suppose. A tag deleted by accident during translation, a variable name that has been altered or a link that has been broken will stop a button from working.

Forms call for attention of their own. Address fields, the order of first and last names, telephone formats and postcode validation all have to work differently for the target market. If these rules have been fixed to suit the source market, it comes out at the testing stage.

Third-party components such as payment and basket modules also fall within this test. If a component tied to an external service stays in its own language, the user meets a foreign screen at the most critical step of all.

Cosmetic testing

Cosmetic testing is concerned with appearance. Does the text fit inside its box? Do the lines overlap? Has the alignment broken? Does the typeface display every character? These are the things the user notices in the first second.

Most of the problems come from changes in the length of the text. Expansion and contraction between languages is a well-known matter, and in some languages the text grows noticeably longer than in the source language. If pseudo-localisation has been carried out, most of these problems will already have been cleared away.

The choice of typeface is tested at this stage too. Some typefaces show characters such as the Turkish dotless “ı” or “ğ” incompletely or incorrectly. This may look like a design decision, but in the end it is a legibility problem.

The most practical side of cosmetic testing is that it produces visual evidence. Findings sent with a screenshot attached are taken up by the development team without leaving room for argument.

Cultural acceptance and user experience testing

This test asks whether the product feels natural in the target market. Images, colours, example names, the way currency is displayed and the tone of voice are all assessed at this stage. A version that is technically faultless can still feel culturally foreign.

It is usually carried out together with an in-country review by a specialist living in the target country. This review is different from proofreading: it focuses on technical consistency, completeness and adherence to the terminology that has been agreed (Esselink 2000, p. 15).

The findings are often small but telling: a reference to a public holiday belonging to the source market, an example address that is not local, a payment method that does not feel familiar. On their own these do not count as errors, but they weaken the sense of trust.

How deep this test goes depends on the level of localisation you have chosen. At a surface level only the obvious mismatches are cleared away; at more advanced levels the whole experience is reviewed.

Accessibility testing

Accessibility testing checks that every component is usable for users in different conditions of access (Jiménez-Crespo 2024, p. 56). Navigating with a screen reader, working with a keyboard and sufficient colour contrast all fall within its scope.

Localisation has an effect here that is easily overlooked. Alternative text for images, accessibility labels on buttons and form descriptions often never make it onto the translation list at all, and the result is that a screen reader user meets an interface in the source language.

Adding this content to the list at the extraction stage is far easier than correcting it at the testing stage. Accessibility is not a layer added afterwards but a requirement planned from the start.

For businesses that work with public bodies or provide services open to the public, this test is increasingly becoming a compliance matter. Automated tools list some of the problems quickly, but only a human being can judge whether the alternative text is meaningful.

From bug report to delivery

The output of testing is the bug report. A good report does not start an argument; it is taken up directly. The sequence that works in practice is this:

1. A screenshot of the screen where the problem appears and the identifier of the text concerned are recorded.
2. The type of error is marked: language, function, appearance, cultural fit or accessibility.
3. The responsible party is identified: will the language team or the development team make the correction?
4. The correction is made and the same screen is checked again in a second round.
5. Closed items are put on record and delivery is signed off.

When this cycle is recorded, it becomes easier to see recurring errors in the next release. The same problem coming up a second time is a sign that something is structurally missing from the process.

The Türkiye context

In Türkiye, localisation testing is not priced as a separate item on most projects; it is treated as part of the translation or skipped altogether. Yet the problems seen most often in translation into Turkish come out not in the file but on the screen.

The agglutinative structure of the language makes cosmetic testing critical. The Turkish equivalent of a short English label can double in length once it takes a suffix, and then it will not fit inside a narrow button. Mishandling the dotted and dotless “i” in case conversion is another common error.

On screens that hold personal data, testing takes on a compliance dimension as well. Details such as where the privacy notice appears and whether the explicit consent box is left unticked are assessed within the KVKK framework, and they are check items independent of translation quality.

What does this mean for you?

Localisation testing is the only stage that shows whether the translation you paid for reaches the user intact. When you place an order, these steps will protect your work:

1. Ask, one by one, which types of testing the quote covers.
2. Give the testing team access to a working copy of the product.
3. Settle the format of the bug report and who will make the corrections at the outset.
4. Build the second verification round into the schedule.

We explain our approach to quality control in detail on our translation services page. If you would like to work out together which types of testing your product needs, you can write to us from our quote page.

Frequently asked questions

Does the translation agency carry out the localisation testing?

Part of it. Linguistic testing and terminology consistency checks usually sit with the language team. Functional and technical tests require access to the product and are therefore mostly run on the developer side; the findings from both should be brought together in a single shared list.

Is a working version of the product essential for testing?

Not essential, but it helps a great deal. If there is no working copy, a limited check can be made from screenshots. In that case some problems, such as overflow and truncation, are only noticed after release.

What is the difference between linguistic testing and proofreading?

Proofreading reads the text on the file; linguistic testing checks the text inside the product, in the place where it appears. The same sentence can be right in the file and wrong on the screen. That is why neither takes the place of the other.

How many rounds of testing are enough?

Two rounds usually do the job: the errors found in the first round are corrected, and the corrections are verified in the second. For products that release continuously, regular sampling suits better than a one-off round.

References

Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge, pp. 56, 63-64. · Esselink, B. (2000). A Practical Guide to Localization. John Benjamins, p. 15. · W3C, Web Content Accessibility Guidelines (WCAG) documents.

This article is for general information only and is not legal advice.