[BUG] German-language Claude Code corrupts canonical technical terminology (Gate→Zaun, Policy→Politik, Root→Wurzel), causing semantic and persistent-memory drift

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Claude Code systematically translates, renames, paraphrases, and sometimes invents variants of established technical and architectural terminology when the conversation/output language is German.

This is NOT merely a UI localization issue and NOT merely a matter of translation quality.

It directly changes the semantic identifiers Claude uses to reason about the architecture of a software project.

Observed examples from real long-running Claude Code projects:

• Gate → Zaun ("fence")
• Gates → Zäune ("fences")
• Policy / Policies → Politik ("politics")
• Root → Wurzel ("root" literally translated as the botanical/anatomical German word)
• canonical internal component/process names → newly invented German variants
• previously established architecture labels → inconsistent translated synonyms

The Root case is particularly important because this demonstrates that the problem is broader than obviously absurd translations.

In German technical prose, words such as "Wurzelverzeichnis" may sometimes be linguistically understandable as a translation of "root directory".

That is NOT the issue.

If Root is the canonical name of an architectural component, filesystem concept, process, scope, node, registry entry, or project-defined identifier, then changing Root to Wurzel is semantically destructive even if the translated word could be understood by a human.

The same applies to all canonical project terminology.

A model must distinguish between:

1. ordinary natural-language prose that may be translated
2. technical vocabulary
3. canonical architecture terminology
4. project-defined component names
5. code identifiers
6. filenames and directory names
7. schema/property names
8. process names
9. state names
10. memory keys and persistent concepts

Claude currently fails to preserve this distinction reliably.

The most severe observed examples are:

Gate → Zaun

In an agent architecture, a Gate is a control/validation boundary. A "Zaun" is literally a physical fence. These are not semantically interchangeable concepts.

Policy / Policies → Politik

In a software architecture, a Policy is a rule, policy object, enforcement definition, permission definition, or behavioral contract. "Politik" means politics/political policy in German and completely changes the semantic domain.

Root → Wurzel

In a software architecture, Root may identify a canonical project root, hierarchy root, root node, filesystem root, or explicitly named architecture component. Translating it creates a different identifier and breaks one-to-one terminology mapping.

The core problem is therefore not simply "bad German".

The core problem is:

CANONICAL CONCEPT A
→ Claude translates/renames it
→ Claude now represents it internally/output-wise as CONCEPT NAME B
→ the new name enters documentation, plans, memory, summaries, or agent communication
→ later Claude treats B as an established project concept
→ more aliases and translations are produced
→ the architecture vocabulary diverges from the actual architecture.

This becomes especially destructive during long-running agent work because the mistranslated or newly invented terminology does not remain conversational wording.

Claude can propagate it into:

• project documentation
• architecture documentation
• implementation plans
• task definitions
• persistent memory
• auto-memory
• external project memory files
• process descriptions
• internal labels
• proposed filenames
• directory descriptions
• rule descriptions
• hook feedback
• Sentinel feedback
• summaries
• context-compaction summaries
• subagent prompts
• subagent responses
• subsequent reasoning
• implementation decisions

Once an incorrect translated term enters persistent project state, Claude can retrieve it later as if it were a valid canonical concept.

This creates a self-reinforcing feedback loop:

1. Canonical English technical term exists.
2. Claude translates or renames it while communicating in German.
3. The translation changes the identifier and potentially its meaning.
4. Claude stores/references the translated version.
5. Context is compacted or the session changes.
6. The translated version survives in memory/documentation.
7. Claude retrieves the translated variant.
8. Claude assumes the translated term is legitimate.
9. Claude creates additional synonyms or variations.
10. Project terminology and architectural reasoning drift further away from the source architecture.

This is effectively persistent semantic-memory contamination.

I have extensively attempted to prevent this behavior using:

• CLAUDE.md instructions
• canonical terminology indexes
• terminology registries
• explicit glossaries
• exact-name lists
• blocklists for previously invented names
• memory definitions
• explicit "DO NOT TRANSLATE" rules
• explicit "DO NOT INVENT ALIASES" rules
• Sentinels
• hooks that inject terminology requirements immediately before operations
• filesystem names as canonical identifiers
• process names as canonical identifiers
• repeated corrections during sessions

These mechanisms can reduce individual occurrences but do not reliably solve the problem.

Claude eventually starts translating, paraphrasing, renaming, or inventing terminology again.

The issue becomes dramatically worse when Claude communicates in German while operating on a project whose technical terminology is primarily English.

Equivalent workflows performed entirely in English show substantially less terminology corruption.

This makes German-language operation unreliable for large agentic software projects.

Concrete observed transformations:

• Gate → Zaun
• Gates → Zäune
• Policy / Policies → Politik
• Root → Wurzel

These are not isolated vocabulary problems. The same translation mechanism is dangerous for a large class of overloaded English software-engineering terms.

Representative examples of the same HIGH-RISK failure class (illustrative examples, not all claimed as individually observed):

• Hook → Haken
• Branch → Zweig
• Fork → Gabel
• Socket → Steckdose
• Port → Hafen
• Thread → Faden
• Pipeline → Rohrleitung
• Worker → Arbeiter
• Shell → Schale / Muschel
• Handle → Griff
• Container → Behälter
• Registry → Registrierung
• Controller → Steuerung / Kontrolleur
• Contract → Vertrag
• Sentinel → Wächter
• Validator → Prüfer
• Capability → Fähigkeit
• State → Zustand
• Scope → Bereich
• Artifact → Artefakt

Some of these translations may be linguistically acceptable in ordinary German prose.

That is precisely why this bug is dangerous.

The problem is NOT whether a German translation exists.

The problem is that a canonical identifier MUST NOT be translated at all.

For example, suppose an architecture explicitly defines:

PolicyGate
RootGate
ContractRegistry
CapabilityRegistry
Sentinel
WorkerPool

If Claude internally or externally starts referring to these as:

Politik-Zaun
Wurzel-Zaun
Vertragsregistrierung
Fähigkeitsregistrierung
Wächter
Arbeiter-Pool

then the deterministic one-to-one relationship between project terminology and model terminology has been destroyed.

This can affect reasoning even before it affects code because Claude begins reasoning about the system using vocabulary that is no longer identical to the vocabulary used by the architecture.

In an agentic system, terminology is not decoration.

Terminology is part of the system model.

What Should Happen?

Claude Code must clearly separate the user's conversational language from the project's canonical technical vocabulary.

A user must be able to communicate naturally with Claude in German without Claude translating, renaming, paraphrasing, or redefining the technical architecture of the project.

Expected behavior:

1. Natural-language explanations may be written in German.

1. Canonical technical terminology must remain unchanged.

1. Project-defined terminology must remain unchanged.

1. Architecture component names must remain unchanged.

1. Code identifiers must remain unchanged.

1. Filenames and directory names must remain unchanged.

1. Process names must remain unchanged.

1. State names must remain unchanged.

1. Schema/property names must remain unchanged.

1. Memory keys must remain unchanged.

1. Glossary-defined terminology must remain unchanged.

1. Existing terminology must always take precedence over generated synonyms.

1. Claude must never invent an alternative name for an already-defined canonical concept unless explicitly requested by the user.

1. Memory writes must preserve canonical terminology exactly.

1. Auto-memory must preserve canonical terminology exactly.

1. Context compaction must preserve canonical terminology exactly.

1. Generated summaries must preserve canonical terminology exactly.

1. Subagents must receive and preserve the same canonical terminology.

1. Tool calls involving project-defined identifiers must use the canonical form.

1. If Claude is uncertain whether a word is ordinary natural language or a technical/project identifier, it must preserve the original token.

A localized explanation may be added separately, but it must never replace the canonical token.

Correct:

Das Policy Gate blockiert Änderungen, wenn die Policy-Prüfung fehlschlägt.

Also acceptable:

Das Policy Gate (Prüfstufe für Richtlinien) blockiert Änderungen.

Incorrect:

Der Politik-Zaun blockiert Änderungen.

Correct:

Die Konfiguration wird relativ zum Root aufgelöst.

Also acceptable:

Die Konfiguration wird relativ zum Root (Projektstamm) aufgelöst.

Incorrect:

Die Konfiguration wird relativ zur Wurzel aufgelöst.

when Root is the canonical project identifier.

Claude Code should treat repository-defined terminology as protected semantic symbols rather than ordinary natural-language tokens.

A robust precedence model should be:

canonical repository terminology
>
canonical project glossary
>
existing architecture terminology
>
existing filenames / identifiers
>
generated natural-language vocabulary

The fundamental invariant should be:

USER LANGUAGE MAY CHANGE.
PROJECT SEMANTICS MUST NOT.

Claude should translate explanations, not redefine engineering vocabulary.

Error Messages/Logs

No explicit error, exception, or crash is produced.

This is a behavioral/model correctness failure.

Representative observed transformations:

Gate     → Zaun
Gates    → Zäune
Policy   → Politik
Policies → Politik
Root     → Wurzel

The failure occurs in generated text, reasoning, architecture descriptions, plans, documentation, persistent memory, summaries, and subsequent agent behavior rather than through an application error message.

This makes the issue especially difficult to detect automatically because Claude Code reports successful operation while silently changing the semantic vocabulary of the project.

Steps to Reproduce

1. Create a new Claude Code project.

1. Create a file named ARCHITECTURE.md with the following content:

# Architecture

The following terms are CANONICAL project terminology.

Their exact spelling is part of the architecture.

NEVER translate, rename, paraphrase, localize, or create aliases for them.

Canonical terms:

• Root
• Gate
• Root Gate
• Policy
• Policy Gate
• Sentinel
• Validator
• Contract Registry
• Capability Registry
• Hook
• Worker Pool

Examples:

The Root contains the canonical system state.

The Root Gate validates mutations before they enter the Root.

The Policy Gate evaluates Policies.

The Sentinel observes violations.

The Validator performs deterministic validation.

The Contract Registry stores Contracts.

The Capability Registry stores Capabilities.

Hooks execute at predefined lifecycle points.

Worker Pool is the canonical name of the worker execution component.

1. Create a CLAUDE.md file containing:

Communicate with the user in German.

IMPORTANT:

All technical terminology defined in ARCHITECTURE.md is canonical.

Preserve every canonical term EXACTLY as written.

Never translate canonical terminology.

Never paraphrase canonical terminology.

Never rename canonical terminology.

Never invent synonyms or aliases.

Canonical terminology must remain unchanged in:

• conversation
• reasoning
• documentation
• planning
• memory
• summaries
• subagent communication
• implementation

1. Start Claude Code using German as the conversational language.

1. Ask:

"Analysiere die ARCHITECTURE.md vollständig und erkläre mir auf Deutsch,
wie Root, Root Gate, Policy Gate, Sentinel, Validator,
Contract Registry und Capability Registry zusammenarbeiten.
Verwende dabei zwingend die kanonischen Namen aus der Datei."

1. Continue with:

"Erstelle jetzt einen detaillierten Implementierungsplan für diese
Architektur. Die kanonischen technischen Begriffe dürfen nicht
übersetzt oder umbenannt werden."

1. Ask Claude to update architecture documentation:

"Erweitere ARCHITECTURE.md um eine Beschreibung der Datenflüsse.
Verwende ausschließlich die bereits definierten kanonischen Namen."

1. Ask Claude to create or update persistent memory:

"Speichere die wichtigen Architekturinformationen für zukünftige
Sitzungen. Alle kanonischen technischen Begriffe müssen exakt
erhalten bleiben."

1. Continue working in German for multiple turns.

1. Ask Claude to delegate architecture analysis to one or more subagents,

if subagents are available.

1. Continue until a longer context has accumulated.

1. Where applicable, allow context compaction/summarization to occur.

1. Continue the same architecture task after compaction.

1. Inspect:

• conversational output
• plans
• documentation
• memory
• summaries
• subagent output
• generated internal terminology

1. Observe whether canonical terminology is translated, paraphrased,

renamed, or replaced.

Observed real-world examples include:

Gate → Zaun
Gates → Zäune
Policy → Politik
Policies → Politik
Root → Wurzel

1. Once one incorrect translated term has appeared, continue working

without manually correcting it.

1. Observe whether Claude later reuses the incorrect term or creates

additional variants from it.

1. Repeat the same workflow using English as the conversational language.

1. Compare terminology stability between the German-language and

English-language sessions.

In my real-world testing, German-language operation causes substantially
more terminology translation and alias creation than equivalent
English-language operation.

The problem also persists despite additional safeguards including:

• terminology registries
• explicit glossaries
• canonical-name indexes
• blocklists
• CLAUDE.md rules
• repeated corrections
• Sentinels
• Hooks
• memory rules
• filesystem-derived canonical names

These mechanisms may reduce individual failures but have not reliably
prevented terminology drift during long-running German-language sessions.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

1.26832.0

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

I Use macOS Claude Code Version, Native APP !

This issue has been reproduced repeatedly during real-world long-running Claude Code development rather than only in an artificial single-prompt test.

I have observed the underlying terminology instability across multiple Claude Opus generations, including previous and current Opus versions.

The affected projects use explicitly structured agent architectures with canonical component names, persistent external memory, terminology registries, validation mechanisms, Hooks, and Sentinels.

This makes terminology stability critical.

The most damaging aspect is NOT an isolated mistranslation in conversational output.

The problem is that incorrectly translated, paraphrased, or newly invented terminology can enter persistent artifacts and subsequently influence future model behavior.

Observed examples include:

Gate → Zaun
Gates → Zäune
Policy → Politik
Policies → Politik
Root → Wurzel

Once a translated variant enters:

• persistent memory
• architecture documentation
• implementation plans
• summaries
• context-compaction output
• subagent communication

it can later be retrieved as if it were legitimate project terminology.

This creates a self-reinforcing terminology drift.

I have attempted to mitigate this using multiple independent mechanisms:

• explicit canonical terminology rules
• CLAUDE.md
• terminology indexes
• canonical terminology registries
• explicit glossaries
• forbidden-alias/block lists
• Hooks
• Sentinels
• persistent memory rules
• filesystem-based canonical identifiers
• repeated corrections
• instructions injected close to execution

None of these mechanisms has made terminology preservation reliable over long-running German-language sessions.

The same architecture is substantially more stable when Claude communicates in English.

Public discussion documenting my investigation and observed examples:

https://www.reddit.com/r/Anthropic/comments/1v9loii/annoying_llm_language_for_filenames_and_processes/

Specific discussion/comment:

https://www.reddit.com/r/Anthropic/comments/1v9loii/comment/p0fb03g/

There are also independent reports from other Claude Code users describing Claude inventing its own technical/project jargon and requiring users to repeatedly ask what newly created terminology means:

https://www.reddit.com/r/ClaudeCode/comments/1vcn3yr/claude_code_making_up_its_own_techproject_jargon/

There are existing German-language Claude Code model/core issues, but they describe different failure modes:

German-language model regression / malformed German output:
https://github.com/anthropics/claude-code/issues/21446

German umlaut corruption:
https://github.com/anthropics/claude-code/issues/14131

German typographic quote corruption:
https://github.com/anthropics/claude-code/issues/23208

This report is DISTINCT from those issues.

This issue is specifically about:

CANONICAL TECHNICAL TERMINOLOGY PRESERVATION
+
SEMANTIC DRIFT
+
PERSISTENT MEMORY CONTAMINATION

rather than grammar, Unicode, quotation marks, or general translation quality.

Another relevant observation is that Anthropic's own German Claude Code documentation currently translates the technical concept "root" using "Wurzel" in some places while retaining other technical terms such as Hooks and Skills in English.

Official German Claude Code glossary:
https://code.claude.com/docs/de/glossary

I am NOT claiming that documentation localization itself proves the model bug.

However, it demonstrates that German-language handling currently has no consistently enforced rule that canonical software-engineering terminology should remain untranslated.

This distinction is crucial:

A translation can be linguistically valid and STILL be technically incorrect.

For example:

Root → Wurzel

may be understandable to a German-speaking human in generic prose.

However, if Root is the canonical identifier of an architecture component, hierarchy node, system scope, directory concept, or explicitly named project element, replacing it with Wurzel destroys identifier stability.

The same is true for terms such as:

Gate
Policy
Hook
Branch
Fork
Socket
Thread
Pipeline
Registry
Controller
Contract
Capability
Sentinel
Validator

A canonical technical/project term must be treated as a semantic symbol, not as freely translatable prose.

I believe this therefore requires a terminology-preservation mechanism rather than another prompt-level instruction.

Potential implementation approaches:

1. Treat repository-defined terminology as protected semantic tokens.

1. Provide a project-level canonical terminology registry.

1. Automatically protect identifiers found in:

• filenames
• directory names
• code identifiers
• schemas
• configuration
• architecture documentation
• explicit glossaries

1. Preserve canonical terminology during:

• model generation
• memory writes
• auto-memory
• context compaction
• summaries
• subagent delegation

1. Give canonical repository terminology precedence over natural-language localization.

1. When uncertain whether a token is ordinary prose or a technical concept, preserve the original token.

1. Allow optional localized explanations without replacing the canonical identifier.

For example:

Policy Gate (Prüfstufe für Richtlinien)

is acceptable.

Replacing the canonical identifier with:

Politik-Zaun

is not.

The required invariant is:

USER LANGUAGE MAY CHANGE.
PROJECT SEMANTICS MUST NOT.

For agentic software development, terminology is part of the system architecture and cannot safely be treated as presentation text.