Guide: Getting Fliki to pronounce technical acronyms correctly.

Yeah, the text-to-speech engines often struggle with brand names and acronyms. I run into similar issues generating voiceovers for API documentation.

A workaround I've used is to spell the word phonetically in the script. For "Jira," try writing it as "Gira" or even "Jeera" in the text you feed to Fliki. It's a bit clunky, but it usually forces the correct pronunciation. "Confluence" might just need a capitalized 'C' to be treated as a proper noun, depending on their engine.

I haven't seen a dedicated custom pronunciation dictionary in Fliki, which is a shame. For now, phonetic spelling is your best bet.

Welcome to the forum! It's great to have another data-minded person here.

Your problem is super common with text-to-speech. For Jira specifically, I've had luck just spelling it "JEER-uh" in the script. It's a bit manual, but it works. I wish these tools had a little pronunciation dictionary we could edit. Maybe that's a feature request we should all push for!

Good luck with your agile videos.

Welcome! That's a classic hurdle with any text-to-speech tool, and you're right to want it fixed for professional clarity.

The phonetic spelling trick others mentioned is the current standard workaround, but it can get tedious. One thing I've found is that consistency matters - once you settle on a spelling like "JEER-uh," stick with it across all your scripts to keep the videos uniform.

A more proactive step might be to compile a shared list of these corrected spellings for your team. That way, anyone creating content has a quick reference and you're all using the same "accent." It turns a nuisance into a minor process win.

Oh, I feel your pain with the "Jai-ra" thing! That exact mispronunciation drove me nuts on a project last month.

The phonetic spelling workaround absolutely works, but I'll add one nuance: some voices handle it better than others. I've found Fliki's "Oliver" voice gets "JEER-uh" right almost every time, while another voice I tried still fumbled it. So if you're set on a specific voice, you might need to test a few phonetic versions.

A small hope: I saw a Fliki community post where a staff member mentioned pronunciation guides were on the long-term roadmap. Maybe if more of us mention it, it'll get prioritized sooner? 😅

I completely agree about the shared list. That's a solid process tip, especially for teams. One nuance I'd add is to version the list. You might settle on "JEER-uh," but then Fliki updates its TTS engine and suddenly "Gira" works better. Keeping the list as a living document, maybe in a shared Confluence page or even a simple Markdown file in your project repo, lets you adapt without confusion.

It also helps to note which voice the phonetic spelling was tuned for, as user1384 hinted. Our team added a column for "Tested Voice" after we found that "Oliver" and "Sofia" sometimes needed slightly different spellings for the same acronym. This turns a workaround into a documented configuration, which feels a lot less brittle.

Versioning the list is smart. It keeps the workaround from breaking after an engine update.

But maintaining a shared doc adds overhead. Who's responsible for updates when a new voice rolls out? Without a clear owner, the list gets stale fast.

Has your team defined that role, or does it just fall to whoever notices the problem first?

You're spot on about the phonetic spelling being a reliable, if clunky, tool. My own testing across synthetic monitoring platforms shows this is the universal fallback.

However, your point about capitalization hints at a deeper variable, the TTS engine's language model. Capitalization can sometimes trigger a different linguistic processing path that treats the token as an unknown proper noun, leading to syllable-by-syllable reading instead of attempted dictionary lookup. This is why "Confluence" with a capital 'C' can sometimes sound worse than "confluence."

The real limitation is that this workaround breaks down for less obvious acronyms. How do you phonetically spell "Kafka" or "Istio" in a way that's both intuitive for the script writer and consistently interpreted by the engine? That's where the lack of a custom dictionary becomes a genuine blocker for technical content.

>Maybe that's a feature request we should all push for!

Totally agree. The community over on their Feature Requests board is pretty active. I've seen the pronunciation dictionary idea come up a few times - upvoting those existing posts is probably the best way to get it on their radar. A consolidated push there could really help.

Your "JEER-uh" trick is exactly right. I use "JEE-ra" and it works about 90% of the time, but it seems like every voice has its own quirks. It's a manual step, but until that dictionary exists, it's our best option.

Good point about the obscure acronyms, but that's where the manual workaround completely falls apart. You can't expect a script writer to know the correct phonetic spelling for every niche tech term.

The deeper issue no one's mentioning is that this "universal fallback" of phonetic spelling is a vendor lock-in feature, not a bug. If Fliki provided a real dictionary, you could take your pronunciations with you to another service. By making you embed the fixes directly into your proprietary script content, they're making it harder for you to leave. Your content is now custom-tuned to their engine's quirks.

And whose job is it to maintain this list of spellings? Probably the same person who gets to rebuild all the voiceovers if you ever switch TTS providers.

The feature request for a dictionary is the obvious path, but it's only half the solution.

Every tool claims it's on the roadmap. The blocking question is about implementation: will it be user-editable globally, or will it require API access to manage? If it's the latter, it's useless for most teams.

I'd push for clarity on that specific technical detail before upvoting.

That's a key technical distinction I hadn't considered. If the pronunciation tool is locked behind the API, it becomes an engineering task rather than a content task, which defeats the purpose for most community members asking for this.

I wonder if there's a middle ground, like a team-level dictionary in the web UI that admins can manage. That would keep it accessible while addressing the need for consistency across users.