Building a live translation glossary that actually works

A glossary is the highest-return hour of preparation before a broadcast, provided you build it in the right place. It is not one list, it is two: one that makes the system hear the term, one that makes it render the term. Doing only the second is the usual mistake.

What each layer fixes

Layer	Input	Problem it solves	Typical implementation
Recognition	Audio	Brand names, model numbers and coined words heard as something else	Azure phrase list, Google PhraseSet
Translation	Recognised text	Term heard correctly but rendered inconsistently, or translated when it shouldn’t be	Azure dynamic dictionary, Google glossary

The order cannot be swapped. The translation layer receives whatever string recognition produced, and if that string is already wrong, no matching rule downstream has anything to work with.

Google states the premise plainly in its speech recognition best practices: the recogniser has a very large vocabulary, but terms and proper names that are out of vocabulary will not be recognised, which is why word and phrase hints exist. Brand names are the textbook case.

Recognition layer: runtime bias, not training

Both major services take the same approach, and neither requires training a model.

Azure AI Speech phrase lists supply a set of words or phrases before recognition begins, raising the likelihood they are recognised. The documentation stresses that this is a just-in-time runtime feature, available for real-time transcription and not supported by batch transcription. That has no effect on a live broadcast, but it matters if you planned to validate your setup using offline batch transcription — phrase lists are not available on that path.

Google Cloud Speech-to-Text model adaptation carries phrases in a PhraseSet resource. One detail from the official docs is easy to miss: supplying a multi-word phrase not only makes the sequence more likely to be recognised, it also raises the probability of recognising individual words inside it. A complete product name works better as one entry than as three isolated ones.

Weights: the documented ranges, and why not to max them out

This is where people tune blindly, and both vendors publish exact numbers.

Azure’s phrase list weight runs from 0.0 to 2.0, with 1.0 as the default, 0.0 disabling the list, and 2.0 the maximum influence. It applies to the whole list rather than to individual entries.

Google’s boost must be a float greater than 0, with a documented practical ceiling of 20. Google recommends a binary search to find the right value, and — a detail worth copying — adding phrases both with and without boost in the same request.

The sentence that follows in Google’s documentation is the important one: the higher the boost, the higher the chance of false positive recognition. That explains a very common experience. After adding a glossary, the brand name comes out right and new errors appear elsewhere, because similar-sounding ordinary words are now being replaced by your terms.

So the procedure is: start at the default weight, raise it only for terms that still come out wrong, and regression-test after every change.

Translation layer: pin the wording, or skip translation entirely

This layer is narrower than most people assume, and the official caveats are worth reading literally.

Azure Translator’s dynamic dictionary lets you inline a rendering inside the request text, written as <mstrans:dictionary translation="target">source</mstrans:dictionary>. Two hard requirements: you must pass the From parameter explicitly rather than relying on autodetect, and English must be one of the two languages. The more important constraint is the one Microsoft states about scope — the feature is safe only for compound nouns such as proper names and product names. Using it to pin the rendering of a catchphrase or a verb phrase is using the wrong tool.

Google Cloud Translation glossaries are separate resources and come in two shapes: unidirectional glossaries that specify one source-to-target rendering, and equivalent term sets that map a term across several languages. Two details change your hit rate directly:

• Matching is case sensitive by default. You can ignore case for all entries when applying a glossary, but if your list mixes case-sensitive and case-insensitive terms, Google recommends keeping the default and including both forms of the case-insensitive ones.
• Stopwords are skipped. Cloud Translation maintains a stopword list, and matching glossary entries for those terms are ignored even though they are in your file.

Not translating at all is a separate mechanism. Azure supports a notranslate class and a translate="no" attribute, but documents that both work only when the input textType is set to HTML. That is by design; in plain-text mode the markup does nothing.

What one glossary entry should record

A useful entry has more than a source and a target column. Given what the two layers can each do, four columns is the practical minimum:

Column	Purpose	Example
Canonical form	What the recognition layer should emit	The brand’s official spelling
Known mishearings	How you tell whether the entry landed	What it came out as last broadcast
Translate or not	Chooses between a dictionary entry and a do-not-translate tag	Brand names usually stay as-is
Pinned rendering	The single approved wording when it is translated	The official name in the target language

The mishearings column is not for the system, it is for you. It is the only evidence that an entry is working. Without it, all you can say is that things feel a bit better.

Keeping it small

Bigger is not better, and both vendors signal where the ceiling is.

Azure publishes an explicit recommendation: a single phrase list should not exceed 500 phrases, and larger vocabularies should move to a custom model rather than a longer list. Google does not state an equivalent soft limit, but the false-positive behaviour of boost is itself the ceiling — more entries mean more opportunities for them to interfere with each other.

A workable rule in practice: if a term has not appeared in three consecutive broadcasts, delete it. It contributes nothing to accuracy and only widens the surface area for false triggers.

Proving it works

Do not judge this from how a live broadcast felt. Use a fixed recording:

1. Cut five to ten minutes of real broadcast audio containing every term you care about;
2. Transcribe it accurately by hand as the reference;
3. Run recognition without the glossary and export the result;
4. Run it again with the glossary and export that;
5. Compare three things: whether the target terms changed to the correct form, whether previously correct words were dragged off, and whether brand names are consistent in the translated output.

The second item in step 5 is the one that matters. Counting only how many new terms landed systematically overstates the benefit, because the errors that biasing introduces appear exactly where you are not looking.

Once you have run that round, you have a concrete answer to the real question: whether this glossary is still worth extending, or has reached the size where a custom model is the better instrument.