What Is Internationalisation (i18n) and Why Is It Done First?

The line item that unexpectedly inflates a localisation budget is usually not translation. It is the product not being ready for translation. The work referred to by the abbreviation internationalisation (i18n) is precisely the name of that preparation.

Contents

The definition is simple: internationalisation means making a product adaptable to any language and locale without changing its source code. It is an engineering task, and it is independent of language. Localisation, in turn, is the filling in of that ready infrastructure for a particular market.

The order matters and cannot be reversed. In a product that has not been internationalised, translation turns into digging text out of the code; it is redone at every release and produces fresh errors each time.

What does internationalisation (i18n) cover?

Its scope can be gathered under four headings: separating text from code, choosing the character encoding correctly, handing formatting over to the locale, and designing the interface so that it can take variable text lengths.

None of these requires knowledge of a language. All of them can be done while the product is still monolingual, and that is in fact the cheapest moment to do them. As the product grows, the cost of the same work rises not in a straight line but in step with the number of files.

The abbreviation comes from the same place: there are 18 letters between the first and the last letter of the word “internationalisation”. By the same logic, localisation is written l10n and accessibility a11y. These abbreviations have become standard in quotations and technical correspondence.

Why is it done before translation?

Because translation works on a list of text that can be extracted from the product. If no such list exists, what sits in front of the translator is not text but source code.

This has three concrete consequences. First, the translator cannot tell which text the user actually sees; internal keys, log messages and user-facing text cannot be told apart. Second, code can be broken by accident; if a quotation mark or a variable name is translated, the product stops working. Third, the whole of the same job is repeated at the next release, because there is no reusable string file to fall back on.

When the sequence is followed correctly, translation memory comes into play and only the strings that have changed are charged for. Industry measurements have found that roughly 40% of translation work is reusable (DePalma 2012); in products that ship in successive versions, that proportion translates directly into budget.

The rule of sequence may look like it admits no exception, but in practice there is a middle road: instead of the whole product, only the screens the user sees most are internationalised and the rest is left to a later release. This is a reasonable approach for teams that want to split the budget; even so, which screens are in scope must be set down in writing, otherwise the missing translation is reported as a defect.

Hard-coded text: the most expensive mistake

Hard-coded text is user-facing wording written directly inside the code. On its own it looks harmless; while the product is monolingual it causes no trouble at all.

The problem begins with the second language. These strings are invisible to export tools; they never appear in the translation package; and when the product is translated into Turkish they sit in the middle of the screen as an English warning. They also tend to be the last things anyone notices: error messages, validation warnings, empty-list text and email templates.

The solution is to move all user-facing text into resource files. Every string is given a key, the code calls the key, and the language file supplies the equivalent. Once this structure is in place, adding a new language amounts to adding a new file.

String files and context: what does the translator see?

In an internationalised product, what goes out for translation is not the screen but a list of strings. The translator sees the list, not the screen. This is the most basic constraint in software translation, and it explains why context notes are not optional.

Single-word strings are the sharpest example of that constraint. The English word “Open” means “Aç” on a button and “Açık” on a status label. With no note, the translator has to pick one of the two, and a fifty-fifty chance of getting it wrong appears. The same problem recurs with every word that can be both a noun and a verb, such as “Save”, “Order” and “Book”.

A well-prepared string file carries three pieces of information for each key: the screen the text appears on, the type of string (button, heading, error message, help text) and the character limit, where there is one. These three items bring the number of revision rounds down directly. XLIFF, the industry’s common interchange format, carries note and context fields within the structure of the file itself, so the information is not lost as it moves from tool to tool.

Sharing screenshots is another low-cost solution. Adding snapshots of the screens to the translation package does much of the work of long context notes, and it takes minutes to prepare.

Encoding, sorting and Turkish letters

Character encoding is the most technical part of i18n work and the easiest to settle. There is a single rule: UTF-8 from end to end. The database, the application, file reading, HTTP headers and email delivery must all use the same encoding.

If one link in the chain stays on an older encoding, Turkish letters turn into mangled characters. Most corruption of this kind damages the data itself permanently; putting it right afterwards usually calls for data repair. Databases inherited from older encodings such as ISO-8859-9, used in Türkiye for many years, are the most frequent source of the problem.

It is worth remembering that encoding affects not only the screen but the exchange of files as well. If string files are opened with the wrong encoding as they are imported into the translation tool, the error surfaces not during translation but when the file is loaded back. That is why testing with a small sample file on the first transfer is safer than sending the whole package.

The second issue is sorting and comparison. Letter order in the Turkish alphabet differs from English, and case conversion is a special case of its own: the upper case of “i” is the dotted “İ”, and the lower case of “I” is the dotless “ı”. Conversions carried out without a locale silently break search results, username matching and sorting.

i18n technical checklist

The list below is the minimum set of checks that can be handed to a development team. Starting translation before these items are complete generates rework further down the line.

1. Move all user-facing text into resource files; leave no text in the code.
2. Use UTF-8 in every layer and verify the database collation setting.
3. Do not assemble sentences piece by piece inside the code; keep the full sentence as a single string.
4. Use variables with named placeholders and avoid any dependency on their order.
5. Hand date, time, number and currency formats over to the locale library.
6. Manage plural rules through a language-independent mechanism.
7. Do not use fixed widths in the interface; build a layout that does not overflow when the text grows.
8. Add a context note and screen information for the translator to every string.

If i18n is missing, where does the cost surface?

The bill for incomplete internationalisation does not show up on the translation line; it is spread across other items. The table below summarises the most common gaps and the line each one ends up being booked to.

Gap	Visible symptom	Line the cost lands on
Hard-coded text	Untranslated wording on screen	Development + an extra correction round
Sentence concatenation	Broken suffixes and inverted sentences	Retranslation + testing
Missing context note	Translation in the wrong sense	Revision + delay
Fixed-width interface	Overflowing or truncated text	Design fix
Mixed encoding	Corrupted Turkish characters	Data repair

The right-hand column shows why i18n is an engineering investment rather than a translation line item. The investment is made once; it does not have to be amortised again for every new language.

The second, invisible component of the cost is time. Most of the gaps listed above come to light when the product is very close to release, and the fix then joins the development team’s queue. What wrecks a localisation schedule is usually not the translation time but the wait for those fixes.

The Türkiye context

Turkish makes gaps in internationalisation visible faster than the average language does. Because the language is agglutinative, the suffix a noun takes changes according to the vowel that precedes it. A pattern built in the code as “%s için” sometimes needs a suffix other than “için”, depending on the word that lands in the placeholder; concatenation logic that works perfectly well in English produces broken sentences in Turkish.

For that reason, if Turkish is one of the target languages, the ban on sentence concatenation is the most critical item on the checklist. The solution is usually to keep full sentences as separate strings rather than to break the pattern apart; where necessary, several variants are defined for the same meaning.

On the locale side, for Türkiye the date runs dd.mm.yyyy, the decimal separator is a comma, the thousands separator is a full stop, and the currency symbol follows the amount. In products integrated with public bodies, format validation for the national identity number, the tax identification number and IBAN fields must also be defined according to the local rule.

What does this mean for you?

For the party buying translation the practical conclusion is clear: you need to know your product’s i18n status before you ask for a quotation. If you do not, the quotation you are given will not be realistic.

1. Ask your developer a single question: “Can you export all user-facing text into one file?”
2. If the answer is yes, find out the file format and state it when you request a quotation.
3. If the answer is no, plan the i18n work first; holding the translation back is cheaper.
4. Write the requirement for context notes in the string files into the scope of work.
5. Choose the first language as a pilot, verify the checklist in that language, then open up the others.

In teams that follow this sequence the cost of the second and third languages falls noticeably, because the repeated work disappears. If you would like us to assess your product’s current state with you, write to us; you can also find what is required in terms of file format and scope on our services page.

Frequently asked questions

Are internationalisation and localisation the same thing?

No. Internationalisation is the technical preparation that makes a product adaptable to any language, and it is independent of language. Localisation is the adaptation of the prepared product to a particular market. One is infrastructure, the other is application.

Can I still have a product translated if it has not been internationalised?

You can, but because the text is buried in the code every string has to be found and changed by hand. That is a cost repeated at every later update, and the error rate is high.

What needs particular attention for Turkish?

UTF-8 encoding, the sorting and search behaviour of Turkish letters, case conversion that respects the dotted and dotless i distinction, interface widths that can stretch, and the dd.mm.yyyy date format.

Who carries out the i18n work?

The development team does. The translation supplier usually provides a checklist, specifies the file formats and validates the string files that come out at the end; it does not change the code itself.

Sources

• Pietrzak, P. & Kornacki, M. (2021). Using CAT Tools in Freelance Translation. Routledge, pp. 14–19.
• Esselink, B. (2000). A Practical Guide to Localization. John Benjamins, pp. 25–40.
• W3C Internationalization Working Group, Internationalization Best Practices.
• Unicode Consortium, Common Locale Data Repository (CLDR): language and locale data.
• DePalma, D. (2012). Translation Productivity Benchmarks. Common Sense Advisory (2012 data).