Building a pronunciation lexicon that survives proper nouns
A lexicon is a maintained artifact, not a one-time export. Pick a phone set, settle heteronyms and numbers, and keep the out-of-vocabulary loop running.
Three consumers, three requirements
A pronunciation lexicon is a table of words and their phone sequences, and in one project it usually serves three consumers. A text-to-speech system needs a pronunciation for every word it will be asked to say, because a missing entry is an audible failure. A forced aligner needs entries that cover the transcript, with variants where the pronunciation varies, and its health metric is the out-of-vocabulary rate. A recognizer that supports contextual biasing needs pronunciations for the terms worth boosting: product names, place names, jargon.
One artifact can serve all three if two things are pinned, the phone set and the file format. The differences between consumers are fields, not separate files. Stress marks and syllable boundaries are fields that the aligner may ignore and the synthesizer will use, and keeping them in one table avoids the situation where three teams maintain three dictionaries that disagree about the same word.
Pick a phone set and freeze it
The three common choices are ARPABET, which is English-centric and what many alignment recipes expect; IPA, which is portable across languages; and X-SAMPA, which is ASCII-safe for tooling. The choice matters less than the freeze. Two phone sets mixed in one dictionary do not raise an error — they silently misalign, because a symbol the model does not know is either treated as out-of-vocabulary or mapped to whatever the nearest symbol happens to be.
Write the inventory into the header of the dictionary and validate every entry against it. For multilingual work, one IPA inventory with a documented symbol-to-language mapping beats per-language alphabets, because a symbol then means the same thing everywhere and a reviewer can read entries from languages they do not speak.
Heteronyms, numbers and abbreviations
Heteronyms are words whose pronunciation depends on meaning: read, lead, live, bass, wind, tear, bow, close, use, present. The lexicon lists both pronunciations as variants, and something outside the lexicon chooses: a part-of-speech tagger or a small set of hand-written rules for the frequent cases in a text-to-speech system, or the aligner itself when it picks the variant that fits the audio. What does not work is picking one pronunciation and hoping.
Numbers and dates should not live in the lexicon as digit entries. Expanding them in the transcript — twenty three, not 23 — keeps the text consistent with what was said, which is what the aligner needs and what a scorer expects. Adding digit entries to the dictionary to paper over unnormalized text moves the problem instead of solving it, and it hides the fact that the transcript and the audio disagree.
Abbreviations need a per-token decision, recorded in a small table: an initialism is spoken as letters, an acronym as a word, and the same string can be both depending on the community that uses it. Units and currency symbols belong to the normalization layer rather than to the dictionary, for the same reason as numbers.
Proper nouns are the cost center
Names are where coverage fails and where grapheme-to-phoneme conversion fails predictably. The errors are not random: stress lands on the wrong syllable, vowels reduce in the wrong places, and names of foreign origin get the patterns of the wrong language, so a name that looks English but is not will be pronounced as if it were.
The workable pipeline is layered. Hand-write the entries for the names that occur most often, because a short list of frequent names covers most of the occurrences. Run a grapheme-to-phoneme tool such as mfa g2p for the remainder, and route its output for names through a review pass, where a speaker of the language checks a hundred entries in minutes and catches the systematic errors. Tools differ in their conventions — the phonemizer libraries, the rule-based backends, and the utilities shipped with alignment toolkits do not produce identical output for the same word — so pick one per language and record which tool produced which entries.
Foreign-origin names inside a language need one more decision, written down: whether the lexicon stores the nativized pronunciation, the way speakers of the language actually say the name, or the source-language pronunciation. Both conventions are defensible. Mixing them within one dataset is not, because the same name then has two entries and no rule for choosing between them.
Keep the loop running
A lexicon is never finished, and the maintenance loop is cheap if it is regular. Score the out-of-vocabulary rate on real transcripts, rank the missing words by how often they occur, and fix the top of that list. The head of the list is short and accounts for most of the occurrences; the tail is long and rarely worth the effort. Two rounds of this usually take the rate down to where it stops mattering.
Keep three things beside the entries: provenance, so it stays clear which entries were hand-written, generated, and reviewed; a version, stamped onto any dataset or model that used the dictionary; and a validation step in the build, so an entry with an illegal symbol or a missing stress mark fails loudly instead of being carried into an alignment. When the dictionary changes, re-run the downstream check — the alignment acceptance rate, or the out-of-vocabulary rate — so the effect of the change is visible rather than assumed.