High volume, tight constraints, and strings that break in production
Software is the content type engines handle best, and we will say so. What they do not handle is a 20-character field, a plural rule, a placeholder, or the same term meaning two different things in two parts of the product.
What we work on
- User interface strings and in-product text
- Help centres and knowledge bases
- Product and developer documentation
- Release notes and change logs
- Onboarding, empty states and error messages
- Legal and policy text inside products
- Marketing pages for product launches
- Support macros and canned responses
An honest assessment
Engine output on general software content is good. Short, declarative, well-structured strings in well-resourced languages are close to the best case for machine translation, and a great deal of product content can go out with light review.
That is not the whole picture, and the exceptions are expensive.
Where it breaks
Strings have no context. A source string reading "Open" might be a verb on a button or an adjective describing a status. The engine sees five characters and guesses. In a language that inflects, or that distinguishes the two grammatically, the guess is visible to every user.
Constraints are invisible to the engine. Character limits, fixed-width fields, buttons that must not wrap. German and Finnish expand; Chinese and Japanese contract; Thai and the Indic scripts have their own line-breaking and rendering behaviour. The engine translates for meaning and the layout breaks after release.
Placeholders, variables and plural rules. Variables translated by mistake, placeholders reordered into nonsense, plural categories that differ from the source language's two. These produce runtime errors and mangled sentences rather than merely awkward text.
Terminology drifts between surfaces. The term in the UI, in the help article and in the error message must match, or search fails and support tickets rise. Each surface is usually translated separately.
Error messages are the highest-stakes strings in the product and are routinely treated as the lowest. They are read by a user who is already stuck.
Legal text inside the product is not product text. Terms, policies and consent flows are legal content that happens to be rendered in an interface, and they should be reviewed as legal content.
What we deliver
- Constraint checking for length, wrapping and field limits, on real target text rather than source estimates.
- Placeholder, variable and plural verification as a mechanical pass, before linguistic review.
- Cross-surface terminology consistency across UI, help, documentation and support content, maintained as a termbase you own.
- Context-driven review — we will ask for screenshots, string context or a build rather than translating a spreadsheet blind, because that is where most of these errors are actually caught.
- Tiered review by surface. Error messages, legal text and onboarding get full review; release notes and long-tail help content get light review. Spending the same on both is the most common waste in this sector.
- Structured error reporting, so you learn what your pipeline gets wrong rather than just receiving corrected strings.
Languages where this matters most
Thai, Vietnamese and the Indic languages, where training data is thinner and script rendering adds a whole class of failure the engine cannot see. Japanese and Korean, where register decisions in product voice are made badly by default. Arabic, where right-to-left layout, interface mirroring and embedded Latin strings create problems entirely outside the text. German and Finnish, where expansion breaks layouts designed in English.