Machines in Every Language
What if the programming language you used didn’t assume you think in English?
Every programming language in widespread use today requires English. Not just the keywords: the documentation, the error messages, the community discussions, the variable naming conventions, the mental model.
This is so deeply embedded that most developers don’t notice it. if, else, for, return, function, class, import, try, catch. English words. English grammar. English left-to-right, subject-verb-object structure.
For the ~80% of the world’s developers whose first language is not English, programming has always required a translation step: think in your language, translate to English keywords, write the code. For compliance officers reviewing AI workflows, the review happens in a language they may not fully command. For enterprises deploying AI globally, every market that isn’t English-speaking is underserved by every tool on the market.
mashinTalk doesn’t assume English.
Seven languages, one compiler
Here’s the same machine in English:
machine greeter
accepts
name as text, required
responds with
greeting as text
implements
compute build_greeting
{greeting: "Hello, " + input.name + "!"}In Japanese:
で書かれた 日本語
マシン greeter
受け取る
name として テキスト, 必須
で応答する
greeting として テキスト
実装
計算 build_greeting
{greeting: "こんにちは、" + input.name + "さん！"}In Spanish:
escrito en español
máquina greeter
acepta
name como texto, requerido
responde con
greeting como texto
implementa
calcula build_greeting
{greeting: "¡Hola, " + input.name + "!"}In French:
ecrit en francais
machine greeter
accepte
name en tant que texte, requis
repond avec
greeting en tant que texte
implemente
calcule build_greeting
{greeting: "Bonjour, " + input.name + " !"}In Chinese:
编写于 中文
机器 greeter
接受
name 为 文本, 必填
回应
greeting 为 文本
实现
算 build_greeting
{greeting: "你好，" + input.name + "！"}In German:
geschrieben in deutsch
Maschine greeter
akzeptiert
name als Text, erforderlich
antwortet mit
greeting als Text
implementiert
berechnet build_greeting
{greeting: "Hallo, " + input.name + "!"}In Korean:
로 작성됨 한국어
기계 greeter
받는다
name 로 텍스트, 필수
로 응답한다
greeting 로 텍스트
구현
계산 build_greeting
{greeting: "안녕하세요, " + input.name + "님!"}Seven machines. Seven languages. One compiler. They all produce the same bytecode.
How it works
The key insight: mashinTalk’s keywords are not English words. They are semantic atoms that happen to be spelled in English by default. machine, accepts, implements, compute: these are atoms in a finite vocabulary, not English prose.
The written in directive at the top of a file tells the compiler which locale to use for keyword resolution. で書かれた 日本語 means “written in Japanese.” After that, every keyword in the file is resolved through the Japanese locale map: マシン maps to the machine atom, 受け取る maps to accepts, 計算 maps to compute.
The expressions inside compute steps ({greeting: "Hello, " + input.name}) use the same syntax in every locale: field names, string literals, and operators don’t change. What changes is the structural vocabulary: the keywords that describe what the machine does, including type declarations (テキスト for text, 数値 for number), modifiers (必須 for required), and field connectors (として for “as”).
This is not “localized keywords bolted onto an English parser.” The parser processes canonical atoms. Each locale is a mapping from human-language words to those atoms. English is one mapping. Japanese is another. Neither is privileged. A machine written in Korean compiles to the same AST as the same machine written in French.
Why this matters
For builders
The contribution isn’t translation. Any language can translate keywords. The contribution is that the entire workflow is accessible without English.
A Japanese domain expert can read a machine definition written in Japanese and understand what it does. Not because someone translated the documentation. Because the machine itself is written in the language they think in. The keywords read naturally. The structure reads like a plan in their language.
A restaurant owner in Tokyo writes a daily specials machine in Japanese. A therapist in Seoul writes a session prep machine in Korean. A farmer in Bavaria writes a planting advisor in German. None of them need to think in English to build AI workflows that run on a production runtime with structural governance.
For governance
Governance requires understanding. If a compliance officer in Tokyo needs to review what a machine does, the review should happen in Japanese. If a doctor in Seoul needs to verify a clinical workflow, the verification should happen in Korean. Governance that requires English comprehension excludes most of the people who need to exercise judgment at the boundary.
Error messages are localized too. When a machine fails validation, the diagnostic explains what went wrong in the language the machine was written in. A French developer writing in French gets French errors. Not translated-from-English errors. Errors that were authored for French speakers.
For enterprises deploying globally
Every enterprise deploying AI in non-English markets faces the same question: can our teams in Tokyo, Sao Paulo, and Berlin build, review, and govern AI workflows without requiring English fluency? With every other platform, the answer is no. With mashin, the answer is yes. The same machine, the same governance, the same audit trail, in the language each team works in.
For research
The “same bytecode” property has a consequence that matters for AI research: it enables structurally controlled cross-lingual experiments. When the same machine is written in Japanese and English, the only thing that changes is the language of the prompts sent to the model. The step structure, the output schema, the governance, and the recording are identical by construction.
This means you can ask questions that no other tool can answer with controlled experiments: Does GPT-5 reason differently in Japanese than in English? Does DeepSeek have an advantage on Chinese reasoning tasks? Does Mistral outperform on European languages? The machine IS the experimental protocol in each language. The behavioral ledger IS the dataset. The comparison is structurally controlled, not approximately controlled.
We are running the first such study now: 8 models, 7 languages, 5 reasoning task types, 1,400 runs. The machines are written and validated. The results will be published with full machine definitions and ledger data so anyone can reproduce the study.
Composition across languages
A machine written in Japanese can call a machine written in English. The governance holds across the boundary. The types are compatible. The composition is natural.
This follows from the architecture: machines produce intents, not effects. An intent is a data structure. Data structures don’t have a language. The governance interpreter processes atoms, not words. Whether the atom arrived from 計算 or compute or calcule, it’s the same atom by the time governance sees it.
This means a registry of machines is a multilingual ecosystem from day one. A Japanese developer publishes a machine. A Brazilian developer composes it into their workflow. Neither needs to read the other’s source language. The interfaces are typed. The governance is structural. The intent is universal.
mashinTalk supports seven locales today: English, French, Spanish, Japanese, Chinese, German, and Korean. More are coming. Any language with capable AI model support can be added; a new locale requires mapping ~120 keywords and the compiler, runtime, governance, and all tooling work unchanged.
mashin is currently in early alpha with a small testing community. If you’re interested in building or researching with us, visit mashin.live.