Back to blog
Published

Patent Translation: What Makes It Different and Why Errors Are Expensive

Patent translation needs legal technical accuracy, not fluency. What changes in the claims, how terminology gets locked, and what a bad rendering costs.

Patent Translation: What Makes It Different and Why Errors Are Expensive

Patent translation is one of the few jobs where one mistranslated conjunction can cost a client the monopoly they spent years and a lot of money obtaining. We work with agencies and freelancers across many document types, and patents are where strong technical translators produce the most dangerous output. The reason is counterintuitive. The habits that make someone excellent at manuals and product specifications work against them here. A patent is a legal instrument that happens to be written in technical language, and it is the legal half that catches people out. Below is what actually changes, and what the mistakes cost when they slip through.

What makes patent translation different from other technical work

In a technical manual, your job includes making the source better. Source sentences are often badly built, and a good translator quietly repairs them: splits the run-on, resolves the dangling reference, picks the clearer of two possible readings. Clients thank you for it.

In a patent, that same instinct is a liability. If the source claim is ambiguous, the ambiguity is part of what was filed. Resolving it in the target language either narrows the protection or broadens it into territory the original never covered, and neither outcome belongs to the translator. Our rule of thumb when we brief translators on patent work: you are allowed to be unreadable, you are not allowed to be different.

The second difference is who reads the file. A manual is read by someone who wants it to work. A patent is read by a patent examiner looking for reasons to refuse, and later by a competitor's attorney reading specifically for a way around the claims. That reader is hostile by design and paid to find the gap between what the inventor meant and what the translated words permit. Almost no other document type has an adversarial reader built into its lifecycle.

Third, the document has an afterlife measured in decades. A patent filed this year can be litigated in 2040, and the translation is what gets litigated. Legal translation in general carries this weight, and the same care that goes into maintaining accuracy when the stakes are high applies here, with one addition: in several jurisdictions, the national-language translation becomes the version that decides scope when it protects less than the original. Under the European Patent Convention, national law can treat the translation as authentic where it confers narrower protection than the language of the proceedings. Your mistake does not get corrected by the original. It replaces it.

The claims are the legal instrument, and they behave differently

Description and claims are not the same kind of text and should not be quoted at the same rate. The description is technical prose. The claims are a numbered set of definitions with formal syntax, and everything that matters legally lives there. Article 69 of the EPC says the extent of protection is determined by the claims, with the description and drawings used for interpretation. That single sentence explains most of what follows.

Transitional phrases decide how wide the claim is

Claim 1 typically has a preamble, a transitional phrase, and a body. The transitional phrase is where the money is. "Comprising" is open: a device with the listed parts plus three more still infringes. "Consisting of" is closed: add a fourth component and you are outside the claim. German "umfassend" and "bestehend aus" map onto that distinction, and so do the equivalents in Japanese, Chinese and Korean claim drafting. A translator who treats these as stylistic variants of "including" has quietly rewritten the scope of the patent.

Antecedent basis and article use

In claim language, "a heating element" introduces an element and "the heating element" refers back to it. If a translation introduces "said heating element" in claim 4 without an earlier "a heating element", an examiner can object that the term has no antecedent basis. This one bites hardest when translating from languages without articles, where the translator has to decide, element by element, whether this mention is the first one. It is bookkeeping, not linguistics, and it cannot be done by feel.

Other claim mechanics that travel badly: dependency chains ("according to claim 3" must still point at claim 3 after any renumbering), reference numerals in parentheses, the two-part characterising form that Rule 43(1) EPC expects for European applications, and the single-sentence claim requirement in several jurisdictions. Japanese claims in particular arrive as one long sentence with heavy use of 前記 for back-reference. Splitting that into three readable English sentences feels like an improvement and is a structural change to a legal definition.

Where a patent translation error turns into real money

Two cases from our own work show how this plays out.

The first was a German to English application in mechanical engineering, heading into a US national-phase filing. The source used "umfassend" in claim 1 and "bestehend aus" in claim 8. The translator, working sentence by sentence without a claim map, rendered both as "consisting of". Claim 1 went from open to closed. The catch happened during the client's attorney review, three days before the deadline, and cost a rushed re-check of the full claim set plus attorney hours. Had it gone through, the client would have owned a patent that a competitor could work around by adding one non-essential part. Nothing in the file would have looked wrong.

The second was Japanese to English, a chemistry application where a single source term for a carrier substrate was rendered as "support member" in claims 1 to 6 and "carrier element" in claim 7 and in four paragraphs of the description. Each rendering was defensible on its own. Together they invited the examiner's question of whether these were two different elements, which produced an office action, a response, and an amendment cycle. The response cost the client several times what the translation had.

Neither of these is a language failure. Both are process failures, and both are the kind of thing a reviewer finds in ten minutes if they are looking for it and never finds if they are reading for fluency. There is also a harder constraint behind them: Article 123(2) EPC prohibits amendments that extend beyond the content of the application as filed, so a translation that lost something cannot always be repaired later by putting it back. The window for fixing this is before filing, not after.

Legal technical accuracy means terminology is locked, not chosen

For most technical translation, terminology work means picking the best term and using it consistently within the document. For patents, the document is the wrong unit. The unit is the patent family.

A family can include the priority application, a PCT application, national-phase entries in several countries, divisionals and continuations, plus office-action correspondence, all filed over years and often translated by different people. Terms have to match across all of it. If an earlier granted patent in the family uses "carrier element" and the new divisional uses "support member" for the same thing, someone will eventually argue that the applicant meant two different things, and the applicant's own file history becomes the evidence.

So the glossary for patent work does not start from the source document. It starts from what already exists: the client's previously granted patents in that family, the terms used in the prosecution correspondence, and the standard designations for the technical field. WIPO Pearl is a genuinely useful check for field-standard multilingual terms, and the client's own granted patents in the target jurisdiction outrank it whenever the two disagree. Our usual sequence is family documents first, then WIPO Pearl or an equivalent reference, then the translator's judgment, in that order of authority.

This is also where hedges earn their protection. "About 5 mm", "substantially planar", "approximately equal" are not vague writing. They are deliberate scope-widening devices drafted by an attorney, and dropping them to make a sentence cleaner is a substantive edit. The same goes for apparent redundancy: patent drafters repeat elements on purpose so that claims stand alone. The general principle behind terminology consistency holds for any domain, but patents are where inconsistency stops being a style problem and starts being evidence.

Where machine translation helps with patent document translation, and where it does not

Machine translation is genuinely good at patents, for one specific purpose. Prior-art search and freedom-to-operate screening involve reading large volumes of foreign-language patents to decide which handful actually matter. WIPO Translate and the EPO's Patent Translate were built for exactly this, trained on patent corpora, and they are good enough that paying for human translation at the screening stage is hard to justify. Read fifty machine-translated abstracts, pick the three that are relevant, then have those translated properly.

The picture changes for anything being filed. In our experience the description post-edits well: it is technical prose, the terminology is checkable, and MTPE on a description with a locked glossary produces solid results at a reasonable rate. The claims are a different matter. The failures we see repeatedly in raw MT output are transitional phrases flattened to a generic "including", hedging words silently dropped, reference numerals lost or renumbered, back-references resolved inconsistently across claims, and long Japanese claims restructured into several sentences.

The practical split we recommend: MTPE for the description, human drafting for the claims, and a patent specialist in the target jurisdiction reading the claims regardless of how they were produced. This works best when the language pair is well served by patent-trained engines and the field has settled terminology. It works poorly for emerging fields where terms are still in flux, and it does not apply at all in jurisdictions where the applicant must certify the translation, because certification means someone is putting their name to every line.

One more thing worth being honest about: a QA report, whether generated by a tool or produced by a reviewer, catches consistency problems and mechanical errors. It does not catch a claim that is grammatically perfect and legally narrower than the original. That check requires someone who reads claims for a living.

What to settle with the client before you accept the job

Patent work goes wrong at the briefing stage more often than at the translation stage, and the questions that prevent it are short.

Ask what the file is for. A translation for internal review, a translation for a national-phase filing, and a translation supporting litigation are three different jobs with three different rates. A filing translation carries formal requirements and sometimes a certification. An information copy for the inventor does not, and charging filing rates for it loses you the client. We have seen agencies quote one rate for all three and lose money on the filings while pricing themselves out of the reading copies.

Ask for the family. If the client can send the priority document, any earlier granted patents covering the same technology in the target jurisdiction, and the prosecution correspondence, you inherit a terminology authority that took years to build. If they cannot, say so in writing before you start, because you are then making terminology decisions that their earlier filings may contradict.

Ask who reviews the claims and when. The answer determines whether the ambiguity list you produce is useful or arrives after the deadline. If the answer is that nobody reviews them, that is a risk to raise, politely and once, in the email where you accept the work.

Ask about the deadline behind the deadline. National-phase entry runs on a fixed 30 or 31 month clock from the priority date, and the date the client gives you is usually the attorney's internal date with some buffer. Knowing how much buffer exists tells you whether a query on day two is welcome or whether it will be treated as a delay.

A translation brief covers most of this on ordinary jobs; the difference here is that the answers change the price and the process, not just the tone.

A pre-delivery checklist for patent files

Run this before the file leaves your hands. It takes well under an hour on a typical application and catches most of what costs money later.

  1. Build a claim map: a table with one row per claim, listing the claim number, its dependency, its transitional phrase, and the elements it introduces. Verify each transitional phrase against the source individually rather than trusting a find-and-replace.
  2. Check antecedent basis element by element. Every definite reference in the claims should have an introduction earlier in the same claim chain.
  3. Verify every reference numeral appears in the translation exactly as in the source, in the same positions.
  4. Confirm dependency references survived renumbering.
  5. Compare your term list against the client's earlier granted patents in the same family before you compare it against any external reference.
  6. Search the target text for places where a hedge was dropped: check each "about", "substantially", "approximately", "generally" and "at least" in the source has a counterpart.
  7. Flag, do not fix, anything ambiguous in the source, and send the list to the attorney with the delivery.

That last point is the one we would push hardest. The most useful thing a translator delivers on a patent job is not a clean file but a clean file plus a short list of the places where the source could be read two ways. Attorneys act on that list. They cannot act on a decision you made silently on their behalf.

Newsletter

Get the next article without checking back.

We send occasional product notes and workflow essays when there is something worth reading.

Need the product walkthrough instead? Read the docs.

We care about your data. Read our privacy policy.