Your board approved a Spanish version of the site back in the spring. Six months later there is a Spanish version of the site — and it is quietly failing in ways nobody has logged as a defect. It ranks for nothing, because search engines never accepted it as a separate version. The registration form rejects half the phone numbers people type into it. Two of the buttons show text clipped mid-word. And the district or health system now owns a second site's worth of accessibility obligations that no one has budgeted for, because everyone assumed the accessibility work done on the English pages came along with the words.
Here is the specific thing most teams have wrong. Somebody added lang="es" to the Spanish pages and considered the multilingual wiring done. That attribute does nothing at all for your search visibility — Google's own documentation states plainly that it does not use the HTML lang attribute (or hreflang) to determine what language a page is in. Meanwhile the hreflang tags an SEO consultant added do nothing for your accessibility, where lang is the mechanism a Level A success criterion actually requires. Two attributes, two entirely separate jobs. Most multilingual sites ship one of them and assume it covered both.
hreflang and canonical wiring that tells a search engine which version belongs to whom. Translation alone produces a page that can be read. Localization is what makes it usable, findable, and defensible. Critically, accessibility conformance does not carry over from the source language: every localized page, PDF, and video caption has to be produced and tested again in that language.
The Distinction, Stated Once and Properly
Translation is the linguistic operation: source text in, target text out, meaning preserved. Localization is the larger operation that contains it — adapting the whole experience to the conventions, formats, and technical expectations of a particular locale. You can translate without localizing. You cannot localize without translating.
That is where nearly every article on this subject ends. It is also, unhelpfully, where the actual work begins. So the rest of this is not about the definitions. It is about what specifically breaks when a project is scoped as translation and delivered into a site that needed localization — and what it costs to find that out after launch instead of before.
What Translation Alone Leaves Broken
Every item below is something a word-for-word translation of your page content leaves in exactly the state it was already in. None of them are edge cases; they are the things that break on a normal organizational website.
| Element | What translation gives you | What localization has to do |
|---|---|---|
| Dates and numbers | The month name translated. | Reorder the fields and swap the separators. A deadline rendered 04/26/2027 is not merely unfamiliar to a day-first reader — parsed day-first it is month 26, which does not exist. Decimal commas, thousands separators, and 24-hour clocks all shift with the locale too. |
| Names, addresses, phone fields | Translated labels above unchanged inputs. | Rebuild the fields and their validation. A single required "Last Name," a five-digit postal-code mask, a US state dropdown, and a (555) 555-5555 phone pattern will each reject legitimate real-world input. Validation logic is where localization failures turn into abandoned forms. |
| Layout and components | Longer text in boxes sized for English. | Set expansion budgets per component before build — see the table below, because the usual rule of thumb gets applied backwards. |
| Reading direction | Arabic, Hebrew, Farsi, or Urdu text inside a left-to-right layout. | Mirror the interface: navigation, progress indicators, breadcrumb separators, and directional icons all flip, while phone numbers and embedded Latin-script strings do not. This is a build decision, not a styling pass. |
| Images and legal copy | Translated captions on the original graphics. | Replace screenshots that show English interface text, re-typeset any text baked into graphics, and source the locale's own version of required notices — nondiscrimination statements, privacy language, and grievance procedures are jurisdiction-specific, not translatable boilerplate. |
| Search wiring | Nothing. Translation does not touch the head of the document. | Reciprocal hreflang annotations, a correct canonical per locale, and an x-default fallback for visitors whose language matches none of your versions. Without these, your language versions read to a crawler as duplicate or competing pages. |
| Linked documents | A translated PDF, untagged. | Re-tag the translated file: reading order, alt text, table headers, and language metadata inside the document itself. The remediation you paid for on the English PDF does not transfer to its translation. |
The Text-Expansion Buffer Most Teams Set Is Backwards
Designers generally know that translated text runs longer, and the figure they have usually heard is around thirty percent. That number is roughly right — for long prose, which is the least useful place to apply it. Per the IBM guidance published by the W3C, the expected expansion ratio climbs sharply as the source string gets shorter:
| English source length | Expected translated length (European languages) |
|---|---|
| Up to 10 characters | 200–300% of source |
| 11–20 characters | 180–200% |
| 21–30 characters | 160–180% |
| 31–50 characters | 140–160% |
| 51–70 characters | 151–170% |
| Over 70 characters | 130% |
Read the first row again. A ten-character button label — "Apply Now," "Submit," "Next Step" — should be expected to come back two to three times longer. The components with the least room to give are precisely the ones that expand the most, which is why localized sites break at the buttons, the navigation, and the form labels while the body copy sits comfortably. A thirty-percent buffer applied evenly across a design protects the paragraphs and leaves every control exposed.
Already have language versions live? The two fastest things to check today are hreflang reciprocity and the lang attribute on each localized template — between them they explain most of the "we launched Spanish and nothing happened" cases we get called into.
The lang Attribute and hreflang Do Not Do Each Other's Job
This is the confusion that costs the most, because both attributes look like they announce a page's language, and neither one does what teams assume.
The lang attribute is an accessibility mechanism. WCAG Success Criterion 3.1.1 Language of Page (Level A) requires the default human language of each page to be programmatically determinable, and 3.1.2 Language of Parts (Level AA) requires the same for passages that switch language mid-page. This is not paperwork. A screen reader uses that declaration to select its pronunciation rules, so a Spanish page left at lang="en" gets read aloud in an English voice — every word technically present, the output close to unintelligible. A page that quotes an untranslated passage needs 3.1.2 handled as well, with a lang on that passage.
The hreflang annotation is a search mechanism, and it carries a requirement teams routinely miss:
Google treats hreflang as a signal rather than a strict directive — and its documentation is explicit that if two pages do not both point at each other, the annotations are ignored entirely. Every localized version has to reference all the others, including itself.
That reciprocity rule is unforgiving in practice. Add hreflang to the Spanish pages only, and you have added nothing at all; the tags are discarded rather than half-credited. It can be implemented three ways — link elements in the HTML head, HTTP Link headers (the only option for non-HTML files such as PDFs), or xhtml:link entries in your XML sitemap — and one method applied consistently everywhere beats a partial mix of all three.
Then the point that ties the two together: Google determines a page's language algorithmically, from the content itself, treating neither attribute as its source of truth. So a page with flawless markup and a half-translated body — Spanish article text inside English navigation, or an untranslated footer and cookie notice — still reads as ambiguous. Partial translation is not a partial win here; it actively muddies the signal you were trying to send.
Accessibility Does Not Carry Over — Plan for That Before You Launch
This is the part that turns a localization project into an unbudgeted second project, so it is worth being blunt: for accessibility purposes, every localized page is a new page.
- Per-language text alternatives. Alt text, form labels, error messages, button names, and link text all have to exist in the target language. An
altattribute left in English on a Spanish page is a failure on that page. - Per-language media. Captions and transcripts are language-specific. An English caption track does not serve a Spanish video, and auto-generated captions in a second language are typically worse than in the first.
- Per-language documents. Tags, reading order, alt text, and table headers live inside each individual PDF. Exporting a translated file from the same layout does not reliably preserve tagging — the accessibility work has to be redone per language, and that is where translated document programs most often stall.
- The deadlines apply to all of it. Public entities working toward the ADA Title II WCAG 2.1 AA dates of April 26, 2027 and April 26, 2028, and healthcare organizations working toward Section 504's May 11, 2027, are measured on their localized content too. Launching a second language now without planning for this does not defer that scope — it multiplies it.
The sequencing lesson is simple. Localizing first and remediating later means paying to fix the same structural problems once per language. Building accessibility into the localized templates and documents as they are produced costs a fraction of that. For the document half of this, our guide to Section 508 PDF remediation covers what "tagged properly" actually means, and our 508 and WCAG compliance services page covers how per-language testing gets scoped.
A Three-Step Plan That Prevents All of This
- Inventory the page, not the word count. Most localization quotes are wrong because the scope submitted was a word count. Separate three things instead: translatable strings, locale-bound elements (dates, numbers, addresses, phone and postal validation, currency, imagery, legal notices), and linked documents and media. The deliverable of this step is a scope that names each of them — not a total.
- Localize and lay out in the same pass. Translate against the actual target templates, with expansion budgets set per component from the string-length table above, and decide right-to-left mirroring before the build rather than after it. Own your translation memory and terminology so the second language costs less than the first, and the third less than the second.
- Re-test per language before launch. Run WCAG testing on each localized template, verify
hreflangreciprocity in both directions, and submit every form with real local data — a genuine address, a genuine phone number, a genuine postal code from the market you are entering. Nearly every defect described in this article surfaces in that one test.
Why Work With Taika
The reason localization projects generate that unbudgeted second project is almost always vendor structure. The translation vendor does not do accessibility, the accessibility vendor does not do languages, and the gap between them is exactly where the tagged PDFs, the caption tracks, and the per-language WCAG testing quietly fail to happen — usually discovered by a complaint rather than an audit.
Taika Translations covers both sides in one house: website translation and localization, multilingual desktop publishing, captioning and transcription, and Section 508 and WCAG 2.1 AA remediation — with ATA-certified linguists doing the language work. We are registered in SAM, hold a GSA Schedule and NASPO ValuePoint, and are a Veteran-Owned Small Business, so public-sector buyers can transact without standing up a fresh solicitation. And we will tell you plainly which parts of a localization scope you do not need, which is usually the more valuable half of the conversation.