Software localization
Localization adapts your product, not just your words: UI strings, docs and marketing translated by software-specialist linguists who see the screens, not just the spreadsheet.
Localization is a product decision, not a word swap
Translation answers one question: what do these words mean in another language? Localization answers a harder one: how should this product behave in another market? Dates flip from MM/DD to DD/MM. Prices need the right currency and decimal convention. German text runs roughly a third longer than English and breaks layouts that were never tested for it. A friendly, casual tone that works in English can read as unprofessional in Japanese.
Get the words right and the rest wrong, and users feel it immediately — the product works, but it feels translated. That feeling costs you activation and retention in every market where it happens.
Short strings are the hardest strings
The most difficult sentence in your product is one word long. “Submit”, “Back”, “Clear”, “Close” — each has several correct translations depending on where it appears and what it does. A translator working from a spreadsheet of bare strings has to guess. Machine translation does not even guess; it picks the statistically most common reading and moves on.
Our software practice group works differently. Translators see screenshots, string descriptions or a staging build, so they know whether “Back” navigates or describes anatomy. Placeholders and variables ({username}, %d, ICU plural forms) are locked so they survive translation intact. And when context is genuinely missing, the string comes back to you as a question, not a silent guess.
One term base across UI, docs and marketing
Your users experience your product as one thing: the button on screen, the help article that mentions the button, the landing page that promised the feature. If those three call the same feature by three names, the product feels broken even when it works.
So we translate all three layers against a single term base per language:
- UI strings — translated in context, length-checked, placeholder-safe
- Documentation and onboarding — help articles, tooltips, in-app guides, release notes, using exactly the labels that appear on screen
- Marketing and web content — adapted for the market rather than translated literally, but never contradicting the product terminology
Translation memory sits underneath everything, so a string you shipped last quarter is never paid for twice, and an updated doc is quoted on what changed.
Machines help, humans sign off
We use technology where it earns its place: translation memory on every account, machine translation with human post-editing for high-volume, low-risk content like archived help articles. For the strings your users see every day, specialist humans translate and a second linguist reviews — because a mistranslated button is a bug, and you cannot patch it with fluency.
Every project starts the same way: send us your strings and context, and you get a fixed quote with a delivery date within 24 hours. If you release continuously, our continuous localization service plugs into your pipeline instead of your inbox.
Frequently asked questions
What is the difference between translation and localization?
Translation converts the words; localization adapts the product — date and number formats, currencies, text expansion in the layout, tone conventions, even which examples make sense locally. A correctly translated app can still feel foreign. Localization is what makes it feel built for the market.
Which file formats do you work with?
The formats developers actually use: JSON, XML, XLIFF, .strings, .resx, PO/POT, YAML, properties files and most TMS exports. Strings go back in the same structure they came out, with placeholders and markup intact.
How do you translate short strings without context?
We ask for context rather than guessing: screenshots, string descriptions, or access to a staging build. A string like "Back" can be a navigation button or a body part in a fitness app. When context is genuinely missing, we flag the string instead of picking the statistically likely reading.
Can you keep the docs and marketing consistent with the UI?
Yes, and it matters more than most teams expect. Every UI label lives in a shared term base, so when your help article says to click "Settings", it uses exactly the word your users see on screen. UI, docs and marketing are translated against the same term base by the same practice group.