Government Website Translation and Language Access

Quick answer — Translate government content by service journey rather than by page, starting with what residents must do rather than what the organisation wants to say. Language access obligations vary by jurisdiction, so confirm yours before scoping.

Vitra.ai Universe runs white-labelled, and on-premise where data cannot leave.

Not every page, and not the ones you expect

A public body's site is mostly organisational content — announcements, minutes, strategy documents, leadership pages. Very little of it changes a resident's day. The pages that do are the ones attached to an action: applying, reporting, paying, renewing, appealing, registering. Those are the pages that decide whether someone gets a service or gives up. Translating by page count starts at the wrong end. Translating by service journey starts where the impact is.

Work out which languages, honestly

The languages spoken in your area are a matter of record, and the ones that need translated service content are usually a shorter list than the ones spoken.

Interpreter demand is the strongest single indicator, because it records people who already needed help and asked for it. Whatever obligations apply in your jurisdiction sit on top of that evidence rather than replacing it.

Whole journeys, not landing pages

A translated landing page in front of an untranslated form is worse than no translation, because it invites someone into a process they cannot finish.

The unit of work is the journey: the explanation, the eligibility check, the form, the confirmation, the follow-up correspondence and the appeal route. Half a journey produces an abandoned application and a phone call.

Plain language first

Translating dense administrative prose produces dense administrative prose in another language. Simplifying the source first improves every version at once, including the original. That work also lowers cost, because shorter clearer source text translates faster and repeats more. It is also the one improvement that does not need a translation budget to begin. A service team can rewrite a journey in plain language this quarter and see the benefit immediately in the original, with every future translation cheaper as a result.

Delivery

Website translation handles the site itself, with translation memory keeping service names and benefit names identical across every page that mentions them.

Where the platform must sit inside your own environment, it can be deployed on-premise, and where the service has to carry your own branding rather than a supplier's, it can run white-labelled under your identity.

The rest of the set

• Forms, benefits and eligibility, accessibility - Emergency alerts, public announcements, public health - Policy documents, consultations, census and surveys - Court notices, immigration content, sensitive records - Local authority sites, signage, procurement, staff training

More at Vitra for government and public sector.

FAQ

Which government pages should be translated first? The pages attached to an action — applying, reporting, paying, renewing, appealing, registering. Organisational content such as announcements and strategy rarely changes a resident's day.

How do you decide which languages to support? From evidence you already hold: local demographic data, interpreter and helpline requests, counter demand and application drop-off. Interpreter demand is the strongest signal because it records people who already asked for help.

Why translate whole journeys rather than pages? Because a translated landing page in front of an untranslated form invites someone into a process they cannot finish, which produces an abandoned application and a phone call.

Can the platform run inside our own environment? Yes. It can be deployed on-premise where data cannot leave your estate, and run white-labelled so the service carries your identity rather than a supplier's.