Implementing Dynamic Translation
Three ways to structure automatic, language-based DPP content.
Want your Digital Product Passports to speak every customer’s language, automatically? Let’s talk dynamic translation. 🧠
Dynamic translation means your DPP content adapts based on the device language of the viewer. No manual switching.
Why Use Dynamic Translation?
- Save time, translate once, use everywhere
- Avoid creating multiple versions of the same DPP
- Enhance global accessibility for your customers
- Keep things clean and centralized
💡 Works great when you manage many templates or multilingual markets.
Three Methods to Structure Dynamic Translation
Here are the different ways you can structure your translations, each with different flexibility and complexity.
1. Map for Each Key (Preferred for Structured Templates)
Each text field in your DPP has its own language map, like this in the JSON content of the Tridy for an API interface:
{
"product_description": {
"en": "T-shirt made from recycled cotton",
"de": "T-Shirt aus recycelter Baumwolle",
"fr": "T-shirt en coton recyclé"
}
}
Effect: ✅ Each field can be translated individually ✅ Easy to update one key without affecting others ✅ Best control and scalability 🔁 Most flexible for future edits
Recommended if you want granular control over each field’s translation.
2. Map for Each Language
You create a map per language, like this in the JSON content of the Tridy for an API interface:
{
"en": {
"product_description": "T-shirt made from recycled cotton",
"material": "100% cotton"
},
"de": {
"product_description": "T-Shirt aus recycelter Baumwolle",
"material": "100% Baumwolle"
}
}
Effect: ✅ All translations for a specific language are grouped together 🛠️ Better for translators who work language by language ⚠️ Can become messy if you have lots of keys or inconsistent key naming
Use this when your translation process is handled language-by-language with external tools or translation agencies.
3. Suffix for Language (Quick and Dirty)
Each translation is stored in a separate key, like in the JSON content of the Tridy for an API interface:
{
"product_description_en": "T-shirt made from recycled cotton",
"product_description_de": "T-Shirt aus recycelter Baumwolle"
}
Effect: ✅ Simple to implement 🚨 Not scalable 🚫 No fallback or structure 😬 High risk of inconsistencies and duplication
Use this method only for quick prototypes or very small-scale projects.
How It Works in the App
When a user opens the Reader app:
- The app detects the phone’s language setting (e.g.,
de-DE) - It checks for a matching translation in the DPP
- If found → show the translated content 🎉
If not → show fallback (default) language
Fallback Logic: No German? No problem, show English instead (or whatever you set as your default).
Summary: What to Choose?
And that’s it! With dynamic translation, your DPP becomes as multilingual as your customer base, no extra templates needed. 🌐💬
Need help structuring your keys? Just ask, we're happy to support you in building your first translation map.