Handling Hinglish in AI Calling — Code-Switching, Mixed Language & Regional Accent Processing
A complete technical and linguistic guide to Hinglish in AI Calling for real estate — the four types of Indian code-switching, ASR language routing strategies, NLU entity extraction across mixed languages, LLM language-mirroring response generation, TTS prosody management, regional accent calibration by city, and a 20-utterance Hinglish evaluation script.
⏱ 13 min read🏢 Technical Architecture & Developer Guides📅 5 July 2026
Hinglish Isn't a Degraded Dialect — It's the Default Mode of Urban India
Hinglish — the fluid, mid-sentence alternation between Hindi and English that characterizes urban Indian speech — is not a dialect or a degraded form of either language. It is a fully productive linguistic system with its own grammar, code-switching rules, and social functions. Among India's urban middle class — the primary buyer demographic for residential real estate in Gurgaon, Noida, Pune, Hyderabad, and Bangalore — Hinglish is the unmarked default mode of professional and semi-formal conversation.
An AI Calling Agent that cannot process and produce Hinglish naturalistically fails in the largest addressable market for Indian real estate. It either responds in English to Hindi-speaking buyers, creating distance and a perception of brand inauthenticity, or responds in pure Hindi to Hinglish-speaking buyers, creating a formal, bureaucratic tone inappropriate for a sales conversation. Both failures reduce qualification rate by 18–26% relative to a Hinglish-capable agent.
The Linguistics of Indian Code-Switching: What the System Must Handle
Type 1: Inter-Sentential Switching (Sentence-Level)
The buyer completes a sentence in one language and begins the next in another: "Haan, 3BHK chahiye. Location kaafi achhi hai. But what about the possession date?" This is the easiest code-switching pattern for AI systems — the language boundary aligns with sentence boundaries that ASR can detect.
Type 2: Intra-Sentential Switching (Mid-Sentence)
The buyer switches language within a single syntactic unit: "Budget ek crore ke aaspaas hai, lekin agar possession ready to move hai toh thoda stretch kar sakte hain." This sentence requires ASR to handle 7 language switches within a single utterance — "budget" (English noun), "ek crore" (Hindi numeral), "lekin" (Hindi conjunction), "possession" and "ready to move" (English terms used as Hindi nouns), "toh" (Hindi particle), and "stretch" (English verb with Hindi conjugation). Most multilingual ASR models trained on clean language-separated data fail on this pattern.
Type 3: Tag-Switching
Hindi or English discourse markers and fillers inserted into the opposite language: "This flat is really good, hai na?", "RERA registered hai, right?", "Yaar, the carpet area is 1,320 sqft only!" These tags function as pragmatic markers, not as language-switch signals requiring a full response-language switch — the AI must recognize this distinction.
Type 4: Domain-Specific Lexical Borrowing
Indian real estate has created a specialized vocabulary where English technical terms are used as Hindi nouns: "Super built-up area kitni hai?", "PLC charges add honge kya?", "RERA number kya hai?" The AI must recognize all of these domain-specific constructions as standard real estate vocabulary — not as exotic switches requiring disambiguation.
ASR Layer: The Language Detection Problem
The first challenge is telling the ASR engine what language to expect. Standard ASR APIs accept a single language code parameter — choosing Hindi-only produces poor English transcription; choosing English-only produces poor Hindi transcription.
Solution 1 — Multi-language ASR (Google STT, Azure): configure the ASR with a primary language and alternate languages so it runs parallel language models and selects the best-fit transcription per utterance segment.
Google STT with alternativeLanguageCodes produces a WER improvement over single-language for Hinglish of 8–14 percentage points.
Solution 2 — Language identification pre-processing: run a lightweight language ID model on the first 1–2 seconds of each utterance before routing to ASR.
async def route_to_asr(audio_chunk: bytes, session: CallSession) -> str:
# Fast language detection (50–80ms)
lang_scores = await lang_id_model.detect(audio_chunk[:16000]) # 2 sec
dominant_lang = max(lang_scores, key=lang_scores.get)
# Hinglish detection: significant scores in both hi and en
if lang_scores.get("hi", 0) > 0.35 and lang_scores.get("en", 0) > 0.25:
return await sarvam_stt.transcribe(audio_chunk) # Best for Hinglish
elif dominant_lang == "hi" and lang_scores["hi"] > 0.75:
return await sarvam_stt.transcribe(audio_chunk)
else:
return await google_stt.transcribe(audio_chunk, lang="en-IN")
Solution 3 — Sarvam AI native Hinglish: Sarvam AI's STT model is trained on actual Indian code-switching data — it handles Hinglish natively without configuration. A single API call routes to Sarvam's code-switching model, eliminating the language routing complexity at the cost of slightly lower English-only accuracy.
NLU Layer: Entity Extraction Across Languages
After transcription, the NLU layer must extract real estate entities from Hinglish text where the same concept may be expressed in multiple forms — "ek crore," "1 crore," "one crore," "100 lakh," "1 crore se 1.5 crore ke beech," "around 1 CR," and "under 1.2 crore" all express the same budget concept in different constructions.
CRORE_MULTIPLIER = 10_000_000 # 1 crore = 10 million
LAKH_MULTIPLIER = 100_000 # 1 lakh = 100,000
def normalize_budget(text: str) -> Optional[int]:
"""Extract and normalize budget amount from Hinglish text."""
# Pattern: number + crore/CR/Cr/करोड़
crore_pattern = r'(\d+(?:\.\d+)?)\s*(?:crore|CR|Cr|cr|करोड़)'
lakh_pattern = r'(\d+(?:\.\d+)?)\s*(?:lakh|L|lacs|lakhs|लाख)'
crore_match = re.search(crore_pattern, text, re.IGNORECASE)
if crore_match:
return int(float(crore_match.group(1)) * CRORE_MULTIPLIER)
lakh_match = re.search(lakh_pattern, text, re.IGNORECASE)
if lakh_match:
return int(float(lakh_match.group(1)) * LAKH_MULTIPLIER)
# Hindi word numerals
hindi_numerals = {
"ek": 1, "do": 2, "teen": 3, "char": 4, "paanch": 5,
"sava": 1.25, "dedh": 1.5, "dhai": 2.5
}
for word, value in hindi_numerals.items():
if word in text.lower():
if "crore" in text.lower() or "कोर" in text:
return int(value * CRORE_MULTIPLIER)
return None
# BHK extraction from Hinglish
def normalize_bhk(text: str) -> Optional[int]:
bhk_patterns = [
r'(\d)\s*(?:BHK|bhk|bedroom|बेडरूम|बीएचके)',
r'(\d)\s*(?:bed|बेड)',
r'(?:teen|3)\s*(?:bedroom|BHK)', # "teen bedroom"
r'(?:do|2)\s*(?:bedroom|BHK)', # "do bedroom"
]
for pattern in bhk_patterns:
match = re.search(pattern, text, re.IGNORECASE)
if match:
val = match.group(1)
if val == "teen": return 3
if val == "do": return 2
return int(val) if val.isdigit() else None
return None
LLM Layer: Generating Natural Hinglish Responses
The LLM must generate responses in Hinglish that match the buyer's code-switching pattern — not generic mixed language that sounds unnatural. The mirroring principle: the AI's Hinglish generation should mirror the buyer's code-switching density. A buyer who uses 70% Hindi / 30% English should receive responses in approximately the same ratio; a buyer who uses 30% Hindi / 70% English should receive English-dominant responses with Hindi discourse markers.
def inject_language_mirror_context(
session: CallSession,
conversation_history: list
) -> str:
# Analyze recent buyer turns for language ratio
buyer_turns = [t for t in conversation_history[-6:] if t["role"] == "user"]
hindi_word_count = sum(
count_hindi_words(turn["content"]) for turn in buyer_turns
)
total_word_count = sum(
len(turn["content"].split()) for turn in buyer_turns
)
hindi_ratio = hindi_word_count / max(total_word_count, 1)
if hindi_ratio > 0.65:
style = "Hindi-dominant Hinglish (use Hindi grammar structure, English only for RE terms)"
elif hindi_ratio > 0.35:
style = "Balanced Hinglish (mix Hindi and English naturally, match buyer's pattern)"
else:
style = "English-dominant with Hindi discourse markers (yaar, theek hai, bilkul)"
return f"LANGUAGE STYLE FOR THIS RESPONSE: {style}"
Example responses by style — Hindi-dominant (buyer spoke 75% Hindi): "Theek hai sir. Carpet area 950 square feet hai aur possession August 2027 mein hai — HARERA registered. Kya weekend mein site visit sambhav hai?" Balanced Hinglish (50/50): "Perfect. So 3BHK ka carpet area 950 sqft hai, possession August 2027 — and it's HARERA registered. Can you visit this weekend?" English-dominant (80% English): "Great, so the 3BHK carpet area is 950 sqft with August 2027 possession — HARERA registered. Would a weekend site visit work for you?"
TTS Layer: Rendering Hinglish Naturalistically
Hinglish TTS requires either Sarvam AI (native) or SSML-tagged Azure/Google (configured). The additional Hinglish-specific consideration is prosody management for mixed-language sentences. In natural Hinglish speech, English words embedded in Hindi sentences are often pronounced with slightly reduced accent — phonologically integrated into the Hindi utterance rather than marked as foreign. The SSML pattern should reflect this using a moderate speech rate for English tokens rather than the full English pronunciation boost.
The rate="95%" on English tokens prevents the prosodic "foreign word" marker that full English pronunciation introduces — making the code-switching sound integrated rather than jarring.
Regional Accent Calibration by City
Beyond Hinglish, regional accent variation requires specific ASR calibration per deployment market:
Market
Primary Language Pattern
Accent Characteristics
ASR Recommendation
Gurgaon / Delhi
Hindi-dominant Hinglish
North Indian retroflex consonants, "r" trilling
Sarvam AI (primary)
Noida / Lucknow
Hindi-dominant, formal
UP/Awadhi vowel lengthening, softer consonants
Sarvam AI + Hindi model
Hyderabad
Telugu-Hinglish
Retroflex stops, vowel-final syllables, Telugu function words
Tamil retroflex, distinctly different "r", vowel harmony
Google ta-IN
Pune
Marathi-Hinglish
Similar to Mumbai, more Marathi phoneme retention
Google mr-IN + Sarvam
Ahmedabad
Gujarati-Hinglish
Gujarati vowel system, aspirated stops
Google gu-IN + Sarvam
Testing Hinglish Capability: The Evaluation Script
Before going to production, run the AI Calling Agent through a Hinglish capability evaluation covering 20 test utterances (5 per type): balanced Hinglish budget statements, Hindi numerals with English real estate terms, English-dominant sentences with Hindi tag markers, tag-switching patterns, and Hindi-language objections.
LLM response language matches buyer language ratio (±15%)
TTS pronunciation of domain terms correct
Response length under 35 words
One question only in response
Frequently Asked Questions
The language mirroring principle handles this naturally — a buyer who speaks 85% Hindi will receive 85% Hindi responses. The additional calibration for Tier 2 markets is to remove English domain terms that the buyer may not know: replace "super built-up area" with "makan ka kul area" when the buyer's language is Hindi-dominant and they have not used the technical term themselves. The AI should match not just the language ratio but also the vocabulary register — technical English real estate terms for buyers who use them; simpler equivalents for buyers who don't.
Build an explicit confusion recovery pattern into the system prompt: if entity extraction from a turn produces no new entities and the conversation state hasn't advanced, the AI should attempt a natural clarification — a bilingual request such as "I didn't quite catch that — could you say that again, or in Hindi? I want to make sure I get this right." The bilingual clarification request covers both language contexts without signaling a hard failure. Limit confusion recovery to 2 consecutive failed turns — after 2, trigger a human escalation rather than continuing to fail.
Yes — Tamil-only and Telugu-only buyers require dedicated language configurations: separate ASR language models (ta-IN or te-IN), separate LLM system prompts written in the target language with instruction language matching, and TTS voices trained on the relevant language. The qualification logic is identical; only the language stack changes. In practice, most real estate buyers in urban Tamil Nadu and Telangana have sufficient English for real estate terminology — budget, BHK, possession, RERA — even when conversational Tamil/Telugu is their preference. Configure the AI for Tamil/Telugu primary with English domain term recognition, and you cover over 90% of the South Indian buyer population.
Deployments that switch from English-only or Hindi-only scripting to full Hinglish mirroring typically see qualification rate improvements of 18–26 percentage points, consistent with the industry pattern of buyers disengaging from AI systems that force them into a single-language mode. The improvement is largest in Hindi-dominant Tier 1 and Tier 2 markets (Gurgaon, Noida, Lucknow, Jaipur) where forcing pure English creates the most noticeable friction, and smaller but still meaningful in English-heavy metro markets (Bangalore, Pune) where the mismatch is less jarring but still measurable.
A single well-trained Hinglish ASR/LLM/TTS stack covers the core code-switching patterns across most North and West Indian markets reasonably well, but regional accent and vocabulary calibration is still required per city — the retroflex consonants and vowel patterns of Hyderabad Telugu-Hinglish differ meaningfully from Mumbai Marathi-Hindi-English or Chennai Tamil-English. Run the 20-utterance evaluation script against a sample of real buyer audio from each new city before full deployment, and recalibrate ASR speech context boosts and TTS pronunciation for city-specific proper nouns (sector names, road names, local project terminology) even when the underlying language stack is unchanged.
Disclaimer: Linguistic analysis, code samples, and ASR/NLU implementation patterns in this article represent technical approaches validated in Indian real estate AI Calling deployments as of Q2 2026. Language processing capabilities of specific ASR, TTS, and LLM providers evolve continuously. Code samples are illustrative and require adaptation to specific deployment environments, languages, and provider APIs. Individual system performance will vary based on audio quality, speaker characteristics, and ambient noise conditions.