What is Code-Switching Speech?
Speech that mixes two or more languages inside a single utterance (Hinglish, Spanglish, Taglish), used for recognition in real spoken settings.
Code-switching speech is audio in which a speaker moves between two or more languages inside a single utterance or conversation. It is not the same as multilingual speech, which is several languages inside one project; here the switching is inside the speech itself.
The phenomenon is normal rather than exceptional. It is the default register for large bilingual populations, and it concentrates in exactly the markets where voice products are growing fastest. A model that treats it as an edge case will fail for a large share of its users.
The technical difficulty is the switch point. Inside one sentence a speaker can change language at a word boundary, and identifying where that happens is what makes the data expensive to annotate and valuable to train on.
What buyers get wrong
The switch point is the hard part, where language A gives way to B inside a sentence, different annotators can place it several words apart. The guideline has to be fixed before annotation starts.
The specification detail that decides everything
Whether annotation marks word-level switch points or only tags the language of the whole utterance. The workload differs by a multiple.
This is the line item that most often separates a dataset that works from one that gets re-ordered. It belongs in the specification before production starts, not in the delivery review.
How we source it
We do not hold inventory in this category. A requirement comes in, we match it to a producer who can meet the specification, and we agree the quality bar with both sides before recording begins. A pilot batch goes first so misalignments surface early.
Scenarios this covers
Buyers rarely ask for a category by name. They describe a situation, and the situation is what tells us whether this category is the right one. If yours is in the list, name it in the brief and it goes straight into the specification. If it is not, describe it anyway, because it usually means the requirement sits in a neighbouring category.
What good Code-Switching Speech looks like
Code-switching data is defined by its annotation decisions rather than by its audio. Five of them decide what the corpus can be used for.
-
A transcription policy for the switched material
Whether switched words are written in their own script, transliterated into the matrix language, or written as spoken. Each produces a different corpus and they are not interchangeable.
-
Switch point granularity
Word-level boundaries, or a tag on the whole utterance. The annotation workload differs by a multiple, and so does what the data supports.
-
Density that is declared
Natural switch density or a deliberately balanced sample. Both are defensible; leaving it unstated is not, because the answer determines who gets recruited.
-
A guideline that names the hard cases
Proper nouns, established loanwords, numerals and single-word switches are where annotators disagree, and a guideline that does not address them produces data that cannot be used consistently.
-
Matrix language identified per utterance
Which language the sentence is built on is a separate fact from which languages appear in it, and a model needs both to learn the switch rather than merely tolerate it.
Public datasets in this category
These are openly documented resources, not products we sell. Each one covers part of the category, and knowing where each stops is usually what decides whether a project needs a collection of its own.
-
SEAME
A Mandarin-English code-switching corpus from Singapore and Malaysia, with a switch-point annotation. It is one of the few corpora that marks where the switch happens, which is what most code-switching work needs.
-
LinCE benchmark
A multilingual benchmark suite for code-switching across several language pairs, mostly text and partly speech. It standardises evaluation, which is its main contribution, and it is not a training-scale resource.
-
ASCEND
A Mandarin-English conversational corpus collected in Singapore, natural rather than scripted. Natural delivery is the point, and it covers one language pair and one community.
-
Why most language pairs have nothing
Public code-switching resources exist for a handful of pairs, mostly Spanish-English and Mandarin-English. For the rest, the corpus has to be collected, and the recruitment is the hard part because it needs genuinely bilingual speakers.
Questions to ask a supplier
Questions that separate a supplier who has annotated code-switching from one who has annotated bilingual audio.
- How are switched words transcribed, and is that rule written in the guideline?
- Are switch points marked at word level, and what is the measured annotator agreement on them?
- How are proper nouns and established loanwords handled?
- Was the switch density natural or designed, and how was it measured?
- Is the matrix language labelled per utterance?
The vague answer here concerns whether the switching is real. A supplier who says the corpus contains code-switching without describing how the switches were elicited may have concatenated two monolingual recordings, which produces audio that no speaker ever produces. Ask for samples at the switch point, because that is where the difference is audible.
A verifiable answer states the language pairs, the switch direction, the switch rate per utterance and the syntactic position of the switches. Switches happen at word, phrase and clause boundaries and they behave differently at each. A corpus that records only the pair, and not the position, cannot be used to study the phenomenon it was bought for.
Technical attributes
The items below are the ones a specification can hold a producer to, and the ones that decide whether a delivery is usable for training rather than only present.
| Language pair or set | Named, with the matrix language identified |
|---|---|
| Switch density | Measured and declared, natural or designed |
| Switch point annotation | Word level, utterance level, or none |
| Transcription policy | Own script, transliterated, or as spoken |
| Loanword handling | Documented rule, with a word list where the boundary is community-specific |
| Delivery format | Audio with per-utterance language and switch annotations |
The switch position column decides what the corpus can train, and it is the column most often missing entirely. Intra-sentential switching, where the languages change inside one grammatical unit, is the hard case and the reason most buyers want this category. A corpus of inter-sentential switching, where whole sentences alternate, is much easier and much less useful.
The values come from the community you are building for. The pairs, the directions and the switch rates differ between populations that both speak the same two languages. A corpus collected from one diaspora does not transfer to another, so the specification has to name the population rather than the language pair.
A mistake here produces a corpus that looks correct and trains the wrong thing. If the switch positions are not labelled, the model learns to detect language boundaries rather than to handle speech across them, and the failure appears as errors concentrated at exactly the switches the corpus was bought for.
How Code-Switching Speech is collected
The guideline is written before recording, because recruitment depends on it.
- Language pair and matrix language defined. Which languages, in which direction, and which one carries the sentence structure.
- Density decision taken. Natural density means recording ordinary conversation; a balanced sample means recruiting speakers who switch often and prompting topics that provoke it.
- Recruitment against the density requirement. The two designs need different contributor pools, and the pool is what sets the schedule.
- Recording with topic prompting. Where a balanced sample is required, prompts are designed to create the switching rather than leaving it to chance.
- Annotation with agreement measured on the hard cases. Agreement is measured specifically over proper nouns, loanwords and numerals, because that is where the guideline either works or does not.
After recording, the utterances are transcribed in both languages, the switch points are marked, and the files are packaged with metadata covering the pair, the direction and the position of each switch. The switch marking is the step that turns a bilingual corpus into a code-switching corpus.
The pilot for code-switching is recorded with speakers who switch naturally rather than with a script that alternates languages, because the property being tested is whether real switches occur at the positions the specification names. A short session with a few speakers shows the actual switch rate and the syntactic positions, and those two figures decide whether the batch is feasible at all.
Acceptance rests on the switch marking, checked by a second annotator on a held-back set, and on the measured switch rate per utterance. The specification should state the minimum switch rate and the positions required before recording starts. Where the pilot shows a community switches less often than required, the elicitation is redesigned rather than the annotation, since concatenating monolingual recordings produces audio no speaker produces.
How a delivery goes wrong
The defects below are the ones that recur across this category. Each is decided at collection or annotation time, which is why none of them can be repaired in delivery review.
-
Switched words were normalized away
Some pipelines transliterate or translate embedded words into the matrix language to make the transcript look consistent. That destroys the phenomenon the corpus exists to capture, and it is done at annotation time so it cannot be undone.
-
Switch density was not measured
A corpus described as code-switching may contain very few switches. Without a density figure, a buyer cannot tell whether the delivery will teach a model to handle switching or only to tolerate it.
-
Speakers were not actually balanced
Bilingual ability varies, and some recruited speakers switch only in formal settings while others switch constantly. Without a proficiency measure in the manifest, the corpus cannot be stratified on the dimension that matters most.
Why this matters to buyers
The direct driver is recognition accuracy in bilingual markets. A model trained on monolingual data treats the switched portion as noise, and the degradation lands on the users who switch most, which in many markets is most of them.
The second driver is downstream tasks. Translation, intent detection and summarization all behave differently on code-switched input, and none of them can be evaluated without data that contains it. The corpus is what makes those systems testable.
A model trained on the wrong kind of switching fails on the speech it was bought for. It handles whole alternating sentences and then breaks inside a sentence, which is where bilingual speakers actually live. The errors look random to anyone who has not seen the corpus, and the investigation starts from the wrong end.
The second cost is that the corpus cannot be repaired. Switch positions are either marked in the transcript or they are not, and inferring them afterwards from two monolingual transcriptions is unreliable enough that the results cannot be trusted. The collection has to be repeated with the annotation built in.
A corpus with verified switch positions gives a model that handles the inside of a sentence rather than only whole alternating sentences, which is where bilingual users actually are. The team can report performance at the switch point rather than an average that hides it.
The second gain is that the corpus documents its population. Switch rates and positions differ between communities that share the same two languages, and a delivery that records which community was recorded can be extended with a second one without the two being conflated. That record is what keeps the corpus comparable across batches.
Specification at a glance
| Category | Code-Switching Speech |
|---|---|
| Group | Speech data |
| Critical spec | Whether annotation marks word-level switch points or only tags the language of the whole utterance. The workload differs by a multiple. |
| Included by default | Pilot batch, metadata schema, source and consent documentation |
| Pricing | Quoted from specification. No published rates |
Code-Switching Speech across languages
This category is available in every language we cover. The difficulty changes with the language, which is why each language page documents its own constraints.
Related categories
-
Call Center Speech
Customer-service calls, simulated rather than intercepted, capturing both the agent and the caller side, used for call center QC, intent recognition, and dialogue systems.
-
Conversational Speech
Speech from natural conversation between two or more people, on open or semi-structured topics, used for conversational AI, voice assistants, and small talk models.
-
Singing Voice
Vocal recordings with melody, in both a cappella and accompanied form, used for singing voice synthesis, music information retrieval, and lyric alignment.
-
Speech Commands
Targeted recordings of short command words or phrases, usually with many speakers reading each entry several times over, used for wake words and on-device command recognition.
-
Read Speech
Recordings of speakers reading specified text, with clear pronunciation and known text, the base material for TTS and ASR.
-
Podcast Speech
Long-form podcast and interview audio, either solo monologue or two-person conversation, used for long-form speech recognition and speaker modeling.
Questions about Code-Switching Speech
How is this different from multilingual speech?
Multilingual speech is several languages inside one project, each of them monolingual. Code-switching is two languages inside one sentence. The collection design, the annotation guideline and the models they train are all different.
Do you mark switch points at word level?
Per the specification, and it is the expensive option. Word-level boundaries are what let a model track the switch rather than merely tolerate it, and they cost more because annotators disagree about them until the guideline resolves the hard cases.
Should the sample be balanced or natural?
Recognition systems usually benefit from natural density because they are evaluated on real traffic. Systems whose purpose is handling the switched case, such as translation in bilingual customer service, usually benefit from a balanced sample. Either works; the choice has to be made before recruitment.
What are the hard cases in annotation?
Proper nouns that exist in both languages, words absorbed into the matrix language as loanwords, numerals, and single-word switches with no morphological integration. Disagreement clusters in those four categories, and a guideline that names them raises agreement more than a longer one describing a general principle.
Do you have Code-Switching Speech available now?
No. We do not hold inventory. Everything is produced against a specification. That means the timeline starts when the spec is agreed rather than immediately, and it also means the data matches your requirement instead of approximately matching something already built.
Can this be combined with other categories in one delivery?
Yes, and it is common. A single specification can cover several categories across several languages, with one pilot batch and one quality bar. It usually reduces total cost because contributor recruitment and project setup are shared.
What does the consent documentation cover?
Signed contributor consent stating the intended use, the collection methodology, and the annotation guideline the data was produced under. For projects involving EU data subjects the chain is built to satisfy GDPR, including the transfer mechanism. The terms for moving the data across a border.
Request Code-Switching Speech
Tell us the language, the hours, and what the data needs to look like. You will get a real number and a real timeline, not a range. If we cannot source it well, we will tell you that instead.
- Pilot batch before the full run, so problems surface early.
- Consent documentation delivered with the data.
- No medical or clinical data. No recorded telephone calls.
- You send the spec Language, hours, recording conditions, and the deadline.
- We reply within two business days A real number and a real timeline, not a range.
- You approve a pilot batch A small run first, so problems surface before the full order.
- Full run, then delivery with documents Audio, transcripts, and the consent record for every speaker.