can I use one QR code to display different language versions of the passport

What you must concretely do

What is expected of you

One data carrier, one underlying passport per product

Article 11 of the ESPR (Regulation (EU) 2024/1781) is based on one data carrier per product that provides access to the digital product passport of that product. The data carrier itself — the QR code — does not point to language versions as separate passports, but to one passport that can be displayed in different languages based on the data behind it. For a manufacturer or importer of aluminium profiles or castings this means in practice: there is not a separate QR code on the product for each language, nor a separate unique identification code per language version. There is one identification code, one data carrier, and the language choice is in the layer behind it — comparable to how a website with a language selector works, not how a product label with separate translations works.

The language choice is in the platform, not in the code

What exactly is meant by "offering in multiple languages" is not detailed in Article 11 itself; the article governs the technical requirements for the design and operation of the passport in general terms, not the way a language selector should work. For a company with 10 to 100 employees that supplies aluminium semi-finished products to customers in multiple countries, this means that the choice for a language selector, automatic language detection based on the reader's location, or a fixed sequence of languages, is a configuration choice of the platform that hosts the passport — not a choice that must be set separately per product on the data carrier itself.

The unique identification code remains unchanged, regardless of language

Article 12 of the ESPR governs the unique identification code that is linked to the product. This code identifies the product, not the language version of the passport. For the practice of a foundry or profile manufacturer this means that one batch of aluminium, with one identification code, can simply be accessed in the underlying data in Dutch, German, French or English without the code itself changing per language. Anyone who works with GS1 Digital Link recognises this principle: the link identifies the product, and the server that answers the link determines which content — and in which language — is displayed.

The label follows its own rules, separate from the passport

Articles 16 and 17 of the ESPR concern labels and the prevention of counterfeit labels. This is a separate component from the digital product passport itself: the label is the visible, physical marking on or attached to the product, whereas the passport is the underlying data made digitally accessible. For a company that exports aluminium profiles to multiple language regions, this means that the language of a label (insofar as applicable) is a different matter from the language in which the passport is displayed via the QR code. The two are independent of each other and each deserves its own attention during implementation.

Where things go wrong in practice

A manufacturer has a separate QR code printed for each export country, each time with a different identification code for what is actually the same product. This results in multiple passports for one batch of aluminium, whereas article 12 assumes one code per product.

Another company assumes that the language selection is automatically correct at the moment of scanning, without having set up a language selector or language detection on the platform. The visitor then always sees the language in which the data was originally entered, even if that is not the language of the recipient.

An exporter translates the content of the passport, but forgets that some fields — such as technical designations of an aluminium alloy or a batch number — should not actually be translated, and should remain consistent across all language versions. Inconsistency in this regard raises questions for a recipient who compares two language versions side by side.

A company thinks that a translated PDF offered alongside the passport is the same as a language version of the passport itself, whereas it is a separate document that does not update when the passport data changes later.

An importer makes the translation of the passport dependent on a separate, external translation agency without agreement on updates. When the passport is amended after publication — see also how data changes after publication works — the translation does not keep pace and a discrepancy arises between the language versions.

What you can document now

• Which languages the passport supports, and who within the company is responsible for keeping each language version current.
• The agreement that one identification code and one data carrier exist per product, regardless of the number of languages — see also the explanation on how the QR code ends up on the aluminium.
• Which fields are translated and which fields (such as alloy designations, batch or lot numbers) must remain identical in all language versions.
• The way in which language selection is technically determined: language selector, location detection, or a fixed default language with choice option.
• A fixed procedure for implementing changes in all language versions simultaneously, so that no language version lags behind after a data update.
• Whether and how the passport is accessible without internet connection in the user's language — relevant to the question whether offline access to the passport is necessary for certain customers or usage environments.
• The link between the source language file in the ERP or inventory system and the published language versions, especially when the passport is linked to its own system.