DEV Community: WizMantra Academy

Counting filler words when speech-to-text deletes them

WizMantra Academy — Sat, 07 Nov 2026 12:34:02 +0000

We wanted a one-minute speaking test that gives a learner three numbers: words a minute, filler words and long pauses. The browser's speech recognizer would do the hard part. We'd count.

It turns out the transcript fights you on all three.

Lie 1: the model cleans up "um"

Speech recognizers are trained to produce readable text, so "um" and "uh" mostly vanish. Count fillers from the transcript and a nervous speaker looks fluent.

There's no fix for that from the page. What you can do is count the fillers that survive transcription because they're real words:

/* Fillers that survive speech-to-text. Recognisers usually drop "um" and "uh". */
var FILL = ["um", "umm", "uh", "uhh", "er", "erm", "hmm", "ah",
  "basically", "actually", "literally", "matlab",
  "you know", "i mean", "kind of", "sort of", "like"];

"Matlab" is the Hindi "I mean", and it turns up in Indian English speech often enough to earn a slot.

Lie 2: "like" is a filler, except when it isn't

"I like Python" isn't a filler. "It was, like, a huge refactor" is. We check the word before it:

var LIKE_OK = /^(i|you|we|they|would|i'd|feel|feels|look|looks|sound|sounds|just|really|don't|didn't|also|not|is|was|it's|that's|seems)$/;

if (w[i] === "like") { if (i > 0 && LIKE_OK.test(w[i - 1])) continue; }

It's crude and it works well enough for a self-check. "Looks like", "feel like" and "I like" pass. A bare "like" in the middle of a clause gets counted.

Lie 3: there's no silence in a transcript

A transcript has no timestamps per word in this API, so you can't see a pause directly. But you can see when results arrive. If two onresult events are more than two seconds apart, the speaker stopped:

rec.onresult = function (e) {
  var now = Date.now();
  if (last && now - last >= 2000) gaps.push(now - last);
  last = now;
  // ...
};

It's a proxy, and a noisy one on slow networks, since Chrome's recognizer runs on Google's servers. For a learner who stalls for four seconds looking for a word, it's accurate enough.

Lie 4: Android repeats itself

With continuous = true, desktop Chrome sends each final result once. Android Chrome sends each new final result with the earlier text still inside it. Join them naively and every sentence appears two or three times, and your words-a-minute doubles.

if (r.isFinal) {
  var prev = finals[finals.length - 1];
  /* Android Chrome repeats earlier text inside each new final result */
  if (prev && tx.toLowerCase().indexOf(prev.toLowerCase()) === 0) finals[finals.length - 1] = tx;
  else if (tx) finals.push(tx);
}

Two smaller ones while we're here. The browser ends a "continuous" session early when it feels like it, so onend restarts it if the timer is still running. And after stop(), the last final result can take over a second to arrive, so we wait up to 1,800 ms before scoring.

The scoring is the boring part

Once the transcript is honest, the score is plain thresholds:

under 70 words a minute: slow
120 to 160: natural
over 165: fast, fine if people follow you

Fillers per minute and long pauses add to the band. That's about 40 lines. The model does the hearing; the judgement is ours, in plain if statements anyone can read and argue with.

Try it

60-second English fluency test. Chrome, Edge or Safari. Firefox gets a typed fallback because it has no SpeechRecognition.

Has anyone found a browser-side way to keep "um" in the transcript? I'd like to know.

Drafted with help from an AI assistant. Code is from the live tool.

Standup English for Indian developers, the 90-second version

WizMantra Academy — Sat, 07 Nov 2026 12:27:19 +0000

Your code is fine. The standup is where the remote team actually hears you, every day, for about 90 seconds. That's the slot this post is about.

A lot of engineers know the feeling: you freeze in the standup, or you switch to Hindi in your head and translate while you talk.

The three-line shape

Yesterday, today, blocked. Keep each to one sentence, with one concrete noun in it.

Yesterday I finished the retry logic for the payment webhook.
Today I'm writing tests for it and then picking up the login bug.
I'm blocked on the staging keys. Could someone on infra share them after this call?

Three things make that work:

A real noun. "The retry logic for the payment webhook", not "that issue".
Present continuous for today. "I'm writing", "I'm picking up". It sounds planned.
The blocker ends in a question with a person in it. "Could someone on infra..." gets an answer. "There is some dependency" gets silence.

What to drop

Common	Better
Basically, actually, so basically	(nothing, just start)
I did the needful for the ticket	I fixed the ticket
I have one doubt on this	I've got a question about this
Will revert by EOD	I'll reply by end of day
Myself Rahul, from the backend team	I'm Rahul, I work on the backend
It is done from my side	It's done on my end

"Basically" is the big one. It buys thinking time, and a silent half-second does the same job better.

Pace is the thing nobody tells you

Most fluent speakers sit around 120 to 160 words a minute. Below 100, listeners start finishing your sentences for you. Way above 165, a non-Indian listener on a laggy call loses you.

You won't know your own pace by feel. Measure it.

Disagreeing without sounding rude or timid

Two extremes show up in standups: silence, or a flat "No, that is wrong". Try these:

"I see it a bit differently. Can I share why after standup?"
"That works for me, with one concern about the migration."
"Can we take that offline? It needs ten minutes."

Notice that all three move the real discussion out of the standup. That's good standup manners anywhere.

Practise it for free

We built these as browser tools. They need no sign-up and run on a phone:

English roleplay has a "Meeting: disagreeing politely" scene and an HR screening call, both with branching replies.
60-second fluency test gives your words a minute, filler count and long pauses. Say tomorrow's standup into it.
Indian English checker: paste your Slack update before you send it.

The fluency test uses the browser's speech recognizer, so it needs Chrome, Edge or Safari, and Chrome sends the audio to Google to transcribe. We don't store anything.

What's the standup phrase you've heard from a teammate that you've quietly stolen? Drop it below.

Drafted with help from an AI assistant. Tool details checked against the live pages.

Why our Indian English checker is 50 regexes and no LLM

WizMantra Academy — Sat, 07 Nov 2026 12:23:43 +0000

Paste "Kindly do the needful and revert at the earliest" into any LLM and ask it to fix the tone. You'll get a nice answer. You'll also get a rewritten email that sounds like the LLM, and no idea which three phrases were the problem.

We built the opposite for our learners: an Indian English checker that's 50 regular expressions in one file. Each one flags a phrase, suggests a swap, and says why.

What a rule looks like

// [pattern, replacement, kind, why]   kind: i = Indianism, s = stiff, c = too casual
[/\bkindly do the needful\b/gi, "please take care of this", "i",
  "\"Do the needful\" is understood in India and puzzling almost everywhere else. Say what you actually need."],
[/\bprepone(d)?\b/gi, function (m, d) { return d ? "brought forward" : "bring forward"; }, "i",
  "\"Prepone\" is Indian English only. Use \"bring forward\" or \"move up\"."],
[/\bI have (a|some|few|a few) doubts?\b/gi, ..., "i",
  "In Indian English \"doubt\" means question. Elsewhere it means you don't believe something."],
[/\bPFA\b/g, "I've attached", "s", "PFA is office shorthand. Many readers won't know it."],

The "why" string matters more than the swap. A learner who reads "outside India, passed out means fainted" once doesn't need the tool the second time.

Why rules and not a model

Explainable. Every highlight points at one phrase and one reason. A learner can argue with it.
It doesn't rewrite your voice. Rules only touch what they match. The rest of the email stays yours.
Free and instant. No API key in the page, no per-request cost, works offline once loaded. Our audience is mostly on phones on mobile data.
Nothing to send anywhere. People paste real client emails into this. The text never leaves the browser.

For this job, the catalogue of Indianisms is finite and well known. You don't need a model to know that "cope up with" should be "cope with".

Where the rules lose

Here's the rule for "revert", which in Indian office English means "reply":

[/\brevert(ing|ed)?\b(?= (to|on|with|at|me|us|by|soon|asap|today|tomorrow|after)\b)/gi,
  "reply", "i", "\"Revert\" means go back to an earlier state. Outside India it doesn't mean reply."],

The lookahead is there so "please revert to me" gets flagged and "revert the change" doesn't. Now type this:

I'll revert to the last stable release.

The old version marked it red as an Indianism. Every developer reading this knows that's wrong, and the rule couldn't, because it has no idea what a release is. "Revert back to the previous version" was worse: the suggested rewrite was "reply to the previous version".

So we patched it the regex way, with a negative lookahead listing what you revert to in standard English:

(?! (?:back )?to (?:the |a |our |that |this )?(?:last|previous|old|original|stable|default|normal|v?\d+|commit|version|release|build|backup|branch|main|config|migration)\b)

"Revert to me" still gets flagged. "Revert to v1.2", "revert to the old config" and "things will revert to normal" don't.

That's the honest trade. A regex knows the phrase, so every new context is another hand-written exception. A model knows the sentence and would never have needed the list.

The bug the test found

Writing that test turned up a second, quieter bug. The tool built each suggested fix by re-running the rule on the matched word alone, "revert". But the rule ends in a lookahead that needs the words after the match, so on its own it never matched, and the suggestion came back unchanged: "revert" becomes "revert".

The fix is to run the replacement against the rest of the text from the match onwards, then cut the tail back off:

var tail = src.slice(h.e),
    out  = src.slice(h.s).replace(new RegExp("^(?:" + r[0].source + ")", flags), r[1]);
var rep  = out.slice(0, out.length - tail.length);

It also keeps the tense now: "reverted on the ticket" becomes "replied on the ticket", not "reply on the ticket".

Lookaheads in a rule table are easy to write and easy to forget about when you reuse the regex somewhere else.

Phrases developers send that land badly abroad

From the rule list, the ones that show up in Slack, PR comments and client email:

You wrote	They read	Try
Kindly revert	Kindly undo?	Please reply when you can
Do the needful	Do... what?	Say the actual ask
I have a doubt	You don't trust me?	I have a question
PFA	?	I've attached
Discuss about	(doubled)	Discuss
Gentle reminder	Passive aggressive	Quick reminder
Today itself	(odd emphasis)	Today
Prepone the call	?	Move the call up

All of these work fine inside India. A reader in Toronto or Berlin just doesn't share them, and a lot of us write for that reader every day now.

If you'd build it differently

The tempting middle ground is rules first, then an LLM pass only on sentences a rule flagged, to catch the contexts our exception list will always miss. It'd cost a fraction of a full rewrite. We haven't built it. If you've done a hybrid like this, I'd like to know how you kept the model from rewriting the rest of the text.

Drafted with help from an AI assistant. Rules quoted are from the live tool.

Using the browser's speech recognizer as a pronunciation judge

WizMantra Academy — Sat, 07 Nov 2026 12:20:59 +0000

Pronunciation scoring APIs charge per request and want your audio on their servers. We teach spoken English to learners in India, mostly on phones, and we wanted a free test that costs us nothing to run.

So we let the browser's speech recognizer play the listener.

The idea: minimal pairs

Vest and west. Thin and tin. Ship and sheep. Each pair differs by one sound, and that's exactly the sound a lot of learners merge.

If you say "vest" and a speech model trained on thousands of speakers writes down "west", a human listener probably hears "west" too. That's the whole test.

Which pairs you get depends on your mother tongue, because the merges are predictable:

var L1 = {
  hindi:   ["vw", "zj", "tht", "thd", "ii"],
  tamil:   ["pb", "kg", "fp", "zj", "thd"],
  bengali: ["bv", "ssh", "zj", "fp", "tht"],
  // 14 languages in all
};

A Hindi speaker gets V/W, Z/J, TH/T, TH/D and short I versus long EE. A Tamil speaker gets P/B and K/G, which a Hindi speaker rarely needs.

One word, six guesses

The trick is maxAlternatives. Most demos read results[0][0] and throw the rest away. We keep all six:

function hearOnce(lang, cb) {
  var rec = new (window.SpeechRecognition || window.webkitSpeechRecognition)();
  rec.lang = lang || "en-IN";
  rec.continuous = false;
  rec.interimResults = false;
  rec.maxAlternatives = 6;
  rec.onresult = function (e) {
    var alts = [];
    for (var i = 0; i < e.results[0].length; i++)
      alts.push(e.results[0][i].transcript.toLowerCase().trim());
    cb(alts);
  };
  rec.start();
}

Then the judge looks at where the target word shows up:

function judge(s, alts) {          // s.w = target word, s.o = the other word in the pair
  if (!alts.length) return "unclear";
  var top = words(alts[0]);
  if (top.indexOf(s.w) > -1) return "ok";
  if (top.indexOf(s.o) > -1) return "merged";
  if (has(alts, s.w)) return "close";
  if (has(alts, s.o)) return "merged";
  return "unclear";
}

If "vest" is the top guess, you said it clearly. If "west" wins, you merged the sounds. And if "vest" only turns up as the fourth guess, the model wasn't sure, and that gets labelled Unclear. The alternatives carry the model's doubt. One transcript can't.

An unclear result gets one retry, with a note showing what was heard.

Choosing whose ears you're testing against

rec.lang changes the listener, and for an accent test that's the most useful setting in the whole API.

Set it to en-IN and the model has heard a lot of Indian English, so it forgives some merges a learner makes. Set it to en-US and it's stricter. The result screen says so: you tested against an Indian listener, switch to US English for a harder check.

For someone preparing for a call with a US client, that's literally the question. Not "is this correct" in the abstract, but "will this listener understand me".

The honest limits

Your audio does leave the device. Chrome's recognizer sends it to Google for processing. The page says nothing reaches WizMantra, which is true, and we don't claim more than that.
Firefox has no SpeechRecognition. There the test flips into ear mode: speechSynthesis plays one word of the pair and you pick which one you heard. If the ear can't split two sounds, the mouth usually can't either.
Laptop mics lie. Fan noise and a cheap mic both produce false merges, so the result tells you to repeat any pair marked Merging before you work on it.
One speaker, one model. It's a screening test. A tutor still has to listen.

In our demos, most Hindi speakers fail V/W first: "vest" comes back as "west" almost every time.

Try it

The test is free and needs no sign-up: English pronunciation test. Pick your first language, press Start, say each word once.

If you've used maxAlternatives for something other than search, I'd like to hear what you did with it.

Drafted with help from an AI assistant. The code above is from the live tool and was checked against it.