Maschinelle Übersetzung ist heute so gut, dass man sie in vielen Fällen nicht mehr von menschlicher unterscheidet. Übersetzungsdienste arbeiten fliessend, idiomatisch, mit Gefühl für Register. Dann übersetzt man einen DPP-Datensatz - und plötzlich wird aus «rear lock fiber closure» «Hinterschloss-Faserverschluss».
Das Problem heisst Fachterminologie. Hier erklären wir, warum Produktdaten nicht wie Romane zu behandeln sind und welche Werkzeuge Transpareo bereitstellt, damit Ihre 39 Sprachversionen verständlich bleiben.
Das Grundproblem: ein Wort, mehrere Bedeutungen
«Seal» im DPP einer Outdoor-Jacke: Abdichtung. «Seal» in einem Labor: Robbe oder Dichtung, je nach Kontext. «Seal» in einem Wartungsprotokoll: unter Umständen ein Siegel.
Ein allgemeines Übersetzungsmodell wählt anhand des statistischen Kontextes. Bei einem fliessenden Text funktioniert das - der Roman liefert reichlich Kontext. Bei einem Datenfeld primary_closure: seal gibt es kaum Kontext. Das Modell rät.
Die Folge sind subtile Fehler. Nicht so dramatisch wie «Hinterschloss-Faserverschluss», aber folgenreich: eine Komponente, die im Deutschen «Dichtung» genannt wird, heisst in einem italienischen DPP plötzlich «sigillo» statt «guarnizione». Ein Einkäufer findet das Ersatzteil nicht mehr.
Was Transpareo heute leistet
Unser Übersetzungssystem überträgt jeden neuen Inhalt automatisch in alle aktiven Sprachen. Vier Eigenschaften prägen es:
-
Markdown- und Variablen-Erhalt: Platzhalter wie
<a href="/de/registrieren">Pro-Mitgliedschaft</a>und Markdown-Strukturen werden vor der Übersetzung extrahiert, der reine Text wird übersetzt, anschliessend werden die Strukturen unverändert wieder eingesetzt. So bleiben Links, Formulare und Layout konsistent über alle Sprachen hinweg. - Zentrale Übersetzungs-Einträge: Übersetzungen werden nicht im Datensatz selbst gespeichert, sondern in einer geteilten Schicht. Mehrere Datensätze mit gleichem Originaltext teilen sich eine Übersetzung. Das spart Übersetzungskosten und vereinheitlicht Begriffe automatisch über das Datenmodell hinweg.
- Automatische Neu-Übersetzung bei Änderung: Wird der Originaltext geändert, werden die Übersetzungen in allen Sprachen neu erzeugt. Eine Korrektur auf Deutsch - 38 andere Sprachversionen folgen automatisch.
- Markierungen pro Datensatz: Inhalte können vom automatischen Lauf ausgenommen oder bestehende Übersetzungen festgeschrieben werden - etwa für internationale Produktnamen oder manuelle Korrekturen.
Wo der Kunde die Verarbeitung ergänzt
Die automatische Übersetzung liefert grösstenteils richtige Ergebnisse für Beschreibungstexte, Marketingtexte und Pflegeanweisungen. Bei kritischer Fachterminologie - dem «seal»/«guarnizione» - bleibt eine Restmenge an Fehlern, die der Admin des Kunden korrigieren muss.
Hier hat der Admin drei Hebel:
- Manuelle Überschreibung pro Sprache und Schlüssel: Jeder Übersetzungs-Eintrag kann im Applikations-Manager geöffnet und je Sprache angepasst werden. Mit der Festhalten-Markierung bleibt diese manuelle Übersetzung beim nächsten automatischen Lauf erhalten.
- Glossar-Import: Bestehende Terminologien aus Übersetzer-Werkzeugen oder PDF-Glossaren lassen sich als CSV einspielen und erzeugen direkt geschriebene Übersetzungs-Einträge.
- Per-Sprache-Korrekturen im laufenden Betrieb: Ein italienischer Vertrieb merkt einen Fehler, korrigiert ihn im Applikations-Manager - die Korrektur ist sofort wirksam, die übrigen Übersetzungen bleiben unangetastet.
Die EU-Sprachen-Realität
24 EU-Amtssprachen klingt viel. In der Praxis sind es drei Schichten:
- Kernmärkte: DE, EN, FR, IT, ES, NL - hier erwartet jeder Konsument Perfektion
- Bedeutende Märkte: PT, PL, SV, DA, FI - gutes Niveau, gelegentlich merkt man die Maschine
- Seltene Sprachen: MT, GA, ET, LV, LT - manchmal hat man einen DPP in maltesischer Sprache, ohne dass je ein Endkonsument in Malta scannt. Trotzdem Pflicht.
Die Pflicht ist nicht optional. Die ESPR fordert DPP-Inhalte in der Sprache des Mitgliedstaates, in dem das Produkt verkauft wird. Wer 27 Staaten bedient, hat also 24 Sprachen im Spiel (manche teilen Sprachen).
Warum eine zentralisierte Lokalisierungs-Schicht
Die meisten Plattformen speichern Übersetzungen als zusätzliche Felder am Datensatz: description_de, description_en, … 39 Felder pro übersetzbarem Attribut. Klingt einfach, hat aber drei Nachteile:
- Doppelt gehaltener Text. Zwei Produkte mit gleichem Material-Hinweis erzeugen 39 + 39 Übersetzungen statt einmal 39
- Schwer skalierbar. Eine 40. Sprache hinzuzufügen heisst: Schema-Migration über alle übersetzbaren Modelle hinweg
- Korrekturen schwer global anwendbar. Wird «guarnizione» überall korrigiert, müssten alle Datensätze einzeln bearbeitet werden
Die geteilte Übersetzungs-Schicht löst das: ein Eintrag, viele Referenzen. Eine Korrektur, alle Datensätze profitieren.
Was wir noch nicht haben
Eine kundenspezifische Terminologie-Datenbank mit automatischer Vorschlagserkennung steht in der Entwicklungsplanung, ist heute aber nicht ausgeliefert. Wer heute startet, kommt mit den vorhandenen Werkzeugen weit: manuelle Überschreibungen, Glossar-Importe und die Festhalten-Markierung decken die häufigsten Anwendungsfälle ab.
Wir glauben, dass Maschinen den Grossteil der Arbeit erledigen sollten und Menschen nur dort eingreifen, wo es wirklich nötig ist. Bis die automatische Terminologie-Erkennung verfügbar ist, ist der manuelle Hebel transparent - und das ist ehrlicher als ein Versprechen, das nicht eingelöst wird.