Text Normalization for Local TTS: Numbers, Dates, and Abbreviations

Direct answer: text normalization converts written forms into the words a speech model should say. It must use document language and context because 1/2 can mean one half, January second, February first, or one of two. Build normalization as a versioned, testable stage before synthesis. Preserve the original text, record every replacement, and let users override ambiguous items. Cover currencies, dates, times, ordinals, decimals, ranges, units, abbreviations, URLs, email addresses, symbols, and proper names. Never use an unrestricted language model rewrite for paid scripts without showing the diff. The goal is faithful speech, not cleaner prose.

Ambiguity examples

Keep the transformation reversible

Store source text, normalized speech text, rule identifier, locale, and user override. Display the changed spans before expensive generation when the script contains financial, legal, medical, or identity-critical tokens. Reversible logs make support and regeneration possible without storing hidden rewrites. Use deterministic rules for known formats and send unresolved items to a review queue. Do not silently expand a product code or surname because a statistical model found a common alternative.

Apply language and domain profiles

Dates, decimal separators, abbreviations, and units change by locale. A news script, scientific paper, game dialogue, and audiobook also use different conventions. Attach a language and style profile to the project, then allow a smaller per-document lexicon. Keep names and brand terms in a pronunciation dictionary rather than scattered substitutions. The local TTS model guide helps separate model capability from frontend preparation.

Test tokens inside sentences

A rule that works on an isolated number can fail next to punctuation or markup. Build fixtures with the token at the start, middle, and end of a sentence, inside quotations, beside units, and across chunk boundaries. Include negative numbers, version strings, phone numbers, addresses, currencies, times, Roman numerals, and mixed-language names. Compare the normalized text and final audio transcript. Listen to pause and emphasis because correct words can still sound wrong.

Version rules with generated projects

Normalization updates can change every regenerated clip. Store the ruleset version with the project and offer an explicit migration preview. When a bug is fixed, regenerate only affected spans where the editor supports it. Track rule coverage and user overrides; repeated overrides identify a missing domain rule. Use the 10,000-word endurance method to test whether normalization remains stable across long scripts.

Production acceptance record

Before acting on this text normalization local TTS recommendation, create an acceptance record for the exact feature and release. Name the owner, reviewer, user task, minimum Mac, operating system, application version, runtime, model revision, precision, input fixture, expected artifact, and pass threshold. Attach two hundred reviewed fixtures, locale and domain labels, original-to-normalized diff. Keep upstream documentation in one section and measurements from your own machine in another. Record every unsupported path, timeout, crash, incorrect output, and manual repair. A result counts as a pass only when the artifact is usable for the stated job. Fast but incomplete output, an unrecoverable cancellation, or a file that cannot be reopened remains a failure.

Run the record once on a clean launch, once after warmup, once with realistic companion applications open, and once after deliberately interrupting the workflow. Exercise the operating steps that matter most here: Preserve original and normalized text. Require locale and domain context. Review high-risk transformations. Save raw timings and checks instead of copying only a winning screenshot. Include rejected options and the reason each lost, so a later framework or model update can reopen the decision without starting from memory. Assign an update trigger such as a new runtime release, model revision, minimum operating system, material support issue, or change in licensing. Review the record before changing defaults, removing a fallback, or publishing a broad performance claim.

Evidence to collect before publication

Release a fixture pack with at least 200 reviewed tokens across English plus one additional supported locale. Include expected normalized text, context, rule ID, and a criticality label. Generate a subset with two local engines, align transcripts, and publish rule failures separately from model pronunciation failures.

• Two hundred reviewed fixtures
• Locale and domain labels
• Original-to-normalized diff
• Two-engine audio subset
• Ruleset version and override record

Reader worksheet

List every special token type in a real script and write its expected reading, locale, domain, criticality, automatic rule, and user override. Mark items that must stop generation for review. Link recurring names to the pronunciation test suite rather than adding one-off spelling hacks.

Practical checklist

1. Preserve original and normalized text.
2. Require locale and domain context.
3. Review high-risk transformations.
4. Test rules inside sentences.
5. Version the ruleset with projects.
6. Separate normalization from model failures.

Frequently asked questions