Why Intuition Is Not Enough
Ask a content team to list the terms that need consistent translation and you will get the product names, a few obvious technical terms, and perhaps the company name.
You will not get the term that appears in forty videos with three slightly different phrasings, the acronym that expands two different ways in different departments, the industry phrase that has no accepted target-language equivalent, or the proper noun that automatic transcription consistently mangles.
Those are the terms that cause problems, and they surface through systematic extraction rather than through recall.
Extraction is a mechanical process that takes a few hours and produces a candidate list. Validation — deciding what each term should be — is the expensive part and should be spent on candidates that actually matter.
Sources to Extract From
The source transcripts. The primary corpus. Every video that will be localized, transcribed and corrected, forms the text you extract from.
Existing localized material. If you ship a localized product interface, translated documentation, or a help centre in the target language, terminology decisions already exist. These are more authoritative than anything you would derive fresh, because customers already see them.
Product string files. For software content specifically, these define the vocabulary the customer encounters and are the source of truth for feature names.
Support content and ticket text. Reveals the vocabulary customers actually use, which frequently differs from internal terminology.
Marketing and brand guidelines. Contains terms that must be used exactly and terms that must never be used.
Legal and compliance documentation. Contains prescribed language that must be reproduced rather than translated freshly.
Extract from all of these before deciding anything, since inconsistencies between them are themselves findings worth surfacing.
Extraction Methods
Frequency analysis over the transcript corpus is the workhorse. Rank terms by occurrence and inspect the top tier. Terms appearing across many assets are the ones where inconsistency is most damaging.
Simple frequency ranking produces a lot of noise — common function words dominate. Filtering against a general-language frequency list surfaces terms that are unusually common in your corpus relative to ordinary language, which is a much better signal.
Multi-word phrase extraction catches terms that single-word frequency misses. Many domain terms are two or three words, and treating them as units matters because the correct translation is frequently not the composition of the individual word translations.
Capitalization and pattern matching catches proper nouns, product names, and acronyms mechanically. Anything appearing capitalized mid-sentence, anything in all caps, and anything matching version or model number patterns is a candidate.
Transcription error clustering. Words that automatic transcription renders inconsistently across the corpus are almost always proper nouns or technical terms the system does not know. The inconsistency itself identifies them, and these are exactly the terms that need glossary entries with pronunciation guidance.
Diff against a general corpus. Terms present in your content and absent from general language are domain vocabulary by definition.
Building the Proper Noun Inventory
Proper nouns deserve separate treatment because frequency ranking underweights them and they cause disproportionate problems.
Inventory exhaustively rather than by frequency: company names including any variants and former names, product names and their versions, feature names, personal names of anyone mentioned, place names, partner and customer names, and event or program names.
For each, record the exact correct spelling, whether it is translated or retained, and the pronunciation for audio generation.
Personal names deserve care in content that mentions individuals. Getting a person's name wrong is conspicuous and avoidable, and transliteration into non-Latin scripts requires the established form rather than a fresh derivation.
Former and deprecated names should be in the forbidden list with the reason, so that content does not reintroduce a name that was retired.
Filtering Candidates
Extraction produces more candidates than are worth validating, and filtering is what makes the validation effort tractable.
Keep terms that recur across multiple assets, since that is where inconsistency compounds.
Keep all proper nouns regardless of frequency, since a single wrong product name is conspicuous.
Keep terms with multiple plausible translations, since these are where translators will diverge without guidance.
Keep terms with regulatory or safety significance, regardless of frequency.
Keep terms where the source usage is already inconsistent, since resolving this is valuable independent of translation.
Drop terms with one obvious translation that no competent translator would get wrong.
Drop hapax terms — appearing once, in one asset, with no particular risk — unless they fall into one of the keep categories.
A candidate list of a few hundred filtered terms is more useful than a thousand unfiltered ones, because the validation effort is finite and should go where it changes outcomes.
Detecting Existing Inconsistency
One of the most valuable outputs of extraction is not the term list but the inconsistencies it reveals in your existing content.
Where the same concept appears with different phrasings across the source corpus, that inconsistency will propagate into every target language and multiply.
Where the same term is rendered differently across existing localized assets, that is an inconsistency already in the wild and a priority for resolution.
Where internal terminology differs from the terminology customers use, that gap affects discovery and support.
These findings frequently justify the extraction effort on their own, independent of the localization they were performed for.
Present them as findings requiring a decision rather than fixing them unilaterally, since the source-side inconsistency may reflect a genuine distinction someone intended.
Validation
Extraction is mechanical; validation requires judgment and is where the time goes.
For each candidate, the decisions are: what the term means precisely, whether it is translated or retained, what the approved rendering is per language, what renderings are forbidden and why, how it should be pronounced, and any inflection or agreement information the target language needs.
Validation requires a native speaker with domain knowledge, and it is worth batching — reviewing two hundred terms in one session is far more efficient than reviewing them as they arise across projects.
Record the reasoning for contested decisions. This is what allows a later reviewer to evaluate rather than relitigate, and it is the single practice that most reduces churn when reviewers change.
Mark each entry as validated or provisional, and treat provisional entries as suggestions rather than as rules until someone qualified has confirmed them.
Maintaining Extraction Over Time
Extraction is not one-time. New content introduces new terminology, and a glossary built once decays.
Run extraction periodically over new content, comparing against the existing glossary to surface terms that are not yet covered.
Watch for terms that reviewers flag repeatedly, which indicates either a missing entry or an entry whose reasoning is not clear enough.
Watch for product and organizational changes — renamed features, new products, deprecated terminology — which should enter the glossary before content using them enters translation rather than after.
Re-extract when entering a new domain or content type, since a glossary built for one content area may not cover another.
Practical Sequence
Assemble the corpus: corrected transcripts of the content to be localized, plus any existing localized material, product strings, and prescribed language.
Run frequency analysis with general-language filtering, multi-word phrase extraction, and pattern matching for proper nouns and acronyms.
Cluster transcription inconsistencies to surface terms the pipeline handles poorly.
Filter the candidates against the keep and drop criteria.
Surface source-side inconsistencies as findings requiring decisions.
Batch-validate the filtered list with a native reviewer who knows the domain, recording reasoning for contested choices.
Structure the validated output into glossary entries with the fields the target languages require.
Re-run periodically over new content.
The whole exercise costs a few hours of mechanical work plus a validation session, and it is the difference between a library that reads as coherent and one that reads as assembled by different people at different times — which is exactly what it would be without it.
Tooling Considerations
Extraction can be done with general-purpose tools or with dedicated terminology software, and the choice depends on scale.
At small scale, frequency analysis in a spreadsheet over concatenated transcripts, combined with manual inspection, is entirely adequate and takes an afternoon. The mechanical work is not complicated.
At larger scale, dedicated term extraction tooling handles multi-word phrases, stop-word filtering, and general-corpus comparison automatically, which saves real time and produces better candidate lists.
Whatever the tooling, a few practical requirements matter:
Case sensitivity should be configurable. Proper noun detection depends on capitalization, and case-folding the corpus destroys it.
Multi-word phrases must be supported. Single-word extraction misses a large share of domain terminology.
Output should be inspectable. A tool that produces a ranked list you can review is more useful than one that produces a finished glossary you have to trust.
Morphological awareness matters for inflected languages. In Polish, Czech, Hungarian, Finnish, or Turkish, surface-form frequency analysis fragments a single term across its inflected variants and underweights all of them. Lemmatization before counting produces a far more accurate picture.
For the target-language side, the same consideration applies when checking whether approved terms are actually being used in output.
Handling Acronyms and Abbreviations
Acronyms deserve specific treatment because they cause several distinct problems.
Expansion inconsistency. The same acronym may expand differently across a corpus, sometimes reflecting genuine ambiguity and sometimes reflecting drift. Extraction surfaces this.
Translation decisions. An acronym may keep its source-language form, take a target-language acronym built from the translated expansion, or be expanded rather than abbreviated. All three appear in real usage and the choice varies by term and language.
Pronunciation. Whether an acronym is spelled out letter by letter or pronounced as a word is a decision, and generated speech gets it wrong regularly. This belongs in the glossary as pronunciation guidance.
First-use expansion. Whether the expansion appears on first use is a style decision that should be consistent, and it interacts with subtitle length constraints.
Collision. An acronym meaning one thing in your domain may mean something else in the target market, which a native reviewer will catch and extraction will not.
Inventory acronyms separately from general terms and validate each of these dimensions, since an acronym handled inconsistently is more conspicuous than an ordinary term.
Extraction for Audio Specifically
Video localization has a requirement document translation does not: the terminology has to be spoken correctly, not merely written correctly.
This makes transcription behaviour a useful extraction signal in its own right.
Terms that automatic transcription renders inconsistently are terms the system does not recognize, which means they are almost certainly proper nouns or specialized vocabulary. These same terms will be mispronounced by generated speech for the same underlying reason.
Building the pronunciation side of the glossary from this signal is efficient: the terms that caused transcription problems are largely the terms that will cause pronunciation problems.
For each such term, record the intended pronunciation in whatever form the platform accepts — phonetic spelling, markup, or a recorded reference.
Pay attention to terms that are pronounced differently from their spelling, terms borrowed from other languages where the source or adapted pronunciation must be chosen, acronyms, and any term where a wrong stress placement changes the word.
This work pays back immediately and permanently. A name corrected once stays corrected across every subsequent asset, whereas a name not entered in the glossary will be rediscovered and re-fixed on every project until someone writes it down.
What Extraction Cannot Do
It is worth being clear about the limits, since extraction is sometimes expected to produce more than it can.
Extraction identifies candidates. It does not decide what they should be, and the deciding is where the expertise and the time go.
It cannot tell you whether a term should be translated or retained, since that depends on what practitioners in the target market say.
It cannot identify terms that matter but appear rarely, unless they fall into the proper noun or regulatory categories that are inventoried exhaustively rather than by frequency.
It cannot catch terminology that is absent from your source content but that the target market would expect — a concept your content assumes and a target-market audience would need named.
It cannot assess whether a term carries an unintended connotation in the target market, which requires a native reviewer.
Treat extraction as the mechanism that makes validation tractable rather than as a substitute for it. Its value is that it narrows a large corpus to a reviewable list, and it does that reliably.
