When we started building Queryvine's language detection layer, we ran a series of tests against a popular general-purpose LLM to understand where the baseline was before we built anything proprietary. The results were instructive — not because the general-purpose model was bad at language detection overall (it was quite good on clean, monolingual text), but because the failure modes were concentrated exactly in the scenarios that show up most frequently in real production support queues.
Those failure modes cluster around three patterns: code-switching, transliteration, and dialect ambiguity. I want to walk through what each of these actually looks like in practice, why generic LLMs struggle with them, and how specialized detection is different.
Failure Mode 1: Code-Switching
Code-switching is when a speaker moves between two or more languages within a single message or conversation. In support contexts, this is extremely common — not as an edge case, but as a normal behavior pattern for bilingual speakers, which describes a large fraction of the customer bases of multinational companies.
Consider a message like this, which we see variants of regularly in queues with bilingual Spanish-English speakers: "Hola, I ordered my package hace dos semanas and it hasn't arrived, can you check the status?" That message contains Spanish words ("hola," "hace dos semanas"), English sentence structure, and a mix of both throughout. It is unambiguously a Spanish-primary message from a customer who is comfortable in both languages, and the reply should be in Spanish.
Generic LLMs, when asked to identify the language of this message, frequently return "English" or "mixed" — both of which are wrong in the context of a routing decision. The English structural patterns and English vocabulary trigger the model's English language signal, despite the fact that the customer's dominant support language is Spanish and an English-language reply would represent a quality failure.
What specialized detection does differently: rather than identifying the single predominant language token by token and aggregating, we use a priority-weighting system that identifies the customer's primary language of expression rather than the simple majority language by word count. The presence of any significant Spanish-language content in a message from a customer with a Spanish-language account history is enough to route the message to the Spanish queue, regardless of how much English vocabulary appears alongside it.
We also maintain per-customer language profile data that persists across sessions. A customer whose last eight messages were in Spanish doesn't need to have their language re-detected from scratch on message nine. The detection task becomes confirmation, not identification, which materially reduces misclassification on code-switched input.
Failure Mode 2: Transliteration
Transliteration happens when a customer writes their language using the wrong script — typically writing a non-Latin-script language using Latin characters. This is common in Arabic (called Arabizi or Franco-Arabic), Hindi (romanized Hindi), and Thai (romanized Thai), among others. It's also common in informal contexts generally: customers writing support messages on mobile keyboards configured for Latin input will sometimes write in their language using whatever characters are available rather than switching keyboard layouts.
Arabizi is the case we've worked hardest on. A message like "3ayiz araga3 el mabla3" is Egyptian Arabic — the phrase means "I want to return the amount" — written using Latin characters and numerals (the "3" represents the Arabic letter ع, a common Arabizi convention). Generic LLMs, when asked to identify the language of this string, frequently identify it as noise, English, or sometimes Catalan or Portuguese based on superficial character pattern matching. It is Egyptian Arabic, and the reply should be in Arabic.
Detecting transliterated Arabic requires a lookup layer that understands Arabizi conventions — both the standard numeral substitutions (2=ء, 3=ع, 7=ح, etc.) and the less standardized regional variants. We maintain a transliteration detection module that runs as a first pass before the main language classifier, specifically to catch Latin-script messages that are actually non-Latin-script languages. If the transliteration module fires, the input is converted back to its native script before being passed to the main classifier.
This is not a problem general-purpose LLMs are designed to solve at the routing layer — they're optimized to understand meaning from text regardless of script, but routing decisions happen before the LLM generates a response, and misidentifying the language at routing time means the wrong resolution template, the wrong dialect register, and potentially a response in the wrong language.
Failure Mode 3: Dialect Ambiguity
This is the most nuanced of the three, and it's where we still have meaningful unsolved problems ourselves. Dialect ambiguity occurs when a message is clearly in a particular language family but could plausibly belong to two or more dialect groups, and the distinction matters for resolution quality.
The clearest example from our data: Spanish messages from customers in border regions. A message from a customer in southern Texas may read as Mexican Spanish or as the distinctive border Spanish that incorporates heavy English loan-vocabulary and code-switching patterns that differ from either Mexican or US Spanish. A message from a customer in Buenos Aires versus Montevideo may be nearly identical in vocabulary but differ in voseo patterns and register expectations for formal versus informal second-person address.
Generic LLMs typically resolve dialect ambiguity by picking the dominant-population dialect — if the model is unsure whether something is Mexican or Argentine Spanish, it defaults to Mexican Spanish patterns because there are more Mexican Spanish training examples. This is correct in absolute frequency terms but wrong in the cases where it matters: the tail of dialect variation is where the quality failures concentrate.
What we do: when dialect ambiguity is above a threshold, we look at available context signals beyond the message text itself. The customer's registered address or time zone, the country code of the phone number on file, the previous ticket history and the language of prior responses the customer accepted without complaint, and in some cases the currency of any transactions in the ticket context. These signals are almost never individually definitive, but in combination they usually resolve the ambiguity with high confidence.
When context signals are unavailable or still ambiguous, we default to the more formal register within the Spanish family rather than a specific regional variant. A slightly formal Mexican Spanish response is acceptable to an Argentine customer in a way that an aggressively informal Argentine voseo response would not be to a Mexican customer expecting tú — asymmetric risk, conservative default.
Why This Matters More Than Most Teams Realize
Language detection errors in support contexts are not always immediately visible in resolution metrics. A ticket that was detected as English-primary and routed to an English response — when the customer was actually Spanish-dominant and just happened to write their first message in English — will often result in the customer accepting the English response. The misclassification doesn't register as a resolution failure. But the customer's satisfaction with that interaction is systematically lower, and they're more likely to contact support again about the same issue, generating a second ticket that shows up as a failure on other metrics.
We're not saying that language detection is the only thing that matters in multilingual support automation. Intent classification, resolution quality, tone calibration — all of those are at least as important. But language detection is the prerequisite: everything downstream of a wrong language classification is working on faulty input, and no amount of quality in the classification or response layer recovers from a routing decision that put the wrong language in the wrong queue.
Building specialized detection for these three failure patterns — code-switching, transliteration, and dialect ambiguity — is not glamorous engineering work. There's no foundation model breakthrough involved. It's a combination of lookup tables, per-customer language history, context-signal aggregation, and fallback logic that has been tuned against real ticket data. But it's the difference between a multilingual support system that works for real customer behavior and one that works for the clean-text benchmark.