Two adopted regulations require a passport to be available in the language or languages a Member State requires. The passport model has no language dimension.
The requirement
Toy Safety Regulation (EU) 2025/2509, Art. 19(2)(e) — the passport shall:
"be available in the language or languages required by the Member State where the toy is made available on the market"
Detergents Regulation (EU) 2026/405, Art. 21(2)(e) — near-identical, for detergents and end-user surfactants.
Both sit in the "shall" list alongside accuracy, completeness and the ten-year availability period.
Current state
Searched dpp-core and dpp-engine: no language tag on any passport field, no locale dimension in any schema, and no Accept-Language handling on any serving path. The only language-adjacent code is XML lang attribute parsing in the trusted-list reader, which is unrelated.
Why it is not a rendering concern
The obvious response is "that is a UI problem". It is not, for two reasons.
1. The mandated content includes operator-authored prose. Toys Annex VI Part II covers "safety information and warnings" and "instructions of use"; detergents Annex VI Part B covers the Art. 17(3)–(4) labelling information. These are values, not labels — a translation layer over field names does not produce them. And the same applies to several Part I items: the "statement indicating that the digital product passport is issued under the sole responsibility of the manufacturer" is a sentence, in a language.
2. A multilingual label vocabulary is a different thing. CIR (EU) 2026/1778 Art. 12(2)(e) requires the semantic repository to publish "multilingual labels and definitions for all mandatory data attributes". That solves attribute names. It says nothing about attribute values, which is what these two articles are about.
🚨 The hard part
"The Member State where the toy is made available on the market" is plural and runtime-determined.
- One passport model sold in three Member States owes three language sets, not one.
- The passport does not know where a scan came from, and under toys Art. 20(4) / detergents Art. 22(d) it may not ask — consumers must not be required to register or provide a password to access it. So there is no identity to key a locale on.
Accept-Language is a browser preference, not a market. It is the obvious signal and it answers a different question.
So the design space is roughly:
- Carry all required languages in the passport and let the client pick. Honest, self-contained, survives the back-up requirement, and grows the payload by a multiple.
- Carry one language per passport instance and mint a passport per market. Clean payloads; multiplies passports for one product model, which fights the "corresponds to a specific model" requirement (toys Art. 19(2)(a), detergents Art. 21(2)(a)) and the one-passport-many-instruments principle the manifests already record.
- Carry a language-tagged map only on the fields that need it, and leave structured data monolingual. Smallest change, and it needs a rule for which fields those are — which the annexes largely give.
My reading is that (3) is right and (1) is the fallback, but this should be decided rather than defaulted.
Timing
Detergents binds 23 September 2029, toys 1 August 2030. Nothing is due.
Filed now for the same reason as the image question: it changes the shape of a persisted, signed structure, and shape changes are free only while nothing depends on them. A language-tagged value is not something that can be retrofitted onto signed passports without a version break.
Two adopted regulations require a passport to be available in the language or languages a Member State requires. The passport model has no language dimension.
The requirement
Toy Safety Regulation (EU) 2025/2509, Art. 19(2)(e) — the passport shall:
Detergents Regulation (EU) 2026/405, Art. 21(2)(e) — near-identical, for detergents and end-user surfactants.
Both sit in the "shall" list alongside accuracy, completeness and the ten-year availability period.
Current state
Searched
dpp-coreanddpp-engine: no language tag on any passport field, no locale dimension in any schema, and noAccept-Languagehandling on any serving path. The only language-adjacent code is XMLlangattribute parsing in the trusted-list reader, which is unrelated.Why it is not a rendering concern
The obvious response is "that is a UI problem". It is not, for two reasons.
1. The mandated content includes operator-authored prose. Toys Annex VI Part II covers "safety information and warnings" and "instructions of use"; detergents Annex VI Part B covers the Art. 17(3)–(4) labelling information. These are values, not labels — a translation layer over field names does not produce them. And the same applies to several Part I items: the "statement indicating that the digital product passport is issued under the sole responsibility of the manufacturer" is a sentence, in a language.
2. A multilingual label vocabulary is a different thing. CIR (EU) 2026/1778 Art. 12(2)(e) requires the semantic repository to publish "multilingual labels and definitions for all mandatory data attributes". That solves attribute names. It says nothing about attribute values, which is what these two articles are about.
🚨 The hard part
"The Member State where the toy is made available on the market" is plural and runtime-determined.
Accept-Languageis a browser preference, not a market. It is the obvious signal and it answers a different question.So the design space is roughly:
My reading is that (3) is right and (1) is the fallback, but this should be decided rather than defaulted.
Timing
Detergents binds 23 September 2029, toys 1 August 2030. Nothing is due.
Filed now for the same reason as the image question: it changes the shape of a persisted, signed structure, and shape changes are free only while nothing depends on them. A language-tagged value is not something that can be retrofitted onto signed passports without a version break.