A standard for reading and writing code in any language.

Scope

What the standard specifies.

NADA is a localization standard for source code, not a programming language and not a tool. It describes the behavior a conforming tool must implement so that the same source reads the same way everywhere.

The localization model

The file is canonical. The view is translated.

The bytes on disk stay in canonical English. The editor renders the programming language’s own vocabulary — keywords and standard library — in the reader’s language, and the identifiers and string contents the author wrote are left exactly as written. The view is faithful and reversible: it round-trips to the same source, byte for byte.

def greet(name):
    if name:
        return f"Hello, {name}"

परिभाषा greet(name):
    अगर name:
        वापसी f"Hello, {name}"

The dataset

The brain: how every term is written, in every language.

The localized view is produced from a compiled dataset — the brain — that records, for each term in a programming language’s vocabulary, how it is written in each human language. The standard defines the dataset’s shape and the contract a conforming tool reads it through. It does not bless any one vendor’s copy: the structure is the standard, the data is open.

The body of mappings is large and is maintained openly under the foundation’s licensing: language data is CC-BY; the pipeline that builds and checks it is AGPL. Exact coverage and counts live in the registry.

The authority cascade

One term, one rendering, resolved in a fixed order.

When more than one mapping could apply to a term, the standard resolves it by a defined order of authority — the cascade. Resolution is deterministic: the same source resolves to the same rendering in every conforming tool, regardless of vendor.

1. 1

   The programming language

   A term is resolved within the vocabulary of the programming language the file is written in. Cross-language collisions never decide the outcome.

2. 2

   The human language

   Within that vocabulary, the mapping for the reader’s chosen human language is selected. The author’s own identifiers and strings are out of scope and pass through untouched.

3. 3

   The authoritative mapping

   Where a curated mapping exists for that term and language, it wins. [TO CONFIRM: the precise tier names and any project- or workspace-level overrides above the curated default.]

4. 4

   Canonical fallback

   If no mapping resolves, the term is shown in its canonical English form. A reader is never shown a guess, and the view never drifts from the source.

Versioning

Stable to read against, honest about change.

The specification and the dataset are versioned independently, and a conforming tool declares which version of each it implements. The rule that governs change is simple: a localized view of an unchanged file must stay reversible and deterministic across versions.

Core principles

Four rules the standard never bends.

• Neutrality.

  The standard prescribes behavior, not a vendor. No human language is privileged over another, and no single company can bend the resolution rules toward its own product. The cascade is the same for everyone.

• The file is canonical.

  The source on disk is the program. NADA never rewrites it. A localized view is exactly that — a view — so a file written by one person opens, runs, and diffs identically for the next, in any language and in none.

• Reversibility.

  Every projection is lossless and round-trips. What you read in your language maps back to the canonical term with no ambiguity and no residue. Turn the view off and the original English source is byte-for-byte what it always was.

• Color is content.

  Following the design system: the world’s scripts carry the meaning, and a script rendered in ink is content, not decoration. Emphasis is a word set in italic or bold, never a hue. The standard inherits this rigor.