A second language that still sounds like you
Machine translation gives you a site that is technically in Spanish and reads like a manual. Language models, given your glossary and your voice, give you one that reads like you wrote it. How that works on WordPress, Shopify or a custom build, and where it does not.
Most second-language websites were made one of two ways. Either a translation agency was paid by the word, once, and the site has drifted out of sync with the English ever since. Or someone switched on a machine translation plugin and the Spanish version reads like the safety card in an aeroplane seat pocket. It is accurate. It is also obviously not you, and the customers it was meant for can tell in the first sentence.
There is a third way now, and it fits on most decent platforms.
What machine translation gets wrong
Google Translate and DeepL translate sentences. They do it well. What they do not do is know that you call it a “care plan” and never a “maintenance contract”, that your brand is casual in English and should be formal in German because your German customers are engineers over fifty, that the headline on the home page is a pun that should be replaced with a different pun, or that “Phase 2” is a term of art in your proposals and should stay in English.
So the output is correct and wrong at the same time. Every page is translated, and none of them sound like the company. A native speaker reads it and places you immediately: a foreign company that did not care enough to hire a person.
What a model does differently
A language model is not a translator. It is a writer that can take instructions. Given the English page, a glossary of your terms with the translations you have chosen, a one-page description of your voice in the target language, and three or four examples of pages already translated the way you like, it writes the page in the target language the way a good bilingual copywriter on your staff would. It keeps the terms consistent. It rewrites the pun. It changes the register where the style guide tells it to. It flags the sentence it is not sure about instead of guessing.
The glossary and the style guide are the work. They take a day with you and a native speaker, and they are the reason the hundredth page sounds like the first. Without them a model is only a more fluent version of the same problem.
The part people skip: review
I will not ship a translated page nobody who speaks the language has read. The model drafts, a native reviewer reads, and the review takes a fraction of the time a translation would, because the draft is already in the right voice. The reviewer’s corrections go back into the glossary and the examples, so the next draft needs fewer. After the first few dozen pages the review is a skim.
That reviewer can be on your staff, in your distributor’s office, or a freelancer I bring. What matters is that they exist and that their corrections are kept.
What it costs
| Approach | Rough cost for a 200-page site, about 100,000 words | What you get |
|---|---|---|
| Translation agency | $10,000 to $30,000 per language at $0.10 to $0.30 a word, then the same again for every rewrite | Accurate, human, slow, and out of date the day you edit a page |
| Machine translation plugin | A plugin licence and a few dollars of API fees (Google charges $20 per million characters; DeepL’s entry plan is around $33 a month) | Every page, instantly, in nobody’s voice |
| Model with glossary, voice guide and review | A day to build the guide, model fees in the tens of dollars, and a reviewer’s hours | Every page, in your voice, kept in sync, with a person’s name on it |
Prices are list prices from October 2026. The model’s share of the cost is close to nothing. The reviewer and the glossary are what you are paying for, and they are the only part worth paying for.
Where it fits, and where it does not
This is mostly stack agnostic, with one condition: the platform has to treat languages as a real thing instead of a plugin bolted on afterwards. What I need from the platform is a way to store a translated version of every field (title, body, buttons, image alt text, meta description, the slug), a language switch that sends the visitor to the right version, correct hreflang tags so search engines know which page is which, and a way for code to read and write all of it.
| Platform | How it goes |
|---|---|
| WordPress with WPML or Polylang | Good. Every field is translatable, the API exposes it, and I have built multilingual sites this way for industrial clients. The plugins are heavy and need a developer who knows them |
| Shopify | Good for stores. Markets and the translation API cover products, collections, theme strings and metafields. Checkout and emails included |
| Astro, Next.js, any custom build | Best. Languages are a folder and a routing rule, and the content pipeline is whatever I say it is |
| Headless CMS (Sanity, Contentful, Storyblok, Payload) | Good. Locales are first class and the API is the point |
| WooCommerce | Good, through WPML’s WooCommerce layer. Watch the product count; large catalogs need the sync scheduled |
| Squarespace, Wix, most page builders | Poor. Either a duplicate site per language you maintain by hand, or a widget that machine-translates on the fly. I would not do this work on these |
If you are on something in the last row, the honest answer is a move first.
How the sync works
The reason agency translations rot is that nobody re-translates a page after the English changes. So the sync is the product. When a source page is edited, the job sees the change, drafts the translation of the changed parts with the glossary and the examples, puts it in the review queue, and publishes when the reviewer approves. Nothing goes live untouched by a person, and nothing stays stale, because the queue tells you what is waiting.
Search is the other thing to get right. The keywords people use in Mexico are not the English keywords translated; they are different words. The glossary carries the target-market keywords for each page so the model writes toward them, and hreflang keeps Google from treating your Spanish page as a duplicate of your English one.
Where to be careful
Legal pages, medical and safety claims, regulated product labelling, and anything a lawyer wrote in English get a professional human translation and a lawyer in the target country. The model drafts, but it does not get the last word there, and I say so up front. Everything else, which is most of a website, is where this approach pays.
If you sell in a second language and the site reads like a manual, that is a few weeks of work to fix properly, and it stays fixed.