Skip to main content
Sonic handles most transcripts as-is. The capabilities below cover cases where you want finer control over mixed-language speech and how written forms are spoken.

Hinglish

Sonic supports code-switching between Hindi and English (Hinglish) in a single generation. Pass the transcript in conventional written form — Devanagari, Latin script, or a mix — and the model switches languages naturally mid-sentence.

Romanized Hindi and Indic text

Sonic reads Hindi and other Indic languages written in Latin script — Hinglish and other transliterated text — and follows romanized transcripts materially better in Sonic 3.6. Write romanized text the way it’s naturally typed, and keep English words in their standard spelling:
Set the language field to the language of the transcript (hi for Hinglish) even when the text is romanized. Quality varies with how scripts are mixed in the transcript: For pure English transcripts, either en or hi works as the language: the more Indian words the sentence carries — names, places, product terms — the more the hi setting pronounces them correctly.
Experiment with these settings to find what sounds best for your content. Both language and normalization are set per generation, so you can vary them transcript by transcript rather than picking one combination for your whole integration.

Worked examples

Accent and reading conventions are independent controls: locale picks the voice’s accent, normalization picks how dates, times, and numbers are read.

Hindi voice, English digit reading

An OTP or confirmation code inside a Hindi transcript should read digit-by-digit the English way: 4821 as “four eight two one” rather than as a Hindi number.

Romanized Hindi with English read-outs

The highest-traffic combination: a Hinglish transcript spoken with a Hindi-Indian accent while dates, times, and digits follow English-Indian conventions.

Locale codes

Sonic 3.6 introduces support for locale codes, which allows you to specify a specific region (not just a language). For example, instead of setting the language to en, you can now be more specific and set the locale to en-GB instead. See API Documentation for more information on the correct usage of locale.

When should I use a locale instead of a language?

A language determines what the model speaks. A locale narrows a language to a region: en is a language, en-GB is a locale. Locale selects region-appropriate reading conventions for dates, times, numbers, and phone numbers. Accent comes from the voice, independently of locale. Most teams can continue to use language for all of their use cases. Using locale is an optional change for more fine-grained control over the TTS generation. Note that for best results, the voice must already support the accent that you want to use! You can use our voice localizer to create voices with specific accents.

Which locales are supported?

See below for a list of supported locales.
Base LanguageSupported Locales
English (en)en-GB, en-US*, en-IN,en-IE,en-ZA,en-NZ,en-SG,en-AU
Spanish (es)es-ES*, es-MX, es-US
French (fr)fr-FR*, fr-CA
Dutch (nl)nl-NL*, nl-BE
Portuguese (pt)pt-PT, pt-BR*
If you do not specify a locale code for these languages, we will use the default language for that locale (marked with an asterisk (*) above).

Turning normalization off

Setting normalization to "off" skips automatic normalization. Turn it off when you pre-normalize text yourself, need a custom read-out for a symbol (for example, # as “number”), or need all-caps words spoken as words rather than spelled out letter by letter. Note that explicit tags and other input validation still work with normalization off: Normalization is set at the request level. If most of a transcript should be normalized but one span shouldn’t, write out that span as it should be spoken (along with any other written forms in the transcript that would have needed normalizing) and send the request with normalization off.