What Is Localisation? How It Differs from Translation

In most requests for a quote, “translation” and “localisation” are used to mean the same thing. They are in fact different work items: they call for a different team, a different timescale and a different budget. The shortest answer to the question of what localisation is runs as follows: everything that makes a product behave, in its target market, as though it had been built there.

Contents

The difference is not academic but commercial. When you have a software interface translated and push it live, the text can be right while the product is broken: the wording overflows the buttons, dates read back to front, the search box returns nothing for words containing Turkish characters. None of this is a translation error, and none of it falls within the translator’s remit.

Below we separate the two concepts under the headings of scope, formatting, non-textual elements, process and cost. At the end you will find a concrete decision framework for working out which of the two a given project needs.

What is localisation, and where does it part company with translation?

Translation carries the meaning of a text into another language. The input is text and the output is text. The quality criteria are linguistic as well: accuracy, terminological consistency, fluency.

In localisation the input is not text but the product. There is text inside the product, but alongside it there are also the interface, data formats, images, audio, legal texts and technical behaviour. The quality criterion is not linguistic but functional: can the user operate the product without trouble in their own market?

This is why “error-free translation” is not on its own an adequate definition of delivery in localisation. In the industry the work is usually referred to by numeric abbreviations: localisation is l10n, internationalisation is i18n, globalisation is g11n. The abbreviations come from the number of letters between the first and last letter of the word.

The difference in scope: text or product?

When you have a contract translated, what you take delivery of is well defined: the same document in another language. When you localise a mobile application, what you take delivery of is not a file but a working build.

To see the scope, do a simple count: in how many separate places does text appear in the product? Interface buttons, error messages, email templates, notification texts, the store description, screenshots, the help centre, the terms of use, the invoice template. Most of these sit in different files and in the hands of different teams.

The commonest cause of delay in localisation projects is not translation time; it is the failure to gather these pieces together. If the text sources are scattered, the project timetable is tied not to translation speed but to the speed at which an inventory can be taken.

The second function of the inventory is to bind the scope to the contract. If it is not set down at the outset which text is to be translated, every new file that surfaces mid-project turns into an argument about scope. Experienced teams therefore prepare a single table before the first delivery: where the text sits, who owns it, in what format it is exported, and how often it changes.

The formatting layer: dates, numbers, currency

Formatting is the least visible layer of localisation and the one that produces the most errors. The same data is written differently under different locales, and when it is written wrongly the user reads it not as a mistake but as a sign of unreliability.

Element	Usage in Türkiye	Common mistake
Date	21.07.2026 (dd.mm.yyyy)	Month and day swapped round
Decimal separator	Comma: 1.250,50	Full stop and comma used the wrong way round
Currency	After the amount: 1.250,00 ₺	Symbol moved to the front
Time	24-hour: 14:30	An am/pm format being forced
Address	Neighbourhood, street, number, district/province	A state field being made mandatory

Most of these settings are a software job rather than a translation job, yet they come to light during the localisation process. Even if the translator writes “1.250,50”, a correction in the text will not reach the screen while the interface is generating the number in its own format.

Other areas belong in the same category: units of measurement, paper size, telephone number format, the first day of the week and sorting rules. Each of these is a small detail on its own; but when one of them shows up wrongly on an invoice, in a report or on a calendar screen, the user notices at once that the product was not thought through for their market.

Non-textual elements: images, colour, forms

Text is not the only thing in a product that carries meaning. Wording embedded in images, icons, colour codes and form fields also change from market to market.

The three commonest cases are these. First, images with text on them: they never enter the translation memory and form a separate editing item. Second, form fields: fields such as postcode, state and second surname are either removed for Türkiye or made non-mandatory. Third, sample data: unless the names, telephone numbers and currencies on demo screens are replaced with local equivalents, the product goes on looking foreign.

Individually these items are small; taken together they are large. If image editing and form adaptation do not appear as separate lines in a localisation quote, that work is in all likelihood out of scope.

The difference in process and cost

A translation project is linear: the file arrives, it is translated, it is revised, it is delivered. A localisation project is cyclical: strings are extracted, translated, loaded back into the product, tested in a working build, and the problems found are put right.

That cycle is what determines the cost. What raises the price in localisation is not the per-word rate but the items outside translation: file preparation, format conversion, on-screen linguistic testing and rounds of correction. If the source files have been properly prepared these items shrink; if they have not, they can exceed the translation fee itself.

There is also the advantage of repetition. Where a translation memory is used, only the strings that have changed are charged for in new versions. Industry data put the proportion of entirely new words in translation work at 59.38 per cent for companies and 59.11 per cent for freelance translators; that is, roughly 40 per cent of a text is reusable (DePalma 2012). In products that advance version by version, the ratio works still further in your favour.

How is localisation quality measured?

Translation quality is measured on the text: terminological consistency, grammar, fidelity to the source. In localisation these criteria are not enough on their own, because a substantial share of the errors appear not in the text but on the screen.

Mature projects therefore run three separate checks. The first is the linguistic check, and it is carried out on the file. The second is on-screen linguistic testing; it is run on the working product and catches overflowing buttons, truncated headings and words used in the wrong context. The third is functional testing, and it is concerned with behaviour rather than language: can you register with a username containing Turkish characters, does the search box return results for the word “şirket”, are the letters printed correctly on the invoice output?

When you are taking quotes, asking which of these three checks are included is the quickest way to understand the scope. A quote that covers only the first is a translation quote, whatever it may be called.

It also matters that the definition of quality be written into the contract in measurable terms. The phrase “error-free translation” cannot be measured; “free correction of linguistic errors reported within 30 days of delivery”, by contrast, is a measurable undertaking. Writing the quality clause of a localisation contract in this second form closes off most later disputes before they arise.

Which does which project need?

A single question settles the decision: does the user interact with this content, or only read it? If they read it, translation is enough. If they click, enter data or make payments, localisation is required.

1. Establish the type of content: a static document or a working product?
2. Work out where the text sits: files, database, inside the code, inside images.
3. List the format-dependent fields: dates, currency, units of measurement, addresses.
4. Estimate the testing load: how many screens and how many flows are to be reviewed?
5. Decide on the update frequency: one-off or versioned?

The answers to those five points also settle the scope of the quote. Large gaps between two quotes for the same product usually stem not from pricing policy but from the fact that some of these points have been left out of one of them. When you are comparing, you can use the item definitions on our pricing page as a yardstick.

The Türkiye context

Turkish creates a burden of its own in localisation. Because it is an agglutinative language, a single word can carry a structure that English builds from several words; on the other hand, the longer the suffixes grow, the longer the word becomes. The result is an unpredictable swing between expansion and contraction in interface text: a button label may shorten while the warning text right next to it overflows. Turkish interfaces therefore call for designs built to flex rather than to fixed widths.

The second particularity lies in the letters. The characters ç, ğ, ı, İ, ö, ş and ü do not survive older encodings; moving between systems left over from the ISO-8859-9 era and UTF-8 throws up corrupted characters. Case conversion is also a special matter in Turkish: the distinction between dotless “ı” and dotted “i” leads to search and input errors when conversions are carried out without knowledge of the locale.

The third area is commercial. For consumer-facing digital products in Türkiye, the distance selling contract, the preliminary information form and the return conditions are expected to be presented in Turkish. This is not translation but adaptation to local legislation, and it is usually carried out with legal support.

What does this mean for you?

If you are opening a product to the Turkish market, comparing the quotes you receive on a per-word price will mislead you. What you need to compare is scope.

1. When you request a quote, state the type of product and its technology stack; do not give a word count alone.
2. Ask your developer whether the strings can be exported; if the answer is no, plan internationalisation first.
3. Confirm in writing whether text inside images and form fields fall within the scope.
4. Ask for linguistic testing as a separate item and establish how many rounds of correction it covers.
5. Have it written into the contract that the translation memory will be handed over to you for updates.

Once these five points are clear, quotes become comparable and the risk of a surprise extra invoice largely disappears. If you are not sure which category your project falls into, describe your product briefly and we will work out the scope together. You can start with the quote form or look through the scope of our services.

Frequently asked questions

How much more expensive is localisation than translation?

Compared with text translation on its own, localisation gives rise to additional items: string extraction, interface adaptation, format settings, image editing and linguistic testing. The price difference depends on how well the product has been prepared technically; where the source files are in order, the gap narrows.

Would translation alone be enough?

It is enough for content that has no element beyond text: contracts, reports, articles. For every product the user interacts with (software, websites, applications, games), translation on its own falls short.

Who does localisation, the translator?

The translator does the linguistic part. String extraction, format settings and testing are handled jointly with a developer and a localisation engineer. It is not a one-person job.

When should a localisation project begin?

During product development. Localising a product that is already ready for release costs almost as much as doing the whole job again, because the text will have been embedded in the code.

Sources

• Pietrzak, P. & Kornacki, M. (2021). Using CAT Tools in Freelance Translation. Routledge, pp. 12–18.
• Esselink, B. (2000). A Practical Guide to Localization. John Benjamins, pp. 1–10.
• DePalma, D. (2012). Translation Productivity Benchmarks. Common Sense Advisory (2012 data).
• W3C Internationalization: Localization vs. Internationalization (W3C i18n Q&A).