Software and UI localisation into Turkish: what breaks and how to prevent it

By Mesut Can Güroy, sworn English–Turkish translator · Published 3 November 2026

Turkish is one of the languages that most often exposes weak spots in internationalisation. The dotted and dotless i break case conversion, suffixes break string concatenation, and long agglutinated words break fixed-width buttons. This guide is for product managers, developers and localisation managers preparing a product for Turkish users. It covers the problems we see most often and what to fix before the strings reach a translator.

The dotted and dotless i

Turkish has a dotted pair (i and İ) and a dotless pair (ı and I). Lower-case i becomes İ in upper case, and upper-case I becomes ı in lower case. The Unicode Character Database records these as language-specific mappings in SpecialCasing.txt, so they apply only when the software knows the text is Turkish.

Two kinds of bug follow from this:

• Display text cased with English rules. A heading shown in capitals turns “bilgi” into “BILGI” instead of “BİLGİ”, and a Turkish reader sees a different word. In JavaScript, toUpperCase() ignores the language; toLocaleUpperCase('tr-TR') applies the Turkish mapping. In CSS, text-transform: uppercase follows the language of the element, so the page or element needs lang="tr".
• Identifiers cased with Turkish rules. The reverse problem appears when code runs on a machine set to a Turkish locale. Lower-casing "FILE" or "ID" with the system locale produces a dotless ı, and a comparison with "file" or "id" fails. File extensions, HTTP headers, configuration keys and command names should be compared with locale-independent (invariant) casing.

The rule of thumb: Turkish casing for anything a person reads, invariant casing for anything a program reads.

Suffixes, placeholders and word order

Turkish expresses case, possession and much of what English does with prepositions through suffixes. The suffix changes with the vowels and the final consonant of the word before it: dosyaya (to the file) but belgeye (to the document). Proper names take the suffix after an apostrophe: Ankara'ya, İzmir'e.

That makes a string such as Send to {name} hard to translate. The correct suffix depends on what {name} will be, and the translator cannot know that. Common solutions:

• Put the variable where it needs no suffix. “Alıcı: {name}” or “{name} adlı kişiye gönder” (send to the person named {name}) works for any value.
• Never build sentences from fragments. Turkish usually puts the verb at the end of the sentence, so English word order rarely survives. "Delete " + count + " files?" needs to be a single string with a placeholder, and the translator decides where the placeholder goes.
• Describe every placeholder. A translator who knows that {0} is a user name, a number or a date can choose a structure that stays grammatical.

Plurals

The Unicode CLDR plural rules give Turkish two cardinal categories: one (exactly 1) and other. A noun after a number does not take the plural suffix, so “1 dosya” and “5 dosya” are both correct. The plural suffix appears when there is no number: “Dosyalar silindi” (the files were deleted).

In practice this means:

• Use your framework's plural handling (ICU MessageFormat, gettext plural forms or the equivalent) and supply both forms for Turkish, even if they look the same.
• Avoid English shortcuts such as file(s). They have no Turkish equivalent.
• Remember that a zero count is other in CLDR. If you want a separate message such as “Dosya yok” (no files), handle zero explicitly in the code.

Length, line breaks and layout

Because grammar is added to the word, Turkish produces long single words: “Kaydedilemedi” means “could not be saved”, and “yapılandırılamıyor” means “cannot be configured”. Words like these cannot break at a space, and automatic hyphenation of Turkish is rarely available in interfaces.

• Let buttons, tabs and table headers grow or wrap instead of fixing their width in pixels.
• Give translators the real character limit for each string that has one, not a general instruction to keep it short.
• Run a pseudo-localised build with longer strings and Turkish characters (İ, ı, ğ, ş) before translation starts, to find truncation and encoding problems early.
• Use UTF-8 throughout. Legacy Turkish code pages (ISO-8859-9, Windows-1254) still appear in older databases and exports, and mixed encodings show up as broken ğ, ş and ı.

Numbers, dates and sorting

Do not format these by hand. Locale-aware libraries (ICU, Intl.NumberFormat, Intl.DateTimeFormat and Intl.Collator with 'tr') apply the CLDR data for Turkish. Hard-coded formats are the usual source of a price shown as 1,234.56 in an otherwise Turkish screen.

Tone and terminology

• Choose a form of address and keep it. Turkish distinguishes the formal or plural siz from the informal sen. Business software usually uses siz in messages. A product that switches between the two looks unfinished.
• Keep commands short. Buttons and menu items normally use a short verb form such as Kaydet (save), İptal (cancel) or Sil (delete).
• Decide on loan words once. Some English terms are commonly kept, and others have established Turkish equivalents. Record each decision in a glossary so “dashboard” is not translated three different ways across the product, the help centre and the release notes.
• Match the platform. Where your product sits on Windows, macOS, Android or iOS, use the terms Turkish users already see in the operating system for the same actions.

What to send your translator

1. String files in their native format (XLIFF, JSON, RESX, .strings, .po and so on), with stable keys.
2. Context for each string: a screenshot, the screen name or a short note on where it appears.
3. Character limits for strings that have them.
4. A description of every placeholder and markup tag.
5. Your glossary and style decisions, or a request to create them.
6. Access to a test build, so the Turkish text can be checked on screen (linguistic QA) before release.

A checklist before you ship in Turkish

1. Case conversion uses Turkish rules for display text and invariant rules for identifiers.
2. No string is assembled from fragments, and no placeholder is followed by a hard-coded suffix.
3. Plurals go through the framework's plural handling, with zero handled where needed.
4. Layouts allow longer words, and the pseudo-localised build shows no truncation.
5. Numbers, dates, currencies and sorting use locale-aware libraries with Turkish data.
6. The form of address and key terms are consistent with the glossary.
7. A Turkish linguist has reviewed the running build, not just the string files.

Related: English–Turkish technical translation · Game localisation · MTPE and AI translation review · Turkish labelling requirements for medical devices (for device software text)

This guide is general information, not legal or regulatory advice. Language requirements for a product depend on its type and market, so confirm your obligations with your regulatory or legal adviser.

Sources: Unicode Character Database, SpecialCasing.txt; Unicode CLDR, plural rules; MDN, CSS text-transform; TDK, Yazım Kuralları: Kesme İşareti.