Software and game localisation

Why Turkish strings need a localiser, not just a translator

Turkish is agglutinative: grammatical information that English expresses with separate words is attached to the end of the noun as suffixes, and the suffix changes with the vowels of the word. “Delete {filename}?” cannot be localised by dropping the placeholder into a fixed sentence, because the suffix that follows the file name depends on the file name. We restructure such strings so the placeholder sits where no suffix is needed, or ask the developer for a variant. Plural rules are simpler than English (Turkish has one plural form after numerals) but sentence order is the reverse of English, so concatenated strings that work in English produce nonsense in Turkish. Character sets matter too: ı, İ, ş, ğ and the dotted and dotless i cause case-conversion bugs in code that assumes English. We flag all of this in the translation file before it reaches your build.

What we localise

• User interface strings in JSON, XLIFF, PO/POT, .resx, .strings, .xml (Android), YAML, CSV and spreadsheet formats.
• Help centres, onboarding, tooltips, error messages, release notes.
• App Store and Google Play listings, screenshots text, keywords.
• Games: dialogue, item and skill names, quest text, UI, achievements, store pages and community posts; subtitle files for cut-scenes.
• Marketing sites and e-mail campaigns for launches (see website localisation).

Games in particular

Türkiye is one of the larger PC and mobile gaming markets in Europe, and Turkish players are vocal about poor localisation. Game text needs a translator who plays games: tone that matches the genre, consistent naming across items and lore, and awareness of length limits in UI boxes. We keep a game glossary from the first batch, translate with context (screenshots, string IDs, speaker and gender where known) and review the text in the build. For Turkish studios going to English-speaking markets we do the reverse with a native English game writer and a British or US spelling decision made at the start.

Linguistic quality assurance

Translation in a spreadsheet is half the job. On request we test the localised build: truncated strings, overlapping text, untranslated hard-coded strings, wrong plurals, broken placeholders, date and number formats, and Turkish characters rendering in every font. We report in a spreadsheet with string ID, screenshot and suggested fix. LQA is charged by the hour.

How it works with your release cycle

We work from your repository export or a localisation platform (Crowdin, Lokalise, Phrase, Transifex or your own), return files in the same structure, and handle continuous small batches at a per-string or per-page rate with a short turnaround so localisation does not block sprints. Translation memory means a string you have already approved is not charged again when it reappears.

What it costs

Quoted per project from the string count, repetition and context available. As a guide, standard UI and help content is priced at our per-page rates (from £6.50 per page into Turkish and £10.00 per page into English, on 1,000 characters of source), creative game text higher, and LQA by the hour. Continuous localisation is invoiced monthly. No UK VAT is charged. Very large volumes of low-risk text, such as user-generated content or legacy help articles, can go through post-edited machine translation at a lower rate; UI strings and game dialogue should not.

Turnaround

Small sprint batches within 1–2 working days; a 20,000-word app in about a week; a game script by agreed schedule with early delivery of UI strings so testing can start.