Software Localisation: The Challenges of Interface Text

Software localisation projects look easy at first glance. The texts are short, the sentences are simple, the total word count is lower even than that of a contract. Even so, these projects regularly take longer than document translation of the same volume and call for more rounds of revision.

Contents

The reason can be summed up in a single sentence: the translator sees the text, not the product. The file in hand holds hundreds of short strings such as “Close”, “OK” and “Continue”; which screen, which button or the middle of which sentence they are used in is most often unknown.

Below we take up six typical difficulties of interface text and the way they are managed. The aim is to let you see which line items are genuinely necessary when you ask for a quote.

Why is software localisation not like document translation?

In document translation the text is linear. When a paragraph escapes you, you look at what comes before and after it; the context is inside the text itself. Interface strings have no such continuity. The order in the file does not reflect the order on the screen; it is usually arranged alphabetically or by the order of the code file.

The second difference is that the text has to fit inside a field. In a document the sentence can run on and the page grows. In an interface the width of the button is fixed; if the text runs long it either overflows or is cut off.

The third difference is the pressure of consistency. The same concept must be rendered by the same word right across the product. “Account” on one screen and “Membership” on another means two different things to the user. That is why a term list on software projects is not a preference but a requirement.

The fourth difference is that the product is alive. A document is translated once and it is finished; software changes with every release. Software localisation is therefore not a delivery but a repeating cycle, and translation memory stands at the centre of that cycle.

The context-free string problem

Lack of context is the most expensive problem in interface translation, because its errors are silent: the translation is grammatically correct, it is simply in the wrong place.

The classic example is single-word commands. The English “Order” means both a purchase order and a sort sequence. “Book” means both a printed book and the act of reserving. “Free” can mean both free of charge and unoccupied. When these words stand alone in a string list, the translator is left to guess.

The remedy is not complicated, but it takes discipline. A note of at least two lines is added to every string: where does this text appear and what does it do? Screenshots are shared in addition. These two practices remove a good part of the correction rounds that would otherwise follow.

The second form of missing context is when the same source text calls for a different translation in different places. Translation tools can fill the same string automatically with a single rendering. That behaviour is useful for consistency, but where two different meanings are involved it multiplies the error. Repeated strings should therefore not be merged blindly.

Text length and interface overflow

Text length almost never stays constant during translation. Languages differ in how densely they express things; the same meaning is built with fewer characters in one language and with more in another.

Turkish behaves in both directions here. Thanks to its agglutinative structure, a construction built from several words in English can come down to a single word; on the other hand, once the suffix chains grow long, that single word itself takes up a lot of room on the screen. The result is an unpredictable fluctuation: some buttons empty out, others overflow.

The precaution to take on the design side is therefore to avoid fixed widths. Button and label areas should be able to flex with the content, and when text overflows, line wrapping or controlled truncation should come into play. Where a fixed width is unavoidable, the character limit has to be given to the translator in the string file.

Once a character limit is given, the translator’s job changes: it is no longer translation but the preservation of meaning within a limit. That is a separate skill and it is assessed separately in pricing as well.

Variables, plurals and sentence concatenation

Some interface texts are not fixed; data is placed inside them at run time. The number in the sentence “You have 3 new messages” is a variable. This structure produces three separate problems in translation.

The first is the problem of order. When variables are written with unnumbered placeholders, the translator cannot change the order, whereas the word order in the target language may be different. The solution is to use named placeholders.

The second is the problem of plurals. Languages diverge in their plural rules; some have more than two plural forms. A simple arrangement that looks at the number and picks one of two texts falls short for those languages. The right approach is to hand the plural forms over to a language-independent mechanism.

The third, and the most critical for Turkish, is sentence concatenation. Building a sentence in code by joining fragments side by side fixes the suffixes to the source language. In Turkish the suffix changes according to the vowel of the word before it; a template that uses a fixed suffix will inevitably produce a broken sentence. Keeping the full sentence as a single string is therefore among the first items on the i18n checklist.

Shortcuts, abbreviations and special characters

In desktop software, menu items are defined together with keyboard shortcuts. The shortcut letter is usually marked inside the text. In translation that letter may not exist in the target language, or the same letter may fall to two items on one screen.

A shortcut clash is a typical error caught in linguistic testing, and if it is not marked in the source file there is no way for the translator to see it. The same holds for abbreviations: where an abbreviation that is established in the source language has no Turkish equivalent, it has to be spelled out, and that brings us back to the problem of space.

Special characters are a heading of their own. String files contain escape characters, formatting tags and line break markers. Preserving these during translation is compulsory; when they are damaged the product either looks wrong or throws an error. The quality control modules of translation tools flag losses of this kind automatically.

The term list and brand language

In interface translation, consistency is a more visible measure of quality than accuracy. The user does not know the most apt rendering of a word, but notices at once when the same thing is called by two different names on two screens.

A term list is therefore approved before the project begins. The list holds at least three pieces of information: the source term, the approved Turkish rendering and the alternatives that are not to be used. Product names, module names and brand terms are additionally marked “do not translate”; otherwise the product name is translated inside a sentence and the support team and the user cannot tell that they are talking about the same thing.

The second function of the term list is stylistic decisions. Will the user be addressed formally, will commands be written in the imperative, will error messages use accusatory language? These decisions are gathered not in individual strings but in a short style guide, which is handed to the translator along with the project.

The list is not a one-off document. Terms that emerge in new releases are added and contested decisions are updated. The termbase function of translation tools exists for exactly this: the approved rendering is suggested automatically as the translator types that term, and the quality control module flags any deviation.

File formats and linguistic testing

The format of the string file largely determines how smoothly the project will run. The table below summarises the common formats and their practical consequences.

Format	Typical use	Does it carry a context note?
XLIFF	Exchange between translation tools	Yes, part of the structure
PO / POT	Open source, PHP, WordPress	Yes, comment fields
JSON / YAML	Web and mobile applications	Partly, an extra field is needed
RESX / strings	Desktop and mobile platforms	Partly
Excel / CSV	A stopgap	No, a column is added by hand

Once the format has been chosen, it is the turn of linguistic testing. This step means loading the translated strings into the product and reviewing it screen by screen. It has no counterpart in document translation, and when it is skipped the errors are left to the user.

What linguistic testing looks for is well defined: text that overflows or is cut off, a word used in the wrong context, an untranslated string, a corrupted character, an inconsistent term and a badly formatted date or amount. The findings are fed back into the source file, so that the same error is not repeated in the next release.

The Türkiye context

The three problems seen most often in Turkish interfaces arise from the structure of the language. The first is suffix harmony: when variable content such as a user name, a product name or a file name is inserted into a sentence, the suffix that follows must change according to the last vowel of the variable. A suffix hard-coded in the software appears to the user as a broken sentence. The practical solution is to move the variable to the end of the sentence or to choose a template that does not call for a suffix.

The second is case conversion. In Turkish the capital of “i” is “İ” and the lower case of “I” is “ı”. In conversions carried out without specifying the locale, the word “İstanbul” is mangled, search results go missing and user name matching fails. Style rules that turn interface text entirely to upper case have to be tested separately for Turkish.

The third is the keyboard and input side. The Turkish Q and F keyboard layouts affect how reachable the shortcut letters are. Beyond that, the validation rules have to be defined separately for the fields where users prefer spelling without Turkish letters (passwords, user names) and the fields where Turkish letters are expected.

What does this mean for you?

If you are going to put your software into Turkish, the success of the project rests on the quality of the preparation before the quality of the translation. The sequence below heads off most of the delays from the start.

1. Export the strings in a structured format (XLIFF, PO, JSON); treat Excel as a last resort.
2. Add the screen name and the element type to every string; share a screenshot where possible.
3. Mark the fields that carry a character limit in the file.
4. Approve the term list before the project starts; say so if product names and brand terms are not to be translated.
5. Plan a separate build and a separate period for linguistic testing; set the delivery date accordingly.
6. Have the handover of the translation memory to you written into the contract; this is what determines the cost of later releases.

Once these six items are complete, the second release becomes routine even if the first one is painful. If you share the file format and the number of screens in your product, we can work out the scope together; you can start from the quote form or look through the scope of our services.

Frequently asked questions

Interface texts are short, so why does the per-word price come out high?

Short strings call for more decisions per unit: context research, character limit checks, terminological consistency and on-screen testing. Pricing is shaped by that decision load rather than by word volume.

My developer can hand over the strings as Excel, is that a problem?

It can be done, but it is not ideal. Excel carries no context field, no character limit and no status information, and the risk of a format error when loading it back is high. Where possible, prefer a structured format such as XLIFF, PO or JSON.

Is Turkish text longer than English, or shorter?

It can be either. The agglutinative structure brings some expressions down to a single word, while suffix chains lengthen others noticeably. That is why the interface should be designed to flex rather than to a fixed width.

Is testing on screen essential?

In a product the user sees, yes. With some of the strings translated without context, the misreading is only noticed once they are seen on screen; overflow and truncation problems also show up only here.

References

• Pietrzak, P. & Kornacki, M. (2021). Using CAT Tools in Freelance Translation. Routledge, pp. 20–27.
• Esselink, B. (2000). A Practical Guide to Localization. John Benjamins, pp. 59–92.
• OASIS, XLIFF Version 2.1 Specification (2018).
• Unicode Consortium, CLDR Plural Rules – plural forms by language.