In short
Localization adapts currency, dates, measurements, names, imagery, tone and legal wording alongside the text, so a product reads as though it was built for the local market.
A fully translated interface can still feel foreign. The words changed and everything around them stayed the same.
What else has to change
- Currency, number formats, dates and measurement units
- Example names, addresses and phone number formats
- Images and icons that carry a different meaning locally
- Tone and formality, which vary widely between languages
- Legal text, which is rarely a direct translation
- Layout, since translated text expands or contracts
Review in context
Strings reviewed in a spreadsheet look fine and break the layout in the product. Give reviewers screenshots or a staging build so they can see where text overflows or reads oddly.
Build a glossary early
Agree the translation of product terms before bulk work starts. Fixing terminology across a finished localisation is slower than agreeing it at the beginning.
Practical checklist
- Define the acceptance rule before any volume starts
- Review a small pilot before committing the full budget
- Track errors by category, language and reviewer
- Keep consent, source notes and version history with the files
Before you ask for a quote
A clear brief saves days. Share a sample file, target language or region, expected volume, deadline, quality threshold and any privacy restrictions. A supplier can then price the work on real effort rather than assumptions.
- Which languages, markets or user groups must be represented?
- What format does the final file need to arrive in?
- Who will approve ambiguous cases during the pilot?
- localization
- translation
- product
Need this done rather than read about it?
We run collection, annotation, transcription and localization projects for teams who would rather spend their time on the product.
Start a conversation