AI Translation and Content Localization - Running Multilingual Content Without a Translation Agency

The human evaluation results from the WMT25 competition (Workshop on Machine Translation), published in late 2025 following earlier automatic-metric results from August, showed something that would have sounded exaggerated a few years back: on most of the 30 evaluated language pairs, general-purpose models - Gemini 2.5 Pro, Claude 4 and the top commercial engines - beat classic machine translation in human linguists' judgment. That doesn't mean DeepL has lost its reason to exist, though: in independent blind tests on European language pairs it still wins most comparisons against general-purpose models, while for Asian languages (Chinese, Japanese, Korean) and Arabic the LLM advantage is clear. The real question isn't "which engine translates better", it's "which engine for which job" - and that's what this post is about.

The human evaluation from the WMT25 competition showed that Gemini 2.5 Pro, Claude 4 and the top commercial engines beat classic machine translation on most of the 30 evaluated language pairs - yet DeepL still wins most blind tests on European language pairs. The real question isn't "which engine translates better", it's "which engine for which job". I cover when to reach for an LLM versus DeepL, how not to lose brand terminology across languages, how localization differs from translation, what it costs per 1,000 words - and how I run this exact blog in Polish and English without a translation agency.

Running content in several languages without a translation agency is technically easier today than ever, but ease of generating text doesn't solve three real problems. Terminology drifts between publications unless someone systematically enforces it. Literal translation differs from localization, which accounts for currency, date format and local regulations. And cost and quality depend on whether you pick the tool for the content type, or the other way around. Here's how to build a process that keeps all of this under control - ending with how I run this exact blog in Polish and English.

Machine translation (NMT) or LLM - when to use which

DeepL is a neural machine translation (NMT) engine trained for exactly one task: translating text. That's the source of its edge - in European languages, where it has the deepest training data, it wins most comparisons against general-purpose models in independent blind tests. It's also cheap and fast, because you're paying for a narrowly defined operation, not a general-purpose language model. The trade-off is inflexibility: you can't instruct DeepL to "translate this in a casual tone, like talking to a friend" - you get one deterministic output.

An LLM (GPT-4o/5, Claude, Gemini) wins wherever more than sentence-level correctness matters. It holds the context of an entire document, so it won't lose the thread between paragraphs. You can steer it with a style prompt to preserve brand voice. And it wins decisively for non-European languages - for Chinese, Japanese, Korean, Arabic and Hindi, independent tests consistently put LLMs ahead of classic MT. Benchmarks also reveal a split within the LLM category itself: Claude tends to handle nuance-heavy marketing copy best, GPT-4o/5 does well with technical documentation, and Gemini holds up best for consistency across very long context (translating dozens of files at once, for instance). Treat this as a shortlist signal, not a verdict - the differences depend on language pair, domain and evaluation method, so it's always worth validating on your own content sample.

A workflow that doesn't lose brand terminology

Telling a model in a prompt "use these terms" gets you probabilistic compliance, not deterministic accuracy - the model will follow it most of the time, but not every time, and at volume "most of the time" means dozens of inconsistencies. An LLM can sound perfectly fluent while drifting on product naming: it might translate a feature as one word in one batch and a different synonym in the next, breaking UI parity and confusing a user reading documentation in two languages at once.

The fix is structure, not another prompt. A glossary - a list of approved terms with their translations and a "do not translate" flag for product proper nouns - gets fed directly into the drafting step, and once a draft is produced, the output is automatically checked against that same list before it ever reaches a human. Translation memory (TM), in turn, is a database of previously translated segments: a segment identical to one already translated is reused rather than retranslated, and a similar segment (a fuzzy match) is billed at a percentage of the full rate - typically 40-75%, depending on the match level. A side effect worth its own section: this is also the single biggest cost lever in the whole process.

Localization is not translation

Translation changes the words. Localization adapts the whole experience - at levels that are easy to forget precisely because they're invisible until they fail. Currency isn't just a symbol swap: the conversion rate has to be current, and the notation itself (1,234.56 USD versus 1 234,56 zł) differs by market. Date format is the classic trap - 03/04/2026 in the US and 04.03.2026 in Poland are two different dates written with the same digits. Units of measurement (metric versus imperial), the decimal separator (comma versus period), and legal requirements (VAT in the EU, sales tax in the US, different cookie-consent patterns) form another layer that no translation engine resolves on its own - because it's not a language problem, it's a product and legal one.

Our own PL/EN pipeline - a case study from this blog

This blog is exactly that case: every post exists in Polish and English, with no translation agency involved. A few rules that matter most for the final quality in practice. First, content in each language is written natively rather than translated sentence by sentence - in the AI/SEO niche, terms like "AI visibility" or "zero-click" don't have one natural equivalent in the other language, so a literal rendering reads as stiff, while rewriting from scratch reads as native. Second, internal links are rewired per language - the English post links to the English slug of the target post, not to the Polish URL with a note that it's a translation. Third, meta title and meta description are written separately per language rather than translated, because search intent and keyword phrasing differ between PL and EN queries even for the same topic. Fourth, a fixed, automatically checked style rulebook applies - among other things, no em/en dashes in favor of a plain hyphen, and a list of banned, generic-sounding stock phrases in both languages - before a post goes live. The result: both language versions read as if written natively in that language from the start, at the cost of more editorial work than dropping text into DeepL and pasting the output back.

The traps vendors mention more quietly

• Fluent and wrong at once. A model can produce a grammatically perfect sentence with an inverted meaning (a dropped negation, for instance) - a native reviewer catches it in a second, a spell-checker never does.
• Forgotten legal pages. Privacy policies, terms of service and cookie banners often fall out of a localization project because they're treated as technical debt, not marketing content - and they're exactly the pages carrying the most legal exposure if something's wrong.
• No glossary means brand drift. Without an approved term list, an LLM will pick a different synonym for the same product feature in every batch, breaking interface consistency.
• Automation with no human in the loop on public pages. Fine for internal documentation. Risky for content that represents the brand externally without a review pass.
• Forgotten hreflang after adding a language. A new language version without correctly wired hreflang tags (covered separately in hreflang architecture) means a search engine may serve the wrong version to the wrong audience - all the translation effort never converts into visibility.

How to choose - four scenarios

1. 1.High volume, European languages, tight budget → DeepL plus your own translation memory.
2. 2.Marketing content, tone matters, non-European languages → an LLM with a style prompt and a glossary wired into the pipeline, not just the instructions.
3. 3.Legal and regulated content → human translator only; the machine at most produces a first draft for review, never the final version.
4. 4.You publish regularly in the same niche → build a glossary and translation memory from day one - the cost pays back by the second or third large batch through match discounts.

A step-by-step implementation plan

1. 1.Inventory your content by type (marketing, legal, UI, blog) and assign each type an engine from the table above.
2. 2.Build a glossary of 30-50 key brand and product terms before translating a single sentence.
3. 3.Pick a tool that supports glossaries and translation memory natively, not only through prompt text.
4. 4.Decide who does human review and on which content types it's mandatory versus optional.
5. 5.Plan localization separately from translation - map currency, date, units and legal requirements per market before you start translating.
6. 6.Measure cost and time on the first batch, then compare against the second - the drop from translation memory should already show on the second publication in the same domain.
7. 7.Wire multilingual content into a correct hreflang architecture, so the translation effort actually converts into search visibility in each market.

What translation and localization cost per 1,000 words

The range is wide because billing models differ. Raw translation APIs (DeepL, Google Cloud Translation, LLM-based engines) typically fall between single cents and a few dollars per 1,000 words, depending on provider and language direction - DeepL bills per character (roughly $5.49 per million characters), while LLM providers bill per token, which for typical English text lands in a comparable order of magnitude. A human translator prices differently: $0.05-0.15 per word, or $50-150 per 1,000 words - tens of times more than the machine alone, which is why the MTPE model (machine translation post-editing) is popular: the machine produces a first pass, and a human edits it for a lower rate than a full translation from scratch. A third factor, easy to miss in a spreadsheet: with regular publishing in the same subject domain, translation memory cuts the cost of repeat content by 30-70%, so the real cost per post drops with every month of work in the same topic - provided someone actually maintains that memory instead of starting from zero on every job.

---

I help build a translation and localization process that doesn't lose brand terminology across languages - from choosing the right engine, through glossary and translation memory, to wiring it into a correct hreflang architecture. I do this as part of AI automation and content marketing SEO. I teach it in the SEO & GEO course. Get in touch - I'll start with an audit of your current multilingual content and where the terminology has already drifted.

Worth reading next:

• Hreflang and International SEO
• AI in Content Marketing - How to Produce 10x More Content
• How to Write Content AI Cites
• Structured outputs from AI: Pydantic, Instructor and JSON Schema
• OpenAI API cost optimisation