Digital Product Passport w wielu językach — jak zarządzać tłumaczeniami danych produktu?

Stan produktu: macierz języków, automatyczne wykrywanie nieaktualnych tłumaczeń i wielojęzyczny workflow publikacji opisane w tym artykule są kierunkiem rozwoju DPP Compliance. Nie są obecnie oferowane jako aktywna funkcja samoobsługowa. Dostępny Data Mapper ocenia dane produktu, a publikacja tworzy wersje paszportu; nie należy utożsamiać tych funkcji z kontrolą tłumaczeń.

Digital Product Passport (DPP) dla kilku rynków wymaga więcej niż przetłumaczenia strony z kodem QR. Trzeba wiedzieć, które dane produktu są aktualne w danym języku, kto zatwierdził tłumaczenie i czy odpowiada ono bieżącej wersji źródła. Inaczej polski DPP może zawierać nową instrukcję naprawy, a niemiecki — poprzednią, choć obie strony wyświetlają się poprawnie.

Najkrótsza zasada operacyjna brzmi: każde tłumaczenie powinno wskazywać konkretną rewizję wartości źródłowej. Zmiana tej rewizji uruchamia ponowny przegląd zależnych wersji językowych przed kolejną publikacją.

Czy DPP musi być dostępny we wszystkich językach UE?

Nie ma jednej zasady, że każdy paszport każdego produktu trzeba opublikować w 24 językach. Art. 9 ESPR ustanawia ramy DPP i wymaga, by jego dane były dokładne, kompletne oraz aktualne. Szczegółowy zakres informacji określają właściwe akty dla grup produktowych. Wymagania językowe trzeba sprawdzać dla konkretnego produktu, rodzaju informacji i państwa, w którym produkt jest udostępniany.

Przykłady pokazują, dlaczego jeden globalny przełącznik PL/EN nie wystarczy:

To są różne obowiązki. Język deklaracji, instrukcji bezpieczeństwa i całego paszportu może być regulowany odmiennie. Profil produktu i rynku powinien wskazywać podstawę dla każdej wymaganej wersji językowej; nie powinien zgadywać jej z adresu IP odwiedzającego.

Dlaczego status „przetłumaczone” jest niewystarczający?

Wyobraźmy sobie trzy instrukcje w DPP dla tego samego produktu:

Instrukcja naprawy — źródło v8
PL: zatwierdzone na podstawie v8
DE: zatwierdzone kiedyś na podstawie v7
FR: draft na podstawie v8, czeka na review

Wersja DE istnieje, lecz po zmianie źródła wymaga ponownej weryfikacji. FR jest świeża względem źródła, lecz nie ma decyzji o zatwierdzeniu. Żadnej z tych sytuacji nie oddaje samo translated = true.

Praktyczny status pola powinien rozróżniać co najmniej: Missing, Draft, In review, Approved i Needs review — source changed. Warto też zapisać metodę powstania tłumaczenia: ręcznie, przez import lub maszynowo. Tłumaczenie maszynowe może być propozycją, ale samo jego wygenerowanie nie jest zatwierdzeniem treści ani oceną prawną.

Locale Coverage Matrix: widok wszystkich wymaganych języków

Macierz łączy pole, wersję źródła i języki wymagane przez wybrany profil produktu oraz rynku. Przykład modelu operacyjnego:

Wynik można pokazać obok gotowości danych produktu, ale nie łączyć tych miar w jeden pozornie precyzyjny procent:

Gotowość danych produktu: 94% — według profilu Furniture v3
Pokrycie językowe: PL 100% · DE 82% · FR 61%
DE: 4 wymagane pola tekstowe do ponownego review

Liczby w przykładzie są ilustracyjne. Rzeczywisty mianownik pokrycia powinien obejmować tylko pola wymagające lokalizacji w danym profilu. Identyfikator produktu, jednostka miary i typowana wartość liczbowa pozostają jednym faktem kanonicznym; lokalizuje się sposób ich pokazania lub instrukcję, nie tworzy trzech konkurencyjnych źródeł prawdy.

Co zrobić po zmianie tekstu źródłowego?

Bezpieczny przepływ wygląda tak:

1. Zapisz nową rewizję wartości źródłowej, np. repair_instruction v7 → v8, z autorem i czasem zmiany.
2. Znajdź tłumaczenia oparte na v7. Oznacz je jako wymagające review; zachowaj poprzednie approval w historii.
3. Pokaż tłumaczowi i reviewerowi diff oraz kontekst produktu, rynku i dokumentów powiązanych z instrukcją.
4. Utwórz nowe rewizje tłumaczeń. Zatwierdzenie powinno wskazywać osobę, czas, źródłową rewizję oraz dokładną zatwierdzoną treść.
5. Przed publikacją sprawdź wszystkie języki i pola wymagane przez wybraną wersję profilu. Brak albo nieaktualna wersja nie powinny cicho przejść jako „gotowe”.
6. Opublikuj nową, niezmienną wersję DPP i zachowaj związek między paszportem, źródłem oraz wersjami językowymi.

Zmiana danych źródłowych nie powinna automatycznie przepisywać już opublikowanego paszportu. Historyczna wersja pozostaje śladem tego, co udostępniono w danym momencie. Jeżeli zmiana jest istotna dla prawdziwości bieżącego publicznego DPP, organizacja musi ocenić potrzebę korekty i opublikować nową wersję. Zobacz proces korekty błędu po publikacji DPP.

Data Mapper: „brak danych” a „brak języka”

Te problemy wymagają innych działań:

• Missing data — organizacja nie ma wartości źródłowej lub dowodu dla wymaganej informacji.
• Locale gap — wartość źródłowa istnieje, ale wymaganej wersji językowej nie ma, jest nieaktualna albo nie została zatwierdzona.

Przy pierwszym problemie trzeba pozyskać albo poprawić dane od właściciela produktu czy dostawcy. Przy drugim potrzebny jest proces tłumaczenia i review. Zespół powinien widzieć ownera, termin i wpływ na planowaną publikację dla konkretnego rynku. Sama kompletność wartości źródłowych nie oznacza gotowości każdego wariantu językowego do publikacji.

Czy można automatycznie wyświetlić wersję angielską zamiast niemieckiej?

Techniczny fallback może być przydatny w interfejsie, ale nie wolno przedstawiać go jako zatwierdzonego tłumaczenia DE. Jeżeli właściwy profil wymaga niemieckiej treści, zastąpienie jej angielską stroną bez ostrzeżenia nie zamyka luki językowej. Podobnie Accept-Language, ustawienie przeglądarki lub lokalizacja IP nie dowodzą, jakie języki są wymagane dla produktu na danym rynku.

Warto rozdzielić requested locale, served locale i required locale. Publiczny widok powinien jasno pokazywać faktycznie wyświetlany język. Dane wewnętrzne lub dostępne wyłącznie organom nie mogą stać się publiczne tylko dlatego, że powstała ich wersja językowa.

Jak zacząć bez pełnego systemu tłumaczeń?

Na pilotażu wystarczy jeden model produktu i dwa rynki. Zespół może przygotować prostą tabelę:

Pole → wersja źródła → rynek → wymagany język
→ właściciel tłumaczenia → reviewer → status → wersja DPP

Najpierw sprawdź podstawę prawną i zakres informacji dla wybranej grupy produktu. Następnie przetestuj zmianę jednej instrukcji po opublikowaniu pierwszej wersji paszportu: czy da się wskazać wszystkie języki wymagające ponownego review, a jednocześnie odtworzyć historyczną treść? To lepsze kryterium wyboru narzędzia niż sama liczba języków na przełączniku.

Zobacz, jak planować źródła danych, role i publikację w usłudze wdrożeniowej DPP.

Najczęstsze pytania

Czy przetłumaczenie interfejsu DPP oznacza przetłumaczenie paszportu?

Nie. Etykiety przycisków, nazwy pól, instrukcje i dokumenty produktu mają różne źródła i statusy. Pokrycie językowe trzeba oceniać dla danych wymaganych w konkretnym DPP, nie tylko dla interfejsu strony.

Czy tłumaczenie maszynowe wystarczy do publikacji?

Zależy od rodzaju treści i polityki review. Wygenerowany tekst powinien zachować metodę, wersję źródła i status. Jeżeli wymagane jest zatwierdzenie, wynik maszynowy pozostaje draftem do oceny człowieka.

Czy zmiana instrukcji źródłowej unieważnia wszystkie historyczne DPP?

Nie. Historyczne wersje pozostają niezmiennym zapisem wcześniejszej publikacji. Zmiana może jednak oznaczać, że bieżący wariant językowy wymaga korekty i nowej wersji przed dalszym udostępnianiem lub kolejną publikacją.

Czy DPP Compliance już pokazuje Locale Coverage Matrix?

Nie. Jest to opis planowanego kierunku produktu. Obecne funkcje katalogu, Data Mappera i publikacji nie są równoznaczne z kontrolą aktualności tłumaczeń per język.