A Digital Product Passport has to remain accessible for the life of the product, in every market where that product is sold. That single requirement makes multilingual handling a structural part of the data model, not a translation task bolted on after publication. Teams that treat it as the latter end up with products that look ready in one locale and visibly incomplete in the next. This guide covers what actually needs translating, what must never be translated, and how a resolvable identifier makes locale routing possible without duplicating records.
Not every field is translatable, and treating them the same is the first mistake
The most common failure is applying one translation workflow to every field in the record. Identifiers, controlled values and technical measurements behave completely differently from consumer-facing explanatory text, and mixing them up creates either broken data (a translated GTIN) or missing content (an untranslated safety instruction).
| Field type | Should it be translated? | How to handle it |
|---|---|---|
| Product identifiers (GTIN, unique ID) | No | Same value everywhere; never translated |
| Units and measurements | No, but the displayed unit convention can vary | Store in one base unit, format for display per locale |
| Material and substance names | Controlled list, translated labels only | One code, many display labels; never free-translate a controlled term |
| Care and safety instructions | Yes | Full translation, reviewed per market, not machine-only for safety-critical text |
| Marketing or descriptive copy | Yes | Translated and often locally adapted, not just literally translated |
| Certificates and evidence documents | Sometimes | The evidence itself may stay in its original language; a summary may need translation |
How a resolvable identifier routes to the right locale
A single physical data carrier, such as a QR code, is printed once and cannot change per market. What can change is what the code resolves to. A GS1 Digital Link (ISO/IEC 18975) expresses the product identifier as a web address; the resolver behind that address can serve locale-specific content based on the scanning device’s language settings, an explicit language selector, or the market it detects, all without printing a different code per country. This is the same resolver pattern used for the passport’s data carrier generally; see how QR code, Data Matrix, NFC and RFID compare for the underlying carrier choice.
Six questions to ask before building a multilingual passport model
- Which markets does this product actually reach? Build for the languages you need, not every EU language by default, which wastes translation budget on markets you may not sell into.
- What is the master language and record? One language should be the source of truth; every other locale is a translation of it, not an independently maintained copy.
- What happens when a locale’s translation is missing? Define an explicit, policy-compliant fallback (typically the master language) rather than showing a blank field silently.
- Who approves a translation before it is published? Machine translation may be acceptable for some fields and unacceptable for safety-critical instructions; decide this per field type, not once for the whole record.
- How is completeness measured per locale? A product should not be marked publishable in one market while a required field is empty in another.
- How are updates propagated? When the master record changes, every locale needs a defined process to catch up, with visibility into which locales are behind.
Common mistakes that compound over time
- Managing translations outside the product record, in spreadsheets or a separate CMS, which drifts out of sync with the source data.
- No distinction between master truth and local adaptation, so a local team’s wording change silently becomes the new source of truth.
- Translation workflows disconnected from the readiness workflow, so a product can reach “approved” status with incomplete locale content.
- No locale-level completeness visibility, so gaps are discovered by a customer or auditor in the target market, not by the internal team.
- Local teams editing structured fields informally, which breaks the controlled-value discipline the rest of the model depends on.
A practical starting model
- Separate translatable from non-translatable fields in the schema itself, using the domain structure from the DPP data model guide .
- Define per-locale completeness thresholds so publishability is measured market by market, not once for the whole product.
- Route through a resolvable identifier so one physical code serves every locale, as covered in the carrier comparison guide .
- Assign translation ownership explicitly, distinct from the field owner, so both roles are accountable for their part of the record.
For the wider programme sequence, including where multilingual readiness fits relative to supplier evidence and publishing, see the 30-step ESPR compliance roadmap and the Digital Product Passport guide .
Frequently asked questions
Which Digital Product Passport fields should not be translated?
Product identifiers, units of measurement, and the underlying codes behind controlled values such as material or substance names should stay identical across locales. Only their display labels are translated.
How does one QR code serve multiple languages?
A resolvable identifier such as a GS1 Digital Link (ISO/IEC 18975) expresses the product identifier as a web address. The resolver behind that address serves locale-specific content based on device language, a selector, or detected market, without changing the printed code.
What is the biggest multilingual mistake teams make?
Treating every field as equally translatable, or managing translations outside the governed product record, which causes drift between the master data and what is actually published in each locale.
How should missing translations be handled?
Define an explicit, policy-compliant fallback, typically the master language, rather than showing a blank or silently mismatched field. The fallback should be visible and logged, not hidden.
Should completeness be measured once or per locale?
Per locale. A product can be complete in its master language and still fail required fields in another market, so publishability should be assessed market by market.
Can machine translation be used for Digital Product Passport content?
It may be acceptable for lower-risk descriptive fields but is generally not appropriate for safety-critical instructions, which should go through a reviewed, approved translation process.
