Choosing which languages to support and what to translate first

Reference article · 7 min read

A language access plan is a set of commitments about who can use your services and in what language. The technology has to deliver on those commitments, which is why the plan should be written before translation tooling is procured rather than after. Agencies that start with a vendor demonstration tend to translate whatever is easiest to translate: the news releases, the about pages, the content with the least legal consequence. Agencies that start with data and a document inventory translate the eligibility notice, the appeal rights, and the application form first.

What follows is a planning sequence: identify the languages spoken in your jurisdiction, apply the thresholds that commonly trigger written translation, rank vital documents and transactions, tier the rest of the content, and keep translated material accurate as the English changes. Obligations in this area vary by state, by program, and by funding source, and federal policy has shifted in recent years, so treat this as a method and confirm your specific requirements with your counsel and with the agencies that fund your programs.

Build the language profile from data you already have

Three kinds of data answer three different questions, and you need all three.

• Population data. Census Bureau American Community Survey tables on language spoken at home and self reported English speaking ability are the standard starting point. Pull them at the smallest geography that matches your service area rather than at the state level, since a county figure can hide a concentration in two neighborhoods.
• Enrollment data. School districts collect home language information at registration. District level counts are often the earliest signal of a newly arrived community, well before it appears in multi year survey estimates.
• Service and demand data. Language preference fields in your case management and eligibility systems, interpreter invoices, language line call logs, 311 and library contact records, and the languages your frontline staff report requesting.

Population data tells you who lives in the jurisdiction. Demand data tells you who is already trying to reach you. The gap between them is a finding in itself: a language with a large resident population and almost no recorded contact usually means people are not getting through.

Apply the thresholds, then document the analysis

Federal civil rights guidance for recipients of federal financial assistance has long framed the question as a balancing test: the number or proportion of limited English proficient people served or likely to be served, how often they interact with the program, how important the service or information is, and the resources available. Guidance has also described a safe harbor under which translating vital documents for language groups that reach a specified share or head count of the eligible population is treated as strong evidence of compliance, with a translated notice of the right to free oral interpretation as the alternative for very small groups. The specific figures and the current status of federal guidance should be confirmed with counsel, and state statutes, consent decrees, and grant conditions may impose their own thresholds that are stricter.

Whatever you conclude, write it down. The record should state the data used, the date, the languages selected, the languages considered and not selected with the reasoning, and the date the analysis will be revisited. That document is what you produce during a compliance review, and it is also what keeps the plan from being relitigated every budget cycle.

Translate vital documents and transactions first

Treat a document as vital when not understanding it could cause someone to lose a benefit, miss a deadline, forfeit a right, or come to harm. That usually includes applications and eligibility forms, notices of denial, reduction, or termination, appeal and hearing rights, consent and release forms, anything requiring a signature, complaint procedures, emergency and public safety alerts, and the notice that free language assistance is available.

Translate the transaction, not just the PDF. A translated application that returns English error messages, sends an English confirmation email, and produces an English determination letter from the case system has not been translated. Inventory the full path: the form, the validation messages, the confirmation screen, the SMS and email templates, the generated correspondence, and the phone tree the resident calls when something goes wrong.

Tier everything else

Rank remaining content so the plan is buildable and so staff know the rules without asking.

• Tier 1. Vital documents and transactions. Human translation or machine translation with qualified human review before publication. Updates propagate within a defined turnaround.
• Tier 2. High traffic task pages: hours, locations, fees, how to apply, eligibility explanations. Reviewed translation, refreshed on a schedule.
• Tier 3. Supporting and reference content. Machine translation acceptable with a visible notice of machine assistance and a correction path.
• Tier 4. Archived, historical, and low traffic material. English with a prominent tagline offering free interpretation.

Use analytics and search logs to place pages, and revisit placement when traffic patterns change.

Machine output, human review, and versioning

Machine translation is genuinely useful for coverage and speed and genuinely unsuitable as the sole method for legally operative text. Build the workflow around that split.

• Maintain a glossary of program terms, agency names, and legal phrases, and require reviewers to follow it.
• Keep translation memory so repeated strings stay consistent and so review effort compounds.
• Version the English source. When a source string changes, its translations should flag as stale automatically rather than depending on someone remembering.
• Retain a record of what was published in each language and when. If a resident says the notice told them something different, you need to be able to show what they saw.
• Be cautious about relying solely on a browser level widget. It is fast to deploy, but you cannot review its output, correct a bad rendering, or prove what was displayed.

Also check that translated pages carry correct language attributes so screen readers pronounce them properly, and confirm that non Latin scripts and right to left text survive the entire path into your system of record.

Interpretation for the channels translation cannot reach

Written translation never covers everything. Telephonic and video remote interpretation handle the phone line, the counter, and field contacts, including languages below your written translation threshold. American Sign Language and other effective communication obligations under disability law are a separate requirement and should be planned separately, not folded into the same vendor assumption.

Give staff a short script for offering interpretation, make clear that the offer is free to the resident, and set expectations about relying on family members, particularly minors. If bilingual staff assist directly, define how their language skills are assessed rather than assuming self identification is sufficient.

What to require from vendors, and what to measure

Ask directly:

• Can we export all source and translated strings and the translation memory in standard formats, and do we own them?
• How are changes to English source detected and flagged for retranslation?
• Who performs human review, what are their qualifications, and how is that documented?
• For interpretation, which languages are available, what are typical connect times, and what are the recording and retention rules?
• Is content submitted for translation retained, logged, or used to train models, and does that match our data handling requirements?

In the contract, secure ownership and export of translation memory and glossaries, turnaround commitments by content tier, a defined correction process when an error is reported, and transition assistance at the end of the term.

Then measure a small set of things: the share of Tier 1 content current in each supported language, the age of the oldest stale translation, interpreter connect time and abandoned calls, contact volume by language and channel compared with your population estimate, completion rates for translated online transactions against English, and language access complaints and their resolution. Report those on the same cadence as your other service metrics, because a plan that is never measured quietly stops being true.

HQT works with state and local agencies on the systems side of this work, including content and translation workflows, integration with case and notification systems, and the reporting needed to show how a language access plan is performing.

Frequently asked questions