UniversalPython: Multilingual Python Layer

• UniversalPython is a multilingual layer over Python that enables coding with human-language tokens while preserving standard Python semantics.
• It uses a source-to-source transpiler with per-language YAML dictionaries and PLY for tokenization to convert localized code into executable Python.
• Empirical studies and performance benchmarks show improved accessibility and acceptable overhead, making it a promising tool for diverse educational and production environments.

UniversalPython denotes a multilingual layer over Python in which programmers write code using human-language tokens while execution remains delegated to standard Python. In "A Multilingual Python Programming Language" (Bazaz et al., 10 Oct 2025), it is defined as a language transpiler built on top of Python: localized code such as Urdu Python is translated into standard English Python and then executed by an ordinary Python interpreter. In "Automated Python Translation" (Otten et al., 15 Apr 2025), the same programmatic ambition is generalized as the translation of Python’s “natural modality”—keywords, built-in functions and modules, error types, and library identifiers—into multiple human languages. Across both formulations, UniversalPython preserves Python’s semantics and runtime while changing the surface vocabulary of code.

1. Motivation and conceptual scope

UniversalPython is motivated by the claim that widely used programming languages are effectively “English-only,” because keywords such as if, for, while, and print, together with most documentation and error messages, are centered on English. The stated problem is not merely pedagogical inconvenience but restricted entry: lack of English proficiency is presented as a barrier for newcomers, especially in developing regions, and educational research cited in the work reports better comprehension, lower dropout rates, and higher engagement when students learn in their mother tongue. The same discussion notes that girls in particular show improvements in achievement and self-image when taught in local languages. Localized programming environments and curricula are described as showing that novices grasp programming concepts faster when keywords and interfaces are localized, but such environments often remain limited to basic operations and do not scale well to complex software or large ecosystems (Bazaz et al., 10 Oct 2025).

The two papers distinguish between localized ancillary material and localization of code itself. The latter is the explicit target. "Automated Python Translation" (Otten et al., 15 Apr 2025) defines the task as automatically translating Python’s natural modality into other human languages. That natural modality includes language keywords, built-in functions and modules, error types such as SyntaxError and IndexError, and library identifiers such as torch.load and numpy.nan_to_num. Comments, user-defined identifiers, and string literals are not the primary target of the automated translation work; the focus is the surface vocabulary of the language and its libraries rather than explanatory prose or arbitrary programmer-chosen names.

A central design requirement is interoperability with mainstream Python. UniversalPython is proposed specifically as a way to let non-English speakers program in a mainstream language without first learning English, while remaining maintainable, scalable across many human languages, and interoperable with the existing Python ecosystem. This places it between monolingual non-English programming languages, which often require a distinct syntax and runtime, and educational localization systems, which frequently stop short of production-level text-based programming (Bazaz et al., 10 Oct 2025).

2. Transpilation architecture and formal model

UniversalPython is implemented as a source-to-source compiler rather than a new VM or runtime. The high-level pipeline is: localized Python code is written by the programmer, the UniversalPython transpiler lexes and parses it, localized keywords, numerals, and punctuation are translated through a language dictionary, standard Python source is produced, and the resulting program is executed by CPython. Output, including some error messages, can then be post-processed so that English terms are reverse-mapped into the user’s language (Bazaz et al., 10 Oct 2025).

The conceptual mapping is given as

$f : L_{\text{human}} \to L_{\text{python}}$

where $L_{\text{human}}$ is Python expressed using human-language tokens and $L_{\text{python}}$ is standard Python source code. The language-specific lexical layer is represented by a dictionary

$D : T_{\text{human}} \to T_{\text{python}}$

and token-sequence translation is described as

$f(t_1, \ldots, t_n) = (D(t_1), \ldots, D(t_n))$

with tokens outside the domain of $D$ left unchanged. The formalism is deliberately lexical: UniversalPython does not alter Python’s semantics, only its surface vocabulary (Bazaz et al., 10 Oct 2025).

Implementation is based on per-language YAML dictionaries and a lexer/parser written with PLY, the Python Lex-Yacc library. PLY provides regex-based token definitions, grammar rules, and reserved-keyword handling. UniversalPython marks localized keywords as reserved tokens and applies grammar rules that replace them with English equivalents, detect and translate localized numerals, and ignore strings and comments for translation. The transpilation pipeline therefore operates token by token: localized keywords are replaced, localized numerals are converted to ASCII digits, differing punctuation is normalized, and operators and other unchanged syntax are passed through directly. The translated token stream is then reassembled into valid Python (Bazaz et al., 10 Oct 2025).

The same architecture extends to interactive environments. The paper describes a Jupyter kernel implemented as a wrapper around IPython that intercepts do_execute and do_complete, translates localized code into Python, sends it to IPython, and preserves memory across cells. This keeps UniversalPython aligned with standard Python tooling while treating localization as a preprocessing layer rather than a runtime divergence (Bazaz et al., 10 Oct 2025).

3. Language packs, token mapping, and illustrative examples

UniversalPython is language-agnostic at the architectural level. Supporting a new human language primarily requires creation of a YAML dictionary containing mappings from human-language keywords to Python keywords, localized digits to ASCII digits, and localized punctuation to ASCII punctuation. The paper explicitly demonstrates Urdu, Chinese, and Hindi. In the Urdu pack, examples include localized forms for print, if, elif, else, while, for, in, input, continue, True, and False; a separate mapping normalizes Urdu period and comma symbols into Python punctuation (Bazaz et al., 10 Oct 2025).

Numeral localization is handled explicitly. Urdu digits occupy Unicode code points 1776–1785 and correspond to Arabic-Indic numerals. UniversalPython uses a regular expression over that numeric range and constructs the corresponding ASCII literal digit by digit. Examples given in the paper include Urdu ٥ mapping to 5, Urdu ٩٠ to 90, and Urdu ۲۰۲۵ to 2025. Identifiers may remain in the local script because Python 3 already supports Unicode identifiers; optional use of the unidecode library is described as an implementation convenience for “Latinizing” identifiers rather than a semantic requirement. Strings, docstrings, and comments are ignored by translation, preserving user-authored natural language exactly as written (Bazaz et al., 10 Oct 2025).

A representative Urdu Python fragment is described as follows:

كجهـ = ٢ اكر كجهـ == ١ : لكهو("Hello") ورنباكر كجهـ == ٢: لكهو("World") ورئم: لكهو("...Didn't understand")

The corresponding transpiled Python is:

khchh = 2 if khchh == 1: print("Hello") elif khchh == 2: print("World") else: print("...Didn't understand")

The example illustrates the intended division of labor: the identifier may be preserved as Unicode or converted with unidecode, the Urdu digit is normalized, localized conditionals and print are replaced by Python keywords, operators such as == remain unchanged, and strings are left untouched. The resulting code runs directly under CPython (Bazaz et al., 10 Oct 2025).

The same lexical mechanism permits interlanguage translation through English as an intermediate representation. The paper shows Urdu source being translated into English Python and then into Hindi Python, with successful execution and output World. Right-to-left script support is handled through Unicode rendering in editors and terminals rather than by custom directional logic in the transpiler itself: internally, the lexer sees a sequence of Unicode code points. A stated limitation is that translations requiring spaces, such as a two-word phrase for elif, are difficult because the tokenizer splits on whitespace and PLY expects tokens to be single lexical units (Bazaz et al., 10 Oct 2025).

4. Execution model, performance, and empirical usability

The execution model is intentionally thin. Localized source can be processed in command-line or file-based workflows, through a custom Jupyter kernel, or in a web demo that translates from one localized Python variant to another via English and executes the result. In all cases, the essential pattern is the same: load a language pack, transpile localized code to English Python, execute that code with Python, and optionally re-localize selected output and error text (Bazaz et al., 10 Oct 2025).

Performance was benchmarked with hyperfine on a MacBook Air (Late 2019) using 110 simple algorithmic Python programs from TheAlgorithms/Python math implementations. For each original Python file, UniversalPython was run in reverse to generate an Urdu version, the Urdu version was executed via UniversalPython, the original was executed via Python, and outputs and execution times were compared. The reported correctness result was that 98% of programs successfully round-tripped between English Python and Urdu Python and still ran correctly; two failures were attributed to difficulties distinguishing between the operator is and the comparison == in reverse translation. The stated conclusion is that translation overhead is modest and that UniversalPython is performant enough for educational and many practical purposes (Bazaz et al., 10 Oct 2025).

Function	Python	UniversalPython
simpson_rule	0.168146	0.428384
quad_eqs_complex_num	0.162974	0.400886
square_root	0.165146	0.330606
softmax	0.408194	0.061837
gaussian	0.873841	0.558138
radix2_fft	0.473321	0.187514

The benchmark narrative emphasizes heterogeneity rather than monotonic slowdown. Simpler, less wordy programs sometimes performed faster or similarly to Python, while verbose or complex algorithms were generally faster under Python alone, though still within what the paper describes as acceptable speed for interactive use (Bazaz et al., 10 Oct 2025).

Usability was also examined through a “speed algorithm coding” hackathon held on May 21, 2022 at the National University of Computer and Emerging Sciences in Islamabad. Participants were aged 13–28, came from high school or bachelor’s-level computer science backgrounds, and had preliminary knowledge of Python and algorithmic programming. UniversalPython with an Urdu dictionary was introduced as the challenge language, and participants were initially unfamiliar with it. After receiving documentation on keyword mappings and usage, over 80% successfully submitted their coding challenges in UniversalPython. Reported feedback was mixed: some participants, especially from remote areas, valued being able to code in their native language, while others preferred English Python. The study therefore suggests usability for learners already somewhat familiar with Python while also indicating that adoption depends on preference and exposure (Bazaz et al., 10 Oct 2025).

5. Automated translation of Python’s natural modality

The second paper broadens UniversalPython from a hand-authored language-pack system into an NLP task and an automated lexicon-construction pipeline. Its core research problem is how to translate Python’s natural modality at scale so that a UniversalPython system can keep pace with a large and evolving ecosystem rather than relying on manual annotation by native speakers. The paper situates this need in relation to UNIPY, which had already shown deterministic, reversible translation of Python’s natural modality and execution of fully non-English code by mapping localized terms back to standard Python, but did so through manual effort that does not scale to 137,000+ Python packages and many target languages (Otten et al., 15 Apr 2025).

The proposed automated pipeline has three stages: Python term expansion, Python term translation, and optional Python term abbreviation. Expansion converts abbreviated or concatenated Python identifiers into fuller English phrases—for example, abs to “absolute value,” delattr to “delete attribute,” memoryview to “memory view,” and SyntaxError to “Syntax Error.” On a dataset of 222 unique standard-library terms using gold expanded forms from UNIPY, GPT-4 Turbo achieved its best expansion result with a 5-shot prompt, reaching 93.2% exact-match accuracy and 95.7% chrF; GPT-3.5-Turbo performed less strongly but well enough to be selected for the production pipeline on cost grounds (Otten et al., 15 Apr 2025).

Translation is then applied to the expanded phrases. The evaluation covers Spanish, French, Greek, Mandarin, Hindi, Bengali, Sorani Kurdish, and a partial vetted Arabic set. For machine translation, Google Translate is tested under three input conditions—no-cntxt, def, and expl—and the central finding is that no-cntxt consistently performs best. Adding context hurts performance because the MT system tends to interpret Python tokens as technical proper names that should remain untranslated. ANOVA is reported to show that differences between context levels are statistically significant at 99% confidence. By contrast, GPT-4 Turbo and Llama-2-70B-chat show weaker and less reliable term-level performance, especially for lower-resource languages, and prompting strategies do not produce statistically significant differences. The paper therefore identifies Google Translate with no-cntxt as the most effective translation component in the pipeline (Otten et al., 15 Apr 2025).

The automated system was instantiated over five libraries—PyTorch, TensorFlow, pandas, NumPy, and random—using manually extracted documentation identifiers. The resulting vocabulary comprised 6,119 unique terms across those libraries, translated into seven target languages. A human-evaluable subset of 407 terms was then checked by native speakers of French, Greek, and Bengali, with one annotator per language/library. Those annotators either accepted the pipeline output as reasonable or corrected it (Otten et al., 15 Apr 2025).

Language	Raw (%)	chrF (%)
French total	50.1	72.7
Greek total	38.6	63.2
Bengali total	82.1	90.8

These results show that the pipeline already functions as a first-pass lexicon generator, with especially strong performance in Bengali and moderate performance in French and Greek. The paper’s qualitative analysis identifies several recurrent failure modes: phrasing and word-order issues, register mismatches such as French “moins ou égal” versus the corrected “inférieur ou égal,” and polysemy errors such as translating “uniform” as clothing rather than the statistical distribution, “keys” as physical keys rather than mapping keys, and “character” as fictional persona rather than character code. A plausible implication is that UniversalPython requires not only translation but domain-specific lexical standardization, especially for overloaded English terms and mathematically specialized vocabulary (Otten et al., 15 Apr 2025).

6. Position within related work, limitations, and projected development

UniversalPython is positioned against several adjacent traditions. Monolingual non-English programming languages such as Yoruba-based languages, Hindi Kalaam, Alif, Wenyan-lang, and UrduScript for JavaScript provide native-language syntax from scratch but are described as tending toward limited adoption, maintenance difficulty, limited third-party library support, and the creation of another syntax to learn. Multilingual educational systems such as Scratch and Hedy localize blocks or interfaces effectively for beginners but are characterized as supporting only basic operations and not scaling readily to production-level software. Previous attempts at localizing Python include PseuToPy, which uses an intermediate pseudo-language and machine translation; Chinese Python, which modifies Python’s source code and requires recompilation; Legesher, a community-driven YAML-based translation system across multiple languages; and UNIPY, which demonstrated the viability of deterministic reversible translation of Python’s natural modality. UniversalPython’s distinguishing position is as a dictionary-driven lexical layer atop unmodified Python, avoiding interpreter recompilation while targeting multiple languages and ecosystem compatibility (Bazaz et al., 10 Oct 2025).

The limitations acknowledged in the two papers are substantial. The transpiler paper states that third-party library APIs such as numpy, pandas, and cv2 are not yet translated, leaving documentation, stack traces, and much library-facing interaction in English. It also notes machine-translation quality problems, ambiguity in reserved-word mappings, multi-word token difficulty, incomplete localization of debuggers, linters, and IDE messages, and the maintenance burden of keeping language packs synchronized with new Python versions. The automated translation paper adds evaluation limits—only 407 terms were human-checked, only three languages received such checking, and there was one annotator per language—as well as abbreviation-scheme limitations, lower quality for under-resourced languages, propagation of expansion errors, cultural and linguistic bias in models, and the fact that finetuned LLM-based code-block translation is still unsuitable for production UniversalPython compilers because it may over-generate and produce non-executable code (Bazaz et al., 10 Oct 2025, Otten et al., 15 Apr 2025).

Future directions are correspondingly expansive. The transpiler paper proposes fuller keyword and library coverage, automated scanning of library source code to discover public APIs, NLP/ML-based suggestion of translations, and a TypeScript-inspired architecture in which localized interfaces might be described through interfaces.<language_code>.yml files. It also proposes broader user customization, human-in-the-loop translation and verification, larger user studies, deeper IDE and REPL integration, support on online platforms such as Replit and LeetCode, and institutional backing from the Python Software Foundation or similar organizations. The automated translation paper emphasizes stronger expansion and translation models, code-aware context engineering, community-maintained glossaries, formal standardization of localized APIs, IDE-level integration, educational studies, and support for multiple lexical registers, including both transliteration and native lexemes where communities use both. Taken together, these directions suggest that UniversalPython is best understood not as a separate programming language with independent semantics, but as a multilingual accessibility layer whose viability depends on sustained lexicon maintenance, community curation, and stable interoperability with standard Python (Bazaz et al., 10 Oct 2025, Otten et al., 15 Apr 2025).