Multilingual Requirements for Public-Sector Websites

"Multilingual" appears in most public-sector website specifications and is almost never defined. It usually arrives as a single line — "the site shall support multiple languages" — which vendors price as a translation plugin, and which then satisfies nobody: not the resident who needs the eligibility rule in Spanish, not the compliance officer who assumed the obligation was covered, and not the staff who now maintain two versions of everything.

Language access on a public-serving site is a set of decisions, not a feature. These are the ones worth making deliberately.

Start from who your community actually is

Do not guess, and do not translate into whatever the plugin offers. Use real data — census figures for your service area, school district enrolment data, the languages your front desk and phone line actually handle, and what your caseworkers report.

That exercise usually produces a shorter and different list than expected. It is also the evidence you need if anyone asks why you chose the languages you did, which is a much better position than "the vendor offered twelve."

Decide what gets translated, not just into what

Translating an entire site is expensive to produce and worse to maintain, and most of it is not what non-English speakers need. Tiering is the workable approach.

Tier one — always translated, professionally. Anything that determines whether someone gets a service or a benefit: eligibility rules, how to apply, required documents, deadlines, fees, appeal rights, emergency information, and how to request an interpreter.

Tier two — translated where resources allow. Programme descriptions, service overviews, key contact information.

Tier three — not translated. Board minutes, staff news, historical archives. Provide a route to request translation instead.

Writing that tiering into the specification changes what you get. Without it, a vendor prices the cheapest interpretation of the requirement.

Understand where machine translation is and is not adequate

Machine translation has improved enormously. It is genuinely useful for browsing, for tier-three content, and for giving someone the gist of a page.

It is not adequate where accuracy is legally or practically consequential — which is exactly tier one. A mistranslated eligibility rule can cause someone to not apply for something they qualify for, and an automated translation of an appeal deadline that gets the date format wrong is a serious problem. Machine output also degrades badly on the jargon and long sentences public-sector writing is prone to.

The workable pattern: professional human translation for tier one, reviewed by someone who speaks the language and understands the programme; machine translation available site-wide for everything else, clearly labelled as automated.

Write the English better first

The most cost-effective language-access intervention is usually improving the source. Translation cost scales with word count, and public-sector prose is full of words that carry no meaning for a resident.

Plain-language English is cheaper to translate, translates more accurately, and helps the much larger group of residents who read English as a second language or at a lower reading level. Do the plain-language pass before commissioning translation, not after — it will reduce the volume and improve the output.

Get the technical details right

Translated pages need their own URLs so they can be shared, bookmarked, indexed and cited. A page that changes language via a widget without changing the URL cannot be linked to in Spanish, which defeats much of the point.

Each page needs the correct language attribute in its markup, so a screen reader pronounces it correctly — a Spanish page announced by an English speech engine is close to unintelligible. Where alternate language versions exist, declare them so search engines serve the right one.

The language switcher should be visible without scrolling, labelled in the target language rather than only in English, and should keep the user on the same page rather than dumping them on a translated homepage. That last failure is extremely common and very frustrating.

Do not forget documents, forms and alerts

Translating web pages while leaving every form and PDF in English covers the easy half. If someone can read about a benefit in their language but the application is English-only, you have not provided access.

The same applies to emergency alerts, which are the highest-stakes content you publish and frequently the least prepared for translation because they are written under pressure. Pre-translate the templates.

Plan for maintenance from the start

Translated content goes stale independently of the source. The English fee schedule gets updated, the Spanish one does not, and now you are publishing two different answers — which is worse than publishing one.

The content model should link translations to their source so an edit flags the translation as out of date. Governance should name who is responsible for keeping tier-one content in sync, which connects to the broader content governance question. Without that, translation is a launch-day feature that decays quietly.

What to specify in an RFP

Put these in the requirements rather than the word "multilingual": the specific languages, chosen from stated data; a content tiering with professional translation for tier one; separate URLs per language with correct language attributes; a switcher that preserves the current page; translated forms and document alternatives; pre-translated emergency templates; and a maintenance model that flags translations when the source changes.

That paragraph turns an unpriceable line into something vendors can bid on comparably — the same principle as the rest of our government RFP checklist, and one of the obligations gathered in the public sector requirements checklist.