must I offer the product passport in multiple languages

What you must concretely do

What is expected of you

The ESPR regulation stipulates that the digital product passport must contain certain data and be accessible via a carrier technology such as a QR code (Article 10, Regulation (EU) 2024/1781). Article 10 itself says little that is concrete about the language in which this data must be presented: the precise language arrangement is worked out per product group in the delegated acts established per sub-category. For electronics and ICT equipment, that act does not yet exist. What a company is practically expected to do in terms of language therefore depends on the way in which the rest of the information requirements are met (Articles 5 to 7, Regulation (EU) 2024/1781).

Accessibility of data for the user

The underlying idea of the passport is that a consumer, a repair technician or a recycler can understand and use the data. For a company with 10 to 100 employees, this practically means that the content of the passport does not automatically match the language of the country in which the manufacturer or importer is established, but rather the market in which the product is sold. For those placing equipment on the market in more than one EU country, it should be borne in mind that the information now being collected—such as data that comes back when which data goes into the digital product passport for electronics —may need to be made available in more than one language version once the delegated act for this product group has been adopted.

Consistency between language versions

Where multiple language versions of the same data exist, the practical task arises of keeping those versions aligned. A passport that displays a different repairability score in one language than in another, or that mentions an update commitment in the Dutch version but omits it in the German version, is a quality issue that is separate from the question of whether languages are mandatory. Companies that already work with translated user manuals or energy labels will recognise this challenge: the source document must be correct once, and translations must be derived from it, not developed separately.

Coherence with the rest of the product information

The choice of language does not stand alone. It touches on virtually every part of the passport that must already be filled in substantively, from energy consumption to the presence of critical raw materials. For a mid-sized company, this means that the language question is answered in practice at the moment the product data is compiled: is the source data, the measurement method or the material information recorded in such a way that it can be presented in another language without factual errors? This is linked to the question according to which method must I measure the values for the passport, because a numerical value is easier to translate than a descriptive text about use or maintenance.

Where things go wrong in practice

A couple of situations that come up regularly with digital product information, and that are connected to the language issue:

• Translation happens afterwards, separate from the source document. A marketing department or local distributor translates the product page without access to the original technical substantiation, resulting in minor discrepancies between language versions.
• Automatic translation without review. Machine translation of technical terms — repair codes, material names, component designations — sometimes produces text that is grammatically correct but substantively unclear or incorrect.
• One language version is updated, the other is not. When an update is made to energy consumption or software support, the Dutch text is amended, but the French or German version lags behind. This directly raises the question how often must I update the data in the product passportas an obligation to update applies in principle to all available language versions simultaneously, not just one.
• Unclear which language version is authoritative in a dispute. When a repairer or supervisor finds a discrepancy between the Dutch and English text, the question arises which version is considered the original and which the translation — a question that becomes relevant in I found an error in the product passport what now.
• Product-category-specific fields are not translated consistently. Because the exact content of the passport differs per product category, as seen in which data must I fill in exactly for my type of devicea generic translation approach sometimes leads to omission of fields that are mandatory for that specific category.

What you can document

• An internal source document per product in which the core data are recorded once and in the language originally used, as the basis for every translation.
• An overview of the language versions offered for a product, linked to the countries in which it is marketed.
• A procedure for maintaining translations with every change to the underlying data, so that an update in the source language automatically triggers a review point for the other language versions.
• A documented agreement on who is responsible for the accuracy of each language version: the manufacturer, the importer, or a local party.
• A log of translation reviews, with the date and name of the reviewer, so that if a discrepancy is found, it can be shown when which version was reviewed.
• Documentation of the translation method used (professional translator, internal staff, automated translation with post-editing), so that the procedure followed is demonstrable.

As long as the delegated act for electronics and ICT equipment has not yet been published, the precise language obligation remains undefined. Documenting a source document and a translation process is work that is useful anyway, because it aligns with the general obligation to keep the passport data current and consistent — with or without a separate language rule.