Customer
The Corpus Christi Regional Transportation Authority (CCRTA) serves a ridership where language access isn't a nice-to-have; it's a federal civil-rights obligation. Under Title VI, transit agencies must provide meaningful access to services for riders with limited English proficiency, and an upcoming compliance audit put a date on it.
Challenge
Enterprise localization platforms (translation proxies and managed services) carry recurring per-language, per-pageview fees, insert a third party into the serving path of every request, and would have taken longer to procure than the audit window allowed.
Professional human translation is priced per word. Across a site of this size — roughly 8,000 unique strings — multiplied by every language and re-purchased every time content changes, the numbers stop making sense for a public agency.
The free Google Translate widget is effectively deprecated, degrades page performance, and — fatally for a transit site — mangles the proper nouns riders depend on. A stop named "Staples & Gollihar" must never come back as something else.
And the audit had a requirement no widget could meet: equivalent access to the content of PDF route maps and schedules, documents that exist only in English.
Solution
Because the site was already server-rendered on SvelteKit, translation could be built as a rendering layer rather than a content-management program. Every page is translated on the server before it reaches the rider: translated pages live at real URLs (ccrta.org/es/…), riders' language preferences follow them across visits, and search engines still see canonical English.
Translation itself is done by an LLM with a curated transit glossary — and, more importantly, with structural protection: stop names, route names, and headsigns are marked untranslatable at the template level, so the data riders navigate by is never touched. Each unique string is translated exactly once per language and cached; after the first render, pages serve from cache at full speed with zero per-request translation cost. When staff edit content in the CMS, the new text translates itself on the next render. There is no translation workflow, no vendor ticket, no stale version.
The system fails open: if any part of the translation pipeline is ever unavailable, riders get English — never an error.
Featured Requirement
The audit's hardest line item — access to translations of PDF route maps — was met without translating a single PDF. Prose documents get an automatic "read translated version" view built from the PDF's extracted text; schedule PDFs, which are dense tables no translation preserves, route riders to the equivalent web page for that route — live map, full schedule, stops — already translated like every other page.
Quality, Continuously Verified
Machine translation without monitoring is a liability. An automated smoke test probes sampled pages in all fourteen languages every six hours — checking for untranslated leakage, verifying routing behavior, and confirming search engines are handled correctly — with failures reported to the same monitoring stack as the rest of the site.
Results
• Fourteen languages — Spanish, Vietnamese, Arabic, Chinese, French, German, Hindi, Italian, Japanese, Korean, Portuguese, Russian, Tagalog, and Thai — across every page of the site.
• One-time translation compute of roughly $1–2 per language for the entire site, versus recurring five-figure annual platform fees.
• Prototype to production in days, inside the audit window.
• New and edited content translates itself — no ongoing localization workflow.
• Audit requirements for PDF route-map access met through equivalent, always-current web content.
• No consent banner required: the only cookie involved is the rider's own language preference.