German definitions missing on every entry in the steel DPP closure (schema-repo O10)

[stiebitzhofer]

Observation

The dpp/v0.0.1 steel content specification in material-identity/schema pins 22 entries from release v2026.08.28. None of them carries a German definition, so the German rendering of a passport (renderDppHtml -Plang=de) shows English definitions under German chrome. Labels/definitions are resolved exclusively from the vendored dictionary entries (schema-repo decision D11); dpp/ never authors or edits entries (D10), so this cannot be fixed on the consuming side.

Recorded there as open item O10 (tasks/dpp-v0.0.1-plan.md, docs/design/dpp-assumption-register.md).

Ask

German definitions for the steel set — productTradeName, steelmakingRoute and its three Value entries, carbonContent, mechanicalProperties and children, substancesOfConcern / substanceEntry and children, declarationOfConformity — through the dictionary's normal workflow (new immutable entries with replaces, since published entries are immutable per R6). The consuming side then re-pins in its next content-spec version.

Note the schema repo's standards review found the steel content set itself will change against the JRC steel-DPP content draft (11 of 22 entries gone or deprecated) — worth coordinating so the translations land on the entries that survive.

[stiebitzhofer]

Analysis, and a mechanism question before anything is published

Two corrections to the scope first, from the data:

• The transitive steel closure is 22 entries, and 24 published entries in total carry no German definition (the closure plus maxPressure and carbonContent v1).
• German preferredName already exists on every one of them. Only definition is English-only, so this is a translation job, not a bilingual-authoring job.

The mechanism is not obvious, and one option is a one-way door

The ask here is "new immutable entries with replaces". That works, but it costs more than it looks:

The cascade. Superseding a member without superseding its parent leaves the current collection pointing at superseded children:

substancesOfConcern → substanceEntry → substanceName, casNumber, concentrationRange, location
mechanicalProperties → tensileStrength, yieldStrength, elongationAtFracture
steelmakingRoute → BF-BOF, EAF, OHF

So it is not 22 supersessions but the whole closure, minted children-first, and the consuming spec re-pins all of it.

And it contradicts the versioning test. A new URI is issued on material semantic change — definition, data type, unit. A translation changes no meaning. Minting here sets the precedent that every additional language re-mints the closure: with 24 EU languages that is arithmetic nobody wants.

Editing the published files in place is the other tempting answer, and it does not work — not for doctrinal reasons but for mechanical ones:

1. Entries are served Cache-Control: public, max-age=31536000, immutable. Anyone who has fetched an entry keeps those bytes for a year and will not revalidate: the edit would be real in the repo and invisible in production, for up to twelve months, with no way to tell who sees which.
2. verifyDppDictionary in the consuming repo treats a changed entry as a failure (unreachable is only a warning). A translation added in place is, from that side, indistinguishable from tampering — it would fire the one alarm that is supposed to mean something.
3. Check 1 fails any M under published/, so the PR cannot merge without disabling the check that carries R6.
4. It contradicts the definition of done: "no process exists by which the JSON response can ever change."

Proposed resolution

If a translation is too small to justify a new id, and immutability forbids changing the old one, then it does not belong in the immutable representation at all — it belongs on a mutable, short-cache surface, exactly like the index, /feed.xml and /superseded.json:

• translations/<uuid>.yaml tracked in the repo → one derived /translations.json, plus the German merged into the HTML pages and into /dictionary.ttl as skos:definition …@de.
• Identifiers minted: 0. Cost per additional language: 0 new identifiers.
• The consuming side vendors one more file instead of re-pinning 22.
• Framing: this is remediation for the backlog. New entries still carry German at birth, which REVIEW.md §2 already requires.

The translations themselves are drafted and ready either way

All 24 are written and reviewed against REVIEW.md §2 (Fachbegriff over calque; standard terminology from the German editions — Zugversuch, Streckgrenze, Bruchdehnung; legal wording from the German text of Regulation (EU) 2024/1781). Samples:

entry	German definition
tensileStrength	Höchste technische Spannung, die ein Werkstoff im Zugversuch erträgt, berechnet aus der erreichten Höchstkraft und dem ursprünglichen Querschnitt.
yieldStrength	Technische Spannung, bei der ein Werkstoff beginnt, sich plastisch zu verformen — die obere oder untere Streckgrenze bei Werkstoffen mit ausgeprägter Streckgrenze, andernfalls die 0,2-%-Dehngrenze.
substanceEntry	Eine gemeldete Angabe zu einem besorgniserregenden Stoff: seine Identität, sein Konzentrationsbereich und sein Ort im Produkt.
declarationOfConformity	Dokument, mit dem der Hersteller die Konformität mit den anwendbaren Rechtsvorschriften der Union erklärt.

They need a native technical review before publication whichever mechanism wins — that is Yes #2, and it is the part no tooling can do.