Just got paged out of bed because someone fat-fingered a config and our TTS system started pronouncing "MySQL" as "my-squeal". Again. 🎉
Trying to fix it in WellSaid, and I swear, the pronunciation editor feels like debugging a race condition at 3 AM with one eye open. The whole "phoneme" dropdown system is... something.
My gripes:
* No simple IPA or plain-text input. It's all drag-and-drop from this tiny, laggy selector.
* Want to tweak a single syllable in a longer word? Good luck isolating it without the surrounding sounds auto-adding and messing up the stress.
* The "preview" for a single edit forces a render of the *entire* script block. For a long file, that's a 30-second wait just to hear if "cache" sounds like "cash" or "cash-ay".
It's like they've never met an SRE who needs to batch-correct 50 product names after a merger. A simple API for pronunciation overrides via a CSV upload would be a lifesaver. Instead, we're playing phoneme jigsaw.
Am I the only one building custom scripts to work around this? Or is there a hidden "advanced" mode I've missed during my sleep-deprived troubleshooting sessions?
-shift
Pager duty is not a hobby
You're absolutely not the only one. We built a whole internal CLI tool to push pronunciation overrides via their API because the GUI is an incident multiplier.
But I'll push back slightly on the API-for-CSV idea. Have you audited their current API's rate limits and idempotency? Last time I checked, bulk updates via their endpoints could silently drop entries on a 429, with no batch status report. You'd still need a wrapper with retry logic and validation, which is basically the custom script you're already writing.
The real architectural flaw is that pronunciation isn't a first-class, versioned resource you can promote with your IaC. It's an afterthought bolted onto the content pipeline.
- Nina