Translating Code Switched Text: 3 Research Checks for Translators

For mixed-language input, the strongest starting point is a large language model like GPT-4, paired with targeted data augmentation and a switch-aware evaluation pass. Human translators still make the call that models cannot: whether to preserve, adapt, or unify each switch based on audience and purpose. Test everything with switch-point checks plus human scoring for semantic faithfulness, not BLEU alone.

TL;DR:

• Large language models like GPT-4 can handle multiple code-switching phenomena better than traditional systems, especially on high-resource language pairs.
• Effective training techniques include sentence concatenation, synthetic data generation, and target-side denoising, which improve model robustness at boundaries.
• Choosing to preserve, adapt, or unify switches depends on audience, genre, and client instructions; annotation before translation enhances consistency.
• Evaluation requires human judgment of pragmatic function preservation and specific stress tests beyond surface-level metrics like BLEU.
• Speech translation faces unique challenges such as phonetic variations and segmentation errors, requiring specialized pipelines and extra quality control.

Table of Contents

• What Code-Switching Actually Is (and Why Translation Breaks Without This Distinction)
• What Recent Research Says About Model Performance on Mixed-Language Text
• Building a Translator Workflow for Mixed-Language Text
• Data and Prompting Recipes That Improve Code-Switched Output
• Handling Code-Switched Speech: What Changes for Audio
• How to Test Whether Your Translation Actually Works
• Datasets, Benchmarks, and Tools to Start Experimenting
• Why Grammar and Meaning Get Slippery When Languages Mix Mid-Sentence
• How Cross-Lingual Embeddings Change What Models Can Actually Learn
• What the Research Actually Tells Us to Prioritize
• When a Real-Time Translation App Fits Better Than a Manual Pipeline
• Sources
• FAQ

What Code-Switching Actually Is (and Why Translation Breaks Without This Distinction)

Code-switching is not one phenomenon. It is at least three, and each breaks a translation pipeline differently.

Intrasentential switching happens inside a single clause, like "Voy al store para comprar leche." Intersentential switching happens across sentence or turn boundaries, where a speaker finishes a thought in one language and starts the next in another. Insertional switching is narrower still: a single borrowed word or fixed phrase dropped into an otherwise monolingual sentence, often a brand name, an idiom, or a cultural term with no clean equivalent. Linguists also talk about a matrix language (the grammatical frame of the sentence) and an embedded language (the inserted material), a distinction that matters because most translation errors cluster at the boundary between the two.

None of this is random. Switches carry social weight the translation has to survive intact.

• Identity signaling — a switch into a heritage language can mark belonging or solidarity with a listener.
• Emphasis and contrast — speakers often switch to underline a point their base language cannot land as sharply.
• Register shift — moving between formal and informal registers within one conversation, sometimes via language choice itself.
• Quotation and reported speech — repeating what someone else said in the language they actually used.
• Topic-triggered switching — certain subjects (work, family, technical topics) pull a bilingual speaker toward whichever language they learned that domain in.

The technical side is just as unforgiving. Language identification (LID) has to flag which language each token belongs to before any translation model can act correctly, and LID models trained on monolingual data routinely misfire on short embedded spans. Segmentation errors compound the problem: if a system cuts a sentence at the wrong boundary, it can strand half a switch on either side of the cut. And plenty of production models still choke on unexpected language tokens, either mistranslating them, deleting them, or leaving them untouched when they should have been rendered. Any translation strategy for code-switched text has to solve LID, segmentation, and token-level ambiguity before pragmatics even enter the conversation.

What Recent Research Says About Model Performance on Mixed-Language Text

The clearest recent signal comes from a 2024 evaluation across seven datasets: GPT-4 and GPT-3.5 showed strong robustness on code-switched translation, often matching or beating supervised neural machine translation (NMT) systems and commercial engines, particularly on high-resource language pairs. That is a meaningful shift from a few years ago, when supervised NMT models trained on clean, monolingual parallel data tended to collapse the moment a switch appeared mid-sentence.

GPT-4 in particular held up under heavier code-switching distributions, the kind where switches happen multiple times per sentence rather than once per paragraph. That robustness doesn't mean the model understands the pragmatic reason for the switch. It means the model's broader training exposure gives it more contextual scaffolding to guess the right output token, even when the input jumps languages unpredictably.

Multilingualism is not just noise for machine translation. It can act as semantic enrichment, and treating code-switching as an opportunity, not a defect, changes how you design evaluation and data pipelines from the start.

What actually moves the needle for supervised systems:

• Sentence concatenation during training, where two (or more) sentences in different languages are joined, teaches models to expect a language boundary mid-sequence. Research on enabling code-switched MT found that training on two-sentence concatenation generalizes well to many-sentence inference, so you don't need to simulate every possible switch density to get the robustness benefit.
• Synthetic code-switched data, generated by splicing translated fragments into monolingual parallel corpora, can train systems that outperform general multilingual models on CSW-specific test sets.
• Noise augmentation and target-side denoising sharpen the model's attention patterns around language boundaries, which is part of why concatenation training transfers so well to inference-time inputs it never explicitly saw.

One caveat from that synthetic-data research matters for anyone designing evaluation later: models trained with pre-translated target fragments learn a near-deterministic copying behavior. They start reproducing the exact target-language chunk they saw during training rather than generating a fresh translation. That is useful when you want literal fidelity for names or fixed phrases. It is a problem if your test set rewards creative or context-sensitive rendering, because the model will just paste the memorized fragment regardless of context.

On the prompting side, in-context learning offers a cheaper lever than retraining. The same 2024 evaluation tested a Clustering-Max Switching (CMS) strategy for selecting few-shot exemplars, choosing examples with high switch-point density rather than picking them at random. CMS-selected prompts produced measurable BLEU gains over naive exemplar selection, which tells you something practical: if you're prompting an LLM for CSW translation, don't hand it easy, mostly-monolingual examples as your few-shot context. Feed it examples that switch as often, and in the same patterns, as the text you actually need translated.

Pivot translation, routing a code-switched sentence through a third language (usually English) before reaching the target, still shows up as a fallback for low-resource pairs with no direct parallel data. It works reasonably well for single switches but degrades fast on double pivots, where errors introduced in the first hop compound in the second. Treat pivoting as a stopgap, not a strategy.

Building a Translator Workflow for Mixed-Language Text

Every code-switched sentence forces a choice before you type a single word of output: preserve the switch, adapt it into the target language's own bilingual conventions, or unify it into one language entirely. Getting that decision wrong is the single biggest source of complaints from bilingual readers, more than any lexical error.

1. Decide preserve, adapt, or unify based on three questions. Who is the audience (bilingual readers who will notice a flattened switch, or monolingual readers who need one language throughout)? What is the publication genre (literary dialogue that trades on code-switching as style, versus a technical manual where clarity wins)? What did the client actually ask for (a faithful rendering of voice, or a clean read in one language)? Preserve when the switch is doing narrative or identity work a monolingual reader can still infer from context. Adapt when the target language has its own established bilingual convention for the same social function. Unify only when the client explicitly wants a single-language deliverable and understands that some texture will be lost.

2. Annotate before you translate, not after. Mark each language span, tag the speaker's role in the switch (initiator, respondent, narrator), and note the apparent function (emphasis, quotation, identity marker, topic shift). This turns a subjective judgment call into a reviewable decision trail, which matters enormously when a client or editor questions why a switch was rendered a certain way.

3. Build the switch into your post-editing pass, not just your first draft. If you're editing an MT draft rather than translating from scratch, treat every switch point as a mandatory checkpoint. MT systems, even strong ones, tend to smooth over switches in ways that erase their social function, translating everything into one flat register.

4. Get sign-off on borderline cases before final delivery. Some switches are genuinely ambiguous even to a fluent bilingual reader. Flag those for the client or a second linguist rather than guessing silently.

Pro Tip: Keep a running glossary of how your client or publication handles recurring switch types (brand names, endearments, professional jargon) across projects. Consistency across a body of work matters more to bilingual readers than any single clever rendering.

Practitioner accounts consistently frame switches as purposeful social signals rather than noise to be cleaned up, which is the mindset that should anchor every one of these decisions.

Data and Prompting Recipes That Improve Code-Switched Output

If you're training or fine-tuning a supervised NMT system, three augmentation techniques consistently show up in the research with real, testable payoff.

• Two-sentence concatenation. Join pairs of sentences in different languages during training, separated by a natural boundary. This alone generalizes to inputs with many more switches than the model ever saw during training, which makes it one of the cheapest robustness gains available.
• Random insertion of translated segments. Splice a translated phrase or clause into an otherwise monolingual sentence, mimicking insertional switching, to teach the model that a language boundary can appear anywhere, not only at clause edges.
• Target-side denoising. Add controlled noise to target sequences during training so the model learns to recover clean output even from a messy or partially mixed source, which sharpens its attention around switch points specifically.

Concatenation combined with denoising produces sharper attention patterns in Transformer models around language boundaries, which is a large part of why a training regime built on short concatenated examples transfers so cleanly to inference-time inputs with far more switching than the training data ever contained.

For LLM prompting, the CMS exemplar-selection strategy described earlier deserves a second look here from a builder's perspective: cluster your few-shot examples by switch-point density and select from the highest-density cluster, rather than sampling exemplars at random from your example bank. It costs nothing beyond a preprocessing step and consistently outperforms naive selection.

Pivot translation still has a place, but only under specific conditions. Pivot to English when you lack direct parallel data for the language pair and English resources for both languages are strong. Pivot to the matrix language (the grammatical frame of the sentence) when the embedded language is the one with sparse resources, since this keeps the sentence's syntactic backbone intact through the translation. Avoid double pivots (language A to English to language B) whenever a more direct path exists. Each hop introduces its own error rate, and those errors don't cancel out. They stack.

Language identification and copying strategy deserve explicit rules rather than default model behavior. Copy tokens verbatim when they're proper nouns, brand names, or fixed technical terms with no target-language equivalent. Translate when the embedded material is a full clause carrying independent meaning. And build LID confidence thresholds into your pipeline so low-confidence spans get flagged for human review instead of silently mistranslated.

Handling Code-Switched Speech: What Changes for Audio

Speech adds failure modes text never has to deal with, and most of them start before translation even begins; for effective solutions, consider structured multilingual TTS production pipelines that handle code-switched audio robustly.

Short switches, a single word or two dropped mid-sentence, are notoriously hard for automatic speech recognition (ASR) to catch, because acoustic models trained predominantly on one language tend to force the closest phonetically similar word in that language rather than recognizing the switch at all. Code-switched phonetics compound this: bilingual speakers often pronounce borrowed words with accent features from their dominant language, which throws off models expecting "clean" pronunciation in either language. Diarization and segmentation errors, misattributing a switch to the wrong speaker or cutting a segment at the wrong boundary, then propagate straight into the translation layer.

Pipeline choice matters more here than in text translation. A cascade pipeline (ASR, then LID, then MT as separate stages) gives you visibility and control at each step, which makes debugging easier and lets you swap in a stronger LID model without retraining the whole stack. End-to-end systems, which go directly from audio to translated text, can avoid some error propagation between stages but are harder to audit when something goes wrong and typically need more code-switched training data than cascade systems to reach comparable performance.

A few practical fixes consistently help, based on reports testing Whisper-style ASR systems on code-switched audio:

• Timestamp every detected switch point in the transcript, not just the language boundaries you're confident about.
• Prefer ASR models with documented multilingual training exposure over ones fine-tuned narrowly on a single language pair.
• Add post-ASR language tags before handing the transcript to the MT stage, rather than letting the MT model guess language identity from context alone.
• Budget extra QA time for diarization review whenever multiple speakers switch languages independently, since errors here are easy to miss on a first pass.

Anyone building a live conversational product on top of this pipeline runs into the same segmentation and LID tradeoffs; see how switching languages mid-conversation plays out in a real chat interface for a concrete look at where these tradeoffs surface for end users.

How to Test Whether Your Translation Actually Works

Standard automatic metrics were not built for this problem, and treating them as sufficient is the fastest way to ship a translation that technically scores well and reads badly to a bilingual audience.

BLEU and chrF measure surface overlap with a reference translation. They can't tell you whether a switch's social function survived, whether a quotation kept its original speaker's voice, or whether a translator correctly chose to preserve a switch that the reference happened to unify. A translation can score reasonably on BLEU while completely erasing the pragmatic reason a speaker switched languages in the first place. That gap is exactly why research on Vietnamese-English code-switched input found that human evaluation sometimes rates CSW-input translations higher on semantic faithfulness than monolingual-input translations, a result automatic metrics alone would never surface, and one that also flagged persistent syntactic issues (interrogative structures in particular) that human raters caught and automatic scores missed.

A workable evaluation suite needs three layers.

Beyond the table, build three specific stress tests into your suite. Run inter-sentential CS checks by feeding the model pairs of sentences in different languages joined at a natural boundary, then verifying the output correctly separates and translates each half. Run missed-segmentation checks by deliberately mis-cutting a sentence mid-switch to see whether the model recovers or produces garbage. And run many-to-one concatenation tests, feeding progressively longer multi-language chains to see where robustness degrades, since the concatenation research shows this is exactly where training-time shortcuts (like two-sentence concatenation) either hold up or fall apart under real inference loads.

Human raters should score on a simple three-part rubric every time: semantic faithfulness (did the meaning survive), pragmatic function preservation (did identity, emphasis, or register signaling survive), and fluency (does it read naturally in the target output, whether that output preserves, adapts, or unifies the original switches).

Datasets, Benchmarks, and Tools to Start Experimenting

You don't need a custom corpus to start testing any of this. A handful of established resources cover most language pairs a working translator or technologist is likely to need.

• SemEval shared tasks on code-switching have produced annotated datasets across several language pairs, useful as a starting benchmark for both MT quality and LID accuracy.
• Flores-derived synthetic sets, built by splicing Flores parallel sentences across languages, give you a controllable way to generate code-switched test data at whatever switch density you want to stress-test.
• CanVEC and comparable community-built corpora offer naturally occurring code-switched text rather than synthetic constructions, which matters if your production use case involves organic speech or chat rather than curated writing.

On the tooling side, group your stack by function rather than by brand. For LLM experimentation, any current-generation model with strong multilingual pretraining is worth testing against the CMS prompting strategy described earlier. For NMT training, standard sequence-to-sequence toolkits that support custom data augmentation pipelines let you implement concatenation and denoising without building infrastructure from scratch. For ASR, prioritize models with documented multilingual and code-switching evaluation results over ones benchmarked only on monolingual speech. For LID, test any candidate model specifically on short embedded spans (two or three tokens), since that's where most production LID systems quietly fail.

Start small: take one Flores-derived synthetic set, run it through a current LLM with CMS-selected few-shot examples, and score the output against the three-layer rubric above before you scale to a full production pipeline.

Why Grammar and Meaning Get Slippery When Languages Mix Mid-Sentence

Code-switched sentences frequently break grammatical rules that hold in either language alone. A speaker might follow the syntax of the matrix language while inserting a noun phrase that carries the embedded language's grammatical gender or plural marking, creating a hybrid structure neither monolingual grammar fully accounts for. Translation models trained on clean, single-language syntax trees have no reliable template for this, which is exactly why supervised NMT historically struggled here more than LLMs with broader exposure.

Semantic ambiguity compounds the problem. A single switched word can carry connotations, idioms, or cultural weight that exist only in its source language, with no direct equivalent in the matrix language surrounding it. A translator (or model) has to decide whether to render the sense, the literal word, or some hybrid, and each choice changes what the sentence actually communicates. Homophone and near-homophone collisions across languages add another layer: a word that's unambiguous in isolation can become genuinely unclear once a listener has to decide, mid-sentence, which language's meaning applies.

This is why switch-point checks matter more than blanket accuracy scores. Grammatical and semantic ambiguity in code-switched text isn't a rare edge case. It's close to the default condition, and any translation workflow that doesn't budget specific attention for it will systematically underperform on exactly the sentences that matter most to bilingual readers.

How Cross-Lingual Embeddings Change What Models Can Actually Learn

Cross-lingual embeddings map words and phrases from different languages into a shared vector space, so that semantically similar terms end up geometrically close regardless of which language they came from. For code-switched translation, this matters because it gives a model a way to relate an embedded-language token to its matrix-language context without needing to have seen that exact combination during training.

Models built on strong cross-lingual embeddings tend to generalize better to switch patterns they weren't explicitly trained on, because the embedding space itself already encodes cross-lingual similarity before the translation task even starts. This is part of why large multilingual language models, trained on enormous cross-lingual corpora, show the robustness advantages described earlier: their embedding layers have effectively pre-learned relationships between languages that a narrower supervised NMT system, trained on a single parallel corpus, never gets exposed to.

The tradeoff is that embedding quality varies sharply by language pair and resource level. High-resource pairs (Spanish-English, French-English) benefit from embedding spaces trained on enormous amounts of parallel and comparable data. Low-resource pairs get a much thinner embedding signal, which is exactly where pivot translation and synthetic data augmentation earn their keep, compensating for an embedding space that hasn't seen enough cross-lingual examples to generalize well on its own.

What the Research Actually Tells Us to Prioritize

The gap between what gets published and what translators actually need is narrower than it used to be, but it hasn't closed. Most CSW research still optimizes for automatic metrics on curated benchmarks, while the hardest real-world cases are messy speech, ambiguous switches, and clients who can't articulate whether they want preservation or unification until they see a draft they dislike.

My honest read: LLMs have earned their place as a first-pass tool for code-switched translation, not because they understand pragmatics, but because their broad training exposure makes them less brittle at language boundaries than purpose-built NMT systems trained on cleaner data. That robustness is a floor, not a ceiling. Every output still needs a human decision layer on top.

Three experiments worth running this week: test CMS-style exemplar selection against your current prompting setup on a sample of real switch-heavy text; build a five-sentence concatenation stress test to see where your current pipeline degrades; and run one batch of output past a bilingual rater using the three-part faithfulness rubric before you trust any BLEU score again.

— Poul

When a Real-Time Translation App Fits Better Than a Manual Pipeline

Everything above assumes you're building or auditing a translation pipeline from research components. If you're the one actually having the mixed-language conversation, in a chat with family, a client call, or a group thread that drifts between two languages mid-message, Oralingo skips the pipeline entirely and handles the switch for you in the moment.

Oralingo translates messages before they're displayed, so a conversation that jumps between languages mid-thread doesn't force you to stop and manually flag which language each part belongs to. Its hands-free voice mode extends the same idea to spoken conversation, useful when a call naturally slides between two languages the way real bilingual speech does. With support for over 100 languages and end-to-end encryption on every conversation, it's built for exactly the kind of live, unpredictable language mixing that formal MT pipelines still struggle with.

Oralingo suits everyday conversational use well: chatting with a multilingual family member, coordinating with an international colleague, or navigating a friendship that naturally switches languages. For anything requiring publication-grade nuance, literary dialogue, legal documents, or marketing copy where every switch is a deliberate stylistic choice, consider pairing the output with a human review workflow. If you want to see how it handles a live mixed-language thread, try Oralingo and start a conversation in whichever languages you actually switch between.

Sources

• Checks and Strategies for Enabling Code-Switched Machine Translation
• Code-switching input for machine translation: a case study of Vietnamese–English data

FAQ

Can code-switching be used by anyone, or is it specific to certain speakers?

Code-switching is a normal bilingual and multilingual behavior, not restricted to any one group. Anyone who speaks more than one language and moves between them, whether for identity, emphasis, or convenience, is code-switching, and the linguistic mechanics described throughout this article apply the same way regardless of who's speaking.

What is code-switching in bilingualism?

In bilingualism, code-switching is the practice of alternating between two or more languages within a single conversation, sentence, or even a single phrase. It typically serves a social or pragmatic purpose, such as signaling identity, adding emphasis, or matching the language a topic was originally learned in, rather than reflecting a gap in vocabulary.

Can you give examples of code-switching?

Common examples include a bilingual speaker saying "I'm so tired, pero necesito terminar esto" (intrasentential switching), answering a question in one language after being asked in another (intersentential switching), or dropping a single untranslated term like a brand name or idiom into an otherwise monolingual sentence (insertional switching). Other patterns include switching languages to quote what someone else actually said, or shifting language mid-conversation when the topic moves into a domain (like work or family) the speaker associates with a specific language.

Is code-switching the same as Spanglish?

No. Spanglish is one specific, named variety of code-switching between Spanish and English, often with its own recurring lexical blends and borrowed structures, while code-switching is the broader linguistic phenomenon that occurs between any two or more languages a speaker knows. Every instance of Spanglish is code-switching, but code-switching happens across countless language pairs well beyond Spanish and English.

Recommended

• 5 Steps to Polite Tone Translation With Copy and Paste Prompts
• AI Chat Translation Accuracy: What Research Shows
• How to Preserve Formatting in Translation for Chat and Voice
• How to Give Cross-Language Feedback That Actually Lands