Software localisation
Desktop and web applications, dashboards and business tools, with the interface, help centre and documentation adapted together.
Translation Services
More than translation. We adapt your product for each market and test it in context, so it feels local rather than translated.
Translation converts the words; localisation adapts the whole product so it works for a particular market. That means the interface strings, but also date and number formats, currencies, units, address and name fields, sorting order, imagery, and text that has to fit inside a button. Prism Linguistics provides localisation services in more than 300 languages for software, mobile apps, games and e-learning, with native-speaker linguists and testing on the built product.
We translate the strings without touching your code, tell you where adaptation is genuinely worth the effort, and check the result on real screens before your users do. Send your string files and target languages and a project manager replies within one working hour during office hours.
Picture an app translated perfectly into French, word for word. Dates still appear as month, day, year. Prices are still in dollars. The name field still expects a first name then a family name in the American order. Text on three buttons now overflows, because French runs longer than English. Every single word is correct, and the app still feels foreign to the person using it.
That gap is what localisation closes. It treats the product as the thing being adapted rather than the text, which is why it applies to anything interactive: software, mobile apps, games, e-learning, connected devices. Translation is a component of the job, not the whole of it.
Localisation sits alongside our wider translation services, drawing on the same pool of native-speaker linguists. The difference is what surrounds the words: file handling, context, character limits, format conventions and a testing pass at the end.
Developers worry, quite reasonably, about linguists breaking things. Software localisation done properly leaves your build exactly as it was, minus the English. We work with the standard formats, including XLIFF, JSON, XML, .properties, .resx, .strings, gettext PO files, CSV and YAML, and we translate only the translatable text. Placeholders, variables, markup tags, escape sequences and keys come back untouched. If you use a localisation platform, we can usually work inside it and fit around your release schedule.
Plurals deserve a mention, because they trip up more projects than anything else on this page. English gets away with two forms. Polish uses three plural categories and Arabic six, so a string built as "1 file" plus "n files" cannot be expressed correctly in either unless your framework supports plural rules. If your code concatenates fragments to build a sentence, flag it early: far cheaper to fix in the source than to work around in twelve languages.
A linguist handed a spreadsheet sees strings in isolation. "Open" could be a button, a menu item, a status label or an adjective. In English it looks the same either way; in German or Spanish those are different words with different capitalisation, and choosing wrongly makes the interface read as though it was assembled by a machine.
So give us context wherever you can: screenshots, a line in the developer comment field, a note saying which screen a key belongs to, character limits, and what each placeholder actually holds. A test build is better still. Where context is missing we will ask rather than guess.
Translated text rarely occupies the same space. German, Polish and Finnish commonly run longer than English, and on short strings the difference can be a third or more, which is exactly where fixed-width buttons and tab labels give way. Chinese and Japanese usually run shorter, leaving gaps that look like a bug even when nothing is wrong. Tell us the character limits up front and we will work inside them, or say honestly when a limit forces a wording that loses meaning.
App localisation covers the interface strings and everything around the app as well: the store listing, the keyword field, screenshot captions, release notes, push notification templates and in-app help. The store listing is easy to overlook and does a surprising amount of work, because it is the only part most people read before deciding whether to install.
Release cycles matter more here than in document work. We keep a translation memory and glossary per product, so each sprint we handle only the new and changed strings. Send the diff, get it back, ship. Most app clients settle into that rhythm within a release or two, and the per-release cost drops sharply once the memory has something in it.
This is the part clients most often discover late. The words can be flawless while the product still behaves like a British one:
We will tell you which of these genuinely affect your users and which are theoretical for your markets. Adapting everything on the list for a product with two European locales is money spent for the sake of a checklist.
Desktop and web applications, dashboards and business tools, with the interface, help centre and documentation adapted together.
iOS and Android apps, including store listings, screenshot text, release notes and push notification templates.
In-game text, menus, item names, dialogue and store pages, worked to character limits and to the tone the game is written in.
Courses, modules and assessments: on-screen text, voiceover scripts, subtitles and the quiz answers that have to stay correct.
Interface text, safety warnings and setup instructions for hardware, appliances and IoT products with small screens.
A linguist reviews the built product, checking fit, placement, formats and flow on real screens before release.
A spreadsheet of strings cannot show you that a heading is clipped at 22 characters, that the same word appears in two different renderings on adjacent screens, or that string 4471 has landed on the wrong dialog. Localisation testing is the pass that catches those, and it happens on the built product rather than the file.
Give a native-speaker linguist a build, a test account and a list of the screens that matter, and they walk the product as a user would. They check that text fits, that formats display correctly, that nothing is truncated, that placeholders have resolved into sensible sentences and that the wording reads naturally in sequence rather than merely correctly in isolation. Findings come back keyed to the string IDs, so your developers can work straight from the list.
It is worth booking for any product with a real interface. For a small string file going into one language it may be more than you need, and we will say so rather than quote for it out of habit.
UK software companies opening a first overseas market, usually one or two European languages before anything wider. App studios whose install data has started showing users in places nobody planned for. Training providers rolling an e-learning course out across an international workforce. Manufacturers shipping devices with a screen and a setup flow. Game developers with a release date and a character limit on every menu item.
Public sector work turns up here too. Councils and NHS trusts with resident-facing portals need those in the community languages their users speak, which is a localisation job rather than a document one, because it involves interface strings and forms.
Single-language projects are as welcome as multi-language ones. Pages such as Spanish translation services and Romanian translation cover individual languages, and the full language list runs to over three hundred, including the rare ones most agencies decline.
String work is priced per source word, so the size of your file and the number of target languages set the shape of the quote. After that: the subject matter, since regulated or technical content costs more per word than plain interface copy; the rarity of the language, because a small pool of qualified linguists moves the rate; and how much context you supply, because guesswork costs time. Repeated strings are reused through translation memory rather than charged again, and localisation testing is quoted separately as time against a defined set of screens. Our pricing page sets out honest per-word ranges rather than one headline rate that would be wrong for most projects.
To start, send your string files through the quote form with your target languages and your release date. We will come back within one working hour during office hours with a fixed price, a realistic schedule and, if it helps, a view on which languages to do first rather than all of them at once.
If the thing being translated is a site rather than a product, meaning pages, blogs, product listings, page titles and meta descriptions, start with website translation. Print collateral such as manuals and datasheets goes through brochure translation, video is covered by subtitling, and if you already have localised strings and simply want an independent check, our proofreading service gives them a second read.
Send us your string files and target languages. We will quote, and recommend a sensible rollout rather than everything at once.