Publishing in a language you cannot read is a bet you cannot check

Every safeguard assumes you can read the result

The working method that makes these tools safe is straightforward: generate, read critically, correct or discard. Each step after the first requires competence in the output. Remove that competence and what remains is generation followed by publication, which is the arrangement everyone agrees is unwise.

This is worth stating plainly because the output gives no signal of trouble. Text in a script you cannot read looks equally confident whether it is idiomatic or embarrassing, and the usual cues that something is off — an odd word, a sentence that does not track — are invisible to you by definition.

The gap is not about translation quality. It is about the absence of a reviewer. A capable translation with no reader is riskier than a mediocre one that someone competent looked over, because the second has a chance of being caught.

The failures are quiet and specific

The characteristic problems are not gibberish. They are a formality level that insults the reader, a word that is correct in one country and vulgar in another, a brand name that means something unfortunate locally, a date format that shifts a deadline by several months, and text that overflows a layout because the language is longer.

A related failure is inconsistency across a set. Ten pages translated in ten separate requests will use different terms for the same product feature, address the reader with different levels of formality, and vary in how headings are phrased. Each page passes on its own and the collection reads as unmaintained.

None of these are detectable without reading. That is the whole point: the errors that survive are exactly the ones that require competence to see, which is why an internal review by people who also do not speak the language provides no assurance at all.

Reduce the exposure before you increase the confidence

If review is unavailable, the sensible move is to publish less rather than to prompt harder. A short, plain page saying what you offer and how to contact you carries far less risk than a full site of marketing copy, and it is also far cheaper to have checked properly later.

Keep numbers, dates, prices and contact details out of the translated flow where you can, presenting them in a table or a fixed block. These are the elements where an error does concrete damage, and isolating them lets you verify them without reading the surrounding prose.

Write the source text for translation as well. Short sentences, no idioms, no jokes, consistent terminology, no clever headline that depends on a double meaning. This costs you a little personality in the original and removes a large share of the ways a translation goes wrong.

Buy the review, not the translation

The economics are favourable and frequently misunderstood. Producing a first draft in another language is now nearly free, while checking one requires a person, so the money is far better spent on review than on production. A native speaker reading finished text works much faster than one writing from scratch.

A short brief for that reviewer makes their time go further: mark the parts that must be exact, name the audience, say what the text is for, and ask specifically whether the formality is right and whether anything reads as machine-produced. Those are questions they can answer quickly.

Where you have colleagues, customers or partners who speak the language, an informal read is worth asking for even though it is not a professional review. The question to ask is not whether the grammar is correct but whether it sounds like something a local organisation would have written.

Say plainly when this is the wrong instrument

For a contract, a warranty, a safety notice, a medical instruction or anything with a regulator behind it, unreviewed machine translation is not an acceptable input, and no prompting technique changes that. The requirement in those cases is usually a named person who can be held responsible for the wording.

A build-up of unreviewed content also compounds. Terminology set in the first ten pages propagates through everything that follows, so a mistake made early becomes expensive to unwind once a site, a product interface and a support archive all depend on it.

The reasonable position is neither refusal nor confidence. These tools have genuinely lowered the cost of operating in several languages at once, and they have not removed the need for one competent reader before publication. Treating that reader as optional is the mistake, and it is usually made for budget reasons that a single bad page would have covered.