Translate | Patent Applications, Patent Claims and Technical Drawings: Preserving Meaning Across Languages

Patent translation is a specialised service for international patent applications, patent claims, patent specifications and technical drawings. A reliable translation must preserve the invention as disclosed, maintain the structure of the claims, and keep defined terms, numerical limits and drawing references consistent. This guide is for applicants, inventors, patent professionals, translators and technical reviewers who need to understand what a careful patent translation process involves.

When a patent document moves between languages, a fluent sentence is not enough. The target text must retain the same technical teaching and the same logical relationships. A changed word can alter whether a feature is optional or required, whether two components are alternatives or used together, or whether a dependent claim incorporates the limitations of another claim. This is why patent translation requires document mapping, terminology control, bilingual review and a clear process for resolving questions.

The guide is educational, not legal advice and not a substitute for office-specific filing instructions. WIPO’s Patent Cooperation Treaty materials describe translation requirements that may cover the description, claims, drawing text and abstract, with the exact requirements depending on the procedural route and applicable office. Patent applicants should confirm current language, form, timing and correction requirements with the relevant patent professional before filing.

Who this guide is for and what it covers

Use this guide as a working framework for planning, translating, reviewing and delivering patent documents. It does not attempt to decide whether an invention is patentable, whether a claim is valid, or what scope an applicant should seek. Those are legal and technical decisions for qualified professionals. Its focus is the language and quality-control work that allows a translated package to represent the same source document accurately.

International applications can contain material created by several contributors: an inventor’s technical notes, a patent agent’s description, drawings from an engineering team, tables from a laboratory and amendments from counsel. These sources may not share a style or vocabulary. Before translation begins, determine which version is authoritative and which material is supporting background only. A background email should not silently override a signed or approved application document.

A high-quality workflow makes decisions visible. It records why a term was chosen, which source file was used, what questions were asked, who answered them and which reviewer approved the final wording. This level of control is useful even for a short application because the cost of a tiny ambiguity can be disproportionate to the number of words involved.

Why patent translation is a technical and legal discipline

Patent translation is not simply the replacement of words in one language with words in another. A patent application is a structured disclosure of an invention, and its parts perform different jobs. The description explains the technical teaching; the claims define the protection being requested; the abstract summarises the disclosure; and drawings, where present, help readers understand components, relationships and embodiments. A translation can sound fluent and still be unreliable if it changes how these parts relate to one another. A missing limitation in a claim, an altered measurement, or a reference numeral attached to the wrong component can create a serious discrepancy between the source and target documents.

The central task is controlled equivalence. The translator must communicate the same technical relationships and preserve the distinctions the drafter made, without adding a feature that was not disclosed or removing a qualification that limits an embodiment. This is different from marketing localisation, where adaptation may be desirable. A patent translation should not make an invention appear broader, narrower, more certain, more commercially attractive or more advanced than the source permits. It must allow a technically informed reader to reconstruct the same teaching and allow a patent professional to compare the translated wording with the source.

The intended filing route matters. Under the Patent Cooperation Treaty, translation requirements depend on the relevant stage, office, language and procedural circumstances. WIPO’s PCT materials explain that translations for national phase purposes can include the description, claims, text in drawings and abstract, and sometimes other elements specified by the applicable rules. This guide explains translation control rather than giving a universal filing checklist. Always verify the current requirements, accepted languages, deadlines, formalities and correction procedures of the receiving or designated office with the relevant patent professional.

Map the document before translating

Begin by identifying every component in the source package. A typical patent application may contain a request form, title, description, claims, abstract, drawings, sequence listing or other technical annexes. Not every case contains every component, and the exact filing set depends on the application and route. Record which file is authoritative, which version is being translated, whether amendments exist, and whether the documents are complete. A translation team should never assume that the newest-looking file is the one intended for filing.

Create a source inventory with file name, language, version date, page count, paragraph numbering, claim count, figure count, table count and any special text objects. Record whether the drawing labels are embedded in vector artwork, supplied separately, or reproduced in a text list. Note whether the abstract or drawing captions are in a different language from the description and claims. These small checks prevent a common failure: translating the main document carefully while overlooking a sentence inside a diagram or an attachment supplied in a separate folder.

A useful control is a document manifest. It can state: Source description, version 3, paragraphs 0001 to 0128; claims 1 to 18; abstract, one page; drawings 1 to 7; legend file, version 2; sequence listing, XML file, unchanged. The manifest is not a substitute for reading the files. It is a map that lets the translator, reviewer and filing professional see what should exist and what has been processed. If a referenced drawing, claim or paragraph is missing, stop and request clarification instead of silently filling the gap.

Understand the difference between description and claims

The description provides the technical explanation. It may introduce the field, describe background problems, identify an objective, explain embodiments, discuss alternatives and give examples. It can include broad statements followed by detailed implementations. The translator must preserve the relationship between general teaching and particular examples. A phrase such as ‘in some embodiments’ is not decorative. It signals that the feature is not necessarily present in every embodiment. Removing it can turn an optional arrangement into an apparently universal requirement.

Claims are different because every word may contribute to the boundary being asserted. A claim often contains a subject matter category, a sequence of elements, functional relationships and one or more limitations. Dependent claims incorporate the limitations of an earlier claim and add further features. The translation must preserve that dependency. If claim 7 depends on claim 3, translating it as though it were independent changes its structure. If the source says ‘comprising’, replacing it with a term that means ‘consisting only of’ can materially alter openness of the claim.

Do not make claims more elegant by removing repetition or rearranging limitations. Repetition can be deliberate, especially when a claim uses a defined antecedent or repeats a component name to maintain clarity. A reviewer should compare each claim as a structured unit: identify the claimed subject, each element, every connector, every modifier, each dependency and the final punctuation. A claim chart with one row per claim and one column per limitation helps reveal omissions that ordinary proofreading may miss.

Preserve claim grammar and logical relationships

Patent claims often use long noun phrases and nested clauses. The target language may require a different word order, but the translation must retain the same logical relationships. A component may be configured to receive another component, connected to a surface, located between two parts or responsive to a signal. Those relationships are not interchangeable. A translator should identify the technical relation first, then choose the natural target-language construction that preserves it.

Pay special attention to conjunctions and alternatives. And, or, at least one of, one or more, each, either and both can affect the claim’s coverage. Some languages express inclusive and exclusive alternatives differently or require the translator to make an implied relationship explicit. Do not guess. Create a question for the patent attorney or inventor when the source is ambiguous. A translator is responsible for linguistic fidelity, not for deciding what scope the applicant ought to claim.

A disciplined method is to decompose the claim into a claim skeleton. For example: a device; comprising a housing; a sensor supported by the housing; a controller connected to the sensor; and the controller configured to perform a stated operation when a condition is detected. Translate each element and its relation, then rebuild the sentence in target-language grammar. The sentence may look different, but the list of elements and relationships should remain intact.

Build a terminology system before drafting

Patent documents reuse technical terms across claims, description, abstract and drawings. Create a terminology list before translating the full document. Include source term, preferred target term, grammatical form, definition from the source context, component or concept, prohibited alternatives, first occurrence, and approval status. Distinguish a true synonym from a term that merely resembles one. If the source uses shaft for a rotating component and axle for a stationary support, translating both with the same target word may erase a technical distinction.

Terms should be researched in context. Consult technical dictionaries, standards where applicable, prior documents from the same applicant, product manuals, scientific literature and specialist reviewers. Search results alone do not establish equivalence. A term used in a machine translation memory may come from an unrelated field. Record the evidence that supports the selected term, especially where a term has several meanings across mechanical, electrical, chemical or software contexts.

The terminology system must also distinguish defined terms from ordinary words. If the description states that the term carrier refers to a particular item, the translation should preserve the definition and then apply the chosen equivalent consistently. Do not replace the term midway because another synonym sounds smoother. If the source itself uses two terms inconsistently, flag the inconsistency and ask whether it is intentional. Consistency does not mean concealing a source defect; it means making every decision traceable.

Translate defined terms and antecedent references

Antecedent basis is the relationship between an element introduced earlier and later references to that element. A claim might introduce a sensor and later refer to the sensor. The translation must preserve the introduction-and-reference relationship in a way that is grammatical and meaningful in the target language. Some languages do not use articles in the same way as English, but the concept still needs to remain clear: the later reference should point to the previously introduced element, not to a new or unspecified one.

Defined terms can be especially difficult where the target language has a more familiar everyday word that appears close in meaning. A source may define module broadly, or give a term a specialised meaning for the document. The translator should follow the definition, not the dictionary’s most common entry. The definition should be translated accurately at its first occurrence and cross-checked wherever the term appears later, including captions, table headings and figure descriptions.

A useful review exercise is to extract every defined term and all of its occurrences. Then inspect whether the translation uses one approved equivalent, whether plural forms remain recognisable, whether abbreviations remain linked to their full forms, and whether cross-references still resolve. If the target language requires different grammatical forms, document the variants so that the reviewer can distinguish legitimate inflection from accidental terminology drift.

Keep numbers, units, ranges and conditions exact

Numbers are part of the technical disclosure. Check dimensions, tolerances, temperatures, pressures, concentrations, angles, time periods, frequencies, ratios and quantities character by character. Do not convert units unless the filing instructions or client expressly require conversion and the conversion is approved. If conversion is permitted, preserve the original value where needed, state the converted value using the agreed convention, and check rounding rules. An apparently harmless rounding decision can change the described embodiment or make a threshold unclear.

Ranges need particular care. From 5 to 10, greater than 5, at least 5, up to 10, less than 10 and about 5 to about 10 are different expressions. Preserve inclusivity, exclusivity, approximation and endpoints. The same applies to negative values, plus-or-minus tolerances, significant figures and decimal separators. A target-language convention may use a comma where the source uses a point, so the localisation must not create ambiguity in a filing context.

Build a separate numerical QA pass. Extract every numeral and unit from the source and target, compare the lists, and inspect differences manually. The comparison should include paragraph numbers, figure numbers, claim numbers, chemical formulae, dates, reference numerals, sequence identifiers and table values. Automated comparison can identify mismatches, but only a human can decide whether a changed format is valid. Have a second reviewer inspect all critical numerical expressions independently.

Translate embodiments without turning examples into requirements

Descriptions commonly use phrases such as for example, in one embodiment, optionally, may include, preferably and in certain implementations. These phrases indicate the status of a feature. If the source says a device may include a second sensor, the translation must not imply that every device must include one. If the source says a component is preferably made from a material, do not translate the preference as a mandatory requirement.

The reverse problem occurs when a translator weakens a definite statement. If the source says that a component is connected to another, the translation should not imply that it merely could be connected. Preserve the degree of commitment and the level of generality. In technical writing, modal verbs and qualifiers often carry the difference between a disclosed possibility, a preferred feature and a required relationship.

A practical technique is to mark every modal or qualifying expression during analysis. Create a source-to-target table for may, can, must, shall, is configured to, preferably, optionally, substantially, approximately and similar expressions. The target language may not have one-to-one equivalents. Choose a phrase that performs the same function and record the reasoning where the wording is high impact.

Handle drawings, labels and reference numerals

Drawings are not merely illustrations placed beside the text. They may contain reference numerals, callouts, words, symbols, arrows, section indicators, legends and abbreviations. The text of the drawing may need translation separately from the figure itself. First identify which elements are text and which are language-neutral graphical features. Do not alter a numeral, arrow direction, line type or component position while editing a label.

A drawing register should list figure number, label number, source wording, approved target wording, location, text-box dimensions, font constraints, file format and review status. If a target-language label is longer, do not shrink it until it is unreadable or move it so that it points to a different part. Ask whether the drawing can be re-laid out, whether an external legend is permitted, or whether a concise approved label is available. A technical illustrator or patent professional should approve any layout change that could affect interpretation.

Check every drawing against the description. If reference numeral 24 identifies a valve in Figure 3, the same numeral should refer to that valve in the translated description and all other drawings. Do not renumber to make a sequence look neater. Where the source contains an apparent mismatch, preserve the source faithfully in the working copy and raise a query. Only the authorised applicant or professional should approve a correction to the underlying disclosure.

Abstracts, titles, captions and sequence listings

An abstract is a compact technical summary. It should preserve the central technical subject, key components and main operation without adding a sales claim. Because an abstract is short, every word is prominent. A translation should not insert an advantage that appears only in the description, exaggerate the claimed effect or omit a stated limitation. A title should be concise and technically recognisable, but should not be rewritten into marketing language.

Captions and headings are navigation aids as well as technical labels. Keep terminology consistent with the body text. If a drawing caption identifies a cross-sectional view, do not translate it as a general side view. If a table heading states measured output at 25 degrees Celsius, preserve the condition. For sequence listings and structured technical data, follow the applicable format and filing instructions. Do not casually reformat machine-readable data or translate language-neutral identifiers.

Separate text from data that should remain unchanged. Gene and protein symbols, mathematical expressions, code fragments, identifiers and certain standardised labels may need to remain in their original form, depending on the governing rules and document purpose. Make a keep-as-is list with justification. The list should be reviewed by the subject expert because a string that looks like an identifier may actually be a natural-language label, and a natural-language phrase may be a formally controlled field.

Use machine translation and terminology tools cautiously

Computer-assisted translation can help manage repeated terms, align prior applications and identify inconsistent phrases. It cannot decide the legal or technical meaning of an ambiguous claim. Machine translation can be useful for a first orientation or for low-risk passages, but every suggested term must be checked against context and the approved glossary. Patent language is especially vulnerable to plausible-sounding substitutions that quietly change the scope or the mechanism.

Translation memory should be segmented carefully. A sentence extracted from an earlier application may have been amended, may use a different claim context, or may belong to a different invention. Reusing it without verification can import an old error. Keep the source segment, target segment, document identifier, date, reviewer and approval status. Mark unverified material clearly so it cannot be mistaken for a precedent.

Do not upload unpublished inventions or confidential application materials to a public translation service unless the applicant has authorised that processing and the provider’s contractual, security and data-retention arrangements have been assessed. Confidentiality obligations may arise from the client relationship, professional rules, employment terms or applicable law. Use approved environments, restrict access, avoid unnecessary copies and maintain a clear deletion or retention policy. Tool convenience is never a reason to expose an invention.

Quality assurance: review the whole filing package

A reliable patent translation requires more than a spellcheck. Use multiple review layers. The first is bilingual completeness: every source sentence, claim, caption, table and note is accounted for. The second is technical accuracy: components, processes, causal relationships and operating conditions are correct. The third is claim integrity: dependencies, limitations, conjunctions and antecedent references have been preserved. The fourth is language quality: grammar, readability and specialist terminology are natural in the target language.

A reviewer should work with the source and target side by side. For claims, use a limitation-by-limitation matrix. For the description, use paragraph alignment. For drawings, use a figure register and visual inspection. For numbers, use an extracted-value comparison. For defined terms, use a glossary concordance. Each tool answers a different question. A single global read-through is useful at the end, but it cannot replace these targeted controls.

Record all queries and answers. A query should identify the exact location, source wording, proposed interpretation, possible alternatives and the decision required. Avoid asking a broad question such as clarify this paragraph. Instead ask whether the second member refers to component 18 introduced in paragraph 42, or to a separate member shown in Figure 5. This makes the answer useful and prevents the translator from making an unapproved technical decision.

Common patent translation errors and how to prevent them

One frequent error is synonym variation. A translator uses three target words for one source component because the prose feels repetitive. The result may suggest three different components. Another is false synonymy: two source terms with distinct meanings are merged into one target term. A terminology list and concordance check prevent both. Review should focus on technical identity, not stylistic variation for its own sake.

A second error is changing the degree of obligation or possibility. May, can, must, is adapted to and is configured to may have different implications depending on language and context. A third error is altering numerical limits through conversion or formatting. A fourth is losing a drawing label or reference numeral. A fifth is changing a dependent claim so that it no longer incorporates the limitations of the claim on which it depends. Each error can survive ordinary proofreading because the final sentence may still sound fluent.

Prevent these errors with a risk-based checklist. Label claim text, numerical expressions, defined terms, drawing callouts, negative limitations, alternatives, ranges and amendments as high-risk. Require a second reviewer for these elements. Track unresolved questions and block finalisation while a high-impact query remains open. A translation should not be marked complete merely because the document is linguistically polished; completion also requires a documented decision on every material uncertainty.

Worked case study: a mechanical fastening invention

Imagine a source claim describing a fastening assembly with a base, a resilient member, a threaded element and a sensor that detects a load condition. The description says that the resilient member may be positioned between the base and the threaded element in one embodiment. A second embodiment uses a washer. The translator must preserve the fact that these are alternatives, not necessarily components used together. If the target text makes the washer mandatory in every version, it changes the disclosure.

The terminology analysis should distinguish resilient member, washer, threaded element and load sensor. The translator should not call the resilient member a washer unless the source definition or technical context supports that equivalence. The claim should be decomposed into elements and relationships. The description should then be checked to ensure that the embodiments and drawings use the same approved terms. Any unclear relationship between the sensor and the threaded element should be raised as a query.

A review matrix could record each claim limitation, the paragraph or figure supporting it, the target phrase, and the reviewer decision. A separate embodiment table could show whether the resilient member, washer or both appear in each variant. The drawing register would link reference numerals to the component names. This approach helps the patent professional compare the translated package against the source without relying on memory or stylistic intuition.

Worked case study: a software-implemented process

Consider an application describing a processor that receives image data, identifies a region, calculates a confidence score and selects an action when the score meets a threshold. A translator may be tempted to replace confidence score with probability because the terms often appear together in machine-learning contexts. That substitution is unsafe unless the source defines the score as a probability. A confidence score may be calibrated, uncalibrated, heuristic or otherwise defined.

The phrase when the score meets a threshold also requires care. Does meets include equality? Does the source say greater than, greater than or equal to, below, within or outside a range? The logical operator may be stated in prose, a formula or a flowchart. Translate the wording and inspect the formula together. If the figure uses a symbol that conflicts with the sentence, do not choose one silently; raise the inconsistency.

The same principles apply to software terminology. Distinguish data, information, input, output, parameter, variable, instruction, model and function where the source does. A common word can have a precise technical role in a claim. Keep code, identifiers and mathematical operators unchanged unless the filing instructions say otherwise. The objective is not to make the target text sound like a software advertisement. It is to preserve what the application actually discloses.

Managing amendments and version history

Patent applications can change during prosecution. Claims may be amended, paragraphs may be corrected, drawings may be replaced and translations may be prepared for different offices or stages. A translator should know whether the task concerns the originally filed text, an amended version, or a consolidated version. Mixing versions can produce a document in which the claims and description do not belong to the same procedural state.

Keep a version ledger. For each source file, record its date, version label, origin, checksum if used, and status. For an amendment, identify the precise changes and whether the client expects a clean text, a marked-up comparison or both. Preserve the distinction between source changes and translation corrections. A translation correction should not be used to conceal an amendment to the underlying application.

When a client sends a replacement file during translation, pause and assess what changed. Compare the new source with the working source, determine which passages are affected, and identify whether the change has procedural significance. Ask the patent professional whether prior translated segments remain valid. Update the glossary and claim matrix where necessary. A controlled version history prevents an old claim from being carried into a new filing package.

Confidentiality, independence and reviewer roles

Patent material can contain unpublished technical information with commercial value. Access should be limited to people who need it for the assignment. Use secure transfer, controlled storage, named reviewers and documented permissions. Do not include confidential claims or drawings in public examples, personal online accounts, general-purpose prompts or training materials unless expressly authorised. Remove client identifiers from internal learning examples and follow contractual retention rules.

Different reviewers answer different questions. A bilingual patent translator checks linguistic equivalence; a technical specialist checks whether the mechanism makes sense; a patent attorney or authorised patent professional checks legal drafting and filing suitability. These roles may overlap in a small team, but the responsibilities should still be explicit. A technically accurate sentence may be legally unsuitable, while a legally polished phrase may misdescribe the invention.

The client should know who can approve terminology, who can resolve source ambiguity, who signs off the final claims, and who is responsible for filing. The translator should never be placed in the position of deciding the applicant’s desired protection. Ask targeted questions and preserve an audit trail. Independence also matters: reviewers should be able to identify an error without being pressured to approve a preferred commercial interpretation.

A practical project workflow from intake to delivery

At intake, receive the complete source package, target language, destination office or audience, filing stage, deadline, formatting requirements and approved reference material. Confirm whether the request includes claims, drawings, abstract, amendments, sequence listings and forms. Agree how queries will be handled and who can approve changes. Estimate work by complexity rather than raw word count alone: claims and drawing labels often require more review than ordinary explanatory prose.

During preparation, create the manifest, glossary, claim matrix, drawing register and numerical checklist. Translate in controlled stages. Review the claims before finalising the description so that terminology choices are visible early. Run a completeness check after each file is processed. Keep unresolved queries in a separate log and make their status visible to the project manager. Do not allow a deadline to convert an unanswered technical question into an assumption.

At delivery, provide the final target files in the required format, a record of versions, an issue log showing resolved items, and any marked-up comparison requested. State which files were translated and which were retained unchanged. Do not imply that the translation itself guarantees acceptance by a patent office. Filing compliance depends on office-specific rules, deadlines, formalities and professional review. The translator’s deliverable is a controlled language version, not a legal opinion or a promise of grant.

Final checklist and learning framework

Before sign-off, verify that every file in the manifest has a completed status; every claim is present and correctly numbered; every dependent claim retains its dependency; every defined term follows the glossary; all drawing labels and reference numerals match; all numbers, units, ranges and conditions have been checked; every amendment has been incorporated in the correct version; and all unresolved high-impact queries have been answered or clearly disclosed.

Read the target document as a technical reader who has never seen the source. Can the reader identify each component, understand how parts connect, follow the process and distinguish optional from required features? Then read it as a bilingual reviewer with the source beside it. Are the same limitations, alternatives, examples, conditions and qualifications present? These two readings complement each other. Neither alone is sufficient.

For students learning specialised translation, practise in layers. Start with short technical descriptions, build a glossary, translate a set of component labels, then analyse a simple claim and map every limitation. Move to dependent claims, numerical ranges, alternatives and drawing cross-references. Finish by reviewing a complete package with a document manifest and issue log. The goal is not to memorise patent vocabulary in isolation; it is to learn how words, grammar, diagrams and filing structure work together.

Frequently asked questions

Is patent translation the same as ordinary technical translation? It shares technical terminology work, but it adds document structures and claim language whose wording may affect the interpretation of the requested protection. The translator must preserve both technical teaching and legal relationships. A technically plausible paraphrase may be unsuitable if it changes a claim limitation or the connection between claims and description.

Can machine translation be used for patent claims? It may support research or drafting in an approved workflow, but it should not be treated as an authority. Claims, numbers, defined terms, alternatives and dependencies need human review by people competent in the relevant languages and technical field. Confidentiality and data-processing controls must also be checked before any unpublished material is uploaded to a tool.

Does one translation satisfy every patent office? No. Filing languages, required documents, accepted formats, deadlines and correction procedures vary by office and procedural stage. Check the current instructions for the actual route and obtain patent-professional advice. Should a translator correct a source error? Not silently. Record the issue, explain its possible effect and ask the authorised professional or applicant to decide whether the source should be amended.

Practical glossary for patent translation

A description is the part that explains the invention and its embodiments. A claim is a numbered statement that sets out the subject matter for which protection is sought. An independent claim stands on its own; a dependent claim refers back to another claim and adds limitations. An embodiment is a described implementation. A reference numeral links a label in a drawing with a component discussed in the text. An abstract provides a brief technical summary. These terms are related but not interchangeable, and the translator should not blur them.

A limitation is a word or phrase that restricts the scope or meaning of a claim element. Antecedent reference links a later expression to an element introduced earlier. A negative limitation excludes a stated feature or condition. A functional feature describes what an element is configured or arranged to do. A numerical range identifies endpoints and sometimes an approximation or tolerance. A translation review should identify these concepts explicitly instead of treating them as ordinary words that need only sound natural.

A source query is a written question raised when the source text does not provide enough information for a reliable choice. A terminology decision records the approved equivalent and the reason for using it. A version ledger identifies the exact source and target files being processed. A bilingual completeness check confirms that every source element has a corresponding target element. A filing check is separate: it confirms that the package follows the procedural instructions applicable to the destination office and filing stage.

Source references and further reading

The World Intellectual Property Organization publishes the PCT Regulations and an Applicant’s Guide describing international application procedures. Rule 49.5 addresses the contents and physical requirements of certain translations, while the Applicant’s Guide explains the relevant elements and office-specific processes. These sources should be read in their current form for the actual filing route. A general article cannot replace the current instructions of a receiving office or designated office.

For authoritative reference, consult WIPO PCT Rule 49 and the PCT Applicant’s Guide. These references explain procedural requirements; they do not approve a particular translation or determine whether a claim is legally adequate. The applicant and patent professional remain responsible for confirming the exact applicable rules and timetable.

The central lesson is that a patent translation is a controlled representation of a technical disclosure. Preserve what the source says, identify what it does not say, and never solve uncertainty by silently inventing meaning. When a translation is accurate, traceable and appropriately reviewed, it helps inventors, patent professionals and technical readers work from the same document across languages.