Language data
How do you collect Hinglish-English code-mixed speech data?
Updated 2026-08-01 · 4 min read
Short answer
Collect Hinglish-English code-mixed speech by eliciting real conversation rather than translated prompts, then transcribing with a single documented convention for embedded English. Hinglish is the code-mixing case itself. Typical urban customer-support speech is 30-60% English tokens embedded in Hindi grammar, with switching several times per utterance. A usable code-mixed corpus needs conversation topics that naturally trigger switching — work, technology, money, healthcare — speakers from urban and semi-urban pools, and a style guide that fixes whether English tokens are written in Roman or Devanagari + Latin. Without that convention, two transcribers produce two different targets for the same audio and your measured WER becomes meaningless.
Key takeaways
- Monolingual Hinglish corpora under-represent how the language is actually spoken in cities.
- Code-mix transcription convention is a modelling decision, not a clerical one — decide it before collection.
- Elicitation topic controls switch rate more reliably than speaker instructions do.
What code-mixing looks like in Hinglish
Hinglish is the code-mixing case itself. Typical urban customer-support speech is 30-60% English tokens embedded in Hindi grammar, with switching several times per utterance.
Switching happens at the word, phrase and clause level, and it is not random: technical nouns, numerals, days of the week and workplace vocabulary switch to English far more often than verbs or function words. A corpus that ignores this trains a model that transcribes the Hinglish frame correctly and fails on precisely the content words your product needs.
Eliciting natural switching
- Two-party conversation on prompted topics rather than read scripts
- Topic sets chosen to trigger switching: banking, mobile plans, medical appointments, job interviews, online shopping
- Urban and semi-urban speaker mix, since switch rate correlates with education and city exposure
- No instruction to 'speak naturally' — instructions of that kind reliably suppress switching
- Separate channels per speaker so overlap is recoverable at annotation time
Transcription conventions that survive QA
Whichever you choose, publish it with worked examples and QA against it. Whether English tokens are written in Latin or transliterated into Devanagari must be fixed by rule, not left to annotators
| Convention | What it means | Best for |
|---|---|---|
| Native script throughout | English words transliterated into Devanagari + Latin | TTS front-ends and consistent grapheme sets |
| Roman for English tokens | Devanagari + Latin for Hinglish, Latin for English | ASR where English tokens must be recovered verbatim |
| Tagged hybrid | Language tags around switched spans | Research corpora and language-ID training |
Where Hinglish code-mixed data is recruited
Recruit by switching behaviour, not by language proficiency. Screening recordings are used to confirm speakers switch naturally rather than performing one language.
Our collection cities for Hinglish include Delhi, Gurugram, Noida, which gives access to both the high-switch urban pool and the lower-switch semi-urban pool in one programme.
Downstream impact
Teams that add code-mixed data to a previously monolingual Hinglish corpus typically see the largest error reductions on entity-heavy utterances — amounts, product names, dates — which is also where transcription errors cost the most in a deployed product.
Frequently asked questions
Is code-mixed Hinglish data harder to collect?
Not harder to record, but harder to specify. The complexity sits in elicitation design and transcription convention rather than in studio work.
Should English words be written in Devanagari + Latin or Roman?
Both are defensible. Roman preserves the English token for ASR recovery; native script keeps a single grapheme set for TTS. Pick one and apply it corpus-wide.
What proportion of a corpus should be code-mixed?
Match your users. For urban consumer apps, 40–60% of conversational material commonly contains switching; for rural service lines it is far lower.
Can synthetic code-mixing substitute for collection?
Synthetic text can help language models, but it does not reproduce the prosody and timing of a real switch, which is what acoustic models need.
Related reading
Turn this into a dataset specification
Tell us the languages, speaker count and minutes. You get a written scope, a protocol and a fixed price within one working day.