TRANSLATION AT SCALE

Translating a marketing site is a afternoon project. Translating ninety-one thousand pages is a pipeline engineering problem. Deluxe Astrology runs across thirty languages. This site ships eight locales on top of English. The constraint is not translation quality in isolation, it is quality per dollar per hour with hreflang integrity and a human review gate that does not become a full-time job.

DeepL wins on European and major Asian language pairs at volume. The API is predictable: send JSON segments, receive translated segments, bill by character count. Latency is low enough to run parallel workers across hundreds of pages per hour. For product listings, directory templates, and structured UI strings, DeepL is my default first pass.

Where DeepL struggles: marketing idioms, SEO headline compression, and languages outside its strongest pairs. It will translate "best WordPress hosting" literally when the locale expects a different head-term shape. That is fixable in post-processing, but it is work.

Claude Haiku is the cost-efficient model for the humanization pass. After DeepL (or straight from English on thin pages), Haiku rewrites batches of fifty to one hundred segments with a style brief: keep meaning, localise idiom, preserve named entities, never invent facts, stay under the character limits for titles and metas. Haiku is fast enough and cheap enough to run on every row before publish.

Compared to GPT-4o-mini on the same task, Haiku tends to respect structural constraints (do not exceed 60 characters on this title) more reliably when the prompt includes worked examples. For high-stakes pages, pillar guides and service pages, I still spot-check with a human fluent reader or escalate to Sonnet for a second pass.

Extract translatable segments from Supabase (or the CMS export) with stable keys. Machine-translate via DeepL API with glossary terms pinned (brand names, product names, legal phrases). Run Haiku humanization with locale-specific briefs stored in repo, not inlined in one mega-prompt. Lint: banned phrases, em-dash density, meta length, hreflang pair completeness. Write to a translations cache table. Build static pages from cache so runtime never hits the translation API.

Build-time SEO lint fails the deploy if a locale page is missing reciprocal hreflang or if meta descriptions exceed 155 characters. Translation quality gates belong in CI, not in a spreadsheet review three weeks later.

Below roughly five hundred URLs and without a custom stack, Weglot or Lokalise is often cheaper than engineering a pipeline. The crossover point is where you already run Astro or Next.js with a Supabase or Postgres content layer and you need programmatic control over what gets translated per locale. That is where DeepL + Haiku + a cache table wins on cost and SEO control.

Related: [multilingual SEO service](/multilingual-seo/), [Weglot vs GTranslate vs custom engine](/blog/weglot-vs-gtranslate-vs-custom-engine/), and the [SEO guides hub](/guides/topic/seo/).