Localisation 5 August 2026
Internationalisation Preparation: A Pre-Localisation Checklist
Most localisation problems can be solved before translation even starts. We look at what internationalisation preparation is and at the checklist that gets a product ready for translation.
Most of the problems encountered in localisation can in fact be solved before translation begins. The stage that makes this possible is called internationalisation preparation. The term refers to making a product fit for localisation before translation starts, that is, resolving in advance the technical and cultural issues that would otherwise cause trouble further down the line. A well-prepared product makes localisation run smoothly; a badly prepared one will block even the most gifted translator.
Contents
In this article we look at what preparation involves, why code and text need to be separated, matters such as character encoding, text direction and text expansion, and the testing done with pseudo-localisation. Our aim is to set out the steps that belong before translation in the form of a checklist.
What is internationalisation preparation?
Internationalisation preparation is the state of a product having been made ready in a form suitable for localisation. It means that known problems have been resolved before they can create difficulty later on. In the literature this approach is also referred to as “localisation-friendly development”. The aim is to design the product from the very outset so that it can travel between different languages and cultures without friction.
This preparation is both a technical and a cultural exercise. On the technical side it takes in character encoding, keyboard shortcuts, user input formats and the separation of text from code. On the cultural side it assesses whether graphics, colours, icons and abbreviations suit the target markets. The fact that a colour or an icon may carry different meanings in different cultures is weighed at this stage.
Separating code from resources
The most basic step in preparation is separating text from code. The operation is known as “externalisation”: locale-specific resources such as text, images and video are lifted out of the code and held in separate resource files. The code itself is developed as a neutral structure, with no actual text embedded in it. The text for each language sits in its own external file and is bound to the application dynamically.
The benefits of this separation are considerable. If text stays embedded in the code, the translator risks breaking that code by accident and managing a separate version for every language becomes hard work. When text is held in external files, translation becomes both safe and flexible; the same code combines with the resource files of different languages to produce a separate version for each market. This structure is the foundation of scalable localisation.
These external files are bound dynamically to the core of the application. The code stays neutral; the text, images and formatting information for each language sit in their own file and are called up when needed. Adding a new language therefore means adding a new resource file rather than changing the code. This flexibility makes it possible to take a product to ten languages or to a hundred on the same basic logic. Once the code has been set up correctly, the number of languages becomes purely a question of files.
Character encoding and input formats
An international product has to be able to accept and display different languages and writing systems. That begins with character encoding. Where older encoding standards support only limited character sets, the Unicode standard gathers all the world’s languages under a single roof. When a product is built on Unicode, different alphabets, accented letters and even emoji display without trouble.
Input formats are part of preparation too. The order of given name and surname, alphabetical sorting order, address formats and date display all vary by language. In some languages, for example, the surname comes first, and in some alphabets accented letters sort in different positions. An international product is designed to account for these differences in advance. All this locale data is defined in shared repositories, and the preparation stage draws on those sources.
Keyboard shortcuts are another frequently overlooked matter. Software uses key combinations that make sense to the user; but a shortcut that is meaningful in one language may lose its logic in another. The shortcuts for functions such as saving or copying need to be rethought for the target language. Details of this kind look small, yet they bear directly on the user experience; if they are not addressed during preparation, they become harder to fix afterwards.
Text direction and text expansion
Text direction is a preparation issue that is often skipped. While most languages are written from left to right, languages such as Arabic, Hebrew and Persian flow from right to left. The product interface has to be designed to support that direction and to mirror the screen where necessary. Trying to add direction support later is usually the most expensive and most laborious route of all.
Text expansion is another critical technical problem. The same content occupies different amounts of space in different languages; a text may grow longer in one and shorter in another. A button label two characters long in English may not fit the interface in another language. Most interfaces today are built with responsive design that adapts dynamically to screen size, but that is not always enough. Allowing for the risk of expansion in advance protects you from interfaces that break later.
Testing with pseudo-localisation
A clever way to test how well preparation has been done is pseudo-localisation. In this method the real text in the product is automatically replaced with dummy characters and lengthened by a set proportion. Possible problems are thus brought to light before real translation has even begun. Whether a text fits the interface, whether a right-to-left language displays correctly, or whether accented characters come out properly can all be checked this way.
The basic checks that belong to the preparation stage can be summarised as follows:
- Separating text from code and moving it into external resource files.
- Securing character encoding with Unicode.
- Designing the interface flexibly for text direction and expansion.
- Testing for possible problems in advance with pseudo-localisation.
Once these checks are complete, the translation stage proceeds with far fewer surprises. We deal with pseudo-localisation in more detail in a separate article; the point we are stressing here is the value of doing the testing before translation.
Cultural preparation and locale data
Preparation is not only technical but cultural as well. Do the graphics, colours, icons and abbreviations of a product suit the target markets? This question should be asked at the very start of internationalisation. A colour may evoke mourning in one culture and purity in another; an icon may be plain in one place and meaningless in another. Thinking these cultural differences through in advance heads off expensive changes later.
Date, time, currency and measurement formats are likewise data that vary by locale. If an application uses alphabetical sorting, that sorting order differs from language to language. All this locale data is defined in shared data repositories; the preparation stage draws on those sources to ensure the product behaves correctly in every market. The table below summarises the main headings of a preparation checklist.
| Area | What to check |
|---|---|
| Code separation | Is the text in external files? |
| Encoding | Is Unicode supported? |
| Text direction | Are right-to-left languages supported? |
| Expansion | Is the interface flexible? |
| Cultural elements | Are the colours and icons appropriate? |
The cost of an unprepared product
If preparation is skipped, the price is paid at the later stages of the process. The later a problem is noticed, the more expensive and time-consuming it is to solve. A fault that arises because text was left embedded in the code tends to surface not during translation but at a point when the developers have moved on to something else. That makes the fix both slower and dearer.
Preparation is therefore not a cost but a saving. Every correct step taken before translation removes a number of problems that would otherwise arise later. A well-prepared product moves between different languages and writing systems almost without friction. The time given to preparation is repaid many times over across the rest of the localisation work.
Preparation also makes relay translation easier. A well-internationalised product can be translated into one language and then carried on into others through that version. An application might first be translated into English, for instance, and that bridge version then taken into further languages. This is a practice that lowers costs, particularly for smaller markets. The precondition for such flexibility, though, is that the product was prepared correctly from the start; where preparation is weak, no shortcut will help.
The Türkiye context
In projects targeting Turkish, preparation matters especially on a few points. The agglutinative structure of Turkish leads to text expansion; a short English label may grow longer once translated into Turkish and no longer fit a narrow space. Displaying Turkish-specific characters correctly also requires Unicode support to be in place from the outset. If these two matters are not addressed during preparation, they cause trouble during translation.
Another feature of Turkish is the distinction between dotted and dotless “i” in case conversion. If this distinction is not handled correctly, it can lead to errors in search, sorting and display. International preparation calls for locale-specific rules of this kind to be defined in advance. The product then behaves as the Turkish user expects. This article is intended as general information.
What does this mean for you?
If you are planning to take a product into new markets, the preparation stage is the step that will save you the most time and money. Here is what you can do:
- Ask your developer whether text is kept separate from code.
- Verify that Unicode support and flexibility for text direction are in place.
- Ask for a pseudo-localisation test to be run before translation.
We can assess together how ready your product is for localisation. You can look through our localisation services and get in touch with us for a preparation review. Our aim is to solve problems before they reach the translator’s desk.
Frequently asked questions
What is internationalisation preparation?
It is making a product fit for localisation before translation begins. It means resolving in advance the technical and cultural issues that could cause problems at later stages.
Why does separating code from text matter?
If text stays embedded in the code, the translator risks breaking that code and managing a separate version for every language becomes hard work. Holding text in external resource files makes localisation safe and flexible.
What is text expansion?
It is the same content taking up more or less space in different languages. A text may grow longer in one language and shorter in another; preparation requires the interface to accommodate that variation.
What is pseudo-localisation for?
It serves to test expansion, text direction and encoding problems before real translation, by replacing strings with dummy characters. Faults are thus caught before translation starts.
References
Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge (Chs. 3/4/5/9/12). · Dunne, K. J. (2014). Localization. Routledge Encyclopedia of Translation Technology.