Localisation is easy when the product has been designed to be ready for it, and almost impossible when it has not. Internationalisation refers to this preparation: texts are separated from the code, formats are made variable, and the layout is built to be flexible. When this step is skipped, every new language turns into a software project.
Definition
Internationalisation is designing the product in a form that can be adapted to different markets. It is constructed not for a particular language but independently of languages. The preparation is done at the product development stage.
How it differs from localisation
Internationalisation comes first and prepares the ground; localisation comes afterwards and adapts to a particular market. The order cannot be reversed. The two are different jobs.
Separating the text from the code
Interface texts are kept in separate files and are not embedded in the code. Embedded text requires a code change for every language. This is the most basic step.
Structure of the resource file
The texts are kept as keys and values, and translation is applied to the values. The keys are not translated. The structure is preserved.
Variable fields
Variables placed inside a sentence are defined with placeholders. Joining up fragments of sentences does not fit the structure of languages. A full sentence is preferred.
The problem of sentence fragmentation
Dividing a text into fragments and joining them in the code leads to breakage in languages with a different word order. This is a widespread design error. It is avoided.
Plural rules
Languages use different plural forms, and the system must support this. The assumption of a single plural produces wrong text. Support is built in advance.
Allowance for text expansion
Because the translated text may get longer, an allowance is left in the interface. Fixed-width fields produce overflow. The design is made flexible.
Character encoding
The system uses an encoding that supports the characters of all languages. Missing support corrupts the letters. The choice is made at the outset.
Handling dates and numbers
Formats are not hard-coded; they are taken from the locale setting. A fixed format looks wrong in every market. Flexibility is built in.
Sorting and searching
Alphabetical sorting changes with the language, and the system must support this. Fixed sorting spoils the lists. Support is added.
Support for writing direction
Some languages are written from right to left, and the interface is built so as to support this. Adding it afterwards is costly. The preparation is done at the outset.
Text in visuals
If the text is not embedded in the visual, translation becomes easier. Embedded text requires a new visual for every language. The design is made accordingly.
Context information
The translator is given information showing where each text appears. Text without context is translated wrongly. This information is kept in the system.
Character limits
The limits of the fields are stated in the translation file. A translation done without knowing the limit gets cut off. The information is shared.
Effect on cost
When this preparation is not done, every new language requires a code change. The cost is multiplied by the number of languages. Early investment pays back.
The translator's role
At this stage the translator can give design feedback. Problematic structures are seen early. Cooperation is established.
What it is confused with
Internationalisation is frequently thought to be a synonym of localisation. Yet one makes the product adaptable, while the other adapts it to a particular market. If the first is not done, the second turns out very expensive.