Insights
Translation Is No Longer the Hard Part
AI has made translated words abundant. The scarce advantage has moved to the architecture, judgment, and operating system around them.
For most of the modern internet, a website localization project began with a word count.
An agency exported the strings. A project manager separated repetitions from new words. Translators worked through batches. Reviewers left comments in spreadsheets or a translation management system. The translation memory grew, and its growth was treated as compounding advantage: the larger the memory, the fewer words the client would need to buy again.
The entire commercial structure reinforced one assumption. Translation was the difficult part.
It was understandable. Good translation is demanding work. It requires language, context, subject knowledge, and judgment. At scale, it also requires coordination. When production capacity was scarce, the bottleneck was visible and easy to price: source words in, target words out.
But bottlenecks move.
In its 2025 Localization Trends Report, based on activity among more than 3,000 Lokalise customers from 2021 through 2024, the company reported that machine-assisted methods accounted for roughly 70% of translation activity. It also reported a 533% increase in its AI translation category during 2024.
Those numbers need boundaries. This is platform data, not a representative census of every translator or localization program. Lokalise does not publish the raw denominator needed to turn the figure into a universal industry benchmark. Still, the direction is hard to miss: machine assistance has moved from an edge case to the normal operating environment for a large set of localization teams.
Translation is no longer scarce in the way it once was. A competent first pass can be produced in seconds, in dozens of languages, at a marginal cost that would have sounded implausible a few years ago.
Expert implementation is still scarce.
Knowing which markets deserve investment is scarce. Designing locale URLs that will survive the next platform migration is scarce. Mapping search intent instead of translating keywords is scarce. Keeping canonicals, hreflang, sitemaps, schema, analytics, and internal links coherent across thousands of pages is scarce. So are governance, cultural judgment, and the discipline to keep every locale correct after launch.
This is why the familiar “website translation project” is becoming obsolete. Multilingual websites are not disappearing, and translation is not becoming irrelevant. The project is disappearing as a useful unit of work. Translation is becoming one automated capability inside a larger, continuous localization system.
We solved the wrong problem
The old model treated a website as a document with interactive features.
Export the words, translate them, import the words, and the site has been localized.
That model confuses the most countable layer with the whole system. A website is not a brochure stored in a browser. It is a living arrangement of:
- URLs and routing rules
- search demand and intent
- titles, descriptions, headings, and structured data
- canonical and alternate-page relationships
- navigation and internal links
- content hierarchy and publishing logic
- analytics dimensions and consent states
- forms, checkout paths, and conversion events
- design constraints, plural rules, and bidirectional layouts
- organizational decisions about who can publish what
Text runs through all of these layers, but text is not the system.
Consider a company launching Canadian French. The homepage copy is fluent. The product pages read naturally. Yet /fr-ca/pricing canonicalizes to /pricing; the language switcher drops users back on the homepage; Product schema still describes the offer in English; the blog links to unprefixed English articles; and paid campaigns land on a form whose confirmation email has never been localized.
Was the website translated? Yes.
Was the market experience localized? No.
The distinction matters because the broken layers can suppress the value of excellent prose. A search engine may not confidently associate the page with the right language cluster. A visitor may enter through a French query and leave when the purchase journey turns English. The analytics team may see “organic traffic” without a reliable page_locale or market dimension, making it impossible to know whether the launch created qualified demand.
The conceptual mistake looks like this:
| What the old project counted | What the market actually experiences |
|---|---|
| Words and strings | Intent, pages, journeys, and outcomes |
| Translation completion | Locale completeness |
| Linguistic QA | Linguistic, technical, functional, and cultural quality |
| Delivery date | A continuously changing production system |
| Cost per word | Cost and value per market |
Translation was never the whole localization problem. It was simply the part with the clearest production line.
AI did not replace localization. It changed what localization means
Spreadsheets did not eliminate accountants. They eliminated much of the manual arithmetic that had occupied accountants.
The profession did not vanish when a formula could total a column faster than a person. Its center of gravity moved toward controls, interpretation, modeling, compliance, and advice. Calculation remained necessary; it stopped being the primary place where professional value accumulated.
AI translation is creating a similar change.
Translation remains consequential. A wrong dosage in medical content, an ambiguous warranty, or an offensive campaign line is not rescued by a perfect hreflang implementation. High-risk material still warrants specialist review, and high-visibility brand language still benefits from exceptional writers.
But for a large class of website copy, producing a serviceable draft is no longer the expensive mystery it was. Models can use a glossary, preserve placeholders, follow tone guidance, and revise against feedback. They can process navigation labels and long-form content in separate passes. They can generate candidate titles fitted to a character constraint. None of this guarantees excellence. It does remove a great deal of repetitive production work.
The valuable question changes from “How do we translate 80,000 words?” to “How do we enter this market without creating an incoherent second website?”
That question is more strategic and more technical.
It asks whether there is enough local demand to justify full parity. It asks whether the business should launch fr-CA, fr-FR, or generic fr; whether country folders, subdomains, or country-code domains fit the operating model; which English pages have no meaningful equivalent in the target market; which terms should remain stable; and what evidence will prove the locale works.
The machine can produce words. The organization still has to make decisions.
The bottleneck has moved from producing translated words to designing a system in which those words can create demand.
That is not the end of localization. It is localization becoming a more complete discipline.
Why most AI translation projects still fail
AI makes it possible to create a large multilingual surface quickly. It does not make that surface coherent by default.
In fact, speed can worsen familiar mistakes. A team that once mistranslated 20 pages in a quarter can now misconfigure 2,000 pages in an afternoon.
Literal keyword translation
Search behavior is not a bilingual dictionary.
An English cybersecurity company might target “endpoint protection.” A literal rendering can be grammatically correct while missing the phrase buyers use in Germany. A US travel company may optimize for “vacation rentals,” while a market searches with a local category term closer to “holiday apartments.” Even when two phrases mean the same thing, their volumes, commercial intent, and SERP composition can differ.
The correct workflow starts with market-specific search evidence, then adapts the page. It does not translate the English keyword map and assume demand moved with the words.
Broken hreflang
Hreflang is easy to generate and surprisingly easy to generate incorrectly.
A Spanish page points to English and German alternates, but the German page does not reciprocate. A deleted French URL remains in the cluster. Region codes use underscores instead of valid language-region notation. Every locale points x-default at itself. Or hreflang is emitted on a noindex placeholder that should never have been declared an alternate.
Google’s documentation is explicit that alternate relationships should be complete and reciprocal. Invalid or nonreciprocal annotations may be ignored. The consequence is not always a dramatic penalty. It is often quieter: the signals a team expected Google to use are simply not dependable.
Incorrect locale architecture
Architecture is a long-lived business decision disguised as a URL choice.
Suppose the first launch uses /es/ for Spanish. Six months later, separate teams need Spain and Mexico, prices differ, and regulated copy diverges. Does /es/ remain a global fallback? Does it redirect to /es-es/? Which URL has accumulated links? How are existing canonicals and language clusters migrated?
AI can create folders. It cannot infer the organization’s market model unless that model has been made explicit. A locale registry should define language, region, URL prefix, HTML language, text direction, fallback behavior, and launch status before pages multiply.
Duplicate metadata
Teams often translate body copy and leave titles or descriptions untouched. Others ask a model to translate one English title across ten markets without inspecting the resulting SERPs.
The first approach produces duplicate English snippets on otherwise localized pages. The second produces unique strings but not necessarily useful search propositions. Metadata needs local intent, local language constraints, and a reason for the searcher to choose the result. “Unique” is a database property, not a quality standard.
Untranslated or contradictory schema
Structured data frequently sits outside the content files handed to translators.
The visible page says “Logiciel de gestion des dépenses,” while JSON-LD says “Expense management software,” declares inLanguage: "en", and points its url to the English canonical. A crawler now receives two accounts of the same entity.
Schema.org defines inLanguage using language codes, but the larger principle is consistency: visible copy, document language, canonical identity, and entity URLs should describe the same locale experience.
Broken internal linking
A translated page can quietly leak users and crawlers back into the source language.
The German navigation is correct, but inline links inside translated articles retain /pricing, /guides, and /contact. Breadcrumbs use localized labels yet resolve to English routes. Related-content modules select the globally newest article instead of a valid locale sibling.
This is not cosmetic. Internal links communicate hierarchy and distribute authority. They also define the next step in a user journey. Locale-aware path helpers and automated checks matter as much as translated anchor text.
Missing locale analytics
If a company cannot segment performance by locale and market, it cannot operate localization as an investment.
Teams routinely launch pages without a consistent locale dimension, then attempt to reconstruct performance from URL regexes. That can work until prefixes change, query parameters appear, or generic-language pages serve multiple markets. Conversion events may not record content language at all.
A useful measurement plan connects page locale, user-selected market, acquisition source, landing page, and downstream outcome—while respecting consent requirements. Otherwise “international traffic grew” can conceal declining conversion quality or demand concentrated in one accidental page.
Poor cultural adaptation
Cultural adaptation is broader than idioms.
A US case study built around annual contracts may be weak proof in a market where monthly billing dominates. A “Book a demo” CTA may be too high-commitment for a new brand entering a trust-sensitive category. Testimonials, payment methods, privacy assurances, imagery, units, and support expectations can all affect whether fluent content feels credible.
Translation preserves a message. Localization decides whether the message belongs in the market.
Ignoring market prioritization
The ability to translate into 30 languages does not create a reason to launch 30 locales.
Every live locale creates an obligation: content parity, legal updates, product changes, support, analytics, and technical maintenance. A thin version of the entire site can be less useful than a complete version of the five pages that answer a specific market’s demand.
The intelligent decision may be to deepen one market, publish a narrow cluster in another, and avoid declaring the rest as active alternates until the organization can maintain them.
Publishing incomplete language versions
The most common failure is a locale that looks complete from the homepage and collapses one click later.
The hero is translated, but pricing is missing. The product pages exist, but help content does not. The footer links to untranslated legal pages. Hreflang promises alternates that return 404s. A model has created the appearance of scale without the operating capacity behind it.
Imperfect wording can reduce trust. These system failures can prevent discovery, break conversion paths, and undermine an entire language cluster. They usually cost more than polishing a sentence that was already understandable.
The evidence points to a new constraint
No single report proves that “translation is solved.” That phrase would flatten major differences among legal, literary, medical, technical, and marketing work.
What the evidence does show is a change in constraint.
Lokalise’s customer data shows machine-assisted work dominating activity on its platform and AI translation usage rising rapidly. The important observation is not that humans disappeared—they did not—but that language production increasingly happens inside machine-assisted workflows.
The complementary evidence comes from implementation.
In a 2026 analysis of 18 multilingual sites, agency Kolonell reported a median organic traffic increase of 127% over nine months for sites it said were built with international SEO foundations in place from the beginning. Its examples emphasize locale-specific URL architecture, reciprocal hreflang clusters, localized metadata, schema, sitemaps, and content.
That number should not be treated as an independent benchmark. Kolonell analyzed its own delivered work, did not name the sites, and did not provide a control group or isolate architecture from additional content, links, redesigns, and market investment. The finding is useful as case evidence, not causal proof.
Its relevance is more modest and more credible: the reported gains appeared in projects where translation was accompanied by sound multilingual SEO and locale architecture. This is consistent with Google’s own guidance to use distinct locale URLs, avoid forced automatic redirects, and keep localized versions and their alternate signals coherent.
When translated content is abundant, implementation quality becomes the differentiator.
Translation is now one step inside a larger workflow
A modern localization workflow is not an export-and-import transaction. It is a loop that connects market strategy to production evidence.
Discover → Audit → Locale architecture → Keyword adaptation → Translation → Technical SEO → Validation → Production verification → Continuous optimization
Each stage answers a different question.
Discover
Map what actually exists. Frameworks, routes, content collections, CMS fields, UI catalogs, schema generators, transactional messages, forms, legal pages, analytics, sitemaps, and hard-coded strings all belong to the localization surface.
Discovery also identifies constraints: locked brand names, regulated claims, unsupported product regions, right-to-left requirements, and pages that should remain intentionally unavailable.
Audit
Establish the baseline before adding another language. Which URLs are indexable? Where do canonicals point? Are existing locale clusters reciprocal? Do templates hard-code lang="en"? Which components link outside the active locale? Are titles generated from local content or a global fallback?
An audit turns invisible assumptions into a risk register.
Locale architecture
Define the registry and routing model. Decide whether locales represent languages, countries, or both. Specify the default locale, URL pattern, fallback policy, language selector behavior, text direction, and which pages are intentionally live.
This is where international expansion becomes software architecture rather than a folder-naming exercise.
Keyword adaptation
Build a local opportunity map. Inspect how native searchers describe the category, which SERP features appear, whether the query is informational or transactional in that market, and which local competitors shape expectations.
The output is not a translated keyword list. It is a market-specific relationship among query, intent, page, and conversion path.
Translation and transcreation
Now produce the language. Give the model or translator context: page purpose, audience, glossary, prohibited terms, style guidance, character constraints, placeholders, and the local keyword map.
Routine text can move quickly. High-risk and high-leverage copy can receive specialist review. Human attention is allocated by consequence rather than spread evenly across every repeated string.
Technical SEO
Connect each page to a stable identity. Generate self-canonicals, matching Open Graph URLs, reciprocal hreflang clusters, locale-aware sitemaps, correct lang and dir, localized structured data, and internal links that keep users in their chosen experience.
Technical SEO is not a post-launch checklist. It is part of how the localized site is rendered.
Validation
Machines are excellent at checking the work machines produce.
CI can fail when a locale page lacks a title, when canonical and og:url disagree, when an alternate is missing, when a translated catalog drops {count}, when an Arabic page renders left-to-right, or when schema points to an English entity URL.
Linguistic review remains important. It is now one layer in a broader test suite.
Production verification
A passing build proves the repository, not the deployed experience.
Spot-check live headers and HTML, sitemap responses, redirects, consent behavior, language switching, analytics events, and representative conversion paths. CDN rules and platform configuration can introduce failures that source-level tests never see.
Continuous optimization
Search demand changes. Products change. Source pages change. Models improve. New competitors teach a market different vocabulary.
Use search performance, conversions, support feedback, and local editorial judgment to update the system. Localization becomes an operating capability, not a launch event.
Translation occupies one stage in that sequence. It is a necessary stage, but no longer a useful description of the whole job.
A $71.7 billion industry still recreates the same knowledge
Nimdzi estimated that the broad global language-services industry reached $71.7 billion in 2024.
That figure includes much more than website localization: interpreting, media localization, dubbing, language technology, data services, cultural consulting, and other categories. Nimdzi also notes that not all of the total is commercially addressable and that some supplier revenue can overlap. The number should be read as the scale of a broad industry, not the size of a single software category.
At that scale, an odd inefficiency persists.
Agencies repeatedly create QA checklists. Consultants rewrite hreflang guidance. Localization managers rebuild glossaries. Engineers rediscover which fields contain translatable content. Teams reproduce review stages, implementation notes, launch templates, and spreadsheet trackers.
Some repetition is necessary because companies differ. A regulated bank should not inherit the approval flow of a travel startup. Locale strategy is contextual.
But much of the repetition is not differentiation. It is intellectual capital trapped in documents that are hard to execute.
A senior consultant knows to ask whether the language switcher preserves the current path. That question lives in a deck. An SEO lead knows that missing reciprocal alternates invalidate an expected signal. That rule lives in a checklist. An engineer knows that ICU placeholders must survive translation. That test may live only in memory until a production incident turns it into code.
Every project assembles the same fragments around a new word count.
This was tolerable when translation production dominated cost and time. As production becomes faster, the coordination tax becomes more visible. The industry does not lack expertise. It lacks a reliable way to package and run that expertise.
AI skills change the equation
Most organizations use generative AI as a conversation.
Someone opens a blank prompt and asks for a translation. On the next project, someone else writes a different prompt. The model has broad capability but no durable memory of the company’s architecture, standards, exceptions, or definition of done.
That is the AI equivalent of rewriting a common algorithm every time an application needs it.
Software engineering developed a better model: libraries. A developer does not rederive cryptographic primitives or rebuild a routing framework for each feature. Experts package a repeatable capability behind an interface. Other developers import it, configure it, test it, and improve it.
Professional knowledge is beginning to adopt the same structure.
An AI skill can encode:
- a sequence of work, including required inputs and outputs
- decision frameworks for architecture and market scope
- quality standards and explicit rejection criteria
- domain guidance for search, language, accessibility, and culture
- implementation patterns for common frameworks
- schemas for locale registries, keyword maps, and audit reports
- validation logic that turns standards into executable checks
- escalation rules for work requiring legal or specialist review
This is more than a long prompt.
A prompt asks for an output. A skill defines an operating method. It can tell an agent to inspect the repository before acting, create a locale plan, separate technical implementation from translation, preserve locked values, run validators, and report intentional exceptions. It gives the next project the benefit of lessons learned in the previous one.
That does not eliminate expert judgment. It changes its leverage.
The expert is no longer paid only to remember and repeat the checklist. The expert designs the checklist, encodes why each decision matters, improves the tests, and handles the exceptions where context changes the answer.
When language production becomes abundant, the reusable system around language becomes the asset.
A case study: packaging localization expertise instead of another translator
An open-source project offers a small but useful example of the shift.
After more than 15 years working in SEO and acquisition, Rank & Beyond founder Dr. Adam Guerguis could have built another interface that accepts text and returns translated text. That would have joined a crowded category solving the increasingly commoditized step.
Instead, the project took the form of an MIT-licensed AI skill: i18n Agent, whose skill identifier is multilingual-i18n-seo.
The distinction is the point.
The repository is not a hosted translation management system and does not claim to guarantee rankings. It packages instructions, templates, checklists, schemas, prompts, and offline Python validators that teach a compatible AI coding agent how to approach multilingual website work.
Its workflow begins with discovery and audit: identify the framework, route model, content sources, locale signals, and existing defects. It then moves into locale planning, including a registry, market priorities, keyword adaptation, risk flags, and a glossary stub for preferred or protected terms.
Technical implementation guidance covers canonicals, hreflang, sitemaps, document language, structured data, and analytics. A translation playbook addresses glossaries, style, search adaptation, placeholders, pluralization, right-to-left languages, CJK considerations, and quality rejection criteria.
The package also includes a CI template and framework-agnostic checks over generated HTML. Production verification is treated as a distinct phase, with live checks for locale head tags, sitemap behavior, language switching, analytics, and representative pages.
None of those ideas is unprecedented. That is precisely why the format matters.
The innovation is not a new theory of hreflang. It is moving known expert practice from scattered prose into a reusable capability an agent can follow. Instead of asking a general model to “translate this Astro site into Spanish,” a team can give the agent a process that requires it to inventory routes, define the locale, adapt search language, implement alternates, preserve structural tokens, validate output, and inspect production.
The project should not be mistaken for proof that every enterprise localization program can be compressed into one package. Large programs still need translators, local reviewers, TMS integrations, legal controls, product ownership, and organizational governance.
It is evidence of a more important direction: the durable product is shifting from translated output to encoded expertise.
The bigger shift: professional expertise is becoming software
Localization is an unusually clear example because it combines language, rules, code, and repeatable QA. But the pattern reaches beyond it.
A doctor can encode a structured intake workflow, evidence retrieval rules, red flags, and escalation thresholds—without delegating diagnosis to an unsupervised model.
A lawyer can package issue-spotting frameworks, jurisdiction checks, clause libraries, and review gates—without pretending a template replaces counsel.
A marketer can encode research methods, positioning decisions, brand constraints, experiment design, and measurement standards—without reducing strategy to generated copy.
Architects, researchers, and consultants can do the same. Each field contains repetitive production, reusable judgment, and high-context exceptions. AI lowers the cost of the first category. Skills and systems capture part of the second. Professionals remain essential for the third.
The simplistic debate asks whether AI will replace a profession.
The operational question is which parts of a profession can be made explicit, repeatable, testable, and distributable.
This creates a different competitive landscape. Experience once scaled mainly through hiring, training, and billable hours. Those mechanisms remain, but expertise can also be expressed as instructions, schemas, evaluators, tool calls, tests, and feedback loops. One expert can improve a system used across hundreds of projects. A junior practitioner can begin with stronger defaults. An organization can retain process knowledge when an employee or agency changes.
There are risks.
Bad expertise can be encoded as efficiently as good expertise. A stale skill can institutionalize obsolete guidance. Hidden assumptions can appear objective because they are written in code. Teams need provenance, versioning, evaluation, ownership, and clear boundaries for human review.
Those are governance problems, not arguments for returning to blank prompts and private checklists.
The future is not a world in which professionals vanish and general models improvise every decision. It is a world in which professionals increasingly design the systems through which their judgment operates.
Better systems win international markets
For decades, the website translation project had a clean shape: count the words, produce the languages, review the files, launch.
That shape fit the old constraint.
Now translated language can be generated quickly, revised against a glossary, and checked at a scale that changes the economics of production. The hard part has moved outward—to market selection, locale architecture, multilingual SEO, cultural adaptation, governance, quality assurance, technical implementation, and continuous learning.
Website translation projects are becoming obsolete, but multilingual work is becoming more ambitious.
The organizations that succeed internationally will not necessarily be the ones that generate the most languages or negotiate the lowest price per word. They will be the ones that know which markets to serve, construct coherent locale experiences, encode what experts know, and verify that the system remains true as the website changes.
They will have better architecture.
Better workflows.
Better knowledge.
Better AI skills.
Translation still matters. It simply no longer gets to stand in for the whole discipline.
Translation is becoming software. Expertise is becoming infrastructure.
Sources and further reading
- Lokalise, Localization Trends Report 2025 and the accompanying report announcement, covering platform activity from 2021–2024.
- Nimdzi Insights, The 2025 Nimdzi 100: The size and state of the language services industry, April 2025.
- Kolonell, Multilingual website creation 2026: i18n architecture + international SEO, May 2026. Agency-reported case evidence; not a controlled independent study.
- Google Search Central, Tell Google about localized versions of your page.
- Google Search Central, Managing multi-regional and multilingual sites.
- Schema.org,
inLanguage. - i18n Agent, the MIT-licensed
multilingual-i18n-seoskill used as the case study in this article.