pseudocode-i18n

Current version: 1.0.2. Release history: pseudocode-i18n changelog. License: GNU GPL-3.0-or-later.

Requirements and dependencies

• Python: 3.11 or newer (>=3.11).
• Pseudocode ecosystem: this is the shared core and therefore has no dependency on another pseudocode-i18n project.
• Runtime Python packages: PyYAML >= 6.0, Pillow >= 10.0, CairoSVG >= 2.7, mermaidx[embed] >= 0.9.5, < 1, and pygraphviz >= 2.0.2, < 3.
• These runtime dependencies are declared by the package and are installed automatically by pip.

pseudocode-i18n lets students, teachers and developers write the same pseudocode language in several natural languages, while keeping one common semantic model underneath.

Write a normal .pseudo or .algo file, in French, Spanish, Italian, Portuguese, German, Dutch, Danish, Swedish, Norwegian, Finnish, Greek, Ukrainian, Russian or English. The language can be detected automatically. The same source can then be checked, semantically linted, formatted, executed, transpiled bidirectionally with Python, or exported/rendered as a Mermaid or Graphviz flowchart/algorigram.

# language: fr

age est un entier
age = 17

Si age >= 18 Alors:
    Afficher "Majeur"
Sinon:
    Afficher "Mineur"
Fin

Transpiles to:

age: int
age = 17

if age >= 18:
    print("Majeur")
else:
    print("Mineur")

Why this project?

Pseudocode used in classrooms is rarely standardized. The same ideas are written as Afficher, Écrire, Mostrar, Escribir, Print, Display, Si ... Alors, If ... Then, FinSi, Fin, or with indentation only.

pseudocode-i18n deliberately accepts these common teaching variants, maps them to one AST, and provides one predictable canonical formatter.

Main goals:

• two equivalent source extensions for every language: .pseudo and .algo;
• automatic language detection with an explicit override when needed;
• tolerant input, but deterministic canonical formatting;
• indentation-based block semantics, like Python;
• optional FinSi / FinPour / FinFonction-style terminators for constructs that need a separate closer;
• a generic optional terminator (Fin, Fim, Fine, Ende, End);
• localized types, constants, operators, input/output verbs and control flow;
• bidirectional Python transpilation for the supported subset, without losing useful type information;
• a shared language definition for CLI, Pygments, MkDocs and VS Code integrations.

Current capabilities

The core keeps language semantics, editor help, execution tracing and flowchart metadata in one editor-neutral model instead of frontend-specific tables or runtimes.

• 14 data-driven languages with Unicode identifiers, automatic detection, # language: xx / # lang: xx, localized infinitive/imperative synonyms and project configuration;
• contextual editor help now covers not only major keywords but also grammar fragments/connectors generated from the language patterns: for example French Alors, fois, Jusqu'à, and every word of multi-word import syntax such as en tant que;
• the shared pedagogical catalogue now models complete constructions instead of ambiguous fragments: counted repeat, repeat-until, range loop, stepped range loop and collection loop have distinct localized entries in all 14 languages; every card carries concrete examples, and Pour … Dans … demonstrates several iterable families rather than repeating its abstract syntax;
• documentation search metadata is generated once in the core with title → aliases/syntax → description/examples priority, so editor frontends can filter instantly without reparsing source or maintaining their own help index;
• import documentation presents simple imports, depuis/from, aliases, the localized local modifier, and both traditional and natural word orders;
• import operands remain identifiers: a name such as sqrt in importe sqrt depuis math is not mistaken for generic builtin documentation;
• the semantic roles used by Pygments/IDE adapters mirror equivalent Python roles: function/class declarations are definitions, localized constructors behave like Python __init__, Vide behaves like None, builtins like Afficher behave like print, and import operands are classified as module/name/alias rather than keywords;
• strict explicit-type contracts, typed-operation checking, recovering multi-diagnostics, project-aware math / random / local modules, localized runtime errors and precise source maps remain part of the core;
• universal English public, private and protected remain accepted in every language alongside localized spellings;
• snippets, semantic index, definitions/references/signatures, bidirectional Pseudocode ↔ Python transpilation, canonical formatting and Mermaid/Graphviz/SVG/PNG/GIF flowcharts are shared core APIs; the core also owns the canonical flowchart topology and both renderer layout policies (pseudocode-flowchart/v1), so editor adapters do not maintain their own spacing/routing rules;
• the editor-neutral pseudocode-tutor/v2 model exposes step-by-step execution with source lines, scopes/variables, changed values, call stack, incremental output deltas/reset markers, conditions and input state; human-facing event/scope labels and rendered true / false / null values follow the detected Pseudocode language while protocol identifiers and native JSON values stay stable for clients;
• Tutor sessions embed static flowchart snapshots with stable node/edge IDs. A rich frontend renders a graph once with Mermaid or Graphviz, then each execution step only activates the IDs supplied by the core instead of recalculating layout;
• the tracing path caches immutable expression/statement transpilation, while parser structures and automatic-language evidence are precompiled/reused; a parsed AST can be shared by linting, semantic indexing, Tutor and flowchart generation instead of reparsing the same document.

The core still keeps normal execution efficient: richer editor intelligence is metadata/static-analysis work and does not add per-statement runtime tracing overhead. Editor/Tutor workloads also reuse parsed and precompiled structures so repeated stepping or live diagnostics do not redo unchanged language work.

Shared editor intelligence, runtime diagnostics and modules

The core exposes an editor-neutral semantic index with exact source ranges, definitions, references, signatures and symbol metadata. The shared pseudocode-i18n-languageserver consumes this API to provide diagnostics, snippets plus semantic completion, pedagogical hover help, signature help, document symbols, navigation, rename and formatting without duplicating the language grammar. VS Code and Thonny both consume this same intelligence.

The core also owns the editor-help catalogue and localized runtime-error catalogue so future IDEs receive the same explanations. Editor help is fully localized (for example Syntaxe in French and Sintaxis in Spanish) and deliberately lists every accepted spelling for a construct, including imperative/infinitive synonyms and automatically accepted accentless variants. Runtime error mapping is designed for execution performance: generated Python contains comment-only source markers, normal execution has no per-statement tracing overhead, and source-line localization is performed only when an exception occurs. Syntax and runtime failures are rendered in the Pseudocode language with the original Pseudocode line number and source line; Python backend exception class names are not exposed in the normal learner-facing message. Parser-recovery details are localized too: an internal English parser message is never appended to a French, Spanish or other localized diagnostic.

Object-oriented access modifiers are language-neutral concepts. Every one of the 14 languages accepts its localized spellings and the universal English spellings public, private and protected; accentless variants supplied by the language packs remain accepted as well.

The linter also recovers after independent malformed lines instead of stopping at the first one. Recovery covers both line-local faults and structural faults such as missing block bodies, unexpected or inconsistent indentation, mixed tab/space indentation, orphan branches, misplaced constructors, malformed expressions and assignment targets, invalid parameter lists, explicit end-marker mistakes and incomplete repeat/until structures. The preflight is a single O(n) structural pass followed by one authoritative parse of the analysis-only repaired source, avoiding repeated reparses and O(n²) worst-case behavior. Crucially, this same preflight always runs when an editor reuses a cached AST, so CLI, VS Code, Thonny and pseudo-lsp cannot silently disagree on indentation or other structural diagnostics. A counted loop missing its localized “times” word, an incomplete input statement and a bad module name can therefore all receive squiggles in the same document. The user's source is never rewritten and invalid code is never made executable.

Diagnostics are deliberately written for learners without losing technical precision. An indentation fault is reported as an indentation fault rather than a generic syntax failure; common missing-block, incomplete-input, malformed-expression, type, import, undefined-name, unreachable-code, zero-range-step and misuse-of-control-flow cases have dedicated localized messages. The complete diagnostic catalogue is present in all 14 languages, and every warning (unused, unreachable, missing return, builtin shadowing) is rendered in the detected Pseudocode language. User-defined variable, function and class names are also checked against the reserved vocabulary of that language; reserved identifiers are errors, while shadowing a known builtin receives its dedicated warning. All independent diagnostics found in a document are returned together and sorted/deduplicated rather than truncating at the first failure.

Imports are now resolved through a deliberately small Pseudocode module model. math and random are standard modules; sibling/project .algo and .pseudo files are local Pseudocode modules. Arbitrary Python packages are not exposed implicitly. Standard module names keep priority, while the localized local keyword explicitly forces a same-named local module. For example in French:

importe sqrt depuis math en tant que rac
importer sqrt depuis math en tant que rac
importe geometrie
importe aire depuis geometrie
importe aire depuis local geometrie en tant que aire_locale

Unknown modules (PSE113) and unknown imported members (PSE114) are reported on the offending token. Local modules are transpiled only when imported and cached afterwards, so this support adds no per-statement execution overhead.

Two universal pedagogical random helpers are available in all 14 languages, alongside the existing localized aliases:

alea()          -> real in [0, 1[
entalea(a, b)   -> integer in [a, b] (both bounds included)

In French, the existing hasard(n) remains the integer helper for [0, n[, and aleatoire(a, b) remains an alias of the inclusive integer range helper.

Install

python -m pip install pseudocode-i18n

On a system-managed Python installation where you deliberately use system packages:

python -m pip install --break-system-packages pseudocode-i18n

The package installs two equivalent commands:

pseudo
pseudocode

Two equivalent source extensions, automatic language detection

Every pseudocode source file uses either of the two canonical extensions, regardless of language:

algo.pseudo
algo.algo

.pseudo and .algo are strictly equivalent; neither extension carries language information.

In the normal case, the language is detected from the source:

pseudo algo.pseudo

If detection needs to be overridden, put a universal metadata directive at the beginning of the file:

# language: es

or force it from the CLI:

pseudo --lang es algo.pseudo

Resolution order is:

CLI/API > # language: xx > project configuration > automatic detection > fallback

The canonical form is # language: fr. The aliases # language fr, # lang: fr and # lang fr are also accepted; language and lang are synonyms and the colon is optional. # is the only comment/directive marker; // is integer division.

Pseudocode in several languages

The bundled language order is French, Spanish, Italian, Portuguese, German, Dutch, Danish, Swedish, Norwegian, Finnish, Greek, Ukrainian, Russian, then English. Every Usage topic is generated separately for all 14 languages.

Français

Si note >= 10 Alors:
    Afficher "Admis"
Sinon:
    Afficher "Ajourné"
Fin

Español

Si nota >= 10 Entonces:
    Mostrar "Aprobado"
Sino:
    Mostrar "No aprobado"
Fin

Italiano

Se voto >= 10 Allora:
    Mostra "Promosso"
Altrimenti:
    Mostra "Non promosso"
Fine

Português

Se nota >= 10 Então:
    Mostrar "Aprovado"
Senão:
    Mostrar "Reprovado"
Fim

Deutsch

Wenn note >= 10 Dann:
    Ausgeben "Bestanden"
Sonst:
    Ausgeben "Nicht bestanden"
Ende

English

If grade >= 10 Then:
    Display "Passed"
Else:
    Display "Failed"
End

Flexible conditionals, canonical formatting

French conditionals accept, among others:

Si condition:
Si condition
Si condition Alors:
Si condition Alors

Sinon, Sinon Si, optional Alors, optional colons, specific terminators and generic Fin are also accepted.

For example, all these tolerant variants converge with pseudo format toward:

Si condition Alors:
    Afficher "oui"
Sinon Si autre_condition Alors:
    Afficher "peut-être"
Sinon:
    Afficher "non"
Fin

Indentation determines the actual block structure. End markers are always optional.

Input and output synonyms

Vocabulary is language data rather than parser code. The plain input command is intentionally an integer input in pseudocode-i18n: when no prompt is written, the target variable name is used as the prompt.

French examples:

Afficher "Bonjour"
Écrire "Bonjour"
Ecrire "Bonjour"

Saisir n                    # n = int(input("n"))
Lire n                      # n = int(input("n"))
Saisir "Valeur de n : ", n # n = int(input("Valeur de n : "))

A prompt-only input statement such as Lis "Allo" is incomplete because the entered value has nowhere to be stored. The linter reports this before execution and points to the original source line.

Typed input commands are available in every supported language. They are derived from each language's input verb and localized type names, so both compact teaching forms and spaced forms are accepted. In French, for example:

SaisirEntier n
SaisirFlottant x
SaisirChaîne nom
SaisirBooléen ok
SaisirTableau valeurs
SaisirDictionnaire d
SaisirEnsemble uniques
SaisirTuple point

They map respectively to int(input(...)), float(input(...)), input(...), bool(input(...)), and safe collection parsing with ast.literal_eval followed by list, dict, set or tuple. Boolean input deliberately follows Python exactly: every non-empty input string is truthy, so bool("False") is True. Collection input never uses eval.

Localized type names are also conversion functions. For example Entier("12"), Flottant("3.5"), Chaîne(12) and their equivalents in all 14 languages map to the corresponding Python constructors.

Spanish follows the same model:

Mostrar "Hola"
Escribir "Hola"

Leer n
Introducir n
Leer "Valor de n: ", n
LeerEntero n
LeerFlotante x
LeerCadena nombre

Natural localized imports are accepted in the same data-driven way. For example:

Importe sqrt depuis math en tant que rac
Importa sqrt desde math como raiz

Both transpile to a Python from ... import ... as ... statement. Matching is case-insensitive, and accentless equivalents of declared accented spellings are generated automatically.

Natural-language comparisons

Symbolic comparisons remain valid in every language: ==, !=, <, <=, > and >=. Each language also provides natural-language comparison phrases. In French, for example:

x est égal à 2
x égal à 2
x égal 2

x n'est pas égal à 3
x non égal à 3

x est strictement supérieur à 2
x strictement supérieur à 2
x strictement supérieur 2

x est supérieur à 2
x supérieur à 2
x supérieur 2

x est strictement inférieur à 2
x est inférieur à 2

pseudocode-i18n uses the following pedagogical convention:

strictement supérieur  -> >
supérieur              -> >=
strictement inférieur  -> <
inférieur              -> <=

Explicit forms such as supérieur ou égal à and inférieur ou égal à are accepted too. Where the language permits it, negated natural forms are aliases of the complementary comparison. Thus French x n'est pas supérieur à 2 and x non supérieur à 2 both mean x < 2, while x n'est pas strictement supérieur à 2 means x <= 2. Equivalent natural forms are defined for all 14 supported languages and are listed on each generated language-reference page.

Variables and optional types

Type declarations are never mandatory. You can write ordinary Python-like assignments:

a = 2
a = a + 2

or add pedagogical type declarations. The compact name: type notation is accepted in every source language as well as the localized natural forms:

i: chaîne
a est un entier
a, b sont des flottants
nom est une chaîne
notes est un tableau
d est un dictionnaire
vus est un ensemble
coordonnees est un tuple

An explicit annotation is a contract: after i: chaîne, assigning i = 0 is a localized PSE105 type error. Binary operations are also checked when both operand types are known. Numeric arithmetic is allowed between numeric types, strings/lists/tuples concatenate only with compatible families, and string/list repetition by an integer remains valid (3 * "ha"), while combinations such as 3 + " pommes" or Vrai + 1 are rejected. Untyped variables remain gradual/dynamic; add an annotation when a stable pedagogical type is required.

They are preserved in Python as annotations:

a: int
a: float
b: float
nom: str
notes: list
d: dict
vus: set
coordonnees: tuple

Bundled semantic type families:

The same model is localized in all 14 bundled languages.

Vide / null values are not empty collections

A localized null constant has the same semantic role as Python None:

x = Vide

becomes:

x = None

Spanish accepts Vacío and its automatically generated accentless form Vacio; the other languages provide their own localized vocabulary.

This is distinct from empty collections:

[]              # empty list
{}              # empty dictionary, exactly like Python
Ensemble()      # empty set -> set()
Tuple()         # empty tuple -> tuple()
Dictionnaire()  # empty dictionary -> dict()

Assignment forms

All of these are accepted as assignments:

a = 2
a := 2
a <- 2
a ← 2
2 -> a
2 → a

The canonical formatter emits =.

Membership and mathematical notation

Localized word operators and mathematical symbols are equivalent.

French examples:

x Dans E
x Inclus Dans E
x ∈ E

x Pas Dans E
x Non Dans E
x Non Inclus Dans E
x ∉ E

They transpile to Python in / not in.

Optional Faire / Do loop suffixes and logical negation

All 14 languages accept an optional localized do suffix on while, range-for and collection-for headers. In French, for example, all of these forms are valid:

Tant Que x < 10 Faire:
    x = x + 1
Fin

Pour valeur Dans valeurs Faire:
    Afficher valeur
Fin

Pour i de 1 à n Faire:
    Afficher i
Fin

The final colon remains optional, exactly as for the corresponding forms without Faire. Canonical snippets use the suffix with the colon. The equivalent suffix is localized in every bundled language (Hacer in Spanish, Do in English, and so on).

Range loops also expose a dedicated step snippet. French uses the concise canonical template Pour … de … à … pas … Faire: while accepting the usual teaching variants avec pas, avec un pas and avec un pas de, with or without the trailing colon. Other languages expose one natural step snippet derived from their own grammar. Hover help remains exhaustive: it lists every accepted spelling for the recognized range-loop structure, without duplicating colon/no-colon forms, and contextual connectors such as French de, à, pas and Faire resolve to the range loop rather than to unrelated constructs such as imports.

Logical negation is localized as well. French NON expression has the same truth-value semantics as Python not expression and always returns a boolean. This applies to booleans, numbers, strings, collections and Vide: zero, empty values and Vide are falsey before negation; non-empty/non-zero values are truthy.

Exclusive OR is also localized. French accepts OUEX and Ou Exclusif, Spanish accepts OEX and O Exclusivo, and every language keeps universal XOR as a compatibility alias. The shared snippet catalogue contains one localized XOR expression template in every language.

Repeat loops

Repeat a fixed number of times:

Répéter 5 fois:
    Afficher "Bonjour"
Fin

All 14 bundled languages accept the infinitive and the natural second-person imperative for action verbs whenever those forms are distinct, not only for repeat. For example, French accepts Afficher / Affiche, Lire / Lis, Retourner / Retourne, Importer / Importe and Répéter / Répète; Spanish accepts Importar / Importa; German accepts Importieren / Importiere and natural multi-word imperatives such as Ausgeben / Gib aus. Languages where both grammatical forms have the same spelling naturally expose only that spelling. Localized collection methods follow the same principle where a verb has distinct forms.

becomes:

for _ in range(5):
    print("Bonjour")

Post-test repeat-until loop:

n = 0
Répéter:
    n = n + 1
Jusqu'à ce que n >= 5

Jusqu'à n >= 5 is equivalent. In French, the formatter (pseudo format, VS Code / Thonny format command) now chooses this shorter Jusqu'à ... spelling as the canonical output while continuing to accept Jusqu'à ce que .... The Jusqu'à ... line closes the post-test loop, so no Fin follows it.

becomes:

n = 0
while True:
    n = n + 1
    if n >= 5:
        break

The body therefore executes at least once.

Fast direct execution

pseudo file.pseudo still transpiles to Python, but the CLI executes the generated Python inside its own short-lived process instead of starting a second Python interpreter. Language definitions and compiled grammar templates are cached per process, and the C-backed safe YAML loader is used when available. These changes reduce startup overhead substantially for the tiny programs used in introductory teaching while keeping Python strictly as the execution backend.

Run, check, transpile and format

Run directly:

pseudo programme.pseudo

Check syntax:

pseudo check programme.pseudo

Transpile pseudocode → Python:

pseudo transpile programme.pseudo -o programme.py
pseudo transpile -i programme.pseudo -o programme.py
pseudo transpile -input programme.pseudo -output programme.py

Transpile Python → pseudocode:

pseudo transpile programme.py -o programme.pseudo --lang fr
pseudo transpile -i programme.py -o programme.pseudo --lang fr
pseudo transpile -input programme.py -output programme.pseudo --lang fr

The direction is inferred from .pseudo/.algo versus .py. Unsupported Python statements fail explicitly rather than being approximated silently. Inclusive bounded loops prefer ordinary Python range(...) whenever the direction is statically known. For example, French Pour i de 1 à 5 Faire: transpiles to for i in range(1, 6):; a small compatibility helper is retained only for genuinely dynamic ranges whose direction cannot be known statically without changing semantics.

Canonical formatting in place:

pseudo format programme.pseudo
pseudo format programme.pseudo --check

Flowchart / algorigram export and rendering

Flowcharts are generated from one editor-neutral core model and can be rendered by Mermaid or Graphviz. Input/output uses parallelograms, ordinary operations use rectangles and decisions use diamonds. Si / Sinon Si diamonds show the tested expression as a question (for example x > 5 ?). Loop layout is pedagogical and shared by every renderer: a range Pour stays at source level as localized Pour … decision → vertical body → exterior return to the decision, without synthetic initialization/update boxes; the return edge alone carries the implicit counter update as a parenthesized reminder such as (i = i + 1) or (i = i + pas). Tant que, Pour … Dans, counted Répéter … fois and Répéter … Jusqu'à do not invent such an increment annotation.

The renderer-specific geometry also stays in the core. Mermaid emits one coordinated ELK profile with stable semantic node/edge identifiers and loop-body layout hints; Mermaid/ELK remains free to make some routing choices of its own. Graphviz is the deterministic renderer: the core emits fixed-position DOT for neato -n2 / nop2, with loop-back routing on the WEST/left side, natural exits on the EAST/right side and ordinary continuation to the SOUTH. VS Code, Thonny, MkDocs, CLI/LSP consumers and future editor adapters therefore receive the same semantics and routing policy instead of recreating geometry locally. Shared Light/Dark palettes are provided for both engines. Ordinary conditional branch lanes expand when labels require more room, preventing pinned Graphviz nodes from touching while preserving fixed geometry.

Flowchart text size is also a shared core presentation contract. Rich frontends expose the renderer-neutral sizes 10, 11, 12, 13, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 36, 40, with 16 as the UI default. Mermaid receives that logical value as pixels; Graphviz converts it to a visually matched point size (16 → 14 pt) and recomputes text-aware branch spacing. A cached FlowchartSnapshot can therefore be serialized again at another text size without reparsing the source or rebuilding the semantic graph.

Export either source representation:

pseudo flowchart programme.pseudo -o programme.mmd --engine mermaid
pseudo flowchart programme.pseudo -o programme.dot --engine graphviz

Render either engine directly to SVG or PNG:

pseudo render programme.pseudo -o programme-mermaid.svg --engine mermaid --theme light
pseudo render programme.pseudo -o programme-mermaid.png --engine mermaid --theme dark
pseudo render programme.pseudo -o programme-graphviz.svg --engine graphviz --theme light
pseudo render programme.pseudo -o programme-graphviz.png --engine graphviz --theme dark

pseudo svg remains an SVG-only alias. Rendering is designed for one-package installation: users do not install Mermaid, Node.js, Chromium or Graphviz separately. Mermaid is rendered in-process by the browserless Python package mermaidx; Graphviz is rendered through PyGraphviz 2.x, whose binary wheels bundle the Graphviz libraries and command-line tools on the supported mainstream platforms. Both imports are lazy, so parsing, linting, formatting and ordinary execution do not load either graphics engine. Graphviz still uses neato -n2 internally so the fixed positions owned by the core are preserved. Both engines use a transparent background by default and the shared light / dark palettes.

Developers can deliberately replace either embedded renderer without changing normal user installation. PSEUDOCODE_I18N_MERMAID_EXECUTABLE=/path/to/mmdc selects an external Mermaid CLI, while PSEUDOCODE_I18N_GRAPHVIZ_EXECUTABLE=/path/to/neato selects an external Graphviz executable. The equivalent Python render configuration keys are mermaid_executable (legacy aliases mermaid_cli / mmdc) and graphviz_executable (legacy aliases graphviz / neato). Explicit overrides take precedence; otherwise the embedded engines are always used.

Tutor executions can also be exported as an animated GIF with either engine:

pseudo tutor-gif programme.pseudo -o programme-mermaid.gif --engine mermaid --theme light
pseudo tutor-gif programme.pseudo -o programme-graphviz.gif --engine graphviz --theme light

Frames are emitted only for meaningful node/edge activation changes. The diagram geometry is rendered once per visited scope/format and subsequent frames only activate stable node/edge IDs, so step-by-step export does not recalculate the layout at every execution step. Frontends that already own a pseudocode-tutor/v2 model can reuse it with --model-json so the program is not traced again.

The MkDocs documentation includes a quick visual comparison with tabs for Pseudocode / Mermaid / Graphviz in Mermaid et Graphviz.

Python API

Automatic language resolution is the default:

from pseudocode_i18n import (
    SUPPORTED_EXTENSIONS, detect_language, format_pseudocode, parse,
    render_graphviz, render_mermaid, resolve_snippets, snippets_for_language,
    to_graphviz, to_mermaid, transpile, transpile_python,
)

source = '''
Si x > 0 Alors:
    Afficher x
Fin
'''

detection = detect_language(source)
tree = parse(source)
python_source = transpile(source)
canonical_source = format_pseudocode(source)
mermaid = to_mermaid(source)
graphviz = to_graphviz(source)
pseudo_again = transpile_python(python_source, language="fr")
render_mermaid(mermaid, "programme-mermaid.svg")
render_graphviz(graphviz, "programme-graphviz.svg")

assert SUPPORTED_EXTENSIONS == (".pseudo", ".algo")
french_snippets = snippets_for_language("fr")
resolved_snippets = resolve_snippets(source, fallback="fr")

Force a language when needed:

python_source = transpile(source, language="fr")

detect_language() returns the selected ISO 639-1 code together with confidence/scores through a LanguageDetection object. snippets_for_language() exposes the canonical localized editor/LSP snippets, while resolve_snippets() applies the same language precedence as normal source processing.

Project configuration and custom synonyms

Canonical project file:

pseudocode.config.yml

Example:

language: auto
fallback_language: fr
index_base: 0

format:
  colons: true
  indent: 4
  end_markers: true

render:
  browser: auto
  background: transparent
  mermaid_cli: auto

languages:
  fr:
    keywords:
      display:
        add:
          - Montrer

lang: is a supported alias for the project-level language: key. The canonical spelling in documentation remains language::

lang: es
fallback_language: fr

This makes Montrer an additional French display synonym without modifying the parser.

Bundled language data live in:

pseudocode_i18n/languages/fr.yml
pseudocode_i18n/languages/es.yml
pseudocode_i18n/languages/it.yml
pseudocode_i18n/languages/pt.yml
pseudocode_i18n/languages/de.yml
pseudocode_i18n/languages/nl.yml
pseudocode_i18n/languages/da.yml
pseudocode_i18n/languages/sv.yml
pseudocode_i18n/languages/no.yml
pseudocode_i18n/languages/fi.yml
pseudocode_i18n/languages/el.yml
pseudocode_i18n/languages/uk.yml
pseudocode_i18n/languages/ru.yml
pseudocode_i18n/languages/en.yml

They define vocabulary, patterns, end forms, type names, method/function aliases and flowchart labels. This is the preferred place for language-specific evolution.

Human-facing IDE documentation is deliberately just as simple and lives one file per language in pseudocode_i18n/documentation/ (fr.yml, es.yml, …, en.yml). Each stable entry contains directly editable title, description and examples; accepted syntax and aliases stay generated from the language grammar so the documentation cannot drift from what the parser actually accepts. This directory is the single source used by Thonny at runtime and by the VS Code generator. See pseudocode_i18n/documentation/README.md for the tiny editing contract.

Add another language

Languages use ISO 639-1 two-letter codes.

For example:

yarn generate nl

creates a Dutch language scaffold containing the full vocabulary, diagnostics, editor text and Usage-documentation contract, then regenerates documentation. Fill the translations and choose language.order, then run the same command again to validate/regenerate it. No parser, linter, lexer, MkDocs or VS Code source registry needs to be edited.

Development

Bootstrap:

corepack enable
yarn setup

Run tests:

yarn test

Run the documentation locally:

yarn dev

LAN/mobile documentation server:

yarn dev:lan

Full validation before committing/releasing:

yarn bfc

yarn bfc synchronizes the project version from package.json, validates version consistency, lints, runs tests, regenerates/checks/builds the documentation, and builds the Python package.

Version source of truth

package.json is the single source of truth for the project version.

yarn version:sync

synchronizes derived Python metadata and the version displayed in this README. MkDocs narrative pages can use:

__PSEUDOCODE_I18N_VERSION__

and site/hooks/version.py replaces that placeholder from package.json during the documentation build.

Documentation policy

Documentation is part of every change. Grammar, CLI, configuration, formatting, transpilation, flowcharts, language data, highlighting vocabulary and development workflow changes must update their corresponding documentation in the same revision.

The MkDocs home page is generated from this README, so the repository landing page and documentation landing page cannot silently drift apart.

License

GNU General Public License version 3 or later (GPL-3.0-or-later). See LICENSE.

AUTRES PROJETS de ce développeur

The Pseudocode ecosystem is split into small reusable projects so that each integration can share the same grammar instead of reimplementing it:

• pygments-lexer-pseudocode-i18n — Pygments lexer using the common multilingual semantic vocabulary and Python-like token categories.
• mkdocs-pseudocode-i18n — MkDocs integration for pseudocode in teaching/documentation sites.
• vscode-pseudocode-i18n — editor integration for .pseudo/.algo files, formatting and language-aware authoring.

The core project is pseudocode-i18n and its documentation is published at rod2ik.gitlab.io/pseudocode-i18n.