Last quarter, our agency took on a client most freelancers would politely decline. A boutique software firm asked us to ship a multilingual rebrand of their corporate site in three weeks. That alone was manageable. The complication was the 35-page reseller agreement they wanted localized into Spanish, German, and Japanese, hosted as downloadable PDFs on the new WordPress build, with the sign-off from their legal team due before launch.

Translating marketing copy is one thing. Translating a contract is something else entirely. One mistranslated indemnity clause in the Japanese version and the entire site relaunch becomes a liability. We were the agency on the hook.

This is the workflow we ended up with, the mistakes we made on the way to it, and why we stopped trusting any single AI engine to make calls on documents like this one. If you build WordPress sites for SMB clients who do business across borders, you are going to run into this problem sooner than you think. The ThemeREX blog has covered the practical side of multilingual WordPress builds, so this is a complement: what to actually do with the source documents before they reach the site.

Why We Stopped Using a Single AI Engine

For about eighteen months we had a perfectly reasonable workflow. Drop the source file into one of the major AI translators, review the output, paste it into the WordPress translation plugin. It was fast and it usually worked.

What broke us was a smaller job earlier in the year. A short German service agreement, maybe twelve pages. The single-engine output looked clean. Our reviewer flagged exactly one phrase as suspicious. We checked it. The engine had translated a binding obligation as a non-binding intent. It was the kind of error you only catch if a native legal speaker happens to read the exact paragraph where it occurred. There was no flag, no warning, no confidence score. The translation was just confidently wrong.

That was the moment we accepted what research had been saying for a while: hallucinations and silent errors are structural to single-model AI translation, not a bug somebody is going to patch out. Stanford’s AI Index has documented the verification burden these tools push back onto reviewers, and the burden falls hardest on people who do not have specialist legal or medical fluency in the target language. Which is most of us.

So when the 35-page reseller agreement came in, we changed the approach.

What «AI Consensus» Actually Means in Practice

The shift was moving from a single-engine workflow to a consensus workflow. Instead of asking one AI model what a paragraph means, you ask many of them, and you only accept the rendering they agree on.

This is not theoretical. There is a working implementation of it in the AI translator at MachineTranslation.com, whose SMART system compares 22 AI models including ChatGPT, Claude, Gemini, DeepL, and Google in a single pass and selects the version the majority converges on. The mechanism is straightforward: if a single engine hallucinates a clause, the other 21 will not produce the same hallucination. The outlier loses. You get the consensus version.

According to the Lokalise 2025 Localization Trends Report, machine-assisted translation now powers about 70% of language workflows. That number is the case for using these tools. The 90% reduction in critical error risk that consensus produces, compared to a single model, is the case for not betting a client deliverable on one of them.

Step 1 — Preparing the Source Document

We did almost no preparation, and that was deliberate.

In the old workflow we would have spent half a day breaking the PDF into smaller chunks, pasting blocks into the translation engine, reassembling the output, and rebuilding the layout in Word. The contract had numbered clauses, defined terms in bold, two appendices with tables, and a signature block. Reformatting any of that by hand introduces its own errors.

The change in this step was confirming the document met the consensus tool’s upload requirements: under the file size limit (ours was 6.4MB, well under the 30MB ceiling), and in a supported format. PDF, DOCX, TXT, CSV, XLSX, and image formats all work. We uploaded the source PDF directly. No splitting, no manual extraction.

For agencies juggling client documents inside WordPress business workflows, this matters more than it sounds. Layout corruption is one of the most common reasons translated PDFs get rejected by clients before legal even reads them.

Step 2 — Running the Consensus Check

We selected Spanish, then German, then Japanese, in three sequential passes. The system processed all 22 models for each language pair simultaneously. The interface returns one selected translation per sentence, the version with majority agreement, with the dissenting renderings available to inspect if we wanted to.

What we did with that affordance is the part most teams underuse, and it is the next step.

Step 3 — Reading the Disagreement Signal

This is where the workflow stopped being a translation tool and started being a quality-assurance tool.

For most sentences in the contract, the 22 models converged tightly. Boilerplate clauses, standard definitions, dates, party names. The consensus was unanimous or near-unanimous and we moved on without inspecting them.

For a smaller subset of sentences, the models disagreed. In Spanish there were 14 such sentences. In German there were 22. In Japanese there were 47.

That disagreement was the signal. Every sentence flagged with model disagreement was a sentence we read manually. In one Japanese clause, eight models had rendered a «best efforts» obligation as a stricter «guaranteed performance» commitment. The consensus correctly picked the looser rendering, but the spread told us this was a sentence the legal team needed to eyeball. We surfaced it for them with a one-line note.

This is the practical use of consensus. It is not just a way of getting a better translation on average. It is a triage system. The model disagreement tells you where the document is risky, and where it is not, before any human reviewer has to read a single line. According to the AI translator MachineTranslation.com’s internal study on the SMART feature, users who used the consensus signal spent 24% less time fixing errors than those who picked outputs manually. Our reviewer’s hours backed that up.

Step 4 — Layout Preservation and Final Delivery

The translated PDFs came back with the original layout intact. Clause numbering, table structures in the appendices, bold defined terms, the signature block. Nothing required reformatting. We dropped the three localized PDFs into the WordPress media library, linked them from the multilingual reseller page, and the build went live on schedule.

The legal team’s review took two days instead of the five we had budgeted. They flagged three sentences across the three languages, all of which we had already pre-flagged from the disagreement signal. They were minor stylistic preferences, not errors.

For a high-stakes file, the consensus also offers a Human Verification step where a professional reviewer signs off on the translation inside the same platform. We did not use it for this job because the client had their own legal counsel doing final review. For projects where the agency is the last line of defense, that escalation is the safety net that turns a 90% error reduction into a guaranteed result.

What We Learned, and What We’d Do Differently

A few things changed permanently in our process after this project.

The disagreement signal is the underused half of consensus translation. Most teams treat the output as the deliverable and stop there. The richer information is in the spread between models, because it tells you which sentences to slow down on and which to accept. We now log the disagreement count per document as a routine quality metric.

We also stopped translating client legal and compliance documents in fragments. The single-engine habit of breaking a PDF into pieces was a workflow built around the limits of an old tool. Modern document-handling capacity makes that step obsolete and risky.

And we changed the conversation we have with clients. Instead of telling them their translation is «AI-powered,» which means almost nothing in 2026, we tell them how many models had to agree before any output was returned, and how many sentences were escalated. That is a number a non-technical client can understand and trust.

If you run WordPress builds for clients who operate in more than one language, the question worth asking is whether your translation step is contributing risk to the project or removing it. For us, the move from one model to twenty-two changed the answer. The site-building resources from the ThemeREX team cover the WordPress side of that equation. The translation side now finally has a credible answer too.