How to extract terminology from a source document automatically

Every document you are handed already contains its own glossary. It is just scattered over 40 pages, used inconsistently in at least three places, and nobody has time to read the file twice before the deadline. Being able to extract terminology automatically is what separates a glossary you build in twenty minutes from one you never build at all. We see both outcomes most weeks. Projects that fall apart at review almost never fall apart because the translator did not know the subject. They fall apart because nobody decided, before translation started, which of the source document's forty recurring nouns were terms and what each one should become in the target language.

This is a practical guide to doing that extraction with software instead of a highlighter: what the tools actually give you, how to run extraction on a DOCX, XLSX or PPTX source, how to cut a noisy candidate list down to something a translator can use, and where the whole approach stops working.

What automatic term extraction actually produces

Start with the right expectation. Terminology extraction does not produce a glossary. It produces a candidate list: a ranked set of strings from the source document that behave statistically or grammatically like terms. Deciding which of them are terms, and what they become in the target language, stays human work.

That distinction matters because of how the tools are tuned. Extraction engines are built for recall rather than precision. They would rather hand you 300 candidates containing all 60 real terms than 70 candidates containing 45 of them, because a term you never saw is a term you cannot fix, while a false positive costs you two seconds of scrolling. A raw candidate list is noisy by design. On a 20,000-word technical manual, expect somewhere between 200 and 800 candidates, of which maybe 10 to 20 percent deserve a place in the glossary.

It helps to hold a working definition of a term while you filter. ISO 704, the standard covering principles of terminology work, treats a term as the designation of a concept within a specific subject field. In a translation project we use something narrower and more operational: a term is any string where the translator does not get to choose freely. Either the client has a preferred rendering, or the document's internal consistency depends on it, or getting it wrong carries a cost. "Housing" in a pump manual is a term. "Important" is not, even though it may appear 40 times.

Two other outputs of extraction get underused. One is the frequency and distribution data. Knowing that a term appears 90 times across every chapter tells you more than knowing it exists. The other is inconsistency in the source itself. Extraction routinely surfaces the fact that the author used two names for the same thing, which is a question for the client rather than a decision for the translator.

Two extraction methods, and why you want both

Extraction tools work on two different principles, and they fail in opposite directions.

Statistical extraction counts things. The simplest version is raw frequency with stopwords removed, which is close to useless on its own, because the most frequent nouns in any document are generic. The versions worth using compare your document against a reference corpus of ordinary language, so what gets ranked is not frequency but unusual frequency. That comparison is normally done with log-likelihood or chi-squared keyness scores, the same measures corpus linguists use, and it is why "impeller" outranks "system" even when "system" appears more often. For multiword terms the standard approach is C-value, which scores a candidate by how often it occurs and how rarely it occurs nested inside something longer. "Mechanical seal" scores well. "Seal" on its own scores lower once the tool notices it mostly lives inside longer units.

Statistical methods need volume. Below roughly 1,500 words of running text the counts stop meaning anything, which is why extraction is near-worthless on a one-page certificate.

Linguistic extraction looks at grammar instead, using the ordinary NLP building blocks: a part-of-speech tagger, a lemmatizer, and a set of patterns typical of terms in that language. Noun plus noun. Adjective plus noun. Noun plus preposition plus noun. This catches terms that occur only twice, which statistics will miss, and it handles inflection properly when the tagger lemmatizes. It also produces more junk, because plenty of adjective-noun pairs are ordinary phrases with no terminological status at all.

LLM-based extraction has become a practical third option, and in our experience it is good at exactly what the other two are bad at: judging whether a candidate belongs to the subject field. It is also willing to invent terms that are not in the document, so it needs the same filtering discipline as anything else. The combination we see working is statistical ranking for the backbone of the list, pattern matching to catch the low-frequency entries, and a language model as a sorter rather than a generator.

How to extract terminology automatically from a DOCX, XLSX or PPTX source

Before any of that runs, you need the text out of the file, and this is where most extraction attempts quietly lose a third of the terminology.

In a DOCX, body paragraphs are the easy part. Terms also live in table cells, headers and footers, figure captions, text boxes, SmartArt labels, footnotes, and author comments nobody cleaned out. Copy-pasting a document into a text editor gets you the body and silently drops several of those. Whatever you use for extraction, confirm that table cells and text boxes are included, because in technical documentation the densest terminology is usually inside the tables.

XLSX needs a different approach entirely. Term-bearing text in a workbook sits in sheet names, column headers, and the repeated string values inside columns. A product catalogue with 11,000 rows does not have 11,000 terms. It has perhaps 25 column headers and a handful of columns whose values form a controlled vocabulary of 20 to 50 options. Run extraction on the distinct values per column rather than on the sheet as one flat text blob, or your frequency counts will be dominated by whichever product line happens to have the most SKUs. Skip numeric cells and formula results.

In a PPTX, pull slide text, notes pages, and text inside grouped shapes. Notes matter more than people expect, because speaker notes often carry the full form of an acronym that appears bare on the slide, which is precisely what you want in the glossary.

With clean text in hand the mechanical part is short. Normalize casing for counting but keep a record of the original capitalization, since capitalized strings in mid-sentence are strong candidates for product names and do-not-translate entries. Lemmatize if the source or target language carries heavy inflection. Set a frequency floor of two or three for statistical candidates, with an exception for anything capitalized or containing a digit. "DN 50" and "Type 4B" appear once and still belong in the list.

Filtering the candidate list down to something usable

A 600-item candidate list is not a deliverable. Filtering is where extraction starts being worth the effort, and it takes about fifteen minutes on a typical file once you have a routine.

We weigh candidates on four things, roughly in this order. Distribution comes first: a term appearing in eight of ten chapters matters more than one appearing 30 times inside a single section. Then position, because anything sitting in a heading, a table header, a figure caption or a slide title has already been treated as a label by the author. Then specificity, which is where the reference-corpus comparison earns its place. Generic business vocabulary goes, document-specific strings stay. Last, and least mechanical, cost of error. A term that appears twice in a safety warning outranks one that appears 50 times in a marketing paragraph.

Then clean up the structure of the list. Drop candidates that exist only as fragments of longer candidates. Merge inflected variants into one entry. Split genuine homographs into separate entries with a context note, because "play" meaning clearance and "play" meaning operation need different target terms, and a translator working segment by segment will not always see which is which.

Target size depends on who has to use the thing. For one freelancer on a 20,000-word manual, 40 to 80 entries is about right. For a five-translator team on an ongoing account, 150 to 300 is manageable. Past that, adherence drops off a cliff. We have watched 900-entry client glossaries get ignored wholesale, because checking them cost more than the fee for the page they were checking. For a fuller framework on the inclusion decision itself, we wrote that up separately in how to choose which terms go in your AI translation glossary.

One habit worth building: keep the rejected candidates on a second sheet instead of deleting them. When a client comes back at review arguing about a word, that list tells you whether you considered it and why you left it out.

Two examples from our desk

A 90-page maintenance manual for industrial pumps, English into German, four translators, three weeks. Extraction on the DOCX returned 540 candidates, which filtered down to 71 entries in under half an hour. Two findings paid for the whole exercise. The source used "retaining ring" and "snap ring" for the same component, 23 and 9 times respectively, in chapters written by different engineers. That went to the client as a question, and the answer (same part, pick one) prevented an inconsistency the translators would otherwise have reproduced faithfully in German. The second finding was that "play" appeared 14 times meaning mechanical clearance and never meaning operation, which is exactly the kind of thing an unguided MT pass renders fluently and wrongly.

The other example is a product catalogue in XLSX, 11,000 rows, English into French and Spanish. Running extraction across the sheet as flat text produced garbage dominated by brand names and SKU fragments. Running it per column produced something useful: the finish column held 31 distinct values, the material column 18, and both were effectively controlled vocabularies the client had never written down anywhere. Those 49 strings became fixed glossary entries before translation started. Without that pass each translator would have rendered "brushed nickel" however they preferred, in a workbook where the string appears over 400 times and any variation is visible to the client after a single sort.

Neither case involved clever tooling. Both involved spending half an hour on extraction before translation instead of three hours on terminology corrections after it.

Where this approach stops working

Automatic extraction has conditions, and it is worth being blunt about them.

It needs text volume. Under about 1,500 words the statistical signal collapses and you are faster reading the file yourself. It needs the terminology to repeat, which rules out most marketing and editorial copy, where the writer deliberately varies wording and the strings that matter most may appear exactly once.

It only gives you the source side. Extraction tells you "mechanical seal" is a term. It does not tell you what this client calls that part in German. For the target side you need a previous translation to align against, an existing termbase, or a subject-matter decision from someone qualified to make it. Bilingual extraction from aligned past deliveries is the strongest option when it exists, and it exists far less often than tool vendors imply.

It degrades badly on OCR output. Scanned PDFs converted to DOCX carry character-level noise that defeats both frequency counting and part-of-speech tagging. Clean the text first or skip the step.

And it knows nothing about your client. Extraction cannot know that their legal department insists on one rendering of a product category, or that last quarter's reviewer rejected a term you are about to propose again. That lives in your project records, and the candidate list is where you reconcile the two.

Turning the list into something the translation step can use

Keep the output boring and portable. Columns: source term, target term, part of speech or a short context note, a do-not-translate flag, status, and a free comment field. CSV or XLSX is fine for project work. If the terms are headed into a termbase that other tools will read, export to TBX, the ISO 30042 exchange format, rather than inventing a column layout the next tool cannot parse.

Then get it approved before translation starts, not after. A glossary agreed with the client at kickoff is a specification. The same glossary presented at delivery is an argument. We have yet to see a project where moving that conversation earlier made things worse.

If the translation step is AI-driven, the glossary has to actually reach the model instead of sitting in a folder next to the file. That is the part of the workflow SnapIntel covers: it takes the DOCX, XLSX or PPTX directly, runs domain analysis on the source, and will not start translating until the glossary and the translation prompt have been reviewed and approved, so the terms you extracted are in force during the run rather than audited afterwards in the QA report. If you want a bilingual starting point instead of a monolingual candidate list, the free Glossary Generator builds one from a document you upload, which you then cut down with the filtering pass above.

Here is the routine, if you want to try it tomorrow. Take the next file over 5,000 words. Extract the full text, including tables, text boxes and speaker notes. Run frequency-based extraction against a general-language reference and keep every candidate appearing twice or more, plus anything capitalized or containing digits. Filter on distribution, position in headings, and cost of error until you are at 40 to 80 entries. Send the client two things: the glossary, and the list of source-document inconsistencies you found along the way. Time yourself. If the first file takes 45 minutes, the third will take 20, and the inconsistency list alone will change how the client talks to you.