Hallo, hier istKototsuki Design.
Wir haben beschlossen, unsere Website, die ursprünglich ausschließlich auf Japanisch betrieben wurde, nun auch auf Englisch und Deutsch anzubieten. Anfangs dachte ich, das wäre eine ziemlich einfache Angelegenheit. Ich dachte, es würde ausreichen, die japanischen Texte ins Englische und Deutsche zu übersetzen und eine Sprachauswahl einzubauen. Ich dachte, das wäre schon alles.
Als ich jedoch tatsächlich damit anfing, stellte sich heraus, dass es gar nicht so einfach war. URL-Struktur, Verwaltung der Übersetzungsdaten, automatische Übersetzung, falsche Übersetzungen von Eigennamen, API-Ratenbegrenzungen, Schriftarten, Google Analytics, Cookie-Einwilligung, GeoIP, DSGVO, gesetzliche Anforderungen für Deutschland. Bevor ich mich versah, ging es nicht mehr nur darum, eine Übersetzungsfunktion hinzuzufügen, sondern die gesamte Struktur der Website zu überarbeiten.
Heute fasse ich zusammen, was ich bei der praktischen Umsetzung der Unterstützung für die drei Sprachen JA/EN/DE getan habe und welche Punkte mir dabei besonders schwerfielen.
Zunächst: Eine ursprünglich auf Japanisch ausgelegte Website mehrsprachig machen
Die ursprüngliche Website war natürlich ausschließlich für Japanisch konzipiert. Um nun Englisch und Deutsch hinzuzufügen, haben wir zunächst die Architektur der Website selbst von einer „japanischen Website“ zu einer „mehrsprachigen Website“ umgestellt.
Bei der URL-Struktur haben wir uns nicht für das Pfadpräfix-Verfahren (kototsuki.com/en/のような形), sondern für das Subdomain-Verfahren entschieden.Dabei bleibt die japanische Sprache auf der bestehenden Domain, während Englisch und Deutsch über Subdomains getrennt werden. Auf den ersten Blick mag dies wie eine kleine Änderung erscheinen, doch in der Praxis müssen Informationen wie „Welche Sprache ist gerade aktiv?“ und „Wo befinden sich die Seiten in anderen Sprachen?“ nun auf der gesamten Website verwaltet werden. Das bedeutet, dass es nicht damit getan ist, die Anzahl der Zeichenfolgen einfach zu verdreifachen.
Wie werden die Übersetzungen verwaltet?
Als nächstes stellte sich das Problem der Übersetzungen selbst. Es wäre zwar möglich, alle englischen und deutschen Seiten manuell zu erstellen, doch angesichts der stetig wachsenden Anzahl von Inhalten wie Blogbeiträgen und Fallbeispielen wäre es ziemlich aufwendig, diese jedes Mal in allen drei Sprachen manuell zu aktualisieren. Daher haben wir ein System entwickelt, das mithilfe der DeepL-API die automatische Übersetzung bereits beim Erstellen der Seiten durchführt.
Zu den zu übersetzenden Elementen gehören UI-Texte, statische Seiten, Fallbeispiele, Blogbeiträge und Ähnliches. Damit werden die erforderlichen Übersetzungen nun automatisch generiert, sobald Inhalte auf der Website hinzugefügt oder geändert werden.
Jedes Mal alles zu übersetzen, wäre eine Verschwendung der API-Ressourcen
Hier gab es noch ein weiteres Problem: Würden wir bei jedem Build den gesamten Inhalt an DeepL senden, würden jedes Mal auch Artikel übersetzt, die gar nicht geändert wurden. Deshalb haben wir ein System entwickelt, bei dem der Hashwert des Originaltextes gespeichert und mit dem Hashwert des letzten Builds verglichen wird – nur bei Abweichungen erfolgt eine Neuübersetzung.
Es handelt sich um eine einfache Verzweigung: Ist der Hash identisch, wird nicht übersetzt; ist er unterschiedlich, erfolgt eine Neuübersetzung mit DeepL. Selbst wenn in einem Blogbeitrag nur ein einziges Zeichen geändert wird, wird nur dieser Beitrag neu übersetzt, wodurch wir die unnötige Nutzung der API erheblich reduzieren konnten.
Umgang mit dem DeepL-Fehler 429
Als die Anzahl der zu übersetzenden Artikel zunahm, stießen wir an die Ratenbegrenzung der DeepL-API. Der Fehler „HTTP 429“, also „Too Many Requests“. Wir haben drei Maßnahmen eingeführt: Wiederholungsversuche, exponentielles Backoff und das Zwischenspeichern bereits übersetzter Daten. Besonders wirksam war dabei das „Zwischenspeichern“.
Anfangs war das System so ausgelegt, dass der Cache nur dann geschrieben wurde, wenn der Übersetzungsprozess erfolgreich bis zum Ende abgeschlossen wurde. Das führte dazu, dass, wenn beim 80. Eintrag ein 429-Fehler auftrat und der Build fehlschlug, auch die Ergebnisse der bis dahin übersetzten 80 Einträge verloren gingen. Beim nächsten Build musste man dann wieder von vorne anfangen. Deshalbtry/finallyhaben wir die Struktur so geändert, dass die bis zu diesem Zeitpunkt übersetzten Daten im Cache gespeichert werden, selbst wenn zwischendurch ein Fehler auftritt. Dabei wurde mir bewusst, dass man bei der Automatisierung nicht nur den Fall eines erfolgreichen Ablaufs berücksichtigen muss, sondern auch, was übrig bleibt, wenn der Vorgang vorzeitig abbricht.
Maschinelle Übersetzung verzerrt Eigennamen
Mit der Einführung der automatischen Übersetzung tauchte ein weiteres Problem auf. Der Eigenname „Kototsuki Design“ auf der Website wurde von DeepL in „Lake and Moon Design“ übersetzt. Als englischer Satz klingt das zwar natürlich, aber da es sich um einen Eigennamen handelt, ist dies problematisch.
Daher habe ich eine Funktion hinzugefügt, mit der Eigennamen von der Übersetzung durch DeepL ausgeschlossen werden können.
Was ich daraus gelernt habe: Selbst bei der Verwendung von maschineller Übersetzung muss nicht alles „vollständig automatisch“ ablaufen. Normale Texte überlässt man der Maschine, während Eigennamen und wichtige Ausdrücke vom Menschen kontrolliert werden. Ein solches System ist letztendlich einfacher zu handhaben.
Und nun zum Bereinigen früherer Fehlübersetzungen
Nachdem ich diesen Mechanismus implementiert hatte, tauchte ein weiteres Problem auf. Im Übersetzungs-Cache waren noch Daten aus früheren Builds vorhanden, die bereits falsch übersetzt worden waren. Es handelte sich um 52 Einträge.Letztendlich haben wir die fehlerhaften Einträge im Cache aufgespürt und gelöscht und die Texte nach den korrekten Regeln neu übersetzt. Automatisch generierte Daten werden nicht automatisch vollständig korrigiert, nur weil der Code geändert wurde. Wenn bereits generierte Cache-Einträge oder Ergebnisse vorhanden sind, müssen diese ebenfalls in die Migration einbezogen werden.
Nach der Übersetzung kam es zu Darstellungsfehlern in der Benutzeroberfläche
Als die Übersetzung endlich reibungslos funktionierte, traten nun Probleme mit der Bildschirmdarstellung auf. Dies betraf insbesondere die deutsche Sprache. Im Vergleich zum Japanischen sind deutsche Sätze oft länger, sodass die Titel der Einträge in der Breadcrumb-Navigation zu lang wurden und das Layout durcheinandergeriet. Daher haben wir die Anzeige auf 32 Zeichen begrenzt und den vollständigen Titel in der HTML-Eigenschafttitle-Attribut zu belassen.
Diese Erfahrung hat mir erneut vor Augen geführt, dass es bei der Mehrsprachigkeit nicht darum geht, „Zeichenfolgen zu übersetzen“, sondern darum, „sicherzustellen, dass die Benutzeroberfläche auch mit den übersetzten Zeichenfolgen noch einwandfrei funktioniert“.
Und nun zum eigentlichen Thema: Mit der Einführung der deutschen Version kamen die DSGVO und deutsche Gesetze ins Spiel
An dieser Stelle wechselt das Thema ein wenig. Durch das Hinzufügen der deutschen Version ist die Wahrscheinlichkeit, dass Besucher aus dem EU-Raum, insbesondere aus Deutschland, auf die Seite zugreifen, realistisch gesehen gestiegen. Es galt nun, nicht nur den Umgang mit Google Analytics und Cookies zu berücksichtigen, sondern auch die gesetzlichen Informationspflichten bei der Bereitstellung digitaler Dienste in Deutschland.
An dieser Stelle war es notwendig, die relevanten Gesetze einmal getrennt zu betrachten.
Auch wenn diese Begriffe oft in einem Atemzug genannt werden, unterscheiden sich ihre Funktionen erheblich. Schauen wir uns nun nacheinander an, worauf sich die einzelnen Begriffe beziehen.
Was ist die DSGVO?
Die DSGVO (Datenschutz-Grundverordnung) ist ein EU-Gesetz, das die Verarbeitung personenbezogener Daten und die Rechte der betroffenen Personen regelt. Im Mittelpunkt stehen dabei externe Dienste wie Google Analytics sowie der Umgang mit Daten, die eine Identifizierung von Personen ermöglichen.
Was ist das TDDDG?
Das TDDDG (Telekommunikation-Digitale-Dienste-Datenschutz-Gesetz) ist ein deutsches Gesetz, das sich mit der Speicherung von und dem Zugriff auf Informationen auf Endgeräten, wie z. B. Cookies, befasst. Es deckt sich zwar mit der DSGVO, konzentriert sich jedoch speziell auf die Bereiche elektronische Kommunikation und Endgerätedaten.
Was ist das DDG?
Das DDG (Digitale-Dienste-Gesetz) ist eine deutsche Regelung, die Anbieter digitaler Dienste zur Bereitstellung von Informationen wie Name und Kontaktdaten verpflichtet. In § 5 des DDG ist festgelegt, dass die für die betreffenden digitalen Dienste relevanten Angaben wie Name, Anschrift und Kontaktdaten leicht erkennbar und direkt zugänglich sein müssen und kontinuierlich bereitgestellt werden müssen.
Der Einfachheit halber wird dies zwar manchmal pauschal als „DSGVO-/DDG-Konformität“ bezeichnet, tatsächlich haben wir die beiden Themen jedoch als separate Aspekte behandelt und nacheinander geprüft.
Die DSGVO-Konformität wird anhand der Frage „Woher kommt der Nutzer?“ beurteilt
Auf Seiten der DSGVO stellten zunächst Google Analytics und Cookies ein Problem dar. Der erste Gedanke war, bei deutschen Seiten ein Cookie-Banner anzuzeigen. Dies hätte jedoch zu einer etwas seltsamen Situation geführt, da man sowohl von Deutschland aus japanische Seiten als auch von Japan aus deutsche Seiten aufrufen kann.
Daher haben wir das Entscheidungskriterium nicht auf die „Sprache der Seite“, sondern auf den „Standort des Besuchers“ vereinheitlicht.if language == "de"Vielmehrif visitor_country == "JP"sondern so. Auf diese Weise können sowohl Besuche von japanischen Seiten aus Deutschland als auch von deutschen Seiten aus Japan nach denselben Kriterien behandelt werden.
Wenn man das grafisch darstellt, wird deutlich, dass es bei einer reinen Sprachauswertung zu Abweichungen kommt: Das Banner erscheint nicht, wenn es notwendig wäre, oder es erscheint, obwohl es nicht benötigt wird. Durch die Ausrichtung am Standort des Besuchers haben wir diese Abweichungen beseitigt.
Um das Land des Besuchers zu ermitteln, nutzen wir den bestehendenprivate-analytics-appServergeoip-liteund/geound einen neuen Endpunkt eingerichtet.geoip-liteDa [Endpunkt] eine lokale Datenbank nutzt, ist keine Abfrage einer externen GeoIP-API erforderlich.
Diese Erkennung wirkt sich nicht nur auf Analytics aus, sondern auch auf Google Fonts, das Kontaktformular und die Anzeige der Datenschutzerklärung. Zusammenfassend sieht das Ganze nun wie folgt aus.
Eine einzige GeoIP-Prüfung führt zu vier völlig unterschiedlichen Implementierungen. Wenn man dies grafisch darstellt, wird deutlich, dass die Auswirkungen weitreichender sind als ursprünglich angenommen. Allerdings handelt es sich hierbei lediglich um das für diese Website gewählte Design. Das bedeutet nicht, dass „Analytics in Japan grundsätzlich ohne Einwilligung genutzt werden darf“; die tatsächlichen Anwendungsbedingungen hängen von den genutzten Diensten, den Verarbeitungsinhalten und der Situation des Betreibers ab.
Überlegungen seitens DDG: Die Website soll nicht wie ein „Dienst für das Ausland“ wirken
Unabhängig von der DSGVO-Konformität mussten wir uns auch Gedanken darüber machen, wie diese Website aus deutscher Sicht wirkt, nachdem wir die deutschsprachige Version veröffentlicht hatten. Der vorliegende Dienst richtet sich an Nutzer in Japan. Wenn wir jedoch die Dienstleistungen in drei Sprachen – Japanisch, Englisch und Deutsch – erläutern und sogar Preispläne präsentieren, könnte der Eindruck entstehen, dass wir unsere Dienste auch für Nutzer im Ausland, insbesondere aus dem EU-Raum, anbieten.
Daher haben wir nicht nur einfach übersetzt, sondern auch die Formulierungen selbst angepasst, um deutlich zu machen, an welche Zielgruppe sich der Dienst richtet. Das bedeutet nicht, dass DDG selbst verlangt hätte: „Bei einer deutschsprachigen Website müssen die Tarife verborgen werden.“ Vielmehr geht es darum, aus Sicht der Webgestaltung den Spielraum so weit wie möglich zu verringern, dass die Website als digitaler Dienst für Deutschland wahrgenommen werden könnte.
Auch bei der Angabe des Einzugsgebiets auf der Startseite haben wir uns nicht vollständig auf die automatische Übersetzung von DeepL verlassen. So wurde beispielsweise der Ausdruck „landesweite Abdeckung“ nicht nur natürlich ins Deutsche übersetzt, sondern manuell so angepasst, dass klar wird, dass sich der Dienst auf Japan bezieht. Zudem haben wir einen Hinweis hinzugefügt, der deutlich macht, dass dieser Dienst für den japanischen Markt bestimmt ist und sich nicht an Kunden im Ausland richtet.Wir haben bei jedem einzelnen Wort darauf geachtet, dass die Lesbarkeit auf Deutsch nicht mit der Ausrichtung auf den deutschen Markt gleichgesetzt wird.
Das Endergebnis
Die endgültige Struktur lässt sich grob wie oben dargestellt zusammenfassen. Was ursprünglich als einfache dreisprachige Website geplant war, umfasst nun mehrsprachige URLs, eine Übersetzungspipeline, einen Übersetzungscache,Differenzerkennung, API-Wiederholungsversuche, die Steuerung von Eigennamen, die Mehrsprachigkeit der Benutzeroberfläche, GeoIP, die Cookie-Einwilligung, die Steuerung von Analytics, selbst gehostete Schriftarten, regional angepasste Inhalte, die differenzierte Darstellung der Datenschutzerklärung sowie die Überarbeitung der Unternehmensinformationen und Dienstleistungsangaben für den deutschen Markt.
Das Schwierigste daran war eigentlich gar nicht die „Übersetzung“
Was mir bei diesem Projekt am deutlichsten bewusst wurde, ist, dass Mehrsprachigkeit nicht einfach nur das Hinzufügen einer Übersetzungsfunktion bedeutet. Anfangs dachte ich, es ginge lediglich darum, Japanisch ins Englische und Deutsche zu übersetzen. Tatsächlich weitete sich der Umfang der Auswirkungen jedoch immer weiter aus.
Besonders in Erinnerung geblieben ist mir, dass die technische Änderung „Hinzufügen einer deutschen Version“ letztendlich zu einer geschäftlichen und rechtlichen Diskussion darüber führte, an welche Zielgruppe sich diese Website eigentlich richtet.
Was ich beim Aufbau einer mehrsprachigen Website gelernt habe
Ich möchte hier einige Lehren zusammenfassen, die ich aus diesem Projekt gezogen habe.
- Von Anfang an N Sprachen vorsehen – statt ja, en und de jeweils separat zu implementieren, sollte das Design von Anfang an so gestaltet sein, dass es N Sprachen unterstützt. So vermeidet man, dass man die Website neu erstellen muss, wenn die Anzahl der Sprachen von drei auf vier oder fünf steigt.
- Maschinelle Übersetzung nicht „vollautomatisch“ gestalten – DeepL ist zwar sehr praktisch, behandelt aber nicht unbedingt auch Eigennamen korrekt. Bei Dienstleistungsnamen, Firmennamen, juristischen Formulierungen sowie Ausdrücken zu Ländern und Regionen war es wichtig, einen Mechanismus beizubehalten, der eine manuelle Kontrolle ermöglicht.
- Die Benutzeroberfläche nach der Übersetzung unbedingt überprüfen – Textzeichenfolgen, die auf Japanisch noch Platz finden, ragen auf Englisch oder Deutsch häufig über den Rand hinaus. Man muss nicht nur prüfen, ob die Übersetzung korrekt ist, sondern auch, ob die Benutzeroberfläche im übersetzten Zustand noch einwandfrei funktioniert.
- Die DSGVO-Konformität nicht anhand der „Sprache der Seite“ beurteilen — Bei dieser Implementierung haben wir uns nicht an der Sprache der Seite orientiert, sondern am Standort der Besucher. Denn es gibt sowohl Nutzer, die eine japanische Seite von Deutschland aus aufrufen, als auch solche, die eine deutsche Seite von Japan aus aufrufen.
- Die DSGVO, TDDDG und DDG nicht in einen Topf werfen – Mit der pauschalen Aussage „Da es sich um eine für Deutschland bestimmte Website handelt, ist sie DSGVO-konform“ lässt sich nicht erkennen, welche Anforderungen tatsächlich erfüllt werden.Schutz personenbezogener Daten, Speicherung auf und Zugriff auf Endgeräte, Informationspflichten des Betreibers. Da es sich jeweils um unterschiedliche Themenbereiche handelt, lässt sich die Umsetzung leichter strukturieren, wenn man getrennt betrachtet, welche Gesetze und welche Anforderungen bei den jeweiligen Maßnahmen berücksichtigt werden.
- Recht und Technik liegen sich überraschend nahe – Letztendlich mussten wir nicht nur darüber nachdenken, in welcher Sprache die Inhalte angezeigt werden, sondern auch, für welche Zielgruppe sich der Dienst richtet. Bei mehrsprachigen Websites sind die technische Umsetzung, die Darstellung auf der Website und die rechtlichen Anforderungen sehr eng miteinander verknüpft.
Häufig gestellte Fragen zur Mehrsprachigkeit und zur DSGVO
F. Ist die Einhaltung der DSGVO zwingend erforderlich, wenn man eine mehrsprachige Website erstellt?
Das Hinzufügen von Sprachen an sich verpflichtet noch nicht zur Einhaltung der DSGVO. Wenn jedoch Sprachen hinzugefügt werden, die im EU-Raum verwendet werden, wie beispielsweise Deutsch oder Französisch, steigt die Wahrscheinlichkeit, dass mehr Besucher aus der EU auf die Website zugreifen. Falls Systeme zum Umgang mit personenbezogenen Daten (wie Analytics oder externe Dienste) zum Einsatz kommen, muss geprüft werden, welche Maßnahmen entsprechend dem Standort der Besucher zu ergreifen sind.
F. Was eignet sich besser für SEO: die Subdomain-Methode oder die Pfadpräfix-Methode?
Beide Methoden haben sich in der Praxis bewährt. Der Unterschied besteht darin, dass es bei Subdomains (en.example.com) einfacher ist, die Serverkonfiguration pro Sprache zu trennen, während sich bei Pfadpräfixen (example.com/en/) die Domain-Bewertung leichter auf eine einzige Domain bündeln lässt.In diesem Fall haben wir uns aus Gründen der Einfachheit der Serverkonfiguration für das Subdomain-Verfahren entschieden.
F. Wie lassen sich die Ratenbeschränkungen der DeepL-API (429-Fehler) umgehen?
Neben Wiederholungsversuchen und exponentiellem Backoff hat sich ein Mechanismus bewährt, bei dem die bis zu diesem Zeitpunkt erzielten Übersetzungsergebnisse im Cache gespeichert werden, selbst wenn der Vorgang vorzeitig fehlschlägt. Je größer das Übersetzungsvolumen einer Website ist, desto sicherer ist es, 429-Fehler von vornherein in das Design einzuplanen.
Frage: Müssen die DSGVO, das DDG und das TDDDG jeweils separat berücksichtigt werden?
Da es sich um unterschiedliche Themen handelt, lassen sich Lücken bei der Umsetzung leichter vermeiden, wenn man den Umgang mit personenbezogenen Daten (DSGVO), den Umgang mit Gerätedaten wie Cookies (TDDDG) und die Pflicht zur Bereitstellung von Unternehmensinformationen (DDG) getrennt betrachtet, anstatt sie zusammen als „eine einzige Maßnahme“ zu betrachten.
Frage: Ich habe Bedenken hinsichtlich der Genauigkeit der Standortbestimmung von Besuchern (GeoIP). Wie wird dies umgesetzt? Wir haben uns
diesmal für ein Design entschieden, bei dem die Verarbeitung je nach Standort differenziert wird, sofern eine Standortbestimmung möglich ist, und bei fehlgeschlagener Standortbestimmung auf Nummer sicher gegangen wird, indem die Zustimmung zu Cookies zwingend vorgeschrieben wird. Der entscheidende Punkt ist, die Architektur so zu gestalten, dass man sich nicht vollständig auf die Genauigkeit der GeoIP-Standortbestimmung verlässt.
Zusammenfassung
Die diesjährige Mehrsprachigkeit war zunächst nur eine kleine Änderung, nämlich das Hinzufügen von Englisch und Deutsch. Tatsächlich wurde dies jedoch zum Anlass, die gesamte Website zu überarbeiten.
Die Übersetzung haben wir mithilfe der DeepL-API automatisiert und so eingerichtet, dass sie in Kombination mit Differenzerkennung, Caching und Wiederholungsversuchen betrieben werden kann. Gleichzeitig war es jedoch notwendig, ein System zu entwickeln, mit dem Eigennamen und wichtige Formulierungen nicht der automatischen Übersetzung überlassen, sondern individuell gesteuert werden können.Ausgehend von der Einführung der deutschen Version haben wir außerdem Maßnahmen zur Cookie-Einwilligung unter Berücksichtigung der DSGVO, zur regionalen Erkennung mittels GeoIP, zur Eigenhosting von Google Fonts sowie zur regionenbezogenen Anzeige von Inhalten umgesetzt. Darüber hinaus mussten wir nicht nur die DSGVO, sondern auch das deutsche Digitaldienstgesetz (DDG) sowie das Teledienstdatenschutzgesetz (TDDDG) in Bezug auf Cookies als separate Themen berücksichtigen.
Im Ergebnis ging es nicht darum, „die Website in drei Sprachen anzubieten“, sondern darum, „die Website so umzugestalten, dass sie in drei Sprachen betrieben werden kann“. Ich hoffe, dass dies für diejenigen, die gerade erst mit der Mehrsprachigkeit beginnen, eine kleine Hilfe sein kann.
Kontaktformular 
Verwandte Artikel 
