Non-English instruction data: native vs translated SFT data

Translated SFT data is cheap coverage with predictable failure modes

Machine-translated instruction data reliably teaches task format, but it carries English-centric content and "translationese" into every target language. The research record reflects this: the authors of a 2025 TACL paper note that large-scale multilingual instruction data remains limited and that many efforts simply extend English data by automatic translation [2]. Translation preserves the prompt distribution of the source set, so your Spanish or Thai model learns to answer questions English-speaking (often US) users ask, about their institutions, in their registers.

The failure modes are specific and testable:

• Cultural transfer errors. Prompts about 401(k) plans, ZIP codes or Thanksgiving survive translation intact and teach the model the wrong defaults. Human evaluation work on LLM translation argues that grammar- and token-level benchmarks miss exactly this kind of cultural nuance [7].
• Register drift. Formal and informal address (tú/usted, du/Sie, tu/vous, Japanese keigo) are often chosen inconsistently by MT, so the fine-tuned assistant switches register mid-conversation.
• Answer-prompt mismatch. Code, units, dates and named entities get translated or localized in the prompt but not in the response, producing pairs where the "correct" answer is wrong.
• Lost code-switching. Real users in Manila, Mumbai or Miami mix languages within a sentence; translated sets are almost always monolingual per turn.

Translation is still the right tool for some layers: tool-call schemas, JSON-output tasks and safety refusals, where the structure matters more than idiom. See structured-output fine-tuning data for that layer.

Native instruction data captures how people actually ask

Native data is written or spoken originally in the target language, so prompt distribution, phrasing and cultural assumptions come from real speakers rather than from an English template. The clearest open example is the Aya Dataset, which collected human-written instruction-completion pairs from native speakers in 65 languages, released alongside the much larger Aya Collection of 513 million templated and translated instances across 114 languages [1]. That pairing is itself a useful lesson: a small native core and a large translated or templated shell are complements, not substitutes.

Native data matters most when:

• Your evaluation set comes from real users in that market, not from translated benchmarks.
• The language has strong regional variation. Spanish projects such as #Somos600M build instruction resources across varieties from Latin America, the Caribbean and Spain [5], and La Leaderboard evaluates Spanish varieties and languages of Spain and Latin America separately [6].
• Domain vocabulary is local: tax forms, legal procedure, payment rails and product names differ by country even within one language.

The native vs translated text guide covers the same trade-off for pretraining and general text; this page is about instruction and preference pairs.

Volume matters less than curation in non-English SFT

A few thousand well-reviewed native pairs per language can do more than a much larger translated set, because, as the LIMA authors argue, SFT mostly teaches format and style on top of what pretraining already knows. LIMA fine-tuned a 65B LLaMA model on just 1,000 carefully curated prompt-response pairs [10]; the authors also note that such curation is labor-intensive. For multilingual work that labor multiplies by language, which is why buyers should budget review time per language rather than per record.

Large open multilingual sets are best treated as starting material. MURI-IT, for instance, lists 2.2 million instruction-output pairs across 200 languages [3], and M3IT extends instruction tuning to multimodal, multilingual tasks [4]. Filter them with the methods in instruction-tuning data quality filtering before mixing them with native data.

Decision table: translate, source native, or go hybrid

The right mix depends on the job each slice of data does in your post-training stack. Use the table below per language, not once for the whole project.

The hybrid column reflects a working hypothesis many teams share rather than a settled result: real native prompts fix the input distribution, and fluent experts writing or post-editing responses fix quality and policy alignment. If you already hold aligned bilingual assets, translation memories can seed parallel tasks, and multilingual training data types compared explains how they differ from native text.

Where native-language instruction data comes from

Native instruction data usually comes from three places: open community datasets, commissioned writing, and operational records from businesses that already serve customers in that language. Each has a different rights profile.

• Open datasets (Aya, #Somos600M, MURI-IT) are fast to start with, but check the license on every component. The Data Provenance Initiative audited more than 1,800 text datasets and found license omission rates above 70% and error rates above 50% on popular hosting sites [9]. The open fine-tuning datasets for commercial use page lists what to verify.
• Commissioned writing by native-speaker annotators gives you control over register, domain and dialect, but output can drift toward a "writer's voice" that does not match real users.
• Operational records such as Spanish-language support tickets, chat transcripts, sales emails, or internal knowledge-base articles carry genuine phrasing, code-switching and domain vocabulary. They need conversion into instruction-response pairs, as covered in turning business records into instruction-response pairs, plus de-identification and a license that permits fine-tuning.

Many US companies run support, sales and back-office work in Spanish and other languages, which is why buyers ask whether AI labs buy non-English business data. If that is the source you need, you can describe it on the SourceX buyer request page.

Multilingual preference data needs native raters, not translated rankings

Preference pairs encode judgments of naturalness, politeness and helpfulness, and those judgments are language- and culture-specific. DPO fits a policy directly to chosen-versus-rejected pairs without a separate reward model [11], so any bias in the pairs passes straight into the policy. Translating English preference data keeps the English raters' choices, including their tolerance for directness or verbosity, and attaches them to text they never read.

For each language, ask for rater metadata: native language, country, years of fluency, and the rubric they applied. Require inter-rater agreement per language, because a single overall agreement number can hide one language where raters disagree constantly. See rubric-based rewards data for rubric design.

Acceptance checks for a multilingual SFT delivery

Run automated language and script checks first, then native-speaker review on a stratified sample per language. Language ID is not trivial for low-resource languages: GlotLID was built precisely because common identifiers misclassify many of them [8]. Run it on both prompt and response, and flag pairs where they disagree.

Illustrative example: invented to show structure; it does not describe an available dataset.

{
  "record_id": "es-mx-000412",
  "lang_tag": "es-MX",
  "script": "Latn",
  "origin": "native_operational",
  "source_type": "support_chat_transcript",
  "prompt": "Oye, me llegó doble cargo en mi tarjeta, ¿me lo pueden reembolsar?",
  "response": "Claro, con gusto lo reviso. ¿Me confirma la fecha del cargo y los últimos cuatro dígitos que aparecen en su estado de cuenta?",
  "register": "usted",
  "code_switching": false,
  "response_author": "native_expert_post_edit",
  "deid_method": "named entities replaced with typed placeholders",
  "reviewer_lang": "es-MX",
  "review_score": 4
}

Illustrative example: invented to show structure; it does not describe an available dataset.

Delivery acceptance checklist (per language)

1. BCP 47 language tag and ISO 15924 script code on every record; reject records where detected language disagrees with the tag.
2. origin field distinguishes native, translated, post-edited and synthetic records, with counts per language.
3. Translationese spot check: a native reviewer flags calques and unnatural word order on a random sample.
4. Register consistency: formal and informal address does not switch within a conversation.
5. Locale correctness: currency, date formats, phone formats and institutions match the tag.
6. Code-switched turns are labeled, not stripped.
7. De-identification method is documented and checked on a sample.
8. License covers fine-tuning, derivative models and the languages delivered; confirm with the fine-tuning-only data license guide.
9. Hold out a native-written evaluation set per language that never enters training.

The general checks in evaluating a fine-tuning dataset before you buy still apply on top of these.

Sourcing native-language instruction data with SourceX

SourceX sources operational datasets, such as support and sales histories, from US companies on request and manages licensing; it holds no stock, so a request does not guarantee a match. Every dataset is rights-reviewed, personal details are removed or replaced before delivery, and each release is approved by the supplying company. Describe the languages, varieties and interaction types you need on the SourceX buyer page.

For the wider cluster, start at the fine-tuning and post-training data hub, the SFT sourcing guide, or training data for multilingual enterprise models. Background on the term: instruction tuning.