Translating your website is not inherently good or bad — it is useful when it removes a real customer barrier. This brief helps small UK businesses decide whether to commission translations, which content to prioritise, and how to hand a concise, actionable brief to a web studio so translations are usable and maintainable.
Decision checklist: when and what to translate
Start with user need. Translate only the content customers need to complete a task (for example: product and checkout pages, booking flows, key legal and support pages), not the entire site by default. GOV.UK’s guidance recommends scoping translations to what users must be able to do and thinking about how translations will be kept up to date and whether responses will also need translation (GOV.UK).
Work through these quick checks:
- Customer evidence: do analytics, sales, enquiries or customer profiles show demand from specific language groups?
- Commercial impact: will translations affect conversion points — product pages, pricing, checkout, or booking confirmations?
- Regulatory obligations: are there legal requirements to make contract or distance-selling information available and understandable to customers in a particular language? If you sell online, you must be clear about key terms and how customers receive them (GOV.UK).
- Support and fulfilment: can your team support customers in the target language (after-sales, returns, complaints)?
- Maintenance load: how often will that content change and who will update translations?
Choosing which languages to prioritise should be pragmatic: use customer data, location of enquiries, and nearby communities. Start with one or two languages that clearly unlock revenue or reduce friction rather than translating into many languages at once.
Quality choices: human vs machine + post-edit
Decide quality by function. For transactional and legal content choose human translation with a reviewer experienced in your sector. For marketing pages you can consider machine translation with human post-editing, but only if the post-editor is briefed on tone and localisation. Be explicit about acceptable quality levels in the brief (literal accuracy, tone, and any terminology to preserve).
Make content ownership and the update flow explicit in the contract: identify who owns source content, how changes are flagged, and whether updates trigger translation workflows. GOV.UK highlights the importance of planning how translations will stay current (GOV.UK).
Technical brief for studios
Give the studio clear technical requirements so translations are searchable, accessible and maintainable:
- Language declaration: each translated page must declare its document language (html lang attribute). This helps screen readers and search engines; validate with the W3C i18n checker (W3C).
- Encoding: use UTF-8 for all pages to avoid character issues with non-Latin scripts (W3C).
- Language navigation: implement an explicit language switcher and link rel-alternate-hreflang where appropriate to show equivalents for each language; follow the GOV.UK design patterns for behaviour and accessibility (GOV.UK Design System).
- Content structure: store translations as discrete content items (fields per language) in the CMS, not as HTML blobs. That keeps text extractable for review, SEO and future reuse.
- CMS/data model: require a language-aware data model: content IDs shared across languages, per-language fields for title, summary, body, metadata, and an admin UI to view and edit language variants.
- SEO basics: ensure human-readable URLs or clear language prefixes (e.g. /fr/), correct hreflang annotations and metadata per language; don’t rely on JavaScript-only navigation for language selection.
Operational appendix: costs, testing and launch checklist
Keep operational reality front of mind: translations add ongoing cost and complexity. Budget for initial translation, periodic retranslation of changed content, and QA. Test with native speakers for functionality, tone and accessibility — automated checks are not enough.
- Pre-launch checks: validate html lang attributes and UTF-8 encoding, confirm language switcher is keyboard accessible and preserves context, check hreflang links and canonical tags, and perform spot checks of transactional copy (checkout, confirmation emails, terms).
- Post-launch: set a monitoring process for incoming enquiries in other languages and a schedule for reviewing translated content after product or policy changes.
If you’d like a one-page commissioning brief to hand the studio, I can draft that from the checklist above and the GOV.UK and W3C references used here. For practical help getting started with a studio or checking your CMS setup, see our commissioning guidance for small businesses (start here).
Sources: GOV.UK content guidance on considering translations; GOV.UK Design System language navigation; W3C i18n Checker; GOV.UK online and distance selling guidance.