Back to Blog
IP & patentDocuments & translation

Patent translation where every term has to stay the same term

General translation tools optimise for fluency. Patent work needs the opposite: the same term rendered identically every time, across the whole family.

Why fluent translation fails patent work

General-purpose translation is optimised for reading. It varies word choice to avoid repetition, resolves ambiguity toward the most natural reading, and smooths syntax that would be awkward in the target language. Every one of those behaviours is a defect in patent translation.

A claim is a legal boundary written as a sentence. Its scope depends on the words used, the consistency with which they are used, and their relationship to the terms in the specification that support them. If the same component is rendered as one term in the claims and a synonym in the description, the support relationship between them weakens. If a deliberately broad term is translated to a narrower one because the narrower one reads better, the claim is narrower. If hedging language is smoothed away, the disclosure has changed.

Ambiguity in a patent is frequently intentional. The drafter chose a general term to cover embodiments not yet described. A translator resolving that ambiguity toward a specific reading is making a claim-scope decision without knowing it, and doing so silently.

This is why translation quality in patent work is not measured by fluency. The relevant measures are terminological consistency, structural fidelity to the source, and traceability — whether a reviewer can see which source text produced which target text. A translation that reads slightly stiffly but preserves all three is the better one.

Term-level control and glossary enforcement

What makes machine translation usable in this context is constraint rather than capability. A term base — the approved rendering of each technical term, defined term and component name — is supplied to the system, and the system is required to use it rather than choose.

Three properties separate enforcement from suggestion. First, the glossary binds: an entry applies every time the term occurs, and is not a preference the model may override for readability. Second, coverage is reported: the output tells you which terms were matched, which occurrences were rendered inconsistently, and which technical terms appear in the source with no glossary entry at all. That last list is the most useful product of the process, because it is the set of decisions someone still has to make. Third, deviations are visible rather than silent, so review becomes a check against a short list instead of a full read.

Building the term base is the real work, and it is the part that carries over between matters. It usually starts from the client's existing filings, granted claims in both languages, and the terminology an examiner has already accepted — terms that have survived prosecution are worth more than dictionary-correct alternatives. Tools such as LexLingua exist to apply and maintain that vocabulary. Deciding what belongs in it is attorney and agent work.

Keeping consistency across a patent family

A patent family is one disclosure filed in several jurisdictions over several years, usually through different local firms, sometimes translated by different vendors under different deadlines. Consistency across it is a records problem before it is a language problem.

It matters in specific ways. Divisional and continuation applications draw claims from a specification that was translated once; translate the divisional afresh and the two texts drift, making the support relationship harder to argue. Priority documents get compared against later filings for added matter, and an inconsistent rendering can look like new subject matter when it is only a different word. In litigation or opposition, an opponent reading two family members side by side will read a terminology difference as substantive, whether or not anything substantive was intended.

The workable discipline is to treat the term base as a per-family asset with a version history, updated only when prosecution forces a change, and applied so that later filings follow the earlier accepted term rather than the reverse. Where a term must change — an examiner objection, a claim amendment — record why. Translation memory helps for the same reason: reusing the exact prior sentence is worth more than retranslating it well.

What still needs an agent to sign off

The parts of patent translation that automate well are the parts where consistency is the requirement. The parts that do not are the parts where the translation is itself a legal decision.

Claim scope comes first. Choosing between two renderings that are both defensible but cover different ground is a prosecution decision, made with knowledge of the prior art, the client's commercial position, and how similar language has been treated in that office. No tool has that context, and a tool that presents the choice as a translation preference is hiding a decision that should be made deliberately.

Second, local formal and drafting requirements. Offices differ in claim format, in what may be referenced, in how multiple dependencies are treated, and in the conventions examiners expect. Some of that is checkable mechanically; the judgement about how to satisfy an objection is not.

Third, anything responsive to prosecution. Amendments, arguments and responses are drafted against a specific objection and a specific file history.

The realistic division is that machine translation with enforced terminology produces a consistent, traceable draft plus a list of the decisions it could not make. The agent's time then goes to those decisions and to the claims, rather than to retyping the specification. That is a real change in where expert attention is spent, and it does not require the tool to be right about anything it was never in a position to know.