Deepgram Nova-3 Adds Right-to-Left Language Support

Deepgram's Nova-3 model now includes native support for four right-to-left languages: Arabic, Hebrew, Farsi, and Urdu. This isn't a wrapper or post-processing fix - it's baked into the model itself. The update addresses a real gap: RTL languages require different tokenization, word ordering, and acoustic handling than left-to-right models.

This matters because RTL languages account for roughly 300+ million native speakers globally. Until now, builders working with these languages either had to chain multiple services, accept degraded accuracy, or build custom workarounds. Nova-3 consolidates that into a single API call.

• Arabic, Hebrew, Farsi, and Urdu now run natively on Nova-3
• Model handles RTL text flow and acoustic characteristics without preprocessing
• Part of broader Nova-3 multilingual improvements rollout

If you're shipping products in Middle East, North Africa, or South Asia, language support directly impacts your TAM and go-to-market velocity. Before this, you'd evaluate speech-to-text vendors and hit a wall: either accept English-only accuracy or piece together multiple APIs. That adds latency, cost, and operational complexity.

For builders specifically: this reduces your decision tree. You can now choose Deepgram for unified multilingual coverage without sacrificing RTL language quality. That's a 1-API solution instead of 2-3. More importantly, it means you can expand regional products without rearchitecting your speech pipeline.

The technical implication is cleaner. RTL languages have fundamentally different phonetic and grammatical structures - Hebrew fricatives don't map to Arabic emphatics, Farsi has distinct vowel patterns. Native model support handles these differences at inference time, not as an afterthought.

• Reduces API sprawl - one vendor instead of multi-vendor workflows
• Eliminates RTL preprocessing overhead and custom tokenization logic
• Lowers latency by cutting out intermediate transformation steps
• Enables faster market entry for MENA and South Asia products

Adoption is straightforward if you're already on Nova-3. The model selection logic doesn't change - you pass the same API call, and Deepgram's language detection handles RTL identification. If you're currently using a different Deepgram model or competitor, migration is a parameter swap in your inference code.

Key consideration: test your specific use case. RTL support in Nova-3 doesn't guarantee equal accuracy across all four languages or all domains. Arabic dialect variation (Egyptian vs. Gulf vs. Levantine) still matters. Farsi and Urdu have smaller training datasets than English or Mandarin. Run benchmarks on your actual audio before rolling out to production - especially if you're processing user-generated or noisy audio.

• Verify language auto-detection works for your audio samples
• Benchmark accuracy on your specific domain and dialect mix
• Test latency impact in your existing inference pipeline
• Update documentation and API client if you're managing SDK versions
• Plan staged rollout by region if supporting multiple RTL markets

This update signals Deepgram's commitment to non-English markets, which is increasingly table-stakes for speech providers. The timing matters: as AI adoption spreads globally, English-first tools become a liability, not a feature. Deepgram is explicitly removing that constraint.

The focus on RTL specifically is pragmatic. These languages weren't afterthoughts - they require distinct model architecture. By shipping RTL support natively, Deepgram is positioning against competitors who treat non-English as bolt-on functionality. That's a different technical and go-to-market strategy.

For builders, this lowers the friction for international expansion. You can now build and scale speech features across multiple regions without fragmenting your infrastructure. That enables product strategies previously blocked by tooling limitations.