Skip to content

Optional custom vocabulary for dictation (term priming + deterministic replacement map) #13

Description

@MaxiKingXXL

Summary

Add an optional, user-defined vocabulary that improves recognition of domain-specific terms during dictation: product names, jargon, acronyms, and identifiers that Whisper often mis-transcribes. Editable from the Settings window and stored in the local SQLite database, the same way WritHer already keeps its other settings. Empty by default, so nothing changes for existing users.

Motivation

WritHer currently pastes the raw Whisper output, which is great for general speech. But domain-specific terms (technical acronyms, product names, CamelCase or under_scored identifiers, table or file names) are frequently mis-heard or mis-cased. Right now there is no way to teach WritHer these terms, so users correct them by hand after every dictation.

Proposed approach (two complementary mechanisms)

  1. Whisper priming: build faster-whisper's initial_prompt from a user list of terms. This biases the model toward those terms during transcription. It is a built-in faster-whisper parameter that WritHer does not currently use. Soft bias, no guarantee.
  2. Deterministic replacement map: after transcription, apply a case-insensitive, whole-word map of spoken-variant -> canonical form. This is the reliable lever for exact spelling and casing that priming alone cannot guarantee (for example forcing an acronym to uppercase, or restoring an underscored identifier). Runs locally, instant, no model involved.

Both are optional and independent. The whole thing is pure text processing, so it stays platform-agnostic.

Storage and editing

The vocabulary should be manageable from the Settings window and persisted in the local SQLite database, consistent with how WritHer already stores user settings:

  • a simple list editor for the priming terms
  • a two-column editor (spoken variant -> canonical form) for the replacement map

A config.py entry could still seed defaults, but the primary experience would be editing in the UI, no source-file editing required.

Backward compatibility

Empty by default: with no terms and no replacements configured, behavior is identical to today.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions