Requirements · Translation and localisation
What a localisation project needs before translators start
Last updated 25 October 2026 · 2 sources listed · Reading time about 3 minutes
Short answer
Localisation adapts a product, not only its words, to a market's language, formats, culture and rules. Before translators begin, source content should be final and free of embedded text, code should support multiple languages and text expansion, and teams should agree glossaries, style guides, review roles and a process for continuous updates.
Who this is for: A team taking a website, app or product into other markets who wants to avoid rework by preparing source content and technical foundations.
What to evaluate
Internationalised code and design
Hard-coded text, fixed-width layouts and assumptions about names or addresses break when languages change.
How to check: Ask developers to confirm string externalisation, Unicode support and flexible layouts before sending text out.
Final, clear source text
Translating drafts multiplies cost, and ambiguous English creates divergent meanings across languages.
How to check: Freeze the source content and have it reviewed for clarity, idioms and cultural assumptions.
Terminology and style guidance
Without agreed terms, translators choose differently, and inconsistency spreads through interface, help content and marketing.
How to check: Prepare a glossary of product terms and a style guide for tone and formality in each market.
Context for translators
Short strings such as buttons are impossible to translate accurately without knowing where and how they appear.
How to check: Provide screenshots, character limits and descriptions of each string's use.
Market requirements
Formats for dates, currencies, units, addresses and legal notices differ, and some markets have regulatory demands on content.
How to check: Create a checklist per market covering formats, legal text, payment methods and imagery.
Update workflow
Products change after launch, and manual file exchange quickly becomes error-prone.
How to check: Decide how added strings are detected, translated, reviewed and released, and who approves them.
Comparison
| Component | Why it matters | What to prepare |
|---|---|---|
| Interface text | Users encounter it constantly and errors undermine trust | Externalised strings with context and limits |
| Help and support content | Reduces support load in each market | Final source articles and glossary |
| Marketing material | Needs cultural adaptation, not literal translation | Creative brief and market insights |
| Legal and compliance text | Differs by jurisdiction and carries consequences | Review by local legal advisers |
Decision worksheet
Rate up to three options against this guide’s own criteria. It runs in your browser and saves only on this device. It is a thinking aid, not a recommendation.
1. Have you checked each criterion?
0 of 6 criteria checked.
2. Compare options (0 = fails or unknown, 3 = meets it well)
| Criterion | |||
|---|---|---|---|
| Internationalised code and design | |||
| Final, clear source text | |||
| Terminology and style guidance | |||
| Context for translators | |||
| Market requirements | |||
| Update workflow | |||
| Total (max 18) | 0 | 0 | 0 |
Questions to ask before you commit
- Is our code ready for text expansion and different scripts?
- Who owns the glossary and style guide?
- Which content needs adaptation rather than translation?
- What local legal or regulatory notices are required?
- How will translators see context for each string?
- Who reviews in-market before release?
- How will future changes to source text flow to translators?
- What is the budget for ongoing maintenance, not only the first launch?
Typical trade-offs
Localise everything at once
- Upside
- Consistent launch across markets
- Downside
- Larger upfront effort and review burden
Pilot in one market
- Upside
- Learn processes and fix technical gaps first
- Downside
- Slower overall expansion
Continuous localisation
- Upside
- Updates ship in step with source changes
- Downside
- Needs integration work and disciplined release process
Common mistakes
- Starting translation before the source interface is stable, causing repeated rounds of changes.
- Embedding text in images, which cannot be translated without redesign.
- Sending lists of strings without context and expecting accurate results.
- Ignoring right-to-left languages, name formats or address layouts until late testing.
- Overlooking in-market review, so awkward phrasing reaches customers.
Related questions
What is the difference between translation and localisation?
Translation converts text from one language to another. Localisation adapts the whole experience for a market, including formats, images, colours, units, legal notices, payment options and cultural references. A translated site may still feel foreign if it shows the wrong date style, address fields or product examples. Plan for localisation when users must complete tasks such as buying or registering, not only read content.
What does internationalisation mean for developers?
Internationalisation is the engineering work that makes a product adaptable to many languages and regions without rewriting code. It includes separating text from code, supporting Unicode, handling plurals and gender, allowing text to expand or run right to left, and formatting dates and numbers by locale. Doing it first lowers later localisation cost and avoids layout bugs. Standards bodies publish practical guidance developers can follow.
How do I check quality before release?
Use a mix of linguistic review and functional testing. Native reviewers should see translations in context, in the actual interface, because mistakes appear that are invisible in spreadsheets, such as truncated text or wrong gender. Testers should run key user journeys in each language. Collect feedback channels after release and agree who fixes issues. Record recurring problems and feed them into the glossary and style guide.
How should I plan for ongoing updates?
Treat localisation as a continuing process rather than a one-off project. Choose tools or integrations that detect changed source text, reuse earlier translations and route only changed content to translators. Define turnaround expectations, approval roles and release windows. Keep a clear change log so reviewers know what to check. Budget for maintenance, because untranslated or outdated text in some markets is common when updates are not planned.
Sources and further reading
These pages were reachable when we last checked. They informed definitions and rules referred to above; they do not endorse this guide. Where rules differ by country, check the authority for your location.
- W3C Internationalization — W3C, retrieved 27 October 2026
- Localization vs. Internationalization — W3C, retrieved 27 October 2026
Related guides
How to choose · Translation and localisation
How to choose a translation provider for business documents
Choose a provider by confirming language pair and subject expertise, the review process, confidentiality terms and how terminology is managed. Ask who actually translates, whether a second linguist reviews the work and what quality standard applies. For legal, medical or regulated content, verify credentials and any certification or sworn-translation requirement in the destination country.
Comparison · Translation and localisation
Machine translation versus human translation for business content
Machine translation is fast and cheap enough for gisting, internal reading and high-volume low-risk text. Human translation, or human review of machine output, is needed where accuracy, tone, legal effect or reputation matter. A common hybrid is machine output followed by professional post-editing, with the level of review matched to the risk of the content.
Requirements · Web and design agencies
What a website project brief must contain before you approach agencies
A useful brief states business goals, audience, core features, content responsibilities, existing systems, constraints, timeline and how decisions will be made. It does not need to prescribe design. The aim is to let agencies see the real problem so they quote against the same scope and ask intelligent questions.
How to choose · Artificial intelligence
How to choose an AI coding assistant for an engineering team
Evaluate coding assistants on how they treat your source code, how well they understand your repository, where they run in the workflow, and how their output fits review and testing. Compare code retention and training terms, repository-aware context, editor and pipeline integration, administrative policy controls, licence-related filters, and measured effect on review burden rather than raw lines produced.
Alternatives · Web and design agencies
Web agency, freelancer or website builder: which route fits
The right route depends on complexity, internal capacity and how often the site will change. Website builders suit simple sites run by the owner. Freelancers suit well-defined, bounded work with a few specialisms. Agencies suit multi-discipline projects with integrations, stakeholders and ongoing development. Compare total effort, continuity risk and flexibility, not only the build cost.
How to choose · Marketing agencies
How to choose an SEO agency
Judge an SEO agency on its diagnosis of your site, the transparency of its methods, how it ties work to business outcomes rather than rankings alone, and who owns the assets it creates. Be sceptical of guaranteed positions and secret techniques. A sound proposal starts with an audit of your situation and explains what will be changed, by whom and how progress is measured.
All Translation and localisation guides · All Professional services