Buyers approach this as one purchase, and vendors are happy to quote it as one. It is four things, and the reason localized products still ship visibly wrong is that the fourth is the only one that checks the other three, and it is the line most often cut.
Worth separating them, including where the established vendors are genuinely strong.
The four things being bought
Translation
Converting text from one language to another, at quality proportional to what you pay. Established vendors do this well, translation memory makes it cheaper over time, and machine translation with human review is now the default for high-volume, low-risk content.
Adaptation
Making the content correct rather than merely translated — currency, units, date and number formats, address and name fields, imagery, examples, legal and regulatory wording. Different work from translation and frequently not covered by a translation quote.
Localization engineering
Extracting strings, handling plurals and gender, supporting right-to-left layout, keeping context available to translators, and running pseudo-localization before anybody translates anything. This is development work and it decides how expensive every subsequent language is.
In-market QA
Checking the built product, in the target language, on the devices people there actually use. The only step that verifies the other three worked, and the one that appears as optional on most statements of work.
A translation can be perfect in the file and wrong on the screen, and only one of those is what a user sees.
What it costs
| Component | Typical cost | Notes |
|---|---|---|
| Translation | $0.08 – $0.30 per word | Language pair and subject specialism drive the range |
| Review by a second linguist | +40 – 60% of translation | Standard for anything user-facing |
| Machine translation with human post-editing | $0.03 – $0.10 per word | Suitable for volume, risky for interface text |
| Localization engineering | Project-based | Paid once, then amortised across every language |
| In-market QA | $15 – $35 per hour | Native speaker, in-country, on a real device |
The interesting number is the last row, because it is small relative to the others and disproportionately effective. A build that has had thirty screens checked by somebody in the market catches the failures that make a product look foreign, and it costs less than translating the release notes.
Machine translation with post-editing deserves a caution rather than a dismissal. It is genuinely good for documentation, help content and long-form material. Interface strings are where it struggles most, because they are short, context-free and unforgiving — the exact conditions under which it produces confident nonsense.
What actually goes wrong
Almost none of it is bad translation. These are the recurring failures, and every one of them is invisible in a spreadsheet of strings.
Text expansion
German, Finnish and Russian commonly run a third longer than English. Buttons truncate, navigation wraps, fixed-height cards clip, and the design was signed off in the shortest language it will ever exist in.
Concatenated strings
A sentence assembled from fragments at runtime works in English and produces word order that does not exist in the target language. This is an engineering defect that surfaces as a translation complaint.
Formats treated as decoration
Dates, decimal separators, thousands separators, address field order, phone formats, name fields that assume a first and last name. Wrong here is not cosmetic; it produces genuinely incorrect information.
Imagery and examples
Screenshots in the wrong language, sample data with foreign names and addresses, gestures and colours that carry different meaning, seasonal references from the wrong hemisphere.
Register
The translation is accurate and the tone is wrong — too formal, too familiar, using a form of address the market does not use in this context. Users notice this before they notice anything else and rarely report it.
The languages that are not simply longer
Text expansion is the failure everybody plans for. The harder ones are structural, and they decide whether a market is a fortnight of work or a quarter.
Right-to-left languages — Arabic, Hebrew, Persian, Urdu — mirror the interface rather than translating it. Navigation, icons that imply direction, progress indicators, sliders and the order of a form's fields all flip. Mixed content makes it harder still, because a Latin-script product name or a phone number inside an Arabic sentence runs the other way and the rules for where it sits are not intuitive to anybody who has not worked in it.
Chinese, Japanese and Korean break lines differently, frequently run shorter than English rather than longer, and depend on font choices that a Latin-first design usually has not made. Text that fits may still look wrong, because line height and letter spacing tuned for Latin script produce cramped or loose results here.
Plural rules are the quiet one. English has two forms and several languages have four or six, with rules that do not map onto a count of one against many. A string built around a singular and a plural branch will be wrong in those languages regardless of how well it was translated, and the fix is in the code rather than the copy.
Then grammatical gender and case. A name or a noun inserted into a sentence may need a different ending depending on its grammatical role, which no runtime substitution can supply. This is the deepest reason concatenated strings fail, and the reason a translator asking for full sentences rather than fragments is doing you a favour rather than being difficult.
Pseudo-localization, before anybody translates
The highest-return step in this whole process costs almost nothing and is skipped by most teams.
Pseudo-localization replaces every translatable string with a machine-generated version that is longer, uses accented characters, and is wrapped in markers. Then you run the product. Anything that truncates, anything that fails to render, and — most usefully — any string that stays in plain English reveals itself immediately, because a hard-coded string is the one thing that cannot be pseudo-localized.
Doing this before the first language is translated moves a whole class of defects to the point where they are cheap to fix. Doing it after eleven languages have shipped means fixing the same layout bug eleven times.
The gap: checking the shipped thing
Translation vendors deliver strings. Quality assurance on those strings, where it happens at all, usually means a second linguist reading the file.
That process cannot catch anything on the list above, because none of it is visible in the file. The button that truncates, the date that reads as a different day, the sentence assembled backwards, the screenshot still in English — all of it requires somebody opening the built product, in that language, on a device of the kind people there use.
Two things about that requirement are worth being precise on.
It has to be a native speaker. Register is the thing that separates correct from natural, and a fluent second-language speaker will reliably pass text that a native speaker flags immediately. This is not a slight on anyone's fluency; it is what the eligibility requirement is for.
And it has to be their device. A German string checked on a developer's phone in a US office tells you the string fits on that phone. Device mix, screen size, font scaling and system language settings differ by market, and the failures cluster exactly where the tester's setup differs from the user's. How each layer of targeting narrows the pool and moves the rate sets out what each of those requirements costs, and what device and market coverage looks like as a testing programme covers the general version.
Specifying a QA pass so it produces something usable
The difference between a useful localization QA round and a list of opinions is entirely in the specification, and it is short.
State the screens and the path to reach each one, including the states that are hard to trigger — errors, empty states, long names, the longest plan title. State the device and OS constraints. State what counts as a finding and what does not, so you do not receive thirty reports about a deliberate style choice.
And fix the evidence requirement before anybody starts: a screenshot of the specific screen, the device and OS version, the string as it appeared, and what the tester expected instead. A report saying "the checkout page reads oddly" cannot be fixed, cannot be regression-tested, and consumes an engineer's afternoon establishing what was meant. What counts as evidence and how to specify it up front covers the formats and the sequencing.
Deciding after the work what would have been convincing is how disputes start. It is also how you end up with findings nobody can act on.
What to ask a vendor
Six questions that separate a translation supplier from a localization partner.
Who translates our content — employed linguists, a contractor pool, or machine translation with post-editing? All three are legitimate; the answer changes what you should expect and what you should pay.
What context do translators receive? Strings with no screenshot, no character limit and no note about whether the word is a button produce exactly the failures listed above, and the vendor knows this.
Is in-market QA included, and if so is it a linguist reading a file or somebody using the built product?
How is terminology managed across releases, and who owns the glossary?
What happens with regulated or legal wording — is it flagged for local legal review or translated like everything else?
And what is the turnaround for a small change? Localization programmes fail on the fiftieth two-word update far more often than on the initial launch.
Where we fit, and where we do not
Plainly: we do not translate. There are good vendors for that and a translation memory built over years is a real asset we have no equivalent of.
What distributes well is the fourth activity. Native speakers, in the market, on their own devices, working through a defined screen list and returning structured evidence — that is a coverage problem rather than a craft problem, and it is the part that gets cut because it is nobody's specialism. Eleven markets means eleven people who each spend an hour, which is a different shape of purchase from a translation contract.
For the people doing that work, and what the language market pays them, what translation and language work is worth covers the supply side honestly. How a brief becomes reserved capacity and verified evidence describes the mechanism end to end, and where the question is whether people can complete a task rather than whether the words are right, structured usability testing is the closer fit.