Ukrainian, Persian and Kurdish Speech Data: Three Languages, Three Different Text Problems

A buyer asking for Ukrainian, Persian and Kurdish conversational speech is really asking for three different transcription decisions. Here is what each language makes difficult.

A Ukrainian woman in her thirties wearing studio headphones and speaking into a condenser microphone

A request for conversational speech in Ukrainian, Persian and Kurdish looks like one order and behaves like three. Each language fails at a different point in the pipeline, and a supplier who treats them as variants of the same job will produce a speech dataset that is unusable for at least two of the three.

The same pattern shows up in every multi-language order: the audio pipeline is shared, the text layer is not. A speech dataset is only as usable as the writing system its transcripts use.

Ukrainian: the recording contains two languages

Ukrainian speech recorded in central and eastern Ukraine routinely mixes Ukrainian and Russian inside the same conversation. The mixed form, known as surzhyk, is not a dialect and not a mistake; it is how a large share of speakers actually talk. A corpus recorded in Kyiv and a corpus recorded in Lviv will differ in how much of it appears.

The annotation decision is where this becomes expensive. If transcripts are cleaned into standard Ukrainian, the corpus stops describing the audio. If they preserve the mixture, the buyer needs a rule for how each token is labelled, or the text layer becomes inconsistent between annotators.

Regional variety belongs in the metadata for the same reason. Ukrainian recorded in the west and in the east differ audibly, and a corpus that mixes them without recording where each speaker came from cannot later be split.

Persian: the spoken form is not the written form

Written Persian and spoken Persian are far apart. Everyday speech contracts verbs, drops syllables and uses vocabulary that does not appear in formal text. Recognition models trained on written Persian degrade sharply on ordinary conversation, because the written form they learned is not the form people speak.

For a speech dataset this means the transcript has to be prepared in the register the buyer will run in production. A corpus transcribed into formal written Persian is internally consistent but does not match the audio; a corpus transcribed verbatim is faithful but harder to align with downstream text data.

The register decision belongs in the specification, not in annotation. Annotators asked to "transcribe naturally" will produce a different convention each, and the difference is invisible until the corpus is trained on.

Kurdish: one language, two scripts, two dialects

Kurdish is not a single written language. Sorani, spoken mainly in Iraq and western Iran, is written in a modified Arabic script. Kurmanji, spoken mainly in Turkey, Syria and parts of Iraq, is written in Latin script. The two differ in vocabulary and grammar as well as in script.

A corpus labelled simply "Kurdish" is therefore ambiguous. A Sorani corpus transcribed in Arabic script cannot be read by a model built for Kurmanji, and the reverse is also true. The variety and the script have to be stated before recruitment, because speakers of one are not interchangeable with speakers of the other.

Dialect boundaries inside each variety add a second layer. Sorani speakers from different cities do not sound identical, and recording the city or province at recruitment is the cheapest way to keep that recoverable.

What this means for a single specification

Three languages, one order, three sets of decisions. The specification has to carry all of them separately, because a rule written for one language will be wrong for the others.

  • State the variety and script per language, not per project.
  • Write the mixed-language rule for Ukrainian before recording starts.
  • Decide the Persian register: verbatim speech or normalised written form.
  • Record speaker region and city as metadata for every speaker.
  • Run separate acceptance checks per language; one language passing does not mean the others do.

The decision that matters is which variety and which register, not how many hours. Hours are easy to add later; a text layer built on the wrong convention has to be rebuilt from the audio.

For related language-specific notes, see the Ukrainian, Persian and Kurdish pages, and the full dataset briefs.

A recording desk with a monitor showing an abstract audio waveform and studio monitors beside it

Questions buyers ask

Can one corpus cover both Sorani and Kurmanji Kurdish?

It can hold both, but not as one undifferentiated set. Sorani is written in Arabic script and Kurmanji in Latin, and the two differ in vocabulary and grammar. They have to be separated and labelled, or a model trained on the result learns neither cleanly.

Should Ukrainian transcripts keep the Russian words?

That is the decision to make before recording. Keeping them preserves the audio faithfully but requires a written labelling rule; removing them produces clean standard Ukrainian that no longer matches what was said.

Why does Persian speech data fail when trained on written text?

Because spoken Persian contracts and drops syllables in ways written Persian does not show. A model trained on the written register meets audio it was never prepared for.

How many hours are enough for these languages?

The hours figure follows from the variety and speaker design, not the other way round. A narrow single-variety corpus needs fewer hours than one intended to cover several regional accents.

Do I need separate acceptance checks per language?

Yes. A batch that passes for one language can fail for another on the same checklist, because the failure modes differ: script consistency for Kurdish, register consistency for Persian, mixture labelling for Ukrainian.

More insights

Submit a sourcing request

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.

We reply within two business days. Your details are used only to answer this request. See our privacy policy.

  1. You send the spec Language, hours, recording conditions, and the deadline.
  2. We reply within two business days A real number and a real timeline, not a range.
  3. You approve a pilot batch A small run first, so problems surface before the full order.
  4. Full run, then delivery with documents Audio, transcripts, and the consent record for every speaker.
Contact

Talk to a human

Send a specification and we will come back with a real number and timeline.

Submit a sourcing request

Or use the contact form