Text-to-SQL for Low-Resource Languages: A Unified Large Language Model Framework Evaluated on Arabic, Japanese, and Vietnamese

Abstract

Text-to-SQL research has concentrated on English, while prior work on Arabic, Japanese, and Vietnamese has largely relied on grammar-constrained parsers or zero-shot prompting, with recent work beginning to explore trained LLM-based alternatives. We investigate whether a unified fine-tuned open-source pipeline can serve typologically distant low-resource languages and quantify the same-pipeline English-to-target gap on parallel Spider instances. We fine-tune Qwen2.5-Coder-7B-Instruct with QLoRA using shared schema grounding, value grounding, an English translation hint, and execution-based self-consistency voting over eight candidates. Architecture, constants, and inference are fixed across languages, while each language uses its own training data and adapter. On Ar-Spider, MultiSpider-JA, and MultiSpider-VI, the pipeline reaches 75–80% execution accuracy (EX), with raw exact set match (ESM) within 0.7 points of the strongest prior Arabic parser and above the strongest multilingual MultiSpider baseline for Japanese (+2.5) and Vietnamese (+3.5). An English same-pipeline run (85.3% EX) yields gaps of −10.1, −10.5, and −5.4 percentage points for Arabic, Japanese, and Vietnamese, respectively. Removing the complete value-grounding group causes the largest degradation. The EX–ESM gap persists without voting and repair, indicating differences in generated SQL rather than decoder effects; we therefore recommend reporting both metrics.

1. Introduction

Text-to-SQL semantic parsing involves converting natural-language questions into executable SQL queries, which allows non-expert users to access information stored in relational databases [1]. This capability holds significant practical value across various domains, including business intelligence, healthcare, and education. In recent years, the field has made remarkable advancements.

The majority of research on text-to-SQL has focused on English [2,3,4,5], leaving limited resources for other languages. This oversight is concerning, as non-English speakers make up the vast majority of the global population. Arabic alone is spoken by over 400 million people, Japanese by approximately 125 million, and Vietnamese by roughly 85 million, yet in the context of text-to-SQL, all three are considered “low-resource.” Each has only one or two benchmark datasets translated from Spider and lacks dedicated text-to-SQL training corpora or augmented datasets. In contrast, English benefits from a rich ecosystem of resources, including Spider [1], Spider 2.0 [6], BIRD [7], WikiSQL [8], and various synthetically augmented datasets such as SynSQL-2.5M [9]. This imbalance means that progress on English benchmarks, where state-of-the-art systems now exceed 90% execution accuracy [10], does not automatically carry over to other languages. As a result, hundreds of millions of potential users still lack reliable natural-language database interfaces.

Cross-lingual text-to-SQL for these languages presents unique challenges that go beyond simple translation. In the Spider-derived benchmarks used in our main experiments, executable SQL and original database identifiers remain in English, creating a cross-lingual linking problem. This cross-lingual schema linking must bridge not only vocabulary differences but also fundamental divergences in morphology and orthography. Arabic is written from right to left and has complex word forms. A single word can show subject, tense, and object, and short vowels are usually left out in writing. This creates ambiguity and makes it harder to match words with English schema identifiers. Japanese uses Kanji characters along with two syllabic scripts, Hiragana and Katakana. Words are not separated by spaces, so it is difficult to split text into words and match them to schema elements. Vietnamese uses the Latin alphabet but relies on many tonal marks. These diacritics must be kept accurate during schema linking, since mistakes can change the meaning of a word. Because of these differences, methods that work for one language family may not work for another. This highlights the need to test approaches across different writing systems.

Recent efforts have introduced benchmarks for non-English text-to-SQL, but a significant resource gap persists. The Ar-Spider benchmark, developed by the authors of [11], is the first Arabic cross-domain benchmark, created through manual translation of the Spider benchmark by qualified translators and verified by native-speaking graduate students. It establishes baseline performance using GNN-based parsers, achieving an Exact Set Match (ESM) of 66.63% with LGESQL, XLM-R, and contextual similarity relationships. The MultiSpider benchmark, created by the authors of [12], expands upon Spider by including support for seven languages, such as Japanese and Vietnamese, and reports a 6.1% absolute drop in accuracy for non-English inputs, a gap that widens further for languages with non-Latin scripts. More recently, the authors of [13] released MultiSpider 2.0, extending Spider 2.0 to eight languages at enterprise-level complexity; in the same work, evaluation on MultiSpider 1.0 shows that even advanced models such as OpenAI o1 reach only 43.4% exact match for Japanese while exceeding 90% for English, underscoring how far the multilingual gap extends.

Despite the availability of these benchmarks, most evaluations have relied on GNN-based parsers with grammar-constrained decoding or on zero-shot prompting of proprietary large language models. Grammar-constrained parsers guarantee syntactically valid SQL, but many published benchmark configurations are evaluated without literal-value prediction and are tightly coupled to the annotation conventions of their training data. Zero-shot prompting of proprietary models avoids fine-tuning costs but provides no mechanism for learning language-specific patterns from training examples. Trained open-source LLMs have recently begun to appear in this setting, for single languages such as Turkish [14] and, through reinforcement learning on MultiSpider, for a small model under its own evaluation protocol [15]. What is still missing is a controlled study in which one fine-tuned open-source pipeline, with a fixed architecture, fixed constants, and a single seeded evaluation harness with paired significance tests, is evaluated across typologically diverse low-resource text-to-SQL languages and against an English same-pipeline reference; this work aims to fill that gap. In this paper, we present a unified pipeline based on large language models (LLMs) that has been evaluated on three low-resource text-to-SQL benchmarks. These benchmarks span three different language families and writing systems: Arabic, Japanese, and Vietnamese. Our contributions are the following findings; the pipeline itself (Section 3) is the instrument that makes them measurable.

• A same-pipeline English-to-target performance gap on parallel Spider instances. With the architecture, prompt template, constants, and inference procedure held fixed, the system reaches 75.2%, 74.8%, and 79.9% EX on Ar-Spider, MultiSpider-JA, and MultiSpider-VI. Because the language versions share the same databases, gold SQL, and query structures, the English same-pipeline reference (85.3% EX) provides a matched benchmark comparison: the gaps are −10.1 pp for Arabic, −10.5 pp for Japanese, and −5.4 pp for Vietnamese. These are same-pipeline performance gaps rather than isolated causal effects of question language, because the language-specific training data, adapter, native-language descriptions, and translation-hint content also differ.
• The EX–ESM gap is a property of the generated SQL, not of the decoder. The 8.6–10.7 pp gap persists essentially unchanged (8.4–10.8 pp) under an exact greedy control with voting and repair disabled. Four guarded, gold-blind rewrites explain about one point of it (every flipped verdict is execution-correct), and set-operation (IUEN) generation emerges as the shared capability gap across the three languages: the gap is partly stylistic and partly a genuine capability gap, and we recommend reporting single-instance EX alongside ESM. On raw Spider ESM, the system surpasses the strongest multilingual MultiSpider baseline for Japanese (+2.5 pp) and Vietnamese (+3.5 pp) and lies 0.7 pp below the strongest prior Arabic parser.
• Value grounding dominates, and grouped ablations reveal component compensation. Removing all value-grounding components costs 4.8–7.3 pp EX, substantially more than any individually tested value-grounding component. Removing all schema-grounding components costs up to 2.5 pp EX, with the largest effect in Vietnamese. A three-layer sensitivity study of the column-linking parameters provides complementary evidence that the linker’s configuration matters most when voting and repair are absent.
• One architecture across four languages and two base models. The identical pipeline and constants serve Arabic, Japanese, Vietnamese, and English, and transfer unchanged to Llama-3.1-8B-Instruct (74.6% EX on Arabic, within 0.6 pp of Qwen2.5-Coder), evidence that the findings characterize the approach rather than one model.

Each configuration in the paper, including the full system, all single-component and grouped ablations, the controls, and the minimal baseline, is measured using a single seeded evaluation harness. We use the original Spider ESM evaluator, bootstrap confidence intervals, and paired McNemar tests. The implementation, trained adapters, and a 149-error translation audit of Ar-Spider are provided as artifacts, not as contributions.

The remainder of this paper is organized as follows. Section 2 reviews related work. Section 3 describes our methodology. Section 4 presents the experimental setup. Section 5 reports the results, Section 6 discusses the implications for evaluation, and Section 7 concludes the paper.

2. Related Work

2.1. Text-to-SQL Benchmarks and Evaluation

The Spider benchmark [1] established the standard for text-to-SQL cross-domain evaluation, comprising 10,181 questions and 5693 unique complex SQL queries in 200 databases in 138 domains. Spider introduced the cross-domain evaluation paradigm where training and test databases are disjoint, testing generalization to unseen schemas. Spider originally used Exact Set Match (ESM) without values, which decomposes predicted SQL into structural components (SELECT, WHERE, GROUP BY, ORDER BY, HAVING) and performs set-wise comparison. Importantly, ESM was designed for models that do not predict values, as the original GNN-based baselines output SQL skeletons with placeholder values.

Spider 2.0 [6] dramatically increased difficulty with 632 enterprise-level tasks involving complex schemas exceeding 3000 columns, multiple SQL dialects, and multi-step workflows. Even advanced LLMs like o1-preview solve only 21.3% of Spider 2.0 tasks, compared to over 90% on Spider 1.0, highlighting the remaining challenges. The BIRD benchmark [7] introduced real-world databases with dirty data and external knowledge requirements, providing a complementary evaluation to Spider. WikiSQL [8] focused on simpler single-table queries and is now considered largely solved. Test-Suite Accuracy [16] was adopted as the official Spider metric in 2020, executing queries against multiple database instances to reduce false positives, while ESM remains the original/reference Spider metric. A recent comprehensive survey [17] provides an overview of LLM-enhanced text-to-SQL methods and evaluation practices.

While there have been many proposals that were evaluated on the English Spider [2,3,4,5,9,10,18,19,20,21,22,23,24,25], very few were dedicated to Arabic, Japanese, and Vietnamese.

2.2. Grammar-Constrained Text-to-SQL Parsers

Traditional text-to-SQL systems employ encoder-decoder architectures with grammar-constrained decoding. Building on this, RAT-SQL [18] introduced relation-aware schema encoding using graph neural networks. LGESQL [19] further enhanced this approach with line graph transformations to capture edge-level interactions between schema elements. Similarly, S2SQL [20] injected syntactic information into the schema interaction graph. Collectively, these models generate SQL through abstract syntax tree (AST) construction, selecting schema elements by pointing to column and table indices. This method guarantees syntactic validity and alignment with evaluation metrics but limits generalization.

ShadowGNN [26] tackled schema linking using abstract schema representations. Similarly, BRIDGE [27] improved contextual understanding by adding database content to the encoding process. Building on these methods, SmBoP [28] used bottom-up semi-autoregressive parsing. RESDSQL [5] separated schema linking from SQL generation and showed strong results with smaller models.

2.3. LLM-Based Text-to-SQL

Large language models have changed text-to-SQL by enabling new prompt engineering and fine-tuning methods. DIN-SQL [3] reached 85.3% on the Spider test set using decomposed prompting with GPT-4. DAIL-SQL [2] explored different prompt engineering strategies and achieved 86.6% with self-consistency voting. CHESS [4] proposed a three-step process: column filtering, table selection, and SQL generation. MiniSeek [10], a company-reported leaderboard entry rather than a peer-reviewed system description, was the first to score over 90% on the Spider test set, showing the high potential of LLM-based methods; all the above were evaluated in English.

CodeS [21] showed strong results by fine-tuning open-source code models on text-to-SQL data. DTS-SQL [22] used schema linking together with supervised fine-tuning. OmniSQL [9] created an automatic data synthesis framework that produced SynSQL-2.5M, the first million-scale text-to-SQL training dataset, and reached state-of-the-art results on several benchmarks with models ranging from 7B to 32B parameters. ExCoT-DPO [23] improved reasoning using execution feedback and direct preference optimization. For smaller open-source models, Databricks reported—in a company engineering blog post rather than a peer-reviewed venue—that fine-tuning Llama-3 8B Instruct achieves 78.9% on the Spider test split [24]; we treat this company-reported figure as an important open-source reference point rather than a directly comparable baseline.

Recently, researchers have used reinforcement learning for text-to-SQL tasks. Arctic-Text2SQL-R1 [25] combined GRPO with OmniSQL initialization and set a new state of the art on the BIRD benchmark. This shows that RL-based training can further improve fine-tuned text-to-SQL models.

Self-consistency [29] and execution-based verification [3] have both helped make text-to-SQL systems more reliable. MAC-SQL [30] looked at how multiple agents can work together for text-to-SQL tasks. PET-SQL [31] pointed out that LLMs are better at writing SQL than at schema linking, which led to the development of specialized schema linking components.

2.4. Multilingual and Low-Resource Text-to-SQL

Interest in cross-lingual text-to-SQL has been increasing, as many languages spoken by hundreds of millions of people still have limited resources for text-to-SQL. For each of these languages, only one or two translated benchmark datasets are available. We review existing work by language family and benchmark.

Chinese. CSpider [32] was one of the first cross-lingual versions of Spider, translating questions into Chinese. DuSQL [33] introduced a larger Chinese text-to-SQL dataset with practical Chinese database designs.

Vietnamese. The authors of [34] conducted the first pilot study on text-to-SQL semantic parsing for Vietnamese, translating both questions and schema elements. They showed the difficulties with Vietnamese tokenization and diacritics when linking schema.

Arabic. Ar-Spider [11] was the first cross-domain Arabic text-to-SQL dataset, created by qualified translators and verified by graduate students. The authors found two main challenges: mapping Arabic questions to English schema elements, and handling Arabic-specific language patterns in SQL generation. Their best result, 66.63% ESM, was achieved using LGESQL, XLM-R, and CSR. The same authors later introduced Ar-SParC [35], a context-dependent Arabic text-to-SQL dataset, and tested GPT-3.5-turbo and GPT-4-turbo with different prompt engineering methods. AraSpider [36] offered a separate machine-translated Arabic Spider dataset, where ChatGPT and SQLCoder were evaluated using back-translation. They found that translating through English greatly improves Arabic text-to-SQL performance.

Other languages. PAUQ [37] introduced a Russian text-to-SQL dataset. TURSpider [14] developed a Turkish benchmark and fine-tuned language models for Turkish, demonstrating that these models can outperform GPT-based models in execution accuracy. mRAT-SQL [38] modified the RAT-SQL architecture for Portuguese and found that training with both English and Portuguese data leads to better results than using only one language.

Multilingual benchmarks. MultiSpider [12] is the most comprehensive multilingual text-to-SQL Spider benchmark that covers seven languages: English, German, French, Spanish, Japanese, Chinese, and Vietnamese. The authors of [12] introduced the SAVe (Schema Augmentation with Verification) framework, which adds target-language translations to English schema items and checks schema linking using back-translation. This approach greatly improved performance and helped reduce the cross-lingual gap. Under their multilingual training setting, RAT-SQL + XLM-R with SAVe achieved ESM scores of 61.6% for Japanese and 67.8% for Vietnamese. More recently, the authors of [13] released MultiSpider 2.0, which expands Spider 2.0 to eight languages and increases complexity to an enterprise level. On MultiSpider 1.0, their COLA framework with OpenAI-o1 reached over 90% EX for English but only 43.4% EM for Japanese, showing that a significant multilingual gap remains even with advanced models. Another study [15] used a contrastive-reward method, applying GRPO with multilingual semantic rewards on MultiSpider. This showed that small models like Llama-3B can improve through reinforcement learning with cross-lingual signals.

2.5. Multilingual Embeddings and Cross-Lingual Transfer

Cross-lingual schema linking is a fundamental challenge in non-English text-to-SQL tasks. mBERT [39] and XLM-RoBERTa [40] offer multilingual representations and are commonly used as encoders in these parsers. BGE-M3 [41] introduced M3-Embedding, which supports over 100 languages and enables dense, sparse, and multi-vector retrieval in one model. We use BGE-M3 for bilingual column linking, taking advantage of its strong cross-lingual alignment to match question fragments in the target language with English schema elements, without needing explicit translation.

2.6. Parameter-Efficient Fine-Tuning

QLoRA [42] enables efficient fine-tuning of large models through 4-bit quantization and low-rank adapters. This allows models with over 7 billion parameters to be fine-tuned on consumer GPUs. LoRA [43] first introduced the low-rank adaptation method. These techniques have been used for text-to-SQL fine-tuning [9,21,22], showing that parameter-efficient methods can perform as well as full fine-tuning. The Qwen2.5-Coder model family [44], based on the Qwen2.5 architecture [45] and trained on more than 5.5 trillion code tokens, is a strong choice for code generation tasks like text-to-SQL. It also supports multiple programming and natural languages.

3. Methodology

Our system has two main stages. During fine-tuning, we build the prompt using M-Schema representation, value injection, sample rows, translation hints, and column linking, and train a QLoRA adapter per language. At inference, the same prompt structure is applied to each development question; the fine-tuned adapter generates eight SQL candidates; each candidate first receives the three per-candidate repairs of the execution-guided repair stage (Section 3.8: identifier fixing, hallucinated-filter removal, and value-literal grounding); the repaired candidates are then aggregated by execution-based self-consistency voting (Section 3.7); and the voted query passes through the remaining two repair procedures, the low-confidence candidate-expansion fallback and error-feedback self-correction. Figure 1 shows an overview of the entire pipeline. Throughout the paper, “full system” denotes this complete pipeline; Section 5 additionally reports controlled variants with the repair stage and voting disabled.

• Notation and typed specification.

A question is a string $q\in {\Sigma }^{*}$ in language L. A database is $D=(S,I)$ with schema $S=(T,C,\mathrm{PK},\mathrm{FK})$ (tables, columns, primary and foreign keys) and instance I; $V\left(c\right)$ denotes the stored values of column $c\in C$ and ${\mathrm{desc}}_L\left(c\right)$ its native-language description. $e:{\Sigma }^{*}\to {\mathbb{R}}^d$ is the BGE-M3 embedding, ${\mathrm{Tr}}_{L\to \mathrm{en}}:{\Sigma }^{*}\to {\Sigma }^{*}$ the external translation (the identity for English), and $\tilde{q}=q\oplus {\mathrm{Tr}}_{L\to \mathrm{en}}\left(q\right)$ the question concatenated with its translation; $\tilde{q}$ is the input to the two value-injection stages H and M and to the entity-gating predicate, so that English cell values can be matched from a non-Latin question, whereas column linking operates on q alone and sample rows are selected from the linked columns rather than from the question (Section 3.2, Section 3.3, Section 3.4 and Section 3.5). We write ${\mathrm{desc}}_L=⌀$ for a configuration in which the native-language descriptions are removed; every stage that reads ${\mathrm{desc}}_L$—schema rendering, column linking, and the column-hint block of the prompt—then omits them. ${\mathrm{exec}}_D:{\Sigma }^{*}\to \mathcal{R}\cup \{\perp \}$ returns a result set or ⊥ on parse failure, execution error, or timeout (60 s). Let $\mathbf{t}=(0,0.3,0.3,0.7,0.7,0.7,1.1,1.1)$ denote the indexed decoding schedule, with $t_0=0$ for the greedy candidate (used for tie-breaking), and let $s_1\left(q\right)$ and $s_2\left(q\right)$ be two distinct deterministic per-sample seeds for the initial and fallback runs. $p_{\theta }$ is the fine-tuned adapter over the frozen backbone. Table 1 specifies every stage as a typed transformation; Algorithm 1 composes the stages without undefined empty-set or tie cases, and Section 3.9 gives the design rationale.

Algorithm 1 End-to-end inference pipeline (composition of the typed stages of Table 1)

Input: question $q\in {\Sigma }^{*}$ in language L; database $D=(S,I)$; adapter $p_{\theta }$; constants $\tau =0.50$, $K=6$, $\mathbf{t}=(0,0.3,0.3,0.7,0.7,0.7,1.1,1.1)$. Output: SQL query $\widehat{y}\in {\Sigma }^{*}$. 1. Set $h\leftarrow {\mathrm{Tr}}_{L\to \mathrm{en}}\left(q\right)$, $\tilde{q}\leftarrow q\oplus h$, $L_c\leftarrow {\mathrm{Link}}_{\tau ,K}(q,S)$, $u_H$←$H(\tilde{q},D)$, $u_M\leftarrow M(\tilde{q},D)$, $u_R\leftarrow R(D,L_c)$, and $u_T\leftarrow \mathrm{Summary}\left(S\right)$. 2. Assemble the full prompt $P\leftarrow {\mathrm{Render}}_L({\sigma }_L\left(S\right),u_H,u_M,L_c,u_R,u_T,q,h)$; the raw-DDL prompt $P_{\mathrm{DDL}}\leftarrow {\mathrm{Render}}_L({\sigma }_{\mathrm{DDL}}\left(S\right),u_H,u_M,L_c,u_R,u_T,q,h)$ differs only in the schema slot and is materialized only if Step 4 is reached. 3. Generate $Y\leftarrow {\mathrm{Gen}}_{\theta }(P,s_1\left(q\right))=(y_0,\dots ,y_7)$, where $y_0$ is greedy and $y_i$ follows $t_i$ for $i\ge 1$; repair each candidate $y_i\leftarrow \rho (y_i,D)$; then set $(\widehat{y},\kappa )\leftarrow \mathrm{Vote}(Y,D)$ and $P^{*}\leftarrow P$. 4. If $\kappa \le 3/8$, set $Y^{\prime }\leftarrow {\mathrm{Gen}}_{\theta }(P_{\mathrm{DDL}},s_2\left(q\right))$, repair every $y_i^{\prime }\leftarrow \rho (y_i^{\prime },D)$, and compute $({\widehat{y}}^{\prime },{\kappa }^{\prime })\leftarrow \mathrm{Vote}(Y^{\prime },D)$. Then set $((\widehat{y},\kappa ),b)\leftarrow \mathrm{Fallback}((\widehat{y},\kappa ),({\widehat{y}}^{\prime },{\kappa }^{\prime }))$; if $b=2$, set $P^{*}\leftarrow P_{\mathrm{DDL}}$. 5. Set $\widehat{y}\leftarrow {\mathrm{Correct}}_2(\widehat{y},P^{*},D)$; this leaves an executable query unchanged and, only when ${\mathrm{exec}}_D\left(\widehat{y}\right)=\perp$, re-prompts from the active prompt $P^{*}$ with the current database error for at most two retries. 6. Return $\widehat{y}$.

Table 1. Typed specification of the pipeline stages. Constants are fixed as described in Section 4.4. The ablation groups G1–G4 (Section 5.3) remove the corresponding transformations: G1 replaces ${\sigma }_L$ by ${\sigma }_{\mathrm{DDL}}$, removes ${\mathrm{Link}}_{\tau ,K}$, and sets ${\mathrm{desc}}_L=⌀$; G2 removes $\{H,M,R,{\mathrm{Ground}}_{0.70}\}$; G3 removes ${\mathrm{Tr}}_{L\to \mathrm{en}}$ and sets ${\mathrm{desc}}_L=⌀$, which also strips the native descriptions from ${\sigma }_L$, from the column-hint block rendered by ${\mathrm{Render}}_L$, and from the text embedded by ${\mathrm{Link}}_{\tau ,K}$, so G3 is not a translation-only removal; G4 removes voting, fallback, self-correction, and $\rho$. G1 and G3 both set ${\mathrm{desc}}_L=⌀$ and are therefore not disjoint groups.

Stage	Signature	Definition and Constants
Schema rendering	${\sigma }_L,{\sigma }_{\mathrm{DDL}}$: $S\to {\Sigma }^{*}$	${\sigma }_L$: M-Schema with ${\mathrm{desc}}_L$; ${\sigma }_{\mathrm{DDL}}$: raw DDL without native descriptions.
Table summary	$\mathrm{Summary}$: $S\to {\Sigma }^{*}$	Compact table-to-columns reference; always present.
Column linking	${\mathrm{Link}}_{\tau ,K}$: ${\Sigma }^{*}\times S\to 2^C$	Top-K columns by bilingual embedding similarity of q against $\mathrm{name}\left(c\right)\oplus {\mathrm{desc}}_L\left(c\right)$, thresholded at $\tau$; $\tau =0.50$, $K=6$.
Value hints	H: ${\Sigma }^{*}\times D\to {\Sigma }^{*}$	Applied to $\tilde{q}$; token-overlap values from text columns; ≤4 values/column.
Matched values	M: ${\Sigma }^{*}\times D\to {\Sigma }^{*}$	Applied to $\tilde{q}$; top-5 values by similarity; threshold 0.40, entity-gated.
Sample rows	R: $D\times 2^C\to {\Sigma }^{*}$	Rows drawn from the tables of the linked columns $L_c$; ≤3 rows, ≤6 columns, ≤3 tables. If $L_c=⌀$ or column linking is disabled, tables are selected deterministically in schema order.
Prompt assembly	${\mathrm{Render}}_L$: ${\left({\Sigma }^{*}\right)}^3\times 2^C\times {\left({\Sigma }^{*}\right)}^4\to {\Sigma }^{*}$	${\mathrm{Render}}_L(\sigma ,H,M,L_c,R,\mathrm{Summary},q,h)$ fills the eight prompt slots of Section 3.6.1; the subscript L marks the use of ${\mathrm{desc}}_L$ when rendering the column-hint block for $L_c$.
Generation	${\mathrm{Gen}}_{\theta }$: ${\Sigma }^{*}\times \mathbb{N}\to {\left({\Sigma }^{*}\right)}^8$	One greedy candidate plus seven sampled candidates under fixed $\mathbf{t}$; nucleus $p=0.95$.
Per-candidate repair	$\rho$: ${\Sigma }^{*}\times D\to {\Sigma }^{*}$	$\rho ={\mathrm{Ground}}_{0.70}\circ \mathrm{DropUnknown}\circ {\mathrm{FixId}}_{0.7}$.
Voting	$\mathrm{Vote}$: ${\left({\Sigma }^{*}\right)}^8\times D\to {\Sigma }^{*}\times [0,1]$	Selects the modal execution-result group; deterministic tie-breaking is defined below; $\kappa =|G^{*}|/8$.
Fallback selection	$\mathrm{Fallback}$: ${({\Sigma }^{*}\times [0,1])}^2\to ({\Sigma }^{*}\times [0,1])\times \{1,2\}$	Returns the selected pair and index b: $b=2$ only when fallback $\kappa$ is strictly larger; otherwise $b=1$.
Self-correction	${\mathrm{Correct}}_2$: ${\left({\Sigma }^{*}\right)}^2\times D\to {\Sigma }^{*}$	${\mathrm{Correct}}_2(y,P^{*},D)$ re-prompts from the active prompt $P^{*}$ with the database error for at most two retries.

${\Sigma }^{*}$ denotes the set of all finite strings over the alphabet $\Sigma$; the superscript star in $G^{*}$ and $P^{*}$ marks the selected execution-result class and the active prompt, respectively.

Figure 1. Overview of the proposed cross-lingual text-to-SQL pipeline. A target-language question and the database schema are processed through the prompt-enrichment components of Section 3: the M-Schema representation with native-language descriptions, value injection (rendered as the value-hint and matched-value slots), sample rows, the English translation hint, and column linking. During training, per-feature dropout (Table 2) ensures prompt alignment between training and inference. The assembled prompt is fed to Qwen2.5-Coder-7B-Instruct fine-tuned with QLoRA ($r=64$, $\alpha =128$). At inference, 8 SQL candidates are generated via multi-temperature sampling; each candidate is repaired (identifier fixing, hallucinated-filter removal, value-literal grounding) and executed against the database; the modal execution-result group determines the selected query; the low-confidence candidate-expansion fallback is then applied when needed, followed by error-feedback self-correction if the retained query still fails execution (Section 3.8). Component colors indicate the three ablation groups analyzed in Section 5: schema grounding (M-Schema, column linking), value grounding (value injection, sample rows), and the translation hint.

Figure 1. Overview of the proposed cross-lingual text-to-SQL pipeline. A target-language question and the database schema are processed through the prompt-enrichment components of Section 3: the M-Schema representation with native-language descriptions, value injection (rendered as the value-hint and matched-value slots), sample rows, the English translation hint, and column linking. During training, per-feature dropout (Table 2) ensures prompt alignment between training and inference. The assembled prompt is fed to Qwen2.5-Coder-7B-Instruct fine-tuned with QLoRA ($r=64$, $\alpha =128$). At inference, 8 SQL candidates are generated via multi-temperature sampling; each candidate is repaired (identifier fixing, hallucinated-filter removal, value-literal grounding) and executed against the database; the modal execution-result group determines the selected query; the low-confidence candidate-expansion fallback is then applied when needed, followed by error-feedback self-correction if the retained query still fails execution (Section 3.8). Component colors indicate the three ablation groups analyzed in Section 5: schema grounding (M-Schema, column linking), value grounding (value injection, sample rows), and the translation hint.

The voting operator is fully deterministic given the generated candidates. For indexed repaired candidates $Y=(y_0,\dots ,y_7)$, let $V=\{i:{\mathrm{exec}}_D\left(y_i\right)\ne \perp \}$. If $V=⌀$, $\mathrm{Vote}(Y,D)=(y_0,0)$. Otherwise define $i{\sim }_{D}j$ iff ${\mathrm{exec}}_D\left(y_i\right)={\mathrm{exec}}_D\left(y_j\right)$ and let $\mathcal{G}=V/{\sim }_D$ be the execution-result equivalence classes. Choose a class of maximal cardinality; if several classes tie, choose the class whose smallest pair $(t_i,i)$ in lexicographic order is smallest. Within the selected class $G^{*}$, choose $i^{*}=arg{min}_{i\in G^{*}}\left(\right|y_i|,i)$, i.e., the shortest SQL with candidate index as the final deterministic tie-break. Then $\mathrm{Vote}(Y,D)=(y_{i^{*}},|G^{*}|/8)$.

Table 2. Per-feature dropout rates during training.

Component	Dropout	Fallback
M-Schema (schema)	20%	Raw DDL
Value hints	20%	Omitted
Matched values	20%	Omitted
Column hints	40%	Omitted
Sample rows	20%	Omitted
Table summary	0%	Always present
Question	0%	Always present
English hint	0%	Always present

Table 2. Per-feature dropout rates during training.

Component	Dropout	Fallback
M-Schema (schema)	20%	Raw DDL
Value hints	20%	Omitted
Matched values	20%	Omitted
Column hints	40%	Omitted
Sample rows	20%	Omitted
Table summary	0%	Always present
Question	0%	Always present
English hint	0%	Always present

3.1. Schema Representation

We use the M-Schema representation [46] to give a clear structure to the database schema. For each table, we show the table name, column names with their data types, primary key markers (marked with *), and foreign-key relationships. We also include column descriptions in the native language to help the model link questions in the target language to the English schema identifiers. For example, we use Arabic descriptions for Ar-Spider, Japanese for MultiSpider-JA, and Vietnamese for MultiSpider-VI. When M-Schema is dropped during training (Section 3.6.2), the prompt falls back to raw DDL (CREATE TABLE statements) without native-language annotations. The complete prompt template, including the M-Schema-rendering format, is provided in Appendix A.

3.2. Value Injection

When questions refer to specific database values, such as country names or categories, we use two complementary value-injection methods to ground the model in actual database content. These approaches address a limitation of the value-agnostic GNN-based baseline configurations used in prior multilingual work, which do not generate literal values.

Value hints. For each text column in the database, we extract up to 4 representative values via SELECT DISTINCT queries, prioritizing columns whose values overlap with question terms. This grounds the model in real data, preventing hallucinated string literals in WHERE clauses.

Matched values. We embed both the question and all database cell values using BGE-M3 [41]. Next, we return the top five cell values with cosine similarity scores above 0.40. This approach helps match cross-lingual entity references; for example, a word for “Netherlands” in another language in the question will map to the exact English cell value in the database.

An entity-gating filter skips the matched values component for numeric or count-only questions that contain no text entities to match, reducing noise in the prompt. Both value-injection methods and the gating filter operate on the target-language question concatenated with its English translation hint (Section 3.4), since token overlap and entity detection against English cell values would otherwise be near-empty for non-Latin questions; the G3 ablation (Section 5.3) removes the translation from these uses as well as from the prompt. When many stored values overlap the question, selection for the value-hint block is deterministic: columns are ranked by the number of question tokens overlapping their distinct values; within a column, overlapping values are listed first, and remaining slots (up to the cap of 4 per column) are filled in the stored retrieval order.

3.3. Sample Rows

We include up to 3 sample rows from the most relevant tables in the prompt, based on evidence that including database content can greatly improve text-to-SQL performance [24,27]. Tables are prioritized based on their appearance in the column linking hints (Section 3.5). If no column is linked, or if column linking is disabled in an ablation, tables are selected deterministically in schema order. These concrete data samples help the model infer data types, JOIN key relationships, and value formats without requiring explicit type annotations.

Each table displays up to 6 columns and 3 rows, with values truncated to 15 characters to keep the prompt compact.

3.4. Translation Hints

To bridge the gap between the target language and English schema identifiers, we append a Google Translate English version of the target-language question as a supplementary hint in the prompt, formatted as “(English: translation)”.

This gives the model an English rendition that can clarify schema references, especially for entity names and technical terms that may be transliterated rather than translated in the original question. The English hint provides supplementary context but does not replace the target-language input, allowing the model to leverage both languages during SQL generation. This is particularly important since the base Qwen2.5-Coder-7B-Instruct model was pre-trained predominantly on English data. The English hint is never dropped during training (Section 3.6.2) because it is cheap, always available, and provides a reliable backup signal.

3.5. Column Linking

One of the main challenges in non-English text-to-SQL is connecting question tokens in the target language to English schema elements. We use BGE-M3 [41], a multilingual embedding model, to compute the cosine similarity between the full question embedding and each column embedding. Each column embedding concatenates the English column name with its native-language description (e.g., “Country: <native description>”). The top-$K=6$ columns above a similarity threshold of 0.50 are injected as explicit schema-linking hints.

This approach uses bilingual embeddings to link schemas across languages without needing to translate schema elements directly. It works consistently across all three languages because BGE-M3 supports over 100 languages. The idea of supplying explicit schema-linking hints ahead of SQL generation follows DTS-SQL [22]; unlike DTS-SQL, which fine-tunes a model for schema linking, we use a frozen multilingual embedding so that the same linker serves every language without retraining.

3.6. Prompt Design and Training

We fine-tune Qwen2.5-Coder-7B-Instruct [44] using a QLoRA [42] adapter with rank 64 and $\alpha =128$. The Qwen2.5-Coder models are built for code generation and show strong multilingual performance in both programming and natural languages.

3.6.1. Prompt Template

The prompt consists of a system message that establishes the [Language]-to-SQL task and a structured user message assembling eight template variables. Five are the enrichment components introduced above: value_hints and matched_values (the two slots of value injection, Section 3.2), column_hints (Section 3.5), sample_rows (Section 3.3), and translation_hint (Section 3.4); all except the translation hint are subject to training-time dropout (Table 2). Three are always present: the schema (M-Schema representation), a compact table_summary (table→columns reference), and the question itself. The system message text and the complete prompt template layout are provided in Appendix A. The target output during training is the gold SQL query wrapped in a ‘‘‘sql… ‘‘‘ code block.

3.6.2. Feature Dropout for Prompt Alignment

We train the QLoRA adapter with the same prompt structure used at inference, applying per-feature random dropout during training. Table 2 summarizes the dropout configuration, which exposes the model during training to the fallback prompt layouts it may encounter at inference. Column hints receive the highest dropout rate (40%) as the noisiest feature (we discovered many columns were not linked correctly). The translation hint and table summary are never dropped: they are cheap, always available at inference, and provide a stable reference signal. When M-Schema is dropped, the prompt falls back to raw DDL. When other features are dropped, their prompt section is simply omitted. This teaches the model to leverage features when present but degrade gracefully when absent.

3.7. Multi-Temperature Self-Consistency Voting

At inference time, we generate 8 SQL candidates using a multi-temperature sampling strategy: 1 greedy decode, 2 candidates at temperature $T=0.3$, 3 at $T=0.7$, and 2 at $T=1.1$. This provides a balance between high-confidence predictions and diverse alternatives. All candidates are drawn with nucleus sampling ($p=0.95$) and a 300-token generation cap.

We then use execution-based self-consistency voting [29]. Each candidate SQL query is run on the database, and those that produce the same result set are grouped together. Candidates that fail to parse or cause an execution error are excluded from voting. On our development sets, 4.8 to 6.6% of candidates fail execution (6.6%, 4.8%, and 5.6% for Arabic, Japanese, and Vietnamese). Each query is limited to 60 s, and any that time out are also considered execution failures. All database connections are opened in SQLite read-only mode (mode = ro URI), so any statement that attempts to modify the database fails at the driver level and is counted as an execution failure, and the released harness additionally rejects any candidate whose first keyword is not SELECT or WITH. In practice, the safeguard is never exercised: across the initial candidates generated by the eight-candidate voting configurations of the unified evaluation and the sensitivity sweep (Section 5.4; eight such runs of 8 × 1034 candidates for Arabic and Vietnamese and 12 for Japanese, excluding the candidate-expansion evaluation and self-correction retries), zero non-SELECT statements were generated. The group with the most candidates wins (ties between equal-sized groups are broken toward the group containing the lowest-temperature candidate), and from this group, we pick the shortest SQL string as the final prediction. This is a simple way to choose among candidates that give the same result. If all candidates fail execution, the sample enters the low-confidence candidate expansion of Section 3.8 with $\kappa =0$; if that run also yields no executable candidate, we return the greedy candidate. All initial candidates fail for only 3 to 6 out of 1034 samples per language (6, 3, and 4 for Arabic, Japanese, and Vietnamese). This method reliably removes syntactically invalid candidates and outliers with minority results, but it cannot catch cases where most candidates agree on an incorrect answer. In these cases, the wrong answer will still be chosen. Empty result sets count as regular votes.

3.8. Execution-Guided Repair Stage

The execution-guided repair stage comprises five procedures. In the released implementation, identifier fixing, hallucinated-filter removal, and value-literal grounding are applied to each candidate before voting, while the low-confidence candidate expansion and then error-feedback self-correction operate on the voted output, in that order (Algorithm 1, Steps 4–5). These procedures operate on the generated SQL text and the database, never on the gold annotation.

Identifier fixing. Table and column names in the predicted SQL that do not exist in the schema are fuzzy-matched against schema identifiers (character-level similarity threshold 0.7) and replaced with the closest valid identifier.

Hallucinated-filter removal. WHERE-clause predicates referencing columns absent from the schema are removed.

Value-literal grounding. String literals in WHERE clauses are matched against actual database cell values (similarity threshold 0.70) and replaced with the exact stored value, correcting casing and formatting divergences.

Low-confidence candidate expansion. If the winning group in the initial eight-candidate run holds three or fewer votes, a second eight-candidate run is generated using a raw-DDL prompt variant and the same multi-temperature schedule, under the distinct per-sample seed $s_2\left(q\right)$ of Section 4.4, so that the second run is independent of the first yet exactly reproducible. Vote confidence is the winning-group size divided by the eight generated candidates; the fallback prediction replaces the initial prediction only when its vote confidence is strictly higher. This fallback was attempted on 7.8–9.8% of samples (101, 90, and 81 of the 1034 samples for Arabic, Japanese, and Vietnamese, respectively) and was retained for 48, 47, and 51 samples, respectively.

Error-feedback self-correction. If the selected query still fails to execute, the model is re-prompted with the database error message, for at most two retries. This fires rarely (2, 1, and 3 of the 1034 samples for Arabic, Japanese, and Vietnamese). It fires less often than the 6, 3, and 4 samples on which every initial candidate fails (Section 3.7) because those samples have $\kappa =0$ and therefore trigger the low-confidence candidate expansion first, which supplies an executable candidate for most of them; self-correction is reached only when both runs leave the selected query non-executable.

The repair stage contributes +0.4, +1.1, and +0.4 pp EX for Arabic, Japanese, and Vietnamese, respectively (Section 5); its effect is statistically significant only for Japanese (McNemar’s exact test against the repair-disabled ablation: EX p = 0.019, ESM $p=1.3\times {10}^{-3}$), not for Arabic (EX $p=0.36$, ESM $p=0.58$) or Vietnamese (EX p = 0.45, ESM p = 0.21). We report the repair stage as an explicit, separately ablated part of the system: all comparisons in Section 5 include a repair-disabled variant so that the contribution of the underlying model and prompt components can be assessed independently.

Algorithm 1 gives the complete formal specification of the inference pipeline as a composition of the typed stages of Table 1; Section 3.9 explains the rationale for each step. The full prompt template and slot formats are reproduced in Appendix A.

3.9. Design Rationale

Each step of Algorithm 1 exists for a stated reason. Step 1 computes the language-dependent evidence used by the prompt. The method does not require replacing executable English schema identifiers with translated identifiers; translated descriptions are nevertheless used as auxiliary prompt context. Bilingual embedding-based column linking maps the target-language question directly to the original English identifiers, while value hints, matched values, and sample rows (H, M, R) help a value-predicting generator reproduce WHERE-clause literals exactly as stored; the grouped ablation G2 shows that this evidence family is the single most important group in every language. Step 2 defines both the normal M-Schema prompt and the raw-DDL fallback prompt over the same evidence, differing only in the schema slot, which makes the fallback a precisely defined schema-rendering change rather than an implicit prompt variant. Step 3 trades one greedy decode for candidate diversity, applies the three deterministic database-checkable repairs before voting, and lets execution results define equivalence classes. The modal execution-result group is selected, with the deterministic tie rules of Table 1; within that group the shortest SQL is chosen. The vote fraction $\kappa$ is retained as an empirical confidence-ranking signal because higher vote counts are strongly associated with higher EX (Section 5.2); it is used only to rank confidence, not as a probability estimate. Step 4 spends extra compute only when $\kappa \le 3/8$ and accepts the raw-DDL run only when its vote fraction is strictly larger. Step 5 applies error-feedback self-correction last and preserves the prompt corresponding to the retained run through $P^{*}$; it is rare (2, 1, and 3 samples per language) because the candidate-expansion fallback resolves most all-candidates-fail cases first. Step 6 returns the resulting SQL. The typed stages of Table 1 are also the units of the ablation study (Section 5.3), so every ablation removes one function or one named set of functions from the specification.

4. Experimental Setup

4.1. Dataset

We evaluate on three cross-domain text-to-SQL benchmarks:

Ar-Spider [11] is an Arabic translation of Spider. In the benchmark files used in this study, we load 8659 training questions and 1034 development questions across 166 databases (146 training and 20 development databases). The dataset was created through manual translation of the English Spider dataset by two qualified translators and verified by three graduate computer science students who are native Arabic speakers.

MultiSpider-JA (Japanese) and MultiSpider-VI (Vietnamese) are drawn from the MultiSpider benchmark [12], which extends Spider to seven languages. Each contains 8659 training and 1034 development samples across the same 166 Spider databases.

For all three languages, we use the standard split: the training set for fine-tuning and the development set (1034 samples) for evaluation. Of each 8659-sample training set, 5% (433 samples) is held out as a validation split (Section 4.4), so 8226 examples per language feed gradient updates; the counts in Table 3 refer to the released files. The databases and SQL queries remain in English, while only the natural-language questions are in the target language as given in the original datasets. Following Spider’s cross-domain protocol, the development-set databases are disjoint from the training-set databases in all three benchmarks, so every result reported in this paper is measured on databases and schemas never seen during fine-tuning. The development sets are held out from model training and schema-disjoint, but the Arabic development set was additionally used to fix the pipeline constants (Section 4.4); Japanese and Vietnamese, on which no constant was selected, are therefore the cleaner transfer tests. None of the three benchmarks releases a target-language test split (all were translated while the Spider test set was still hidden), and every published baseline in Table 4 likewise reports development-set results; all comparisons in this paper are therefore like-for-like on the same held-out-database split.

Table 3. Programmatic cross-language split-overlap audit for the three target-language benchmarks. Pairwise entries are order-free multiset intersections of $(\mathtt{db}\_\mathtt{id},\mathrm{gold}\mathrm{SQL})$ pairs; $m/m$ denotes complete multiset identity.

Split	Arabic (n/DBs)	Japanese (n/DBs)	Vietnamese (n/DBs)	Shared DBs/Union
Train	8659/146	8659/146	8659/146	146/146
Dev	1034/20	1034/20	1034/20	20/20
Split	Arabic–Japanese	Arabic–Vietnamese	Japanese–Vietnamese
Train	8659/8659	8659/8659	8659/8659
Dev	1034/1034	1034/1034	1034/1034

All three pairwise comparisons are therefore multiset-identical in both train and development splits.

Table 4. Exact Set Match (ESM) accuracy (%) on development sets.

Language	System	ESM
Arabic	LGESQL + mBERT + CSR 1	55.4
	S2SQL + XLM-R + CSR 1	64.0
	LGESQL + XLM-R 1	65.6
	LGESQL + XLM-R + CSR 1	66.63
	Ours	65.9 [63.0, 68.8]
	Ours + Normalization (diagnostic)	67.0 [64.1, 69.9]
Japanese	RAT-SQL + XLM-R + SAVe (multilingual) 2	61.6
	Ours	64.1 [61.2, 67.0]
	Ours + Normalization (diagnostic)	65.1 [62.2, 68.1]
Vietnamese	RAT-SQL + XLM-R + SAVe (multilingual) 2	67.8
	Ours	71.3 [68.6, 74.0]
	Ours + Normalization (diagnostic)	72.2 [69.6, 75.0]

¹ Baselines from [11], we compare their strongest four configurations reported in [11]. ² Baselines from [12]. Brackets give 95% bootstrap confidence intervals ($B=\mathrm{10,000}$). Raw Spider ESM (the unmodified original Spider ESM evaluator) is the primary comparison metric; normalization is a secondary diagnostic (Section 4.2). Bold marks results above all published baselines on the raw metric. For Arabic, our raw ESM (65.9) lies 0.7 pp below the strongest baseline (66.63, reported with two decimals by its authors); the normalized diagnostic (67.0) is numerically above it. All flipped verdicts under normalization are execution-verified (Section 4.2). Baseline values are as reported by their authors (Section 4.3).

The four language versions are parallel by construction, and Table 3 quantifies the overlap directly. Our programmatic audit verifies complete identity across the three target-language copies in both released splits. In training, Arabic, Japanese, and Vietnamese each contain 8659 samples over the same 146 databases, and every pair has an order-free multiset intersection of 8659/8659 $(\mathtt{db}\_\mathtt{id},\mathrm{gold}\mathrm{SQL})$ pairs. In development, each contains 1034 samples over the same 20 databases, with 1034/1034 identical pairs for every language pair. For both splits, the number of databases shared by all three languages equals the union size (146/146 for training and 20/20 for development). English Spider is the source benchmark and uses the same 8659/1034 train/development instance counts and the same 146/20 database partition. Thus, the databases, gold SQL, and query structures are held fixed across language versions; only the natural-language questions differ. Two consequences follow. First, the English-to-target differences measured against the English reference run (Section 5.5) are same-pipeline performance gaps on parallel Spider instances: the databases, gold SQL, and query structures are held fixed, which controls task structure, but the language-specific training data, adapter, native-language descriptions, and translation-hint content also differ, so the gaps do not isolate a causal effect of question language. Second, the shared, parallel structure is why joint multilingual training on these benchmarks cannot isolate cross-lingual transfer (Section 7): concatenating the target-language training sets would expose the model to three renderings of identical SQL targets.

English reference run. To help interpret the cross-lingual results, we also run the same pipeline on the original English Spider dataset [1], which has 8659 training and 1034 development samples using the same databases. In English, the translation-hint slot simply repeats the question, so no external translation service is needed, and the column-description dictionaries are empty because the schema identifiers are already in English. All other components, hyperparameters, and inference steps, including voting and the repair stage, stay the same. We train a separate QLoRA adapter on the English training set, just as we do for the other languages.

4.2. Evaluation Metrics

We report the following metrics:

Execution Accuracy (EX): A prediction counts as correct if running both the predicted and gold SQL on the database returns identical result sets. EX is the most semantically faithful standard metric because it checks values, joins, and logic together. We report single-instance EX: queries are executed against the single database instance shipped with each benchmark, so a semantically different query can coincidentally return the gold result set on that instance, particularly for small databases. Test-Suite Accuracy [16] mitigates this by executing against multiple distilled instances. Because the three benchmarks share Spider’s development databases and gold SQL (Table 3), the Spider test-suite databases are applicable in principle, but no prior work on these benchmarks has reported test-suite accuracy, and we leave it to future work; our EX figures should therefore be read as upper bounds subject to coincidental-match false positives. This limitation applies symmetrically across our three languages and configurations.

Exact Set Match (ESM): The original Spider exact set match metric [1], and the metric reported by every baseline in Table 4, breaks down both the predicted and gold SQL into parts like SELECT columns, WHERE conditions, GROUP BY, ORDER BY, HAVING, and IUEN set operations, then checks if each part matches as a set. ESM works without considering values (DISABLE_VALUE = True in the evaluation script) and without DISTINCT (DISABLE_DISTINCT = True), so it only checks if the structure is correct.

Understanding the distinction between EX and ESM is essential for interpreting our results. EX evaluates functional correctness by determining whether the query returns the correct answer, regardless of the specific SQL formulation. In contrast, ESM assesses structural conformity, examining whether the query employs the same SQL patterns as the gold annotation. A query may satisfy EX but not ESM if it adopts a different, yet semantically equivalent, structure, such as using a NOT IN subquery instead of EXCEPT. Conversely, a query may conform to ESM but fail EX if it exhibits the correct structure but yields incorrect results due to erroneous values, which ESM does not account for. This distinction is central to the analyses in Section 5 and Section 6.

Because a share of ESM failures reflect well-defined structural alternatives rather than semantic errors, we additionally report a normalized ESM that applies four instance-validated diagnostic rewrites, each restricted by structural guards to the query shapes under which the two forms yield the same ESM verdict (Appendix B states the guards and the cases in which the rewritten form is not an executable equivalent: Boolean precedence, duplicate rows, NULLs, and empty tables): NOT IN versus EXCEPT, MIN/MAX versus ORDER BY LIMIT 1, literal IN-lists versus OR-chains, and BETWEEN versus explicit range predicates. The normalization is gold-blind at application time: identical rewrite rules are applied to both predicted and gold SQL before comparison, and no rule is conditioned on the gold annotation. The rewritten strings are used only for the ESM comparison and are never executed; the execution check below is always performed on the original, unrewritten prediction. We disclose that the rule set itself was selected on the same development predictions: candidate rules were kept only if every ESM verdict they flipped was execution-correct, which is how the fifth rule below was rejected; the diagnostic is therefore validated on, not independent of, the evaluated instances, and its execution check inherits the single-instance limitation of EX. We accordingly describe the rules as verdict-preserving canonicalizations validated by execution, not as semantic equivalences. The rewrites are consequently reported as a secondary diagnostic and never as the comparison metric. We validate the rules empirically: every development sample whose ESM verdict flips from incorrect to correct under normalization is checked against its execution outcome. On the unified-harness headline predictions for all three languages, 100% of flipped verdicts are execution-correct (12/12, 10/10, and 10/10 for Arabic, Japanese, and Vietnamese), no correct verdict is lost, and no gold query or parseable prediction becomes unparseable. A fifth candidate rule (integer-threshold rewriting, $>N\to \ge N+1$) was evaluated under the same protocol and rejected: because ESM disables value comparison, the rewrite erased genuine boundary differences and produced execution-incorrect flips on Japanese; we report this negative result as evidence that the protocol constrains the rule set. The unified-harness predictions confirm the rule remains unsound in every language, producing execution-incorrect flips in Arabic and Vietnamese as well as Japanese. Per-rule conversion counts on both predicted and gold SQL are produced by the released evaluation scripts, confirming the symmetry of application; Algorithm A1 in Appendix B reproduces the implementation as executable pseudocode, and Table A1 reports, per rule, how many queries were considered, rejected by a guard, and rewritten, together with the flip counts. We additionally report 95% confidence intervals for all headline proportions (nonparametric bootstrap, $B=\mathrm{10,000}$, over per-sample outcomes) and use McNemar’s exact test for paired within-system comparisons. We use McNemar’s test rather than a paired t-test because per-sample correctness is binary: the t-test assumes approximately continuous paired differences, while McNemar’s is the exact paired analogue for 0/1 outcomes. The reported p-values are unadjusted and should be interpreted as exploratory evidence across the multiple component and sensitivity comparisons. The rules are reproduced with examples in Appendix B.

4.3. Baselines

For Arabic, we compare against all results reported in the Ar-Spider paper [11]. These use two GNN-based parsers (LGESQL [19] and S2SQL [20]) with two cross-lingual encoders (mBERT [39] and XLM-R [40]), optionally augmented with the context similarity relationship (CSR) approach. All baselines report ESM only; their published configurations use value-agnostic decoding and therefore do not provide a directly comparable end-to-end execution-accuracy result.

For Japanese and Vietnamese, we compare against the strongest multilingual SAVe configuration reported in MultiSpider [12]: RAT-SQL + XLM-R + SAVe, evaluated using exact set match, with reported ESM scores of 61.6% for Japanese and 67.8% for Vietnamese. Two more recent studies use the same MultiSpider development sets but are not included in Table 4: the COLA agent framework of [13] relies on zero-shot prompting of the proprietary OpenAI-o1 model and reports 43.4% exact match for Japanese, below SAVe, and the contrastive-reward study of [15] targets a different model class (a 3B model trained with GRPO) under its own evaluation protocol. Because these two studies differ from ours in model access, model scale, or evaluation protocol, their figures are not directly comparable, and the multilingual RAT-SQL + XLM-R + SAVe configuration remains the strongest comparable published MultiSpider baseline for Japanese and Vietnamese. The baseline values in Table 4 are as reported by their authors: neither the Ar-Spider nor the MultiSpider release includes prediction files or a runnable training configuration for its strongest system, so the baseline outputs could not be re-scored under our harness. The comparison therefore uses the same nominal original Spider ESM protocol reported by the baseline studies, including disabled value and DISTINCT comparison. However, because the original baseline predictions were unavailable, we could not re-score them under our exact evaluator implementation and software environment; minor implementation- or version-level differences therefore cannot be ruled out.

4.4. Implementation Details

We fine-tune Qwen2.5-Coder-7B-Instruct using QLoRA with rank 64, alpha 128, and adapter dropout 0.05 (distinct from the prompt-level feature dropout of Section 3.6.2). Training uses a learning rate of $5\times {10}^{-5}$ with cosine scheduling over 3 epochs (1029 optimizer steps at an effective batch size of 24). The maximum sequence length is 4096 tokens. Fine-tuning is performed on a single NVIDIA A100 GPU (NVIDIA Corporation, Santa Clara, CA, USA). A separate adapter is trained for each language using the respective training set, following the modular per-language-adapter design of adapter-based cross-lingual transfer frameworks [47]; the architecture, prompt template, hyperparameters, and inference procedure are identical across languages, with only the training data, native-language column descriptions, and translation hints differing. The native-language column descriptions require no manual authoring: for Arabic, they are generated automatically using Google Translate, whereas for Japanese and Vietnamese they are obtained from the schema translations released with MultiSpider; missing translations are automatically filled using Google Translate. The English reference run (Section 4.1) uses the same procedure with the identity translation hint and empty description dictionaries. The base-model transferability experiment (Section 5.6) instantiates the same pipeline on Llama-3.1-8B-Instruct with no other changes, including the 60-s per-query execution limit of Section 3.7. During inference, we generate eight candidates using the multi-temperature strategy of Section 3.7, followed by the repair stage of Section 3.8. All results reported in this paper (the full system, every single-component and grouped ablation, the exact no-voting/no-repair control, and the minimal baseline) come from a single evaluation harness run under one set of library versions, with deterministic per-sample sampling seeds (base seed 1234 combined with a hash of the sample identifier and with the run index, so each sample receives the same seed regardless of run order; the initial eight-candidate run uses $s_1\left(q\right)$ and the raw-DDL candidate-expansion run of Section 3.8 uses the distinct seed $s_2\left(q\right)$ obtained from the second run index), and exact set match computed per sample with the original Spider ESM evaluator. Unless stated otherwise, every percentage-point difference quoted in the text is the difference of the rounded values shown in the tables; normalization gains are exact flipped-verdict counts divided by 1034. All pipeline constants (column-linking threshold $\tau =0.50$ with top-$K=6$, matched-value similarity threshold 0.40, value-grounding threshold 0.70, fuzzy-identifier threshold 0.7, and the 1/2/3/2 temperature schedule) were fixed once during preliminary exploration on the Arabic development set, before any Japanese or Vietnamese experiments, and reused unchanged for all languages, the English reference run, and the Llama-3.1 run; none were tuned per benchmark. The reuse of the same configuration across four languages and two base models provides evidence of cross-setting robustness, and Section 5.4 reports a direct sensitivity study of the column-linking threshold and top-K: a retrieval-level analysis of the linker at seven $\tau$/K settings, an end-task sweep of six alternative settings in all three languages, and full-pipeline evaluations at the two extreme settings on Japanese. The component-removal ablation provides complementary context for the magnitude of the column-linking and value-injection contributions under the selected configuration (≤1.3 pp and ≤2.7 pp EX, respectively, Table 5). The base model is loaded in NF4 4-bit double quantization with bfloat16 compute; optimization uses a 0.05 warmup ratio, weight decay 0.01, gradient clipping 1.0, and gradient checkpointing, with a per-device batch size of 6 and gradient accumulation of 4, and 5% of each training set is held out for validation (seed 42). Decoding uses nucleus sampling ($p=0.95$) with a 300-token generation cap and a sampling base seed of 1234. Per-language training and inference wall-clock times, together with the GPUs used, are reported in Appendix C (Table A2). The remaining implementation details, including exact library versions and the training scripts themselves, are contained verbatim in the released code.

Table 5. Ablation study of different component removals under the unified seeded harness.

Row	Configuration	AR	JA	VI
	Full system (Ours)	75.2	74.8	79.9
1	Minimal baseline (greedy)	62.9 ***	66.4 ***	68.6 ***
2	−Column linking	73.9	74.7	79.6
3	−Value injection	72.5 **	74.1	77.8 *
4	−Sample rows	75.2	74.1	79.3
5	−Self-consistency voting	72.9 ***	73.3 **	78.4 **
6	−Repair stage	74.8	73.7 *	79.5
G1	−All schema grounding	73.3 *	73.6	77.4 **
G2	−All value grounding	67.9 ***	70.0 ***	74.2 ***
G3	−Translation everywhere	74.4	73.7	77.7 *
G4	−Voting − repair (greedy control)	71.1 ***	71.4 ***	76.8 ***

The prefix − denotes the full system with the named component or group removed (e.g., −Repair stage is the full system without the repair stage). Cells give EX (%). Stars denote McNemar significance versus the full system: * p < 0.05, ** p < 0.01, *** p < 0.001.

5. Results

5.1. Main Results

Table 4 and Table 6 present our main results across all three languages. Table 4 compares exact set match (ESM) accuracy against published baselines. Our full system achieves 65.9%, 64.1%, and 71.3% raw Spider ESM for Arabic, Japanese, and Vietnamese, respectively. Already at the raw Spider ESM level, the Japanese and Vietnamese results surpass the strongest multilingual MultiSpider baseline (RAT-SQL + XLM-R + SAVe) by +2.5 pp and +3.5 pp, respectively; the Vietnamese confidence lower bound (68.6) clears the baseline (67.8), while the Japanese lower bound (61.2) does not clear the baseline (61.6), so the Japanese margin is directional rather than interval-separated. The Arabic raw ESM (65.9) lies 0.7pp below the strongest baseline (66.63). Gold-blind normalization (Section 4.2) is reported as a secondary diagnostic: it yields 67.0% [64.1, 69.9], 65.1% [62.2, 68.1], and 72.2% [69.6, 75.0] for Arabic, Japanese, and Vietnamese, i.e., +1.2, +1.0, and +1.0 pp computed as 12, 10, and 10 flipped verdicts out of 1034 (the rounded table values differ by 1.1, 1.0, and 0.9 pp). Under the diagnostic, the Japanese and Vietnamese margins over the multilingual SAVe baseline widen to +3.5 and +4.4 pp, and the Arabic value moves numerically above the strongest baseline (67.0 vs. 66.63), a margin well within the bootstrap uncertainty of our estimate; the primary raw-metric ordering of Table 4 is unchanged by this diagnostic. Relative to the exact greedy control, the full system’s raw ESM is higher by +3.2, +3.5, and +3.0 pp for Arabic, Japanese, and Vietnamese (Table 6), and McNemar’s exact test on the paired per-sample outcomes is significant in all three languages ($p=1.5\times {10}^{-3}$, $6.1\times {10}^{-4}$, and $1.2\times {10}^{-3}$): voting filters degenerate candidates, a benefit visible to both metrics; only 15, 9, and 10 of the 1034 selected queries fail to parse under the original Spider ESM evaluator for Arabic, Japanese, and Vietnamese, and 5, 4, and 4 of these are well-formed SQLite queries containing a literal IN-list, a construct the original Spider ESM parser rejects (Appendix B). The original Spider ESM evaluator’s component-level breakdown identifies set-operation (IUEN) generation as the dominant shared failure mode: it is the lowest-scoring component in every language (35.4%, 27.8%, and 37.3% partial accuracy over the 79, 79, and 83 samples in which a set operation occurs in the gold or predicted SQL, for Arabic, Japanese, and Vietnamese on the unified-harness predictions), well below every other component; this is a genuine capability gap, consistent with our future-work item on EXCEPT/UNION generation, rather than a stylistic preference.

Table 6. EX and raw Spider ESM on the 1034-sample development sets under the unified seeded harness.

	Arabic	Japanese	Vietnamese
EX, full system	75.2 [72.6, 77.8]	74.8 [72.2, 77.4]	79.9 [77.5, 82.3]
EX, −repair stage	74.8	73.7	79.5
EX, greedy (−voting, −repair)	71.1 [68.4, 73.8]	71.4 [68.7, 74.1]	76.8 [74.3, 79.3]
ESM, full system	65.9	64.1	71.3
ESM, −repair stage	65.6	62.8	70.7
ESM, greedy (−voting, −repair)	62.7	60.6	68.3
EX–ESM gap, full system	9.3 pp	10.7 pp	8.6 pp
EX–ESM gap, greedy	8.4 pp	10.8 pp	8.5 pp

The prefix − denotes the full system with the named component removed (e.g., −repair stage is the full system without the repair stage). Brackets give 95% bootstrap CIs ($B=\mathrm{10,000}$). The greedy control is an exact single-decode run under the unified harness. Greedy differs from the full system with $p<{10}^{-6}$ (EX) and $p\le 1.5\times {10}^{-3}$ (ESM) in all three languages (McNemar’s exact test).

The normalization rules are reproduced in Appendix B, and the Ar-Spider translation-error audit that bounds the reported Arabic accuracy is presented in Section 5.7. Table 6 reports single-instance execution accuracy (EX) together with two controlled variants (repair stage disabled, and greedy decoding with both voting and repair disabled); EX is a metric not reported by these baselines, whose published configurations use value-agnostic decoding.

Several patterns emerge across languages. Vietnamese achieves the highest EX (79.9%) and ESM (71.3%). Its use of a Latin-based script may be one of several factors that reduce surface-form distance from English schema identifiers, but the present experiments do not isolate a script effect. Arabic and Japanese achieve nearly identical EX (75.2% and 74.8%) despite their different writing systems, which is consistent with the bilingual embedding-based column linking and translation hints helping across scripts, but does not establish that script family is irrelevant. Ar-Spider and MultiSpider also come from different translation projects, and the languages may differ in pretraining coverage, tokenization, and translation quality; cross-language performance differences should therefore not be attributed to orthography alone. The guarded normalization yields similar modest gains in all three languages (+1.2, +1.0, and +1.0 pp on the unified-harness predictions, i.e., 12, 10, and 10 flipped verdicts out of 1034), the uniformity expected of benchmark-agnostic rules.

The EX–ESM gap is present across all three languages (Table 6): 9.3 pp for Arabic, 10.7 pp for Japanese, and 8.6 pp for Vietnamese under the full system. Crucially, the gap persists at essentially the same magnitude when the repair stage is disabled and in the exact no-voting/no-repair control with both inference-stage procedures removed (8.4, 10.8, and 8.5 pp): removing execution-based voting and repair leaves the gap intact.

Figure 2 visualizes the relationship between EX, ESM, and the normalized ESM across all three languages, clearly illustrating the consistent 8.6–10.7 pp gap and the partial recovery achieved through SQL normalization.

Figure 2. EX, ESM, and normalized ESM across the three languages. The persistent EX–ESM gap mainly reflects generated SQL differences rather than decoding.

5.2. Self-Consistency Voting Analysis

Table 7 shows a strong link between self-consistency vote counts and prediction accuracy in all three languages. This supports the effectiveness of our multi-temperature voting strategy. We illustrate this trend, with vote count and execution accuracy rising together in each language in Figure 3.

Table 7. Execution accuracy by self-consistency vote count. Cells show sample count and EX (%); unanimous predictions achieve 91–94% EX and cover 49–55% of each development set.

Votes	Arabic	Japanese	Vietnamese
1	8 (12.5)	8 (37.5)	3 (33.3)
2	19 (26.3)	9 (0.0)	14 (14.3)
3	35 (37.1)	33 (33.3)	27 (37.0)
4	111 (41.4)	101 (41.6)	81 (38.3)
5	93 (49.5)	84 (45.2)	96 (55.2)
6	112 (66.1)	101 (65.3)	91 (68.1)
7	140 (80.7)	146 (76.0)	146 (86.3)
8	510 (93.7)	549 (91.4)	572 (94.2)
Unanimous (8/8) share of samples	49.3%	53.1%	55.3%
EX on unanimous subset	93.7%	91.4%	94.2%

Cells show sample count and EX (%) within each vote-count stratum. The retained run’s vote count is reported after fallback selection; samples with no initially executable candidate are excluded. Thus, strata summarize pre-repair voting output and need not match final EX.

Figure 3. Execution accuracy by self-consistency vote count across Arabic, Japanese, and Vietnamese. Higher vote counts generally indicate higher accuracy, with unanimous predictions achieving 91–94% EX.

Across all three languages, samples with unanimous agreement (8/8 votes) achieve 91–94% EX accuracy and constitute 49–55% of all samples, providing a highly reliable prediction subset. Vietnamese has the highest proportion of unanimous samples (55.3%), consistent with its highest overall EX, and Japanese and Vietnamese still differ by just over 5 pp EX, showing that performance is not uniform even within one benchmark source. The association between higher vote counts and higher accuracy is consistent across the three benchmarks studied, suggesting that vote count can serve as a practical confidence indicator for deployment; whether this extends to further languages remains to be tested.

5.3. Ablation Study

To measure how much each part of the pipeline contributes, we run an ablation study where we remove one component at a time and keep the rest unchanged, together with the grouped removals of Table 5 (rows G1–G4). Every configuration removes components at inference from the same fine-tuned adapter, which was trained with per-feature prompt dropout (Table 2) and has therefore seen every reduced prompt layout except the two that G3 produces (the English hint was never dropped during training, and native descriptions were never removed while M-Schema was retained), so G3 is an inference-time test of a layout outside the training distribution; nothing is retrained, and all rows come from the unified seeded harness with paired McNemar tests against the full system. The baseline (row 1) includes only raw DDL, the table summary, the target-language question, and the English translation hint with greedy decoding and no repair, which is the simplest setup that works. Table 5 shows the execution accuracy on the development set for each version, and Figure 4 illustrates how removing each part affects performance.

Figure 4. Impact of individual component ablations on EX. Bars show percentage-point changes relative to the full system; value injection and self-consistency voting have the largest effects.

Value injection is the largest and most consistently significant single prompt component: removing it costs $-2.7$ pp EX in Arabic ($p=2.6\times {10}^{-3}$) and $-2.1$ pp in Vietnamese ($p=0.02$); in Japanese its single removal is small ($-0.7$ pp, n.s.), but the grouped removal below shows that this understates the group it belongs to. Using real database content, through both representative column values and BGE-M3 matched entities, is essential for generating correct WHERE-clause literals, especially in cross-lingual cases where entity names in the question might not match their English database versions.

Self-consistency voting is significant in every language: $-2.3$ pp for Arabic ($p=2.7\times {10}^{-4}$), $-1.5$ pp for Japanese ($p=8.1\times {10}^{-3}$), and $-1.5$pp for Vietnamese ($p=5.9\times {10}^{-3}$). The multi-temperature sampling strategy generates diverse SQL candidates, and execution-based voting filters out incorrect alternatives, which is especially valuable in the multilingual setting, where translation ambiguities can produce varied but partially correct candidates. The repair stage (row 6) contributes +0.4, +1.1, and +0.4 pp, largely attributable to the low-confidence candidate-expansion fallback (Section 3.8); its effect is significant only for Japanese.

For the remaining single removals, column linking and sample rows, no statistically significant difference from the full system was detected in any language.

The grouped removals (rows G1–G3) provide the direct test of redundancy. Removing all value-grounding components (G2) costs $-7.3$, $-4.8$, and $-5.7$ pp EX ($p\le 1.9\times {10}^{-6}$ everywhere), substantially more than the drop from any individually tested value-grounding component. This indicates that the components are partially compensatory and that leave-one-out ablations can understate the value of the full group. Removing all schema-grounding components (G1) costs $-1.9$, $-1.2$, and $-2.5$ pp for Arabic, Japanese, and Vietnamese, respectively, with the largest effect in Vietnamese ($p=3.4\times {10}^{-3}$), indicating that the combined schema-grounding mechanisms contribute even when column linking alone has a small effect. Removing the external translation from every use together with the native descriptions (G3) costs at most $-2.2$ pp (significant only in Vietnamese), so the system retains $\ge 97\%$ of its performance when it is fully translation-free at inference; because the adapters were trained with the hint present, this establishes inference-time rather than training-time independence. Finally, removing voting and repair jointly (G4) costs $-4.1$, $-3.4$, and $-3.1$ pp, exceeding the sum of the two single removals ($-2.7$, $-2.6$, and $-1.9$ pp) even though both single removals already exclude the candidate-expansion fallback. The excess indicates that per-candidate repair is worth more without voting than with it: with voting, a candidate with a misspelled identifier or a mis-cased literal is simply out-voted, whereas under a single greedy decode the same error is recoverable only by repair.

The cumulative effect is substantial: the full system outperforms the minimal baseline by 12.3 pp for Arabic, 8.4 pp for Japanese, and 11.3 pp for Vietnamese. The grouped removals indicate that several components are partially redundant and mutually compensating. Establishing the full interaction structure (add-one-in and Shapley-style analysis) remains future work.

5.4. Sensitivity of the Column-Linking Parameters

To determine whether the column-linking threshold ($\tau =0.50$) and top-K ($K=6$), fixed once on the Arabic development set (Section 4.4), are load-bearing, we conduct three analyses: a retrieval-level analysis of the linker alone, varying $\tau \in \{0.30,0.40,0.50,0.60,0.70\}$ at $K=6$ and $K\in \{3,6,10\}$ at $\tau =0.50$, an end-task sweep of six alternative settings under the greedy no-voting/no-repair control in all three languages, and full-pipeline evaluations at the two extreme settings on Japanese, one of the two languages on which no constant was tuned. Table 8 reports the end-task sweep together with the linker’s gold-column recall at each setting, and Figure 5 visualizes the central contrast: retrieval recall varies by an order of magnitude across the swept settings while end-task accuracy barely moves, except for Vietnamese in the greedy regime.

Table 8. Sensitivity of the column-linking parameters. Retrieval columns give the linker’s gold-column recall (%; columns referenced by the gold SQL, $n=992$ samples with at least one such column, identical across languages). EX columns give greedy no-voting/no-repair execution accuracy (%), compared with the default row by McNemar’s exact test: * p < 0.05, ** p < 0.01, *** p < 0.001. The last two rows evaluate the extreme settings under the complete 8-candidate pipeline on Japanese, compared with the full system.

Setting	Arabic		Japanese		Vietnamese
	Recall	EX	Recall	EX	Recall	EX
$\tau =0.30$, $K=6$	77.7	71.1	82.5	70.8	78.8	73.8 **
$\tau =0.40$, $K=6$	76.0	71.3	80.2	70.8	78.0	74.2 *
$\tau =0.50$, $K=6$ (default; greedy control)	59.6	71.1	66.0	71.4	64.6	76.8
$\tau =0.60$, $K=6$	24.0	70.8	33.4	71.1	31.1	72.6 ***
$\tau =0.70$, $K=6$ (linker effectively off)	4.0	69.5	6.2	71.0	6.0	72.1 ***
$\tau =0.50$, $K=3$	50.9	70.3	57.6	70.5	54.4	74.0 **
$\tau =0.50$, $K=10$	62.3	69.9	67.8	71.5	68.3	73.8 **
Full pipeline, $\tau =0.30$, $K=10$ (loosest)	–	–	91.4	74.8	–	–
Full pipeline, $\tau =0.70$, $K=3$ (strictest)	–	–	6.2	74.5	–	–

Full-pipeline reference: Japanese full system 74.8% EX. Neither extreme differs from it (loosest: $\Delta$ 0.0 pp, $p=1.0$; strictest: $-0.3$ pp, $p=0.76$).

Figure 5. Column-linking sensitivity across languages. Panels vary $\tau$ and top-K around the default, showing linker recall and greedy EX; Japanese extreme settings also include full-pipeline results. Stars mark settings whose greedy EX differs significantly from the default setting ($\tau =0.50$, $K=6$) by McNemar’s exact test: * $p<0.05$, ** $p<0.01$, *** $p<0.001$; no Arabic or Japanese setting reaches significance, so stars appear only in the Vietnamese panels.

Three findings emerge. First, the retrieval behavior is shared across languages: recall at the default setting is 59.6–66.0% at 43–48% precision, rises to 77.7–82.5% at $\tau =0.30$, falls to 24.0–33.4% at $\tau =0.60$, and collapses to 4.0–6.2% at $\tau =0.70$, where the linker emits almost no hints (0.07–0.13 per question). Across the swept settings, the threshold dominates top-K, because the bilingual embedding similarities concentrate in the 0.3–0.6 band; the chosen setting is a precision-leaning operating point on this curve, not a recall-maximizing or finely tuned one.

Second, Arabic and Japanese end-task accuracy is insensitive to the setting: no alternative differs significantly from the default on EX (Arabic $p\ge 0.17$, Japanese $p\ge 0.23$; the largest Japanese movement is 0.9pp), even though retrieval recall varies from 4% to 83% across the same settings. The only other significant result outside Vietnamese is Arabic ESM at $\tau =0.70$ ($-2.6$ pp, $p=0.018$), the setting at which the linker is effectively disabled; its EX drop ($-1.6$ pp) is consistent with the no-column-linking ablation of Table 5.

Third, Vietnamese is the exception, and the exception is informative. Under greedy decoding, every alternative setting is significantly worse ($-2.6$ to $-4.7$ pp EX, $p\le 0.013$), in both directions of both parameters: the default is a sharp optimum. That the optimum falls exactly at constants fixed on Arabic is, as far as we can tell, a coincidence of the Vietnamese embedding-similarity distribution rather than evidence of tuning, since no Vietnamese result informed the choice. Under the full pipeline, however, removing column linking entirely costs Vietnamese only $-0.3$ pp (n.s., Table 5 row 2), and the Japanese full-pipeline extremes in Table 8 show the same absorption directly: the loosest setting reproduces full-system EX exactly ($\Delta$ 0.0 pp) and the strictest costs 0.3 pp (n.s.), despite retrieval recall spanning 6% to 91% between them. We note the limit of this evidence: the full-pipeline extremes were run on Japanese, whose greedy accuracy is already insensitive to the setting, so for Vietnamese, the one language where greedy sensitivity was found, the absorption is inferred from the full-pipeline column-linking ablation rather than tested at every setting. Within that limit, the linker’s configuration matters only in the no-voting/no-repair regime, and execution-based voting and repair appear to absorb its perturbations. This is a further manifestation of the inference-stage compensation seen in the grouped ablations of Section 5.3 (the super-additive G2 and G4 removals), and it is the mechanism by which the pipeline tolerates an intentionally simple retrieval component. We conclude that the reported full-pipeline results do not appear to depend on fine-tuning of $\tau$ or K; the adapters were trained with 40% dropout on the column-hint block (Table 2), which is why varying the linking parameters at inference is a within-distribution test rather than an out-of-distribution one.

Scope of the decoding-temperature analysis. The multi-temperature schedule (0, 0.3, 0.3, 0.7, 0.7, 0.7, 1.1, 1.1) was held fixed throughout all experiments and was not independently swept. A controlled temperature analysis requires regenerating and executing the complete candidate set for every development example under each alternative schedule; because the unified seeded evaluation, grouped ablations, and the column-linking sensitivity experiments already required repeated full-candidate generation, we could not add a sufficiently powered temperature sweep within the available computational budget. We therefore make no claim that the chosen temperature schedule is optimal or temperature-insensitive. A systematic comparison of alternative temperature allocations is left to future work.

5.5. English Reference Run and Same-Pipeline Performance Gap

Table 9 reports the English same-pipeline reference run. The full system reaches 85.3% EX [95% CI: 83.0, 87.4] on the English Spider development set. We present this as a same-pipeline reference point rather than as an English leaderboard entry: English Spider has an extensive, separately maintained literature, and the purpose of this run is to decompose our multilingual results into two interpretable quantities.

Table 9. English same-pipeline reference run and the resulting English-to-target performance gaps on parallel Spider instances. The identical documented pipeline (identity translation hint; empty native-description dictionaries; all other components unchanged) is trained and evaluated on the original English Spider. Gaps are the differences in the reported accuracies.

Quantity	Value
EX, English reference (full system)	85.3 [83.0, 87.4]
Same-pipeline gap: English → Arabic	$-10.1$ pp
Same-pipeline gap: English → Japanese	$-10.5$ pp
Same-pipeline gap: English → Vietnamese	$-5.4$ pp

For external context: a fine-tuned open-source Llama-3-8B reaches 78.9% EX on the Spider test set [24], while state-of-the-art systems built on much larger or proprietary models exceed 90% [10].

The first quantity is the same-pipeline English-to-target performance gap on parallel Spider instances: the difference between the English reference and each target-language run while the databases, gold SQL, query structures, architecture, constants, and inference procedure are held fixed. Arabic and Japanese show similar gaps of $-10.1$ and $-10.5$ pp despite their different writing systems, while Vietnamese shows a smaller gap ($-5.4$ pp). These are matched benchmark performance gaps, not isolated causal effects of question language: each target-language run uses language-specific training data and adapter weights, native-language descriptions, and non-identity translation-hint content, whereas the English run uses English training data, empty description dictionaries, and an identity hint. The pattern is nevertheless useful for comparing performance under the same pipeline design on parallel Spider instances, and it is consistent with the hypothesis that Latin-script overlap may contribute to Vietnamese’s smaller gap; script cannot be isolated from other language- and dataset-level factors in the present experiments. The near-equal Arabic and Japanese gaps further suggest that writing-system differences alone do not explain the observed degradation. The second quantity is the setup capacity: the distance between our English reference (85.3% on the development split) and the >90% state of the art (reported on the hidden test split) reflects the 7B open-source setting rather than the multilingual method, and our English figure sitting above the fine-tuned open-source Llama-3-8B anchor (78.9% on test [24]) confirms the pipeline itself is competitive in the English setting.

Two internal statistics corroborate this reading. Vote unanimity is highest on English (63.6% of samples are unanimous at 8/8 votes, vs. 49–55% for the target languages, with EX on the unanimous subset in the same 91–94% range), and repair-stage activity is lowest (the low-confidence fallback is attempted on 33 English samples vs. 81–101 for the target languages): both inference-stage procedures are more active in the target-language settings than in English, consistent with cross-lingual ambiguity contributing substantially to the residual difficulty.

5.6. Base-Model Transferability

Table 10 evaluates whether the pipeline’s performance depends on its base model. We fine-tune Llama-3.1-8B-Instruct [48] on the Arabic training set with the identical pipeline, data, hyperparameters, and inference procedure. Only the base model changes. Llama-3.1 reaches 74.6% EX [95% CI: 72.0, 77.2], within 0.6 pp of the Qwen2.5-Coder result (75.2%) and well inside its confidence interval. Compute constraints limited this second-model run to one language; we selected Arabic as the benchmark with the tightest baseline margin.

Table 10. Base-model transferability on Arabic (Ar-Spider dev): the identical pipeline instantiated on two base models. Only the base model changes; training data, hyperparameters, prompt components, voting, and the repair stage are held fixed.

Base Model (Identical Pipeline)	EX
Qwen2.5-Coder-7B-Instruct	75.2 [72.6, 77.8]
Llama-3.1-8B-Instruct	74.6 [72.0, 77.2]

This near-parity carries two implications. First, the pipeline’s gains are not an artifact of one base model’s idiosyncrasies: a general-purpose instruction-tuned model, without Qwen-Coder’s code-specialized pretraining, achieves comparable execution accuracy under the same prompt-enrichment and inference-stage procedures, with a difference of only 0.6pp relative to Qwen2.5-Coder. Second, the experiment provides some robustness against a model-specific explanation of the result, although it cannot rule out benchmark contamination. Spider is a widely used benchmark whose English content may have appeared in the pretraining corpora of either base model, and we therefore do not use this experiment as a contamination test. Instead, the relevant observation is that two models with different pretraining objectives and architectures reach similar Arabic EX under the same pipeline. In addition, within Qwen2.5-Coder itself, the full system exceeds the minimal configuration of Table 5 by 8.4–12.3 pp EX while holding the base model and fine-tuning data fixed. These results indicate that the reported gains are not uniquely attributable to Qwen2.5-Coder, while leaving possible benchmark exposure as an unresolved limitation.

5.7. Dataset Translation Errors

We conducted a manual, full-dataset quality audit of Ar-Spider, covering both the development set (1034 samples) and the training set (8659 samples), and identified 149 translation errors in which the Arabic question diverges from the intent of the gold SQL query: 15 in the development set (1.45%) and 134 in the training set (1.55%). Table 11 reports the distribution across four error categories, and Figure 6 presents representative examples of each.

Table 11. Systematic audit of translation errors in Ar-Spider, by error class and split. Classes (a), (b), and (d) are value-level errors, visible only to execution-based evaluation (ESM disables value comparison); class (c) is structural and ESM-visible. Notably, no structural errors occur in the development set.

Error Class	Dev	Train	Total
(a) Entity mistranslation	13	91	104
(b) Value typo/error	1	11	12
(c) Added/dropped columns & constraints	0	27	27
(d) Transliteration mismatch	1	5	6
Total	15	134	149

Figure 6. Representative translation errors in the Ar-Spider dataset. Each entry shows the original Arabic question, its English meaning, the gold SQL clause, and the identified mismatch. In each case, a model faithfully following the Arabic input would be penalized by the evaluation.

Entity mistranslation (Figure 6a). The Arabic question asks about the most spoken language in “Europe,” but the gold SQL filters for WHERE T1.Name = "Aruba". The original English Spider question referred to Aruba; however, the Arabic words for “Europe” and “Aruba” differ by only a single character, and the translator selected the wrong one. A model that correctly grounds “Europe” through value injection would search for European countries, producing a query that disagrees with the gold SQL.

Value typo (Figure 6b). The Arabic question refers to airport code “ACO,” while the gold SQL filters for AirportCode = “AKO”. This is a typographical error introduced during translation. Any model that faithfully uses the value stated in the question will be penalized.

Added column in translation (Figure 6c). The Arabic question asks for employee “names and ages” sorted by age, but the gold SQL is SELECT name FROM employee ORDER BY age, selecting only the name column. The translator added the phrase “and their ages” that was not present in the original English question, creating a mismatch between the Arabic intent and the gold annotation.

Transliteration mismatch (Figure 6d). The Arabic question asks about a person whose name transliterates to “Kelly” or “Keely” in English, but the gold SQL filters for WHERE T2.name = "Kyle". The correct Arabic transliteration for “Kyle” would use different characters. A model performing faithful cross-lingual entity matching would produce the wrong value.

These errors create an inherent evaluation ceiling: a model that correctly follows the Arabic question is penalized because the gold SQL reflects the original English intent rather than the translated Arabic text. The audit quantifies this ceiling precisely. In the development set, 15 samples (1.45%) carry confirmed errors, so correcting them could raise the Arabic EX ceiling by at most 1.5 pp; our reported EX of 75.2% is, in this respect, conservatively biased by dataset noise (while remaining an upper bound with respect to single-instance evaluation, Section 4.2). The metric-visibility structure of the errors matters: all 15 development-set errors are value-level (entity mistranslations, value typos, and transliteration mismatches), which affect primarily execution-based evaluation because ESM disables value comparison, while the ESM-visible structural class (added/dropped columns) does not occur in the development set at all. A value-level error can still reach ESM indirectly when a faithful reading of the mistranslated entity changes the query structure (for example, grounding “Europe” rather than “Aruba” may require a different filter column or join), so the audit bounds our EX figures directly and affects the ESM comparison against baselines only through such second-order cases. The 134 training-set errors (1.55%) act as label noise during fine-tuning; their similar rate across splits suggests a systematic property of the translation process rather than split-specific artifacts. Datasets were used exactly as released; none of the identified errors were corrected or excluded from training or evaluation.

6. Discussion

Our results across three languages highlight a fundamental tension in text-to-SQL evaluation. ESM was designed for grammar-constrained parsers that select schema elements through pointer networks and construct SQL via abstract syntax trees. These reported configurations use exact schema names, produce parseable SQL, reproduce annotation-style patterns because they were trained directly on gold annotations, and are evaluated without literal-value prediction. LLM-based approaches operate under fundamentally different constraints: they generate SQL as free-form text, can predict values, and learn SQL patterns from broad training corpora.

The English reference run (Section 5.5) sharpens what our multilingual results do and do not claim. Under the same pipeline design on parallel Spider instances, the English-to-target performance gaps are 5.4–10.5 pp EX. These gaps hold the databases, gold SQL, query structures, architecture, constants, and inference procedure fixed, but they do not isolate a causal language effect because the language-specific training data and adapter, native-language descriptions, and translation-hint content also change. The prompt-enrichment and inference-stage procedures lift the target languages 8.4–12.3 pp above the minimal baseline, a gain comparable in magnitude to these same-pipeline gaps; because the same procedures would also lift an English minimal baseline, which we did not run, this comparison relates the scale of the two effects rather than showing that the components close the gap. The near-equal Arabic and Japanese gaps despite their different scripts, together with Vietnamese’s smaller gap, suggest that orthography alone does not account for the observed differences and that broader cross-lingual semantic-mapping and dataset factors are likely involved. The English run’s higher vote unanimity and lower repair activity also show that the system exhibits greater uncertainty in the target-language settings. We therefore read the multilingual results as follows: a 7B open-source setup that is competitive on English (85.3% on dev, above the company-reported fine-tuned open-source reference of 78.9% on the test split [24], cited for context rather than direct comparison) retains 88–94% of its English performance across three typologically distinct low-resource languages with no language-specific architecture or constants. The base-model experiment further supports transferability: Llama-3.1-8B-Instruct reaches 74.6% EX on Arabic compared with 75.2% for Qwen2.5-Coder under the identical pipeline. Although this experiment is limited to one additional model and one language, the small 0.6pp difference provides evidence that the reported Arabic performance is not specific to Qwen2.5-Coder.

The consistency of the EX–ESM gap across Arabic (9.3 pp), Japanese (10.7 pp), and Vietnamese (8.6 pp), and its persistence when voting and the repair stage are disabled (8.4–10.8 pp under the exact greedy control), indicates that this is a property of LLM-generated SQL across typologically diverse languages, not an artifact of any particular language or decoding procedure. Our validated gold-blind normalization shows that about one percentage point (1.0–1.2 pp) of the gap is attributable to guarded, instance-validated alternative SQL formulations on the evaluated benchmark instances; the remainder reflects deeper structural divergences, among which the component-level analysis identifies set-operation (IUEN) generation as a shared capability gap across the three evaluated benchmarks (28–37% partial accuracy across the three languages) rather than a benign stylistic preference. The grouped ablations sharpen the component picture: value grounding is the dominant component group in every language, and removing the complete group causes a substantially larger degradation than any individually tested value-grounding component, indicating partial compensation among components. The two metrics therefore exhibit complementary biases: ESM can under-credit semantically equivalent SQL forms produced by value-predicting LLMs, whereas single-instance EX can over-credit incorrect queries that happen to return the same result on one database instance (Section 4.2). We consequently recommend reporting both, and we note that applying Spider’s existing test-suite databases to these parallel benchmarks is a natural next step. Our 75–80% EX across three languages shows that the system generates correct, executable SQL for most non-English natural-language queries; the reported value-agnostic grammar-constrained baselines do not provide directly comparable end-to-end EX measurements of this capability.

Implications of injecting database content into prompts. Value hints, matched values, and sample rows place real cell values into the model prompt, and this has consequences beyond accuracy. The first is data exposure: in deployment, the value-hint and sample-row components must be restricted to tables and columns the querying user is authorized to read, and columns holding personal data should be excluded or masked before injection. In our setting, the model runs locally, and no database content leaves the host; the same design with an API-hosted model would transmit database content to a third party. Only the natural-language question, never database content, is sent to the external translation service. The second is prompt injection: cell contents are untrusted text and could carry instructions to the model. The read-only connections, the statement whitelist (Section 3.7), and the fact that the output is executed rather than acted upon limit the consequences to an incorrect query, but the attack surface exists and deployed systems should filter injected content. The third is scale: the SELECT DISTINCT scans and the per-column value cap were tuned on Spider’s small, clean databases; large tables require sampling or a pre-built value index, and the 15-character truncation of injected sample values would need revisiting for long text fields. Finally, evaluation fairness: the injected content is drawn from the database only, never from the gold query, and would be equally available at inference time in any real deployment, so it does not constitute test leakage; we state this explicitly because value injection is the component group with the largest measured effect (Section 5.3).

7. Conclusions

We presented a unified LLM-based framework for low-resource text-to-SQL and tested it on three diverse benchmarks: Ar-Spider (Arabic), MultiSpider-JA (Japanese), and MultiSpider-VI (Vietnamese). Our approach achieved execution accuracies of 75.2%, 74.8%, and 79.9% on these datasets, with every configuration measured in a single seeded evaluation harness with paired significance tests. The pipeline combines QLoRA fine-tuning of Qwen2.5-Coder-7B-Instruct, bilingual schema linking, multi-temperature self-consistency voting, an execution-guided repair stage, and native-language prompt content (column descriptions and translation hints), instantiated per language through separately trained adapters.

An English same-pipeline reference run reaches 85.3% EX, yielding English-to-target performance gaps on parallel Spider instances of $-10.1$ pp for Arabic, $-10.5$ pp for Japanese, and $-5.4$ pp for Vietnamese; the system thus retains 88–94% of its English performance across three writing systems. These are matched same-pipeline performance gaps rather than isolated causal effects of question language, because the language-specific training data, adapter, native-language descriptions, and translation-hint content differ across runs. The pipeline also shows initial evidence of base-model transferability: Llama-3.1-8B-Instruct achieves 74.6% EX on Arabic under the identical pipeline, within 0.6pp of the Qwen-based system.

On raw Spider ESM, the primary comparison metric, the system reaches 65.9%, 64.1%, and 71.3% for Arabic, Japanese, and Vietnamese, respectively: the Japanese and Vietnamese results surpass the strongest multilingual MultiSpider baselines by +2.5 pp and +3.5 pp, while the Arabic result lies 0.7pp below the previous best of 66.63% (LGESQL + XLM-R + CSR). Gold-blind normalization is reported as a secondary diagnostic: it adds +1.2, +1.0, and +1.0 pp (67.0%, 65.1%, and 72.2%), placing the Japanese and Vietnamese diagnostics +3.5 and +4.4 pp above the multilingual MultiSpider baseline and the Arabic diagnostic numerically above 66.63 within bootstrap uncertainty. Our controlled component-level analysis showed that the EX–ESM gap (8.6–10.7pp across all three languages) persists under an exact greedy control with voting and repair disabled and is therefore a property of LLM-generated SQL; guarded, instance-validated rewrites explain roughly one percentage point, and the IUEN component emerges as the clearest shared capability gap across the three evaluated languages.

These findings have important implications for extending text-to-SQL to the many languages that remain low-resource for this task. As the field transitions from grammar-constrained parsers to LLM-based approaches, evaluation metrics must evolve to account for the semantic equivalence of structurally diverse SQL queries. We recommend that future work on non-English text-to-SQL report execution accuracy alongside ESM to provide a complete picture of system capabilities. Overall, our results show that fine-tuned open-source LLMs with bilingual schema linking can provide practical text-to-SQL solutions for low-resource languages using a translated benchmark dataset, an off-the-shelf machine-translation service, and native-language column descriptions obtained without manual authoring (machine-translated or taken from the benchmark release). This approach is much easier than creating language-specific parsers from the ground up.

Several directions remain. The first is joint multilingual adapter training (a single set of adapter weights shared across languages). On the present benchmarks, this requires non-parallel multilingual data to be interpretable: Ar-Spider and MultiSpider are translations of the same underlying Spider instances with shared gold SQL, so joint training would mix three renderings of identical targets, and the evidence on multilingual co-training is mixed: bilingual training helped Portuguese in mRAT-SQL [38], whereas sharing fixed capacity across many languages dilutes per-language performance in XLM-R [40]. Related training-side directions are a hint-free training variant, targeted data augmentation to improve EXCEPT/UNION generation across languages, and an add-one-in or Shapley-style analysis of the component interaction structure (Section 5.3). Inference-side future work includes a controlled sensitivity study of alternative sampling-temperature schedules. On the evaluation side, we plan to report test-suite accuracy on the shared Spider development databases, to explore context-dependent text-to-SQL on the Ar-SParC dataset [35], to extend the approach to additional low-resource text-to-SQL languages in the MultiSpider benchmark (e.g., German, French, Spanish), to evaluate translation-provenance robustness on independently translated question sets such as AraSpider [36], and to investigate larger model scales and reinforcement learning with execution feedback.