Software and Technology Localization
Software localization fails on structure more often than on wording. Strings arrive without context, plural forms are hard-coded to English rules, placeholders get reordered, and layouts assume English length. Fixing those four things does more for quality than any change of translator.
What do you need from our codebase to localize properly?
The string files in their native format and, critically, context for each string. A translator seeing only the word Open cannot know whether it is a button, a status, or an adjective describing a ticket. Keys, comments and screenshots resolve that; guessing does not.
We work directly in JSON, XLIFF, .po, .strings, YAML, RESX and the usual variants, so nothing has to be copied into a spreadsheet and pasted back — which is where placeholder corruption and key mismatches are introduced.
Where your source strings carry developer comments, we read them. Where they do not, the fastest quality win available is adding them once, because the same ambiguity is otherwise re-resolved incorrectly in every language you ship.
- Native string formats, no spreadsheet round-trips
- Developer comments or screenshots for ambiguous strings
- A do-not-translate list for product names and code identifiers
- Pseudo-localization run before real translation to expose layout limits
How are plurals and variables handled safely?
Through ICU MessageFormat rather than string concatenation. English has two plural categories, so code written against English assumptions breaks elsewhere: Polish has four in CLDR and Arabic has six. Concatenating a number with a hard-coded suffix cannot be translated correctly at all.
Placeholders are the other recurring failure. Word order differs between languages, so a translator has to be able to move a placeholder within the sentence. Named placeholders make that safe; positional ones make it a guess. We lock placeholders in the tool so they cannot be edited or dropped, and we test that the rendered string still forms a sentence.
Can localization keep up with a weekly release?
Yes, with continuous localization rather than batch handoffs. New and changed strings are pulled from the repository as they land, translated against the existing memory and glossary, and pushed back — so the translation lag is hours to days rather than a release cycle.
That requires a decision about what ships untranslated. Most teams choose to ship the feature with English fallback for new strings and let translations land in the following build, which is cleaner than holding a release or shipping machine output to users.
Do you localize documentation and support content too?
Yes, and it should share the interface glossary. When help documentation calls a feature something the interface does not, users stop trusting both. One terminology base across product, docs and support content is the point of doing it in one place.
Frequently asked questions
Will translation break our placeholders or markup?
Not if they are locked. We protect placeholders, markup and code identifiers in the translation tool so they cannot be altered or deleted, and the exported files are validated against the source structure before delivery.
Can we use machine translation for some string types?
A reasonable pattern is machine translation with human post-editing for long-tail documentation, and human translation for interface strings, onboarding and anything commercial. Interface strings are short, high-visibility and context-poor — exactly where engines err.
How do you handle right-to-left languages?
Translation is the smaller half; the interface has to mirror. Layout direction, icon direction, progress indicators and number formatting all change, so we flag components that will not mirror correctly rather than deliver text into a layout that cannot hold it.
Shipping a product in more languages?
Send a sample string file. We report back on what will break before we quote.
Request a quote