Word replacement rule tester
A word replacement rule rewrites what a speech model heard into what you meant: "post gres" into Postgres. VoiceGem applies rules longest trigger first, matches case-insensitively, and accepts several triggers per rule separated by commas. The tester above runs that exact logic and shows which rules fired.
Given replacement rules and a transcript, produce the rewritten text, in under 1 second.
We moved the Postgres migration to React Native, then patched the API key handling in API_key_store.
Rules run longest trigger first, so a rule for “react native” fires before a rule for “react” whatever order you typed them in. Boundaries are letters and digits only, which means an underscore counts as a boundary: a rule for “api” rewrites api_key_store and leaves apiKey alone.
Rules are worth more where the transcript is made.
A rule tested here is a rule you can paste into VoiceGem's dictionary on macOS, where it runs on every transcription before the text reaches your cursor. Export the set as JSON and keep it beside the project it belongs to.
Build a per-project vocabulary listVoiceGem has no mailing list and runs no drip sequence. An address left here is stored on voicegem.app for one purpose — sending you a single message when the code-dictation accuracy benchmark publishes — and is deleted after that send. The lawful basis is your consent, given by submitting this form; the field is optional and nothing is pre-selected. Leaving it blank costs you nothing on this page, because everything above is already yours. See the privacy policy.
This tool runs entirely in your browser. Rules and transcripts are processed by a JavaScript function on this page and nothing is sent anywhere, stored, or logged — which matters here, because a project vocabulary list is a list of your internal service names. The one exception is the email box under the result.
What a word replacement rule is for
Speech models are trained on general language, and technical vocabulary is exactly where they fail. A library name, an internal service, a colleague's surname, an acronym pronounced as letters — each of these comes back as the nearest common English words. "Postgres" becomes "post gres", "Kubernetes" becomes "coober netties", and no amount of speaking clearly fixes it, because the model has no reason to prefer a word it has barely seen.
A replacement rule closes that gap after transcription rather than during it. VoiceGem stores a list of trigger-to-replacement pairs and rewrites the transcript before the text reaches your cursor. The rules are per-installation, they are pure text substitution, and they never touch the model — which is why they are predictable in a way that prompting a model to "use the right spelling" is not.
The commonest mistake is writing rules from memory instead of from transcripts. Dictate for a week, note what actually came back wrong, and write rules for those. A rule for a word the model already gets right is a rule that can only cause harm.
The three matching rules that decide what a rule does
Order is by trigger length, longest first, and this is not the order you typed them in. VoiceGem sorts rules by the length of their trigger text before applying any of them, and sorts the comma-separated variants inside a single rule the same way. A rule for "react native" therefore fires before a rule for "react", which is the behavior you want and not the behavior you get from a naive loop.
Boundaries are lookarounds over letters and digits, not the usual word-boundary escape, and the difference shows up on underscores. A rule for "api" rewrites api_key_store, because an underscore is neither a letter nor a digit and therefore counts as a boundary. The same rule leaves apiKey alone, because a letter does not. Anyone writing rules against identifier-shaped text needs to know which of those two cases they are in.
Matching is case-insensitive and the replacement is written literally, so a rule from "api" to "API" rewrites "Api", "api" and "API" alike. Languages written without spaces — Japanese, Chinese, Korean and Thai — skip boundary matching entirely and fall back to substring replacement, because word boundaries are not a meaningful concept there.
Where replacement rules cause damage
A short trigger is the classic self-inflicted wound. A rule from "id" to "ID" looks harmless and rewrites every standalone "id" in your prose, including the ones in "id est" and in quoted code. Longer triggers are safer, and a trigger under three characters is almost always a mistake.
Overlapping rules are the second trap, and length ordering only partly protects you. A rule from "react" to "React" and a second from "React Native" to "RN" will not compose the way you expect, because the first rule runs on text the second has already changed. The tester above shows the finished output and the per-rule hit counts, which is the fastest way to find this class of bug.
The third is scope. VoiceGem applies rules to everything it transcribes, not only to the app you were thinking of when you wrote them. A rule tuned for a codebase will also fire in an email. Modes exist partly to contain that, and the mode configuration planner on this site is where to think it through.
What the tester does not cover
Replacement rules are one of two vocabulary features and this page covers the deterministic one. VoiceGem also has a personal dictionary and a custom vocabulary service that influence transcription itself rather than rewriting its output. Those depend on the model and cannot be reproduced in a browser, so no page here claims to.
The tester also cannot tell you which rules you need. That comes from your own transcripts, and the per-project vocabulary builder on this site is a place to collect them as you notice them, rather than trying to remember at the end of the week.
Related: what changes for the filler word remover, the paragraph formatter, step by step, or the punctuation cleanup tool, step by step.
Common questions
The longer trigger, always. Rules are sorted by trigger length before any of them run, and the comma-separated variants inside one rule are sorted the same way, so "react native" beats "react" regardless of the order you added them.
Yes. Boundaries are letters and digits only, so an underscore counts as a boundary and api_key becomes API_key. The same rule leaves apiKey untouched, because a letter is not a boundary.
Yes. Separate them with commas — "post gres, postgress" is one rule with two triggers, and both are tried longest first.
No. Matching ignores case, and the replacement text is written exactly as you typed it.
No, and the distinction matters. Replacement rules rewrite the transcript after the model has produced it. VoiceGem has a separate personal dictionary that influences transcription itself, which is a different mechanism with different behavior.